Η άσχημη αλήθεια για τη διαδικασία ανάπτυξης λογισμικού

πηγή εικόνας: perfectdigital.com

Ξέρετε αυτή την εικόνα, σωστά;

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

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

1. Πώς εξήγησε ο πελάτης την ιδέα;

Θα υπάρχουν αποκλίσεις στο όραμα του προϊόντος από την αρχή. Γιατί; Ο λόγος είναι πολύ απλός - ο καθένας ερμηνεύει την πραγματικότητα με τον δικό του τρόπο, έχει μια ιδέα για κάτι στο μυαλό του και μπορεί να μην παρουσιάσει με ακρίβεια αυτό το όραμα στο άλλο μέρος. Αν περιγράψετε με λόγια ένα προϊόν που θα θέλατε να κατασκευάσετε, υπάρχει μεγάλη πιθανότητα η ομάδα ανάπτυξης να κατανοήσει το όραμά σας με διαφορετικό τρόπο από αυτόν που εσείς θέλατε.

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

2. Πώς το κατανόησε ο επικεφαλής του έργου;

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

3. Πώς το σχεδίασε ο αναλυτής; και 4. Πώς το έγραψε ο προγραμματιστής;

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

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

Πώς να το αλλάξετε αυτό; Νομίζω ότι μια καλή λύση είναι να βεβαιωθείτε ότι οι άνθρωποι που είναι βασικοί για το έργο έχουν λεπτομερή γνώση για το έργο - τη λεγόμενη "ευρύτερη εικόνα". Σε περίπτωση παρεξηγήσεων, θα είναι ευκολότερο γι' αυτούς να φέρουν το διαδικασία ανάπτυξης λογισμικού πίσω στο σωστό δρόμο. Επομένως, να θυμάστε - αν ο καθένας βλέπει μόνο το δικό του μικρό κομμάτι της αναπτυγμένης λειτουργικότητας, οι παρεξηγήσεις στο όραμα γίνονται μια πιθανή απειλή.

5. Πώς το περιέγραψε ο σύμβουλος επιχειρήσεων;

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

6. Πώς τεκμηριώθηκε το έργο;

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

7. Ποιες λειτουργίες εγκαταστάθηκαν;

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

8. Πώς χρεώθηκε ο πελάτης;

Είναι το αποτέλεσμα της κακής επικοινωνίας, της έλλειψης UX και ούτω καθεξής. Η εμφάνιση σφαλμάτων αυξάνει τον χρόνο ανάπτυξης. Και ο χρόνος είναι χρήμα, σωστά; Η συμβουλή μου είναι να εκτελέσω το έργο σύμφωνα με την ευέλικτη, να διατηρείτε τα υψηλότερα πρότυπα επικοινωνίας και να τηρείτε σαφείς κατευθυντήριες γραμμές για τον προϋπολογισμό. Δεν έχω καμία αμφιβολία ότι με αυτόν τον τρόπο θα αποφύγετε τέτοια προβλήματα.

9. Πώς υποστηρίχθηκε;

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

10. Τι χρειαζόταν πραγματικά ο πελάτης;

Φτάσαμε στο τελευταίο σημείο. Κοιτάξτε την απόκλιση μεταξύ του πρώτου και του τελευταίου γραφήματος. Εξάλλου, και τα δύο αφορούν την οπτική γωνία του πελάτη. Γιατί συμβαίνει αυτό; Όλοι ψεύδονται τόσο απλά 🙂 Τα αποτελέσματα των ερευνών διαφέρουν πάντα από τις πραγματικές ανάγκες των ερωτηθέντων σας. Ενώ απαντούν στην ερώτηση του ερευνητή, οι χρήστες θέλουν να δείξουν την καλύτερη πλευρά τους. Ως εκ τούτου, ΣΥΧΝΆ ΔΕΝ ΑΠΑΝΤΟΎΝ ΜΕ ΕΙΛΙΚΡΊΝΕΙΑ, αλλά μάλλον με τον τρόπο που νομίζουν ότι πρέπει να απαντήσουν. Βασικά, δεν θέλουν να εκτεθούν στην αρνητική αξιολόγηση των άλλων. Να μια μικρή συμβουλή για εσάς - αναφέρετε στις οδηγίες ότι δεν υπάρχουν ούτε καλές ούτε κακές απαντήσεις.

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

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

Περίληψη

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

- καλό UX και δοκιμές, ώστε να μάθετε τι πραγματικά χρειάζονται οι χρήστες σας,

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

- να αναπτύξει το προϊόν σύμφωνα με Ευέλικτη,

- μην ξεχνάτε την τεχνική υποστήριξη.

Διαβάστε περισσότερα:

– Πώς να διαχειρίζεστε αποτελεσματικά τους απομακρυσμένους προγραμματιστές; Ο οδηγός για τους CTOs

– Python vs. Ruby? Ποια τεχνολογία πρέπει να χρησιμοποιήσετε για την ανάπτυξη προϊόντων;

– Ένας γρήγορος οδηγός για τη δημιουργία και την ανάπτυξη της δικής σας αγοράς. Τι αξίζει να γνωρίζετε;