Πώς να κάνετε scoping σε ένα software έργο πριν γραφτεί η πρώτη γραμμή κώδικα

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

Βήμα 1: γράψτε το business problem σε μία παράγραφο, χωρίς λέξη για τεχνολογία

Πριν κανείς μιλήσει για features, frameworks ή οθόνες, αναγκάστε τον εαυτό σας να περιγράψει το πραγματικό πρόβλημα με απλά λόγια. 'Ξοδεύουμε 12 ώρες την εβδομάδα συμφωνώντας τιμολόγια μεταξύ δύο συστημάτων.' 'Οι πωλητές δεν ξέρουν ποια leads είναι hot γιατί τα δεδομένα ζουν σε τρία σημεία.' 'Χάνουμε πελάτες στο checkout επειδή η φόρμα είναι σπασμένη στο κινητό.' Αν δεν μπορείτε να περιγράψετε το πρόβλημα σε μία παράγραφο χωρίς τη λέξη 'app', δεν το καταλαβαίνετε αρκετά καλά για να φτιάξετε ακόμη λύση.

Βήμα 2: εντοπίστε τον έναν χρήστη που το λογισμικό πρέπει να του φτιάξει τη μέρα

Κάθε επιτυχημένο λογισμικό υπάρχει για να κάνει τη μέρα ενός συγκεκριμένου ανθρώπου καλύτερη. Ονομάστε τον. Τον υπεύθυνο αποθήκης που κάνει συμφωνία αποθέματος στις 6 το πρωί. Τον πωλητή που πρέπει να καταγράψει μια κλήση μεταξύ συναντήσεων. Τον πελάτη που θέλει να δει την κατάσταση της παραγγελίας του από το κινητό. Όταν ξέρετε για ποιον είναι το λογισμικό, κάθε επόμενη απόφαση — τι μπαίνει, τι κόβεται, πώς πρέπει να αισθάνεται το interface — έχει ξεκάθαρη απάντηση. Χωρίς αυτό, οι αποφάσεις παίρνονται από επιτροπή και το αποτέλεσμα δεν ικανοποιεί κανέναν.

Βήμα 3: γράψτε τις ροές εργασίας, όχι τα features

Τα features είναι παγίδα. Είναι αφηρημένα, επεκτείνονται χωρίς όριο και δεν σας λένε αν το σύστημα όντως δουλεύει. Οι ροές εργασίας είναι συγκεκριμένες: μια ροή είναι ένας άνθρωπος που κάθεται να κάνει ένα συγκεκριμένο πράγμα από την αρχή ως το τέλος. 'Ο υπεύθυνος αποθήκης παραλαμβάνει παράδοση, τη σαρώνει, ενημερώνει το stock.' 'Ένας πελάτης ψάχνει προϊόν, το βάζει στο καλάθι, πληρώνει.' Γράψτε τις πέντε ή έξι ροές που πρέπει να υποστηρίζει το σύστημα. Οτιδήποτε δεν είναι μέρος μιας από αυτές βγαίνει εκτός scope για την έκδοση δύο.

Βήμα 4: ξεχωρίστε must-have από nice-to-have, χωρίς ελεημοσύνη

Για κάθε ροή, κάντε την ίδια ερώτηση: αν αυτό το feature δεν υπήρχε, θα μπορούσε ο χρήστης να ολοκληρώσει τη ροή; Αν ναι, είναι nice-to-have. Αν όχι, είναι must-have. Τα must-have μπαίνουν στην έκδοση ένα. Τα nice-to-have πάνε σε μια λίστα που θα ξαναδείτε μετά το launch. Αυτό είναι το δυσκολότερο βήμα, γιατί όλοι έχουν αγαπημένα features που θέλουν να υπερασπιστούν. Αλλά κάθε nice-to-have που στέλνετε στην έκδοση ένα είναι μια βδομάδα που δεν αφιερώσατε στο να κάνετε σωστά τα must-haves.

Βήμα 5: ορίστε τι σημαίνει επιτυχία σε νούμερα

Πριν αρχίσει το build, συμφωνήστε τι σημαίνει 'το έργο πέτυχε'. 'Μειώσαμε τη συμφωνία τιμολογίων από 12 ώρες σε λιγότερο από 1 την εβδομάδα.' 'Οι πωλητές καταγράφουν 90% των κλήσεων την ίδια μέρα.' 'Το abandonment στο mobile checkout πέφτει 30%.' Ένα έργο χωρίς success metric είναι αδύνατο να αξιολογηθεί. Θα παραδώσετε λογισμικό, ο πελάτης θα το χρησιμοποιήσει για λίγο, και κανείς δεν θα ξέρει αν άξιζε τα λεφτά. Βάλτε το metric από την αρχή και θα ξέρετε.

Βήμα 6: γράψτε το και υπογράψτε το

Κάθε δέσμευση από τα παραπάνω πέντε βήματα μπαίνει σε ένα μονοσέλιδο scope document: πρόβλημα, χρήστης, ροές, must-haves, success metrics. Και οι δύο πλευρές υπογράφουν. Δεν είναι γραφειοκρατία — είναι το πιο χρήσιμο έγγραφο που θα έχετε για τους επόμενους τρεις μήνες. Κάθε φορά που κάποιος λέει 'να προσθέσουμε και…', επιστρέφετε στο document. Είτε το νέο αίτημα είναι πραγματικά κρίσιμο και αξίζει επίσημη αλλαγή, είτε είναι nice-to-have και πάει στη λίστα μετά το launch.

Γιατί έχει σημασία

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