portaldacalheta.pt
  • Κύριος
  • Κατανεμημένες Ομάδες
  • Τροποσ Ζωησ
  • Αλλα
  • Κερδοφορία & Αποδοτικότητα
Τεχνολογία

Εκτίμηση κόστους λογισμικού στη διαχείριση έργων Agile



Εισαγωγή

Ένα από τα πιο δύσκολα πράγματα που πρέπει να κάνετε στην ανάπτυξη λογισμικού είναι να προσδιορίσετε πόσο καιρό και πόσο θα χρειαστεί για την παράδοση ενός νέου προϊόντος λογισμικού. Πρέπει να είναι τόσο δύσκολο; Η απάντηση δεν είναι απλή.

Η εκτίμηση του κόστους λογισμικού είναι εγγενώς δύσκολη και οι άνθρωποι είναι εξαιρετικά κακοί στην πρόβλεψη των απόλυτων αποτελεσμάτων. Δεν υπάρχουν δύο έργα τα ίδια. το καθένα είναι μοναδικό σε αυτό που θέλει να επιτύχει και μοναδικό στις μυριάδες παραμέτρους που σχηματίζουν την ύπαρξή του. Συχνά, αυτό που φαίνεται να είναι ένα απλό πρόβλημα στην επιφάνεια είναι πολύ πιο δύσκολο ή τεχνικά δύσκολο να εφαρμοστεί στην πραγματικότητα. Και, αναμφίβολα, θα υπάρξουν «άγνωστα» με το έργο που μπορούν να εντοπιστούν μόνο όταν προκύψουν.



Επιπλέον, κανένα άτομο δεν είναι το ίδιο, είτε είστε πελάτης, προγραμματιστής είτε χρήστης. Έχουμε προφορτωμένο με το δικό μας σύνολο γνώσεων, εμπειριών, αξιών, προσδοκιών, στάσης απέναντι στον κίνδυνο και ικανότητας προσαρμογής.



Η σύνταξη λογισμικού καλής ποιότητας είναι ψωμί και βούτυρο για ανώτερους μηχανικούς. Η δημιουργία καταπληκτικών προϊόντων λογισμικού μπορεί να είναι πολύ πιο δύσκολη για όλους τους εμπλεκόμενους.



Η παροχή φοβερού λογισμικού είναι ένας νόμος εξισορρόπησης

Η παροχή φοβερού λογισμικού είναι ένας νόμος εξισορρόπησης Τιτίβισμα

Όμως, όσον αφορά το λογισμικό, η κατανόηση της διάρκειας και του κόστους είναι καθοριστικής σημασίας για τη λήψη στρατηγικών επιχειρηματικών αποφάσεων και αυτό ισχύει εάν δημιουργείτε μια εκκίνηση, πραγματοποιείτε μια νέα επιχειρηματική ευκαιρία ή επιτρέπετε στην επιχείρησή σας να αποδίδει καλύτερα. Ο συγχρονισμός, η απόδοση της επένδυσης και το όφελος που παραδίδονται μπορούν να κάνουν, να ταρακουνήσει ή να διαλύσει την επιχείρησή σας. Θα αναρωτιέστε: Τι παίρνουμε για τα χρήματά μας; Μπορούμε να προβλέψουμε το κόστος μας; Τι θα κοστίσει για τη δημιουργία του προϊόντος που θέλουμε; Πότε μπορούμε να ξεκινήσουμε; Θα αποκτήσουμε ποιοτικό προϊόν για την επένδυσή μας; Θα αναπτυχθεί με την επιχείρησή μας; Θα προσφέρει επιχειρηματική αξία;



Λοιπόν, πώς θα εκτιμήσετε το μέγεθος, τη διάρκεια και το κόστος ενός έργου; Ας διερευνήσουμε την εκτίμηση του έργου Agile και το κόστος ανάπτυξης λογισμικού και πώς το κάνουμε στο ApeeScape.

Παραδοσιακή τιμολόγηση και εκτίμηση συμβολαίου

Παραδοσιακά, χρησιμοποιώντας μη ευέλικτες πρακτικές, τα προγράμματα λογισμικού έχουν επιδιώξει να διορθώσουν τη λειτουργικότητα ή το εύρος και να αφήσουν το χρόνο και το κόστος να είναι μια μεταβλητή. Αυτό προκαλεί προβλήματα:



  1. Πώς γνωρίζετε ότι η λειτουργικότητα που διορθώνετε στην αρχή ενός έργου είναι πραγματικά η λειτουργικότητα που εξυπηρετεί καλύτερα την επιχείρηση ή τους πελάτες σας; Τις περισσότερες φορές, η λειτουργικότητα ή το εύρος θα αλλάξουν, γι 'αυτό και ακούμε για το «ερπυσμό του πεδίου», το αποτέλεσμα των επιθυμητών αναγκών προσδιορίζονται μέσω του κύκλου ζωής ενός έργου και προσδιορίζονται ως απαραίτητα ή υποχρεωτικά

  2. Όταν το κόστος μεταβληθεί χάνουμε τον έλεγχο της απόδοσης επένδυσης (ROI) που επιδιώκουμε να επιτύχουμε. Το αυξημένο κόστος είναι συχνά προϊόν μη αναγνωρισμένων κινδύνων ή αλλαγών απαιτήσεων, πράγμα που σημαίνει ότι πρέπει να προσθέσουμε μέλη της ομάδας για να κάνουμε περισσότερη δουλειά στο ίδιο χρονικό πλαίσιο ή να διατηρήσουμε τα μέλη της ομάδας περισσότερο. Ούτε είναι επιθυμητό



  3. Όταν ο χρόνος είναι μεταβλητή, χάνουμε τον έλεγχο της θέσης στην αγορά μας. Ίσως χάνουμε μια σημαντική ημερομηνία στον κλάδο ή οι ανταγωνιστές μας βγάζουν το προϊόν τους μπροστά μας, χάνοντας έτσι οποιοδήποτε ανταγωνιστικό πλεονέκτημα που μπορεί να είχε το έργο μας.

Υπάρχουν πολλά άλλα αποτελέσματα μεταβλητού χρόνου και κόστους, τα οποία είναι συχνά αρνητικά και ανεπιθύμητα.



Φυσικά, πολλοί πελάτες και οργανισμοί επιδιώκουν να διορθώσουν και τα τρία στοιχεία αυτού του «μαγικού τριγώνου». Δυστυχώς, είναι σχεδόν αδύνατο να επιτευχθεί ρεαλιστικά. Υπάρχουν πάρα πολλά στοιχεία που συνωμοτούν για να ξεπεράσουν αυτό το ιδανικό, το οποίο τελικά καταλήγει σε προϊόντα που δεν ικανοποιούν μια ανάγκη, χρειάζονται πολύ χρόνο για να ωφελήσουν τους πελάτες της ή να κοστίσουν πάρα πολύ για να πραγματοποιήσουν την επιχειρηματική αξία.

Η εκτίμηση κόστους λογισμικού Agile κερδίζει κάθε φορά



Agile Συμβάσεις για Έργα Λογισμικού

Το κόστος είναι προϊόν χρόνου και ανθρώπων (μέλη της ομάδας). Προσθέστε περισσότερο χρόνο και προσθέτετε κόστος για την απασχόληση ατόμων για μεγαλύτερο χρονικό διάστημα. Προσθέστε περισσότερα μέλη της ομάδας και αυξάνετε το κόστος για να αποδώσετε την ίδια επιχειρηματική αξία. Τα πράγματα που πραγματικά θέλουμε να αποφύγουμε. Αυτός είναι ο λόγος για τον οποίο οι αρχές του Agile πιστεύουν στον καθορισμό του χρόνου και των μελών της ομάδας και επιτρέποντας στο πεδίο εφαρμογής να είναι το μεταβλητό στοιχείο.

Ποιο ακούγεται καλύτερο και αυξάνει την εμπιστοσύνη των ενδιαφερομένων, το σταθερό κόστος ή το μεταβλητό κόστος;

Φυσικά, είναι σημαντικό ένα προϊόν να ανταποκρίνεται στις υποσχέσεις του και στις ανάγκες των πελατών του. Δεν είναι καλό να ξοδεύετε ένα ακριβές χρονικό διάστημα και ένα ακριβές χρηματικό ποσό εάν, στο τέλος, έχετε ένα προϊόν που κανείς δεν θέλει ή μπορεί να χρησιμοποιήσει αποτελεσματικά.

Έτσι, οι συμβάσεις Agile επικεντρώνονται στα ακόλουθα:

τι σημαίνει βαθμολογία imdb
  • Σταθερά πακέτα εργασίας - Όλο το έργο χωρίζεται σε λογικές «μίνι» κυκλοφορίες που συμβάλλουν στο πλήρες αποτέλεσμα του προϊόντος. Κάθε κυκλοφορία είναι ένα πακέτο εργασίας που τιμολογείται ανάλογα. Καθώς το πακέτο εργασίας έχει ολοκληρωθεί, τα μελλοντικά πακέτα εργασίας επανεκτιμώνται με βάση όσα έχουμε μάθει από το προηγούμενο. Αυτό αποφεύγει την περιττή έκτακτη ανάγκη και επιτρέπει τον καθορισμό ενός επιπέδου εκ νέου ιεράρχησης και νέων / αναθεωρημένων λειτουργιών από τον πελάτη.

  • Πρόωρη λήξη - Αυτό επιτρέπει στον πελάτη να επιδιώξει να τερματίσει το έργο νωρίτερα εάν έχει παραδοθεί αρκετό από το προϊόν και δεν υπάρχει περαιτέρω απόδοση επένδυσης με τη διατήρηση μιας ομάδας έργου που θα συνεχίσει να παρέχει οριακά κέρδη μόνο. Αυτή η ρήτρα επιτρέπεται συνήθως ανά πάσα στιγμή και ισχύει εφόσον η ομάδα του έργου και ο πελάτης έχουν διατηρήσει μια ισχυρή, αξιόπιστη και στενή συνεργατική σχέση. Το όφελος για τον πελάτη είναι ότι το έργο θα ολοκληρωθεί νωρίς, έχοντας παραδώσει όλα τα πολύτιμα χαρακτηριστικά που είναι απαραίτητα για να καταστήσει το προϊόν βιώσιμο. Σε αντάλλαγμα, ο προμηθευτής καταβάλλεται 20 τοις εκατό της υπόλοιπης αξίας της σύμβασης και αντισταθμίζει τον κίνδυνο διατήρησης προσωπικού.

  • Ευέλικτες αλλαγές - Η αλλαγή είναι ένα θέμα που τρέχει δυνατά μέσα από τις φλέβες της παράδοσης λογισμικού Agile. Περιμένουμε να μην γνωρίζουμε όλα όσα χρειαζόμαστε για να κάνουμε ένα προϊόν επιτυχημένο από την αρχή. Έτσι, προωθούμε την αλλαγή, με βάση τα σχετικά δεδομένα και τα σχόλια, για να διασφαλίσουμε την παράδοση του σωστού προϊόντος. Στο τέλος μιας επανάληψης, οι αλλαγές μπορούν να αντικατασταθούν για παλιά χαρακτηριστικά που δεν θεωρούνται πλέον απαραίτητα ή ως προτεραιότητα. Εφόσον η αλλαγή είναι ίσης αξίας, δεν υπάρχει περαιτέρω κόστος. Εάν η αλλαγή είναι χαμηλότερης αξίας, μπορούν να εντοπιστούν ή να προωθηθούν επιπλέον εργασίες από το υπόλοιπο καθυστέρησης. Αυτή η ρήτρα ισχύει εφόσον η ομάδα του έργου και ο πελάτης έχουν διατηρήσει μια ισχυρή, αξιόπιστη και στενή συνεργατική σχέση καθ 'όλη τη διάρκεια του έργου.

  • Επιπλέον εργασία - Καθ 'όλη τη διάρκεια ζωής ενός έργου, ενδέχεται να εντοπιστούν περισσότερα χαρακτηριστικά που δεν θα μπορούσαν να επιτευχθούν βάσει της υφιστάμενης σύμβασης σταθερής τιμής. Για αυτό το σενάριο, είτε πρόσθετα πακέτα εργασίας με νέες τιμές μπορούν να προστεθούν στο τέλος του έργου είτε να επιστρέψουν σε χρόνο και υλικό.

  • Εκτεταμένες εκτιμήσεις - Υπάρχουν δύο τρόποι με τους οποίους οι εκτιμήσεις μπορούν να κυμαίνονται σε μια σύμβαση έργου Agile: ένα εύρος διάρκειας ή μια σειρά χαρακτηριστικών. Ένα εύρος διάρκειας επιτρέπει μια εκτίμηση να λέει ότι το έργο ή το πακέτο εργασίας θα διαρκέσει 12 έως 16 εβδομάδες για ένα δεδομένο σύνολο πεδίου. Ωστόσο, η προσθήκη διάρκειας αυξάνει το κόστος καθώς διατηρείτε τα μέλη της ομάδας έργου για μεγαλύτερο χρονικό διάστημα ή αυτό σημαίνει ότι δεν μπορούν να αφεθούν ελεύθεροι για να εργαστούν σε άλλα αναπτυξιακά έργα. Στο ApeeScape, προτιμούμε να επεκτείνουμε χαρακτηριστικά σε ένα εύρος σημείων ιστορίας, διατηρώντας το εύρος ως μεταβλητή αλλά υπόσχεται να προσφέρει ένα ελάχιστο επίπεδο αξίας στον πελάτη εντός του καθορισμένου χρονικού πλαισίου του πακέτου εργασίας ή του συνολικού έργου.

Αξίζει να θυμάστε ότι μπορείτε πάντα να προσθέσετε περισσότερο εύρος αργότερα. Ίσως έχετε αρχίσει να κερδίζετε έσοδα, έχετε αυξήσει τους χρήστες ή έχετε μειώσει το κόστος. Είτε έτσι είτε αλλιώς, είναι πολύ πιο εύκολο να ζητήσετε περισσότερα χρήματα και χρόνο εάν έχετε ήδη δείξει απόδοση ή βελτίωση και αποδίδετε επιχειρηματική αξία.

Ευέλικτα συμβόλαια

Η προσέγγισή μας στο κόστος και την τιμολόγηση του λογισμικού

Στο ApeeScape συνεργαζόμαστε στενά με τους πελάτες και τους μηχανικούς μας για να χρησιμοποιήσουμε τεχνικές που προάγουν την εμπιστοσύνη των ενδιαφερομένων στη διάρκεια και το κόστος του έργου. Εργαζόμαστε συνεχώς στην επεξεργασία και την προσαρμογή του σχεδιασμού από ένα αρχικό υψηλό επίπεδο σε πιο λεπτομερείς λεπτομέρειες, όταν είναι κατάλληλο και απαραίτητο για την αποφυγή σπατάλης και την ενεργοποίηση της διαχειριζόμενης αλλαγής.

Τα ακόλουθα βήματα λαμβάνονται για την εκπόνηση ενός έργου εκτίμησης και σταθερής τιμής:

1. Αρχικό πεδίο υψηλού επιπέδου

Στην αρχή ενός έργου, γνωρίζουμε λιγότερο για το τελικό αποτέλεσμα. Είναι ανόητο να φανταζόμαστε ότι είναι δυνατόν να γνωρίζουμε ακριβώς τι χαρακτηριστικά χρειάζονται οι πελάτες και οι χρήστες μας από την αρχή.

Ξεκινάμε λοιπόν με έναν χάρτη έργου και ένα υψηλό επίπεδο 'επικών' χαρακτηριστικών που καθοδηγούν την κατεύθυνση του έργου, με βάση ένα υγιές όραμα και στόχους

προς το. Ρύθμιση οράματος και στόχου Τι πρέπει να χτίσουμε; Τι πρέπει να πετύχετε και ποιοι είναι οι επιχειρηματικοί σας στόχοι; Η κατανόηση αυτών των ερωτήσεων μας επιτρέπει να καθορίσουμε την κλίμακα του έργου. Χρειάζεστε ένα πρωτότυπο για να δοκιμάσετε μια αρχική ιδέα, ιδέα ή τεχνολογία; Έχετε προσδιορίσει μια σαφή πρόταση που έχει δοκιμαστεί με την αγορά σας και είστε έτοιμοι να δημιουργήσετε το πρώτο σας ελάχιστο βιώσιμο προϊόν ( MVP ); Ή, κλιμακώνετε την υπάρχουσα επιχείρηση ή το προϊόν σας για να φτάσετε στο επόμενο επίπεδο;

σι. Χαρακτηριστικά 'επικού' υψηλού επιπέδου Χωρίς να αναφερθείτε σε πολλές λεπτομέρειες, θα θελήσετε να καθορίσετε τις δυνατότητες που διαθέτει το προϊόν σας για να ικανοποιήσει τις ανάγκες του πελάτη σας. Αυτή είναι μια δομημένη «λίστα αγορών» που περιγράφει τα γυμνά οστά του προϊόντος σας. συχνά αναφέρονται ως « Ιστορίες χρηστών Ή επικά

ντο. Ανάλυση MoSCoW Ανάλυση MoSCoW είναι μια τεχνική που, με απλά λόγια, βοηθά στον προσδιορισμό του τι είναι πραγματικά απαραίτητο για να καταστεί το προϊόν βιώσιμο και τι είναι ωραίο να έχεις. Εκείνοι που χαρακτηρίζονται ως 'Πρέπει' ικανοποιούν αυτό που θα ενθαρρύνει τους χρήστες να εμπλακούν και να υιοθετήσουν το προϊόν σας. Αυτά τα χαρακτηριστικά γνωρίσματα ως 'Πρέπει' θα εκπλήξουν και θα ενθουσιάσουν τους πελάτες σας, αλλά θα μπορούσαν να κατασκευαστούν αργότερα. Τα στοιχεία 'Could' συχνά δεν προσθέτουν σημαντική επιχειρηματική αξία, ενδέχεται να μην αυξάνουν την απόδοση και είναι τα χαμηλότερα από τις προτεραιότητές σας. Οι λειτουργίες 'δεν θα' θα μπορούσαν να είναι σημαντικές μια μέρα, αλλά δεν είναι περιθώρια για την επανάληψη αυτού του έργου. Ωστόσο, η αναγνώρισή τους τώρα μπορεί να βοηθήσει στο να έχουμε κατά νου την πιθανή κλίμακα και μέγεθος του προϊόντος για το μέλλον.

MSCW

2. Πρόταση

Για να αποφασίσετε εάν θα προχωρήσετε σε ένα έργο, είναι απαραίτητο να βασιστεί αυτή η απόφαση σε καλά ενημερωμένα δεδομένα: κόστος και διάρκεια. Αυτά είναι τα ελάχιστα που πρέπει να αναρωτηθείτε: Τι θα χρειαστεί για τη δημιουργία του προϊόντος που θέλουμε; Πότε μπορούμε να ξεκινήσουμε; Αυτό ευθυγραμμίζεται με την επιχειρηματική στρατηγική και τα οικονομικά μας;

Με τις παραπάνω λεπτομέρειες, είμαστε σε θέση να υποβάλουμε πρόταση. Οι μηχανικοί μας επιλέγονται με το χέρι για τις συγκεκριμένες απαιτήσεις του έργου και συνεργάζονται με έναν διαχειριστή έργου για να αντλήσουν τουλάχιστον μία τεχνική λύση, μια εκτιμώμενη διάρκεια που παρέχει το γνωστό πεδίο και ένα εκτιμώμενο κόστος για την ολοκλήρωση του έργου.

Όπως αναφέραμε προηγουμένως, στην αρχή ενός έργου γνωρίζουμε λιγότερο για το τι θα παραδοθεί. Διατηρούμε σκόπιμα τα χαρακτηριστικά και το πεδίο εφαρμογής, καθώς κάτι διαφορετικό υποδηλώνει ότι γνωρίζουμε ακριβώς τι απαιτείται. Μια εκτίμηση σε αυτό το στάδιο θα ήταν η λιγότερο ακριβής, αλλά παρέχει καθοδήγηση σχετικά με το αν αξίζει να προχωρήσετε στο έργο.

Η πρόταση είναι το πρώτο εργαλείο για την επεξεργασία της διάρκειας και του κόστους ενός έργου. Μόλις γίνει αποδεκτή μια πρόταση, μπορούμε να προχωρήσουμε προς τα εμπρός για να παρέχουμε μια προσφορά σταθερής τιμής.

3. Σχεδιασμός απελευθέρωσης

Το επόμενο επίπεδο επεξεργασίας εκτιμήσεων είναι να δημιουργήσετε ένα σχέδιο απελευθέρωσης που θα παρέχει μια σειρά χαρακτηριστικών σε ένα δεδομένο χρονικό πλαίσιο. Το αντλούμε από μια λίστα χαρακτηριστικών, το μέγεθος του έργου, πόσο γρήγορα η ομάδα μας μπορεί να αναπτύξει ποιοτικό λογισμικό που ανταποκρίνεται στις προσδοκίες και τις τεχνικές ενός πελάτη για τη διαχείριση του κινδύνου αβεβαιότητας.

προς το. Καθυστέρηση προϊόντος ο καθυστέρηση προϊόντος είναι απλώς μια σειρά παραγγελιών 'Epics' ή 'User Stories' που αντιπροσωπεύει τις λειτουργίες που απαιτούνται για ένα προϊόν. Αυτή η λίστα ξεκινά τη ζωή όπως τα έπη που συζητήθηκαν νωρίτερα, αλλά μεταξύ της ομάδας έργου, του διαχειριστή έργου και του πελάτη, τα χωρίζουμε τώρα σε πιο σημαντικά αντικείμενα. Κάθε ένα από τα στοιχεία αντιπροσωπεύει ένα μέρος της επιχειρηματικής αξίας για τον πελάτη. Δεν μπαίνουμε σε περισσότερες λεπτομέρειες σε αυτό το στάδιο, δεν χρειάζεται να γνωρίζουμε τα κριτήρια αποδοχής, δεν χρειάζεται να γνωρίζουμε εάν ένα κουμπί είναι μπλε ή πράσινο, απλά πρέπει να γνωρίζουμε ότι υπάρχει ένα κουμπί που επιτρέπει κάποια εργασία που πρέπει να εκτελεστούν.

σι. Εκτίμηση Τώρα που έχουμε τη λίστα των χαρακτηριστικών μας που περιγράφονται ως ιστορίες χρηστών, η ομάδα εκτιμά αυτά τα διακριτά στοιχεία χαρακτηριστικών χρησιμοποιώντας μια τεχνική που ονομάζεται 'Planning Poker'. Αυτή είναι μια χρήσιμη τεχνική που εξασφαλίζει γρήγορα, αξιόπιστα αποτελέσματα με βάση τη γνώμη των εμπειρογνωμόνων και το ανάλογο μέγεθος. Το Planning Poker εκχωρεί έναν συμφωνημένο αριθμό σε κάθε στοιχείο που αντιπροσωπεύει το μέγεθος και την πολυπλοκότητά του. Αυτό ονομάζεται ένα σημείο ιστορίας. Αλλα Ευέλικτη εκτίμηση τεχνικές και μεγέθη, όπως « ιδανικές μέρες ', είναι διαθέσιμα.

Το τέλος αυτής της διαδικασίας θα καθορίσει το μέγεθος του έργου και τις εξαρτήσεις μεταξύ των χαρακτηριστικών. Το μέγεθος καθορίζεται με την προσθήκη όλων των σημείων ιστορίας από τα στοιχεία στο καθυστερημένο προϊόν. Εάν αυτός ο αριθμός ισούται με 120, τότε το μέγεθος του έργου μας είναι 120 σημεία ιστορίας.

ντο. Προτεραιότητα Τώρα που έχουμε καθυστερήσεις και μέγεθος για το έργο, είμαστε σε θέση να το δώσουμε προτεραιότητα στον πελάτη. Αυτό αφορά πραγματικά τον προσδιορισμό του τι είναι πολύτιμο για τον πελάτη, προκειμένου να επιτευχθούν τα επιθυμητά αποτελέσματα. Το στοιχείο στην κορυφή της λίστας θεωρείται το πιο σημαντικό, το δεύτερο στοιχείο είναι λιγότερο σημαντικό από το πρώτο και ούτω καθεξής μέσω της λίστας. Κανένα στοιχείο δεν μπορεί να είναι τόσο σημαντικό όσο ένα άλλο, η προτεραιότητα κάθε στοιχείου έχει σχετική σημασία ή αξία για κάθε ένα από τα άλλα στοιχεία.

Αυτή η προσέγγιση για την ιεράρχηση αποτελεί σημαντικό ορόσημο στο σχεδιασμό ενός έργου λογισμικού. Γνωρίζουμε τώρα τι είναι σημαντικό για τον πελάτη και με ποιον τρόπο να ολοκληρώσουμε τη δουλειά, φροντίζοντας τις εξαρτήσεις, για να παραδώσουμε ένα προϊόν που ανταποκρίνεται στις προσδοκίες.

ρε. Σχεδιασμός απελευθέρωσης Μέχρι σήμερα, έχουμε προσδιορίσει τι πιστεύουμε ότι είναι το προϊόν και πόσο μεγάλο είναι.

Τώρα, καθορίζουμε πόσο καιρό θα χρειαστεί για την παράδοση ενός προϊόντος με δυνατότητα απελευθέρωσης. Ο πελάτης και η ομάδα, συμπεριλαμβανομένων των σχεδιαστών, των μηχανικών, των υπευθύνων δοκιμών, του master scrum και του διαχειριστή έργου, συνεργάζονται για να προσδιορίσουν τι μπορεί να επιτευχθεί και πόσο γρήγορα μπορεί να γίνει εργασία για τη δημιουργία ενός σχεδίου κυκλοφορίας.

Το σχέδιο κυκλοφορίας δίνει επίσης πληροφορίες για το πώς το έργο θα ευθυγραμμιστεί με τα στρατηγικά σχέδια ενός πελάτη.

Και τέλος, αυτό το σχέδιο διασφαλίζει ότι η ομάδα του έργου έχει καθοδηγητικό φως που οδηγεί τον δρόμο και καθορίζει ένα λογικό τελικό σημείο στην ανάπτυξη.

Πριν ξεκινήσουμε, διασφαλίζουμε ότι κατανοούμε τον συμφωνημένο ορισμό του «ολοκληρωμένου». Αυτό είναι ένα δεδομένο σύνολο κριτηρίων που ένας πελάτης θα αποδεχτεί ως πλήρης και πληροί επίσης όλες τις τεχνικές απαιτήσεις που πρέπει να θεωρηθούν αποδεσμεύσιμες.

Για να πάρουμε ένα βασικό σενάριο, παίρνουμε τον συνολικό αριθμό των πόντων ιστορίας που έχουμε από το μέγεθος των καθυστερήσεων και το διαιρούμε από τις αναμενόμενες ομάδες μας ταχύτητα . (Η ταχύτητα NB εκφράζεται συνήθως ως εύρος, αλλά για απλότητα, θα χρησιμοποιήσουμε έναν μόνο αριθμό εδώ.) Εργαζόμαστε σε επαναλήψεις δύο εβδομάδων, ώστε η ταχύτητά μας να αντικατοπτρίζεται από το πόσο μπορούμε να ολοκληρώσουμε σε έναν κύκλο δύο εβδομάδων με τα διαθέσιμα ικανότητα της ομάδας. Εάν οι πόντοι ιστορίας μας ανέρχονταν σε 120 και αναμένουμε να ολοκληρώσουμε 20 πόντους ανά επανάληψη, η συνολική διάρκεια ανάπτυξης θα ήταν 12 εβδομάδες ή 6 επαναλήψεις. Προσθέτουμε σε αυτό ένα σπριντ 0 των 2 εβδομάδων και ένα σπριντ προετοιμασίας απελευθέρωσης δύο εβδομάδων. Συνολικά, η διάρκεια του έργου μας είναι 16 εβδομάδες. Υπάρχουν τεχνικές που μπορούμε να χρησιμοποιήσουμε που θα μπορούσαν να βοηθήσουν στη δημιουργία ενός κατάλληλου ρυθμιστικού κινδύνου στον σχεδιασμό μας, τις οποίες θα συζητήσουμε αργότερα. Εν ολίγοις, χρησιμοποιούμε το buffer για να διαχειριστούμε τον κίνδυνο αβεβαιότητας και να καταλήξουμε σε μια ελάχιστη συμφωνία των αναμενόμενων σημείων ιστορίας που θα παραδοθούν. Το αποτέλεσμα μπορεί να είναι μια σειρά από 90 έως 150 σημεία ιστορίας που παραδόθηκαν, 90 είναι το ελάχιστο που θα ήταν αποδεκτό για τη δημιουργία ενός βιώσιμου προϊόντος.

Ευέλικτος σχεδιασμός

Εναλλακτικά, εάν το έργο πρέπει να ολοκληρωθεί σε μια δεδομένη ημερομηνία, δηλαδή 10 εβδομάδες, η ομάδα θα καθορίσει πόση από τις καθυστερήσεις μπορεί να ολοκληρωθεί εκείνη τη στιγμή. Αν προβλέψουμε 20 πόντους ιστορίας ανά σπριντ, συν Sprint 0 και σπριντ κυκλοφορίας, θα στοχεύαμε 60 πόντους που ολοκληρώθηκαν μέχρι το τέλος του έργου. Και πάλι, θα προσπαθούσαμε να διαχειριστούμε τον κίνδυνο προσθέτοντας ένα κατάλληλο buffer, το οποίο θα μπορούσε να οδηγήσει σε έναν στόχο 45 έως 75 πόντων ιστορίας που έχουν ολοκληρωθεί και έτοιμοι να κυκλοφορήσουν. Τα 45 σημεία ιστορίας θα ευθυγραμμιστούν με το ελάχιστο αποδεκτό για την παράδοση ενός βιώσιμου και πολύτιμου προϊόντος. Αυτό είναι ένα σενάριο όπου μπορείτε να περιμένετε να προσθέσετε ένα μέλος της ομάδας για να αυξήσετε την ταχύτητα, εάν είναι απαραίτητο.

Φυσικά, όλα τα παραπάνω υποστηρίζονται από καλής ποιότητας επικοινωνία και συνεργασία μεταξύ όλων των μερών για την κατάρτιση ενός σχεδίου έκδοσης που είναι εφικτό, ρεαλιστικό και αποδεκτό από τον πελάτη.

4. Συμβόλαιο σταθερής τιμής

Μόλις συμφωνηθεί ένα σχέδιο κυκλοφορίας, θα μπορέσουμε να δημιουργήσουμε μια προσφορά για μια σύμβαση έργου σταθερής τιμής. Όπως αναφέρθηκε προηγουμένως, συνιστάται να διατηρήσετε τη διάρκεια του έργου και την ομάδα σταθερή και τη μεταβλητή του πεδίου.

Η προσφορά για μια σύμβαση σταθερής τιμής παραδίδεται μαζί με μια δήλωση εργασίας και ένα συμφωνημένο πρόγραμμα πληρωμών.

Όσο υπάρχει εμπιστοσύνη, επικοινωνία, συνεργασία και ετοιμότητα να ενταχθούμε στο πνεύμα ενός έργου λογισμικού Agile, όλα τα παραπάνω βήματα μας επιτρέπουν να παραδώσουμε μια προσφορά με ρεαλιστικό βαθμό εμπιστοσύνης ότι ένα έργο θα παραδοθεί εγκαίρως και στον προϋπολογισμό. Φυσικά, θα υπάρξουν περιπτώσεις όπου ένα έργο παραδίδεται νωρίς ή αργά και αντιμετωπίζουμε αυτές τις παραλλαγές με τη μέγιστη διαφάνεια.

Τεχνική εκτίμηση

Ο ευέλικτος σχεδιασμός και η εκτίμηση υποστηρίζονται από μια σειρά τεχνικών που μπορεί να χρησιμοποιήσει μια ομάδα ανάπτυξης για να αποκτήσει εμπιστοσύνη στο μέγεθος, την προσπάθεια, τη διάρκεια και το κόστος τους. Εδώ είναι μερικά από αυτά που χρησιμοποιούν οι ομάδες μας για να εκτιμήσουν το μέγεθος και το κόστος ενός έργου λογισμικού.

Εκτίμηση μεγέθους

Το μέγεθος του έργου είναι πραγματικά μια εκτίμηση του εύρους, της πολυπλοκότητας, των διαστάσεων, του κινδύνου και του μεγέθους του. Για να χρησιμοποιήσετε μια αναλογία, πρόκειται για κατανόηση εάν χτίζουμε τον Πύργο του Άιφελ ή το Σινικό Τείχος της Κίνας. Ο πύργος του Άιφελ είναι μια ψηλή, βαριά, περίπλοκη κατασκευή χτισμένη σε ένα στενό αστικό περιβάλλον. Το Σινικό Τείχος της Κίνας είναι μια σχετικά απλή, αλλά μακρά και ανθεκτική κατασκευή που εκτείνεται σε πολλά μίλια από κυματιστό έδαφος.

Παρόλο που θα ήταν και τα δύο μεγάλα έργα, το εύρος, η πολυπλοκότητα, οι διαστάσεις, το μέγεθος και το μέγεθος τους είναι διαφορετικά.

Είναι σημαντικό να διαχειριστείτε τις προσδοκίες με εκτιμήσεις. Δεν είναι ποτέ προβλέψεις, δεσμεύσεις ή εγγυήσεις. Όταν συζητάμε για το συνολικό μέγεθος, τη συνολική διάρκεια και το συνολικό κόστος, εργαζόμαστε πάντα εντός εύρους, ώστε να μετριάσουμε τον κίνδυνο, την αβεβαιότητα και τα άγνωστα.

Οι ιστορίες που αντιπροσωπεύουν χαρακτηριστικά του προϊόντος σας έχουν ξεχωριστό μέγεθος και εκτιμάται χρησιμοποιώντας σημεία ιστορίας ή ιδανικές μέρες. Ο συνολικός αριθμός αυτών των μονάδων καθορίζει το συνολικό μέγεθος του έργου.

Σημεία ιστορίας

Τα σημεία ιστορίας είναι μια μονάδα μέτρησης που εκφράζει το συνολικό μέγεθος μιας ιστορίας χρήστη. Το μέγεθος μιας ιστορίας, όταν εκτιμάται, περιλαμβάνει όλες τις πτυχές του σχεδιασμού, της μηχανικής, των δοκιμών, της επισκόπησης κώδικα, της ενσωμάτωσης κ.λπ.

Κάθε μέγεθος μιας ιστορίας σχετίζεται με μια άλλη ιστορία. Για παράδειγμα, η ιστορία Α μπορεί να έχει μέγεθος ως ένα σημείο, η ιστορία Β ως δύο σημεία και η ιστορία Γ ως τρία σημεία. Εδώ, η ιστορία Γ είναι τουλάχιστον τρεις φορές το μέγεθος της ιστορίας Α και τουλάχιστον το μισό τόσο μεγαλύτερη όσο η ιστορία Β.

Εάν οι ακόλουθες ιστορίες στο καθυστερημένο προϊόν μας έχουν τα σχετικά μεγέθη:

Ιστορία Μέγεθος
ΠΡΟΣ ΤΟ ένας
σι 5
ντο 3
ρε ένας
ΕΙΝΑΙ 2


Το συνολικό μέγεθος του έργου είναι 12 σημεία ιστορίας.

Ιδανικές μέρες

Αυτό είναι ένα μέτρο μεγέθους που εκφράζεται σε ημέρες. Καταργεί την έννοια των γενικών εξόδων, όπως διακοπές, ευέλικτες δραστηριότητες σχεδιασμού, ανάγνωση email και άλλες δραστηριότητες εκτός έργου. Επικεντρώνεται μόνο στο πόσο καιρό θα χρειαζόταν αν εργαζόσουν κάτι συνεχώς χωρίς διακοπή, παρά στον χρόνο που πέρασε από την αρχή έως το τέλος.

Συνήθως, κατά την εκτίμηση σε υψηλό επίπεδο όταν γνωρίζουμε λιγότερο για ένα έργο, θα εκτιμούσαμε σε ιδανικές μέρες, καθώς αυτή είναι μια ευκολότερη έννοια για συσχέτιση με την ιστορία και την εμπειρία του παρελθόντος από έναν αφηρημένο αριθμό όπως ένα σημείο ιστορίας. Ειδικά όταν οι ιστορίες σε υψηλό επίπεδο είναι πιο επικής φύσης με λίγη λεπτομέρεια και πιθανώς περιέχουν πρόσθετα στοιχεία όταν αναλυθούν αργότερα.

Κατά την εκτίμηση σε πιο αναλυτικό επίπεδο, ας πούμε μια ιστορία σε ένα καθιερωμένο καθυστερημένο προϊόν, μπορεί να χρησιμοποιηθεί οποιαδήποτε προσέγγιση και να αποφασιστεί από την ομάδα μηχανικών. Υπάρχουν οφέλη και για τις δύο προσεγγίσεις και κάθε ομάδα θα έχει την προτίμησή της.

Τεχνικές για Εκτίμηση

Κοινόχρηστες εκτιμήσεις Οι εκτιμήσεις δεν πραγματοποιούνται μεμονωμένα. Εκτελούνται από κοινού από όλη την ομάδα μηχανικών μαζί και περιλαμβάνουν σχεδιασμό, βάση δεδομένων, διακομιστή, διεπαφή διεπαφής, QA και άλλους διαλειτουργικούς εμπειρογνώμονες. Αυτό αποφεύγει τα προβλήματα του να μην ληφθούν υπόψη όλες οι πτυχές του έργου για την ολοκλήρωση μιας δυνατότητας και διασφαλίζει ότι κανένα άτομο δεν έχει το βάρος ή την ατυχία να υπερβεί ή να υποτιμήσει το μέγεθος μιας δυνατότητας. Η συνδυασμένη ομάδα θα έχει μια άποψη που μπορεί να συζητηθεί και να συμφωνηθεί.

Αναλογικές εκτιμήσεις Εδώ εξετάζουμε δύο διακριτά χαρακτηριστικά και αποφασίζουμε ότι το ένα είναι σχετικά μικρότερο ή μεγαλύτερο από το άλλο. Μπορούμε να δούμε μια δεδομένη ιστορία και να συμφωνήσουμε ότι είναι μικρό σε μέγεθος, και αν χρησιμοποιούμε σημεία ιστορίας θα μπορούσαμε να της δώσουμε ένα μέγεθος δύο. Η επόμενη ιστορία μπορεί να θεωρηθεί μεγάλη σε σύγκριση με την πρώτη και θα της έδινα μέγεθος πέντε. Αυτό υποδηλώνει ότι ένα μεγάλο είναι τουλάχιστον διπλάσιο του μεγέθους ενός μικρού χαρακτηριστικού.

Θα συνεχίζαμε αυτήν την άσκηση με όλες τις ιστορίες. Μόλις ολοκληρωθεί, μπορούμε στη συνέχεια να τοποθετήσουμε όλες τις μικρές, μεσαίες, μεγάλες και πολύ μεγάλες ιστορίες δίπλα-δίπλα και να ελέγξουμε ξανά το μέγεθος για να διασφαλίσουμε ότι υπάρχει ένα επίπεδο ομοιομορφίας στην εκτίμησή μας.

Σχεδιασμός πόκερ Πολλά έχουν γραφτεί για το πόκερ προγραμματισμού. Το ανέφερα και στο προηγούμενο Ιστολόγιο . Ένας από τους καλύτερους πόρους για την κατανόησή του είναι εδώ .

Στην ουσία, συνδυάζει τη γνώμη των εμπειρογνωμόνων, την αναλογία και την ομαδική συνεργασία σε μια εύκολη, γρήγορη και αξιόπιστη διαδικασία.

Συγκεντρώνει πολλούς εμπειρογνώμονες που ταιριάζουν καλύτερα στη δημιουργία εκτίμησης με βάση την τεχνική εμπειρία και την εμπειρία του τομέα, έναν ζωντανό διάλογο και μια ορθή αιτιολόγηση.

Κουβέντα

Ταχύτητα

Η ταχύτητα είναι ένα μέτρο της ικανότητας μιας ομάδας να κάνει τη δουλειά σε μια δεδομένη επανάληψη (ή σπριντ).

Εκφράζεται ως ένα εύρος, για παράδειγμα, 23 έως 32 σημεία ιστορίας ανά σπριντ, ειδικά νωρίς στη ζωή ενός έργου. Σε γενικές γραμμές, αυτό συμβαίνει επειδή εάν η ίδια ομάδα δεν έχει εργαστεί στο παρελθόν για το ίδιο πρόβλημα, είναι δύσκολο να απεικονιστεί ακριβώς ποια θα είναι η ταχύτητα της ομάδας. Παρατηρήστε, αναφερόμαστε στην ταχύτητα μιας ομάδας και όχι σε ένα άτομο!

Χρησιμοποιούμε την ταχύτητα για να σχεδιάσουμε τις κυκλοφορίες μας και να προσαρμόσουμε τα σχέδια και τα πακέτα εργασίας μας καθώς προχωράμε σε ένα έργο, επιτρέποντάς μας έτσι να προσαρμόζουμε τις προβλέψεις μας για ολοκλήρωση τακτικά και με ακρίβεια μέσω εκτέλεσης.

Όταν ξεκινάμε, είμαστε υποχρεωμένοι να ορίσουμε ένα εύρος ταχύτητας με πολύ λίγα δεδομένα. Μπορούμε να χρησιμοποιήσουμε ιστορικές τιμές εάν η ομάδα και ο χώρος προβλημάτων είναι οι ίδιοι, κάτι που είναι συχνά λιγότερο πιθανό. Μπορούμε να κάνουμε μια επανάληψη για να πάρουμε μια ιδέα της ταχύτητας από μια ομάδα που πραγματικά εργάζεται στο έργο, αλλά αυτό είναι δαπανηρό και δεν λειτουργεί εάν πρέπει να ληφθούν αποφάσεις σχετικά με τη συμφωνία για την έναρξη ενός έργου. Ή, μπορούμε να κάνουμε μια πρόβλεψη.

Η πρόβλεψη μιας ταχύτητας περιλαμβάνει τη λήψη ιστοριών αξίας σπριντ και τη διάσπασή τους σε εργασίες που εκτελούνται για την ολοκλήρωση της ιστορίας. Υπολογίζουμε τον αριθμό των ωρών που θα λάβει κάθε εργασία, που περιλαμβάνει σχεδιασμό, ανάπτυξη, δοκιμές και ούτω καθεξής και θα εκτιμήσουμε πόση ικανότητα θα έχει η ομάδα σε ένα συγκεκριμένο σπριντ. Η ικανότητα του 70 τοις εκατό για μια ομάδα χωρίς επιβάρυνση είναι μια καλή αρχή. Έτσι, σε μια απλή κατάσταση, εάν οι συνολικές ώρες που είναι διαθέσιμες στην ομάδα είναι:

  • 4 μέλη της ομάδας * δύο εβδομάδες * 40 ώρες την εβδομάδα = 320 ώρες
  • Πολλαπλασιάζεται με τη χωρητικότητα 70 τοις εκατό = 224 ώρες
  • Προσθέστε όλες τις λειτουργίες λειτουργιών και σταματήστε να μετράτε στο 224
  • Πάρτε όλες τις ολοκληρωμένες δυνατότητες, προσθέστε τα σημεία της ιστορίας τους και έχετε την ταχύτητά σας, ας πούμε 36
  • Εφαρμόστε 20 τοις εκατό και στις δύο πλευρές για να φτάσετε στο εύρος του χαμηλότερου και του υψηλότερου, για να φτάσετε με εκτιμώμενη ταχύτητα 29 έως 43 σημεία ιστορίας.

Η ταχύτητα κυμαίνεται συνήθως στις πρώτες δύο έως τέσσερις επαναλήψεις και στη συνέχεια σταθεροποιείται σε ένα μικρό εύρος σημείων. Έτσι, όπου το αρχικό μας εύρος πριν από το σπριντ ήταν 29 έως 43, με το σπριντ τέσσερα, μπορεί να είναι οροπέδιο από 34 έως 38. Αυτό μας δίνει τότε μεγαλύτερη εμπιστοσύνη στην πρόβλεψη της τελικής ημερομηνίας ολοκλήρωσης.

Ρυθμιστικά σχέδια για κίνδυνο & αβεβαιότητα

Όλα τα έργα λογισμικού έρχονται δεμένα με ένα επίπεδο αβεβαιότητας. Αυτή η αβεβαιότητα μειώνεται όσο προχωράμε στο έργο και είναι πιο γνωστά για την τεχνολογία, το περιβάλλον, τις επιδόσεις και τις ανάγκες του πελάτη και των χρηστών.

Μειώνουμε αυτήν την αβεβαιότητα ή τον κίνδυνο με ένα buffer στο πρόγραμμα, το οποίο αντιπροσωπεύει ένα περιθώριο σφάλματος στην εκτίμησή μας και τα άγνωστα που δεν μπορούμε να προσδιορίσουμε πριν ξεκινήσει η ανάπτυξη.

Συνήθως, υπάρχουν δύο τύποι buffer: Χαρακτηριστικό και χρονοδιάγραμμα. Καθώς ορίζουμε συχνά μια σταθερή τιμή για μια σταθερή ημερομηνία παράδοσης, είναι προτιμότερο να χρησιμοποιήσετε το buffer Feature.

Αυτή η προσέγγιση μας δίνει μια αξιόπιστη στρατηγική μετριασμού των κινδύνων και δίνει στους πελάτες εμπιστοσύνη σε αυτό που πρέπει να περιμένουν να δουν ως αποτέλεσμα όταν το έργο ολοκληρωθεί.

Ρυθμιστικά λειτουργιών

Με ένα buffer χαρακτηριστικών, προβλέπουμε ότι θα παραδώσουμε ένα δεδομένο σύνολο δυνατοτήτων, αλλά ιδανικά θα ολοκληρώσουμε ένα περαιτέρω σύνολο χαρακτηριστικών. Αυτό θα πρέπει να αντικατοπτρίζει τουλάχιστον το ελάχιστο σύνολο χαρακτηριστικών που ο πελάτης θεωρεί απαραίτητο για την έναρξη ενός βιώσιμου προϊόντος, αλλά περισσότερα μπορεί να παραδοθούν εντός του χρονικού πλαισίου, εάν το επιτρέπουν όλες οι διάφορες εσωτερικές και εξωτερικές επιρροές.

Έτσι, ένας πελάτης μπορεί να αποφασίσει ότι οι λειτουργίες υψηλότερης προτεραιότητας από το καθυστερημένο προϊόν, προσθέτοντας έως και 100 σημεία ιστορίας, είναι οι πιο σημαντικές. Στη συνέχεια, μπορούν να εξετάσουν πρόσθετα χαρακτηριστικά που προσθέτουν έως και 30 σημεία ιστορίας. Η ομάδα, λοιπόν, θα σχεδιάσει με βάση την παράδοση 130 πόντων ιστορίας, με τουλάχιστον 100 να έχουν ολοκληρωθεί έως το τέλος της προγραμματισμένης ημερομηνίας ολοκλήρωσης για τη δεδομένη σύμβαση σταθερής τιμής.

Κάποιες σκέψεις κλεισίματος

Το Agile μπορεί να είναι μια πολύ δύσκολη ιδέα για πλήρη κατανόηση και υιοθέτηση. Αυτό δεν ισχύει λιγότερο κατά τη διαχείριση ευαίσθητων θεμάτων όπως η τιμή, το εύρος και η διάρκεια. Δυστυχώς, γνωρίζω από πρώτο χέρι ότι οι απαιτητικοί πελάτες θέλουν όλα τα πράγματα να είναι μπροστά και είναι πρόθυμοι να κατηγορήσουν τον προμηθευτή όταν αρχίσει να ξετυλίγεται. Ομοίως, γνωρίζω πωλητές που σκάβουν τακούνια τους, αποκρίνονται και δεν ανταποκρίνονται στις ανάγκες των πελατών. Η λήψη ενός ευέλικτου μονοπατιού βασίζεται βασικά στην εμπιστοσύνη, τις καλές σχέσεις και την αστρική επικοινωνία. Αυτές πρέπει να είναι αξίες που κατέχουν και τα δύο μέρη για να διατηρήσουν ένα υγιές έργο για το ίδιο όφελος, ικανοποίηση και επιτυχία για όλους τους εμπλεκόμενους. Το να διατηρείτε ανοιχτό μυαλό και εποικοδομητική στάση απέναντι στη συνεργασία και τη διαπραγμάτευση είναι ο καλύτερος τρόπος για να αποφύγετε τις ξινές σχέσεις.

Συνεργάστηκα με πελάτες που δυσκολεύτηκαν να αγκαλιάσουν την προσαρμοστική φύση του Agile και να παραιτηθούν από μια στάση ελέγχου και ελέγχου. Είναι δύσκολο να αφήσεις και να βάλεις όλη την πίστη και την εμπιστοσύνη σου σε μια ομάδα που δεν ξέρεις. Συχνά, οι πελάτες ενδέχεται να επιθυμούν να δημιουργήσουν όλες τις απαιτήσεις εκ των προτέρων ως περιγραφή του τι θα παραδοθεί. Αυτό τους δίνει μια αίσθηση εμπιστοσύνης ότι το εύρος ενός έργου είναι καλά καθορισμένο. Αλλά τελικά, αυτό δεν υλοποιείται ως μια επιτυχημένη προσέγγιση. Εάν είμαστε κλειδωμένοι στο πεδίο εφαρμογής και τις μη ρεαλιστικές απαιτήσεις σε μια σύμβαση, τα προβλήματα προκύπτουν πολύ γρήγορα.

Γνωρίζουμε, όταν ακολουθούμε αυτήν την προσέγγιση με παραδοσιακές μεθόδους, ότι το πεδίο εφαρμογής αλλάζει, τα άγνωστα αποκαλύπτονται ή αυτό που πιστεύαμε ότι ο πελάτης ήθελε δεν είναι πλέον αλήθεια ή δεν ξεχωρίζει. Η υιοθέτηση μιας προσαρμοστικής προσέγγισης για την τιμολόγηση, τον προγραμματισμό και το εύρος επιτρέπει στους πελάτες να αναγνωρίζουν πραγματικά το προϊόν τους ώστε να είναι ακριβώς αυτό που χρειάζεται η αγορά τους. Επιτρέπει σε έναν πωλητή να ανταποκρίνεται, ευφάνταστο και αποτελεσματικό. Η αξιοποίηση της συνεργασίας μεταξύ πελάτη και προμηθευτή για διαπραγμάτευση συμβολαίου είναι το κλειδί.

Οι προμηθευτές πρέπει να είναι ειλικρινείς και οι πελάτες πρέπει να είναι ρεαλιστές για το τι μπορεί να επιτευχθεί από την αρχή. Ένας πωλητής που υπόσχεται μη ρεαλιστικούς στόχους και στη συνέχεια αυξάνει το κόστος μπορεί να κερδίσει το αρχικό συμβόλαιο, αλλά σύντομα θα χάσει την εύνοιά του από έναν δυσαρεστημένο πελάτη. Πολύ συχνά, οι σχέσεις καταρρέουν λόγω έλλειψης εμπιστοσύνης ή εμπιστοσύνης μεταξύ των μερών. Η εμπιστοσύνη πρέπει να οικοδομηθεί εξαρχής και να διατηρηθεί καθ 'όλη τη διάρκεια ενός έργου. Ένας πωλητής πρέπει να είναι ευέλικτος και να συνεργάζεται με τις μεταβαλλόμενες ανάγκες. Οι πελάτες θέλουν πάντα περισσότερα. είναι μια φυσική συνέπεια της επιχειρηματικής δραστηριότητας. Πρέπει να υπάρχει ισότιμη και ωφέλιμη ανταλλαγή αξίας μεταξύ των δύο πλευρών. Για τους πελάτες, αναζητούν να δημιουργήσουν αξία για την επιχείρησή τους. Για τους πωλητές, θα πρέπει να προσπαθούν να δημιουργήσουν αξία σχηματίζοντας μακροχρόνιες σχέσεις με τους πελάτες. Η τήρηση των αξιών και των κατευθυντήριων αρχών του Agile Manifesto είναι μια καλή βάση για τη δημιουργία ισχυρών, ισορροπημένων και μακροχρόνιων σχέσεων.

γιατί να χρησιμοποιήσω το node.js

Περίληψη

Ελπίζω ότι αυτό σας έδωσε κάποια εικόνα για το σχεδιασμό, την εκτίμηση και τον καθορισμό μιας τιμής για ένα Ευκίνητος έργο λογισμικού. Όλες οι παραπάνω προσεγγίσεις και τεχνικές έχουν σχεδιαστεί για την οικοδόμηση εμπιστοσύνης σε μια ομάδα και για την οικοδόμηση εμπιστοσύνης στο μυαλό των πελατών για το πόσο καιρό και πόσο θα χρειαστεί για την κατασκευή ενός προϊόντος λογισμικού. Και τελικά, για να οικοδομήσουμε εμπιστοσύνη στη λήψη απόφασης για να προχωρήσουμε.

Ακολουθήστε αυτές τις οδηγίες και θα είστε βέβαιοι ότι θα βρείτε μια ικανοποιητική διαδρομή για να ζωντανέψετε το προϊόν λογισμικού σας.

Επικεφαλής Εκδόσεων

Αλλα

Επικεφαλής Εκδόσεων
Embracing Sass: Γιατί πρέπει να σταματήσετε να χρησιμοποιείτε το Vanilla CSS

Embracing Sass: Γιατί πρέπει να σταματήσετε να χρησιμοποιείτε το Vanilla CSS

Τεχνολογία

Δημοφιλείς Αναρτήσεις
Πώς να δημιουργήσετε μια εφαρμογή επεξεργασίας φυσικής γλώσσας
Πώς να δημιουργήσετε μια εφαρμογή επεξεργασίας φυσικής γλώσσας
Πρόβλεψη επενδυτικού κεφαλαίου 2017: Σημάδια κόπωσης
Πρόβλεψη επενδυτικού κεφαλαίου 2017: Σημάδια κόπωσης
Μια βαθιά ματιά στο JSON εναντίον XML, Μέρος 2: Τα δυνατά σημεία και οι αδυναμίες και των δύο
Μια βαθιά ματιά στο JSON εναντίον XML, Μέρος 2: Τα δυνατά σημεία και οι αδυναμίες και των δύο
Πώς να ποσοτικοποιήσετε αποτελεσματικά την αξία προϊόντος - Ένας οδηγός για τους διαχειριστές προϊόντων
Πώς να ποσοτικοποιήσετε αποτελεσματικά την αξία προϊόντος - Ένας οδηγός για τους διαχειριστές προϊόντων
Το μέλλον των ομάδων: Διαχείριση του συνδυασμένου εργατικού δυναμικού
Το μέλλον των ομάδων: Διαχείριση του συνδυασμένου εργατικού δυναμικού
 
Think Business - Πώς να αυξήσετε την αξία του σχεδιαστή σας
Think Business - Πώς να αυξήσετε την αξία του σχεδιαστή σας
Εργονομία για Ψηφιακούς Νομάδες: Εργασία στο δρόμο χωρίς να σκοτωθείτε
Εργονομία για Ψηφιακούς Νομάδες: Εργασία στο δρόμο χωρίς να σκοτωθείτε
Μια βαθιά κατάδυση στις επενδύσεις του Elon Musk: The Makings of a Billionaire
Μια βαθιά κατάδυση στις επενδύσεις του Elon Musk: The Makings of a Billionaire
Αρχιτεκτονικοί Αλγόριθμοι Βελτιστοποίησης με HorusLP
Αρχιτεκτονικοί Αλγόριθμοι Βελτιστοποίησης με HorusLP
Κοιτάζοντας τα αποτυχημένα IPO στην εποχή του μονόκερου
Κοιτάζοντας τα αποτυχημένα IPO στην εποχή του μονόκερου
Δημοφιλείς Αναρτήσεις
  • απόδοση διακομιστή έναντι πελάτη
  • τι είναι η σχεδιαστική σκέψη στην επιχείρηση
  • φτιάχνοντας ένα bot για διχόνοια
  • πώς να χακάρετε τις προπληρωμένες κάρτες
  • πώς να χρησιμοποιήσετε τη μηχανική μάθηση
Κατηγορίες
  • Κατανεμημένες Ομάδες
  • Τροποσ Ζωησ
  • Αλλα
  • Κερδοφορία & Αποδοτικότητα
  • © 2022 | Ολα Τα Δικαιώματα Διατηρούνται

    portaldacalheta.pt