Χειρισμός του Scope Creep και του Gold Plating σε έργα λογισμικού

Στην περίπτωση των έργων πληροφορικής, το Scope Creep (που προέρχεται από την πλευρά του ιδιοκτήτη) και το Gold Plating (που προέρχεται από τον PM, τον Scrum Master ή τους προγραμματιστές) είναι η δημοφιλής απειλή. Οι ανεξέλεγκτες αλλαγές στο έργο, η προσθήκη νέων λειτουργιών ή η εισαγωγή αλλαγών ανήκουν αναμφίβολα στις απειλές που επηρεάζουν τόσο την αποτελεσματικότητα όσο και την ταχύτητα των έργων. Στο παρελθόν είχαμε την ευκαιρία να συνεργαστούμε με νεοσύστατες επιχειρήσεις και μεγαλύτερες εταιρείες όπως η Livenation / Ticketmaster, η Stroer ή η Agora (ο μεγαλύτερος όμιλος μέσων ενημέρωσης στην Ευρώπη). Κατά τη διάρκεια αυτής της περιόδου, συντόνισα πολλά έργα πληροφορικής - ιδίως εκείνα που αφορούσαν ανάπτυξη λογισμικού. Αυτή η εμπειρία μου επέτρεψε να καταλάβω ότι δεν έχει σημασία αν εργάζεστε σε μια μικρή ή μεγάλη εταιρεία: αν θέλετε να πετύχετε, πρέπει να είστε ένα βήμα μπροστά από τον ανταγωνισμό σας.

Θα ήθελα να μοιραστώ τις απόψεις μου για την αποτελεσματική ανάπτυξη των έργα ανάπτυξης λογισμικού. Ως CCO στην Codest, υλοποιούμε καθημερινά έργα για παγκόσμιες εταιρείες σε όλο τον κόσμο. Η σωστή προσέγγιση της διαχείρισης είναι το πρώτο βασικό στάδιο που επηρεάζει αργότερα την επιτυχία του έργου. Διακρίνω τέσσερις βασικές αρχές, η διατήρηση των οποίων μας επέτρεψε να αναπτύξουμε ένα πραγματικά αποτελεσματικό μοντέλο διαχείρισης. Χάρη σε αυτές, αποφεύγουμε τα μεταγενέστερα προβλήματα - συμπεριλαμβανομένων εκείνων που σχετίζονται με το ερπυσμό και τη χρυσή φύτευση "πεδίου εφαρμογής". Αυτές είναι οι εξής:

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

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

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

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

4. Ανάπτυξη. Η κατασκευή της εφαρμογής θα πρέπει να ξεκινά με το UX, το Design, το Backend και το Frontend. Εν ολίγοις, τα πάντα ξεκινούν με τις απλές εργασίες που πρέπει να "έχουν" και οι οποίες συνθέτουν το προϊόν MVP. Αφού επιτευχθεί αυτή η φάση ανάπτυξης, μπορείτε να επικεντρωθείτε στην ανάπτυξη της λειτουργικότητας που ονομάζεται "nice to have".

Περίληψη

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

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

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