Οι διευθυντές χωρίς τεχνικό υπόβαθρο συχνά πιστεύουν ότι το κύριο πράγμα είναι να γράψουν λεπτομερείς όρους αναφοράς για προγραμματιστές και μετά από αυτό, το μόνο που απομένει είναι να τους ζητήσουμε να τηρούν αυστηρά τις προθεσμίες. Ναι, αυτό είναι σημαντικό.
Εκτός από την περιγραφή της λειτουργικότητας, οι όροι αναφοράς πρέπει να περιλαμβάνουν τις μακέτες των οθονών με πλήρως ολοκληρωμένο σχέδιο και τα κείμενα όλων των μηνυμάτων που εμφανίζονται στον χρήστη, επειδή είναι κακή ιδέα να αφήσετε το σχέδιο και το copywrit στην ανάπτυξη λογισμικού .
Αλλά το χειρότερο από όλα, αφού συζητήσετε τη λειτουργικότητα με τους προγραμματιστές, να μείνετε πίσω και να περιμένετε ήσυχα για το αποτέλεσμα. Η ανάπτυξη λογισμικού είναι μια συνεχής διαδικασία και πρέπει να κατανοήσετε ξεκάθαρα τι εργάζεστε αυτή τη στιγμή και τι απομένει να κάνετε. Όσο πιο βαθιά μπείτε στη διαδικασία, τόσο πιο πιθανό είναι να παρατηρήσετε πότε κάτι πάει στραβά.
Εστίαση στις Κύριες Λειτουργίες
Πώς μπορεί να βοηθήσει αυτό το είδος εμβάπτισης; Μία από τις πιο κοινές αιτίες ολίσθησης της προθεσμίας είναι οι απροσδόκητες δυσκολίες στην εφαρμογή μικρών και όχι και τόσο σημαντικών λειτουργιών. Οι καλοί προγραμματιστές προσπαθούν να κάνουν καλά προϊόντα, πράγμα που σημαίνει ότι εφαρμόζουν όλα τα καθορισμένα στοιχεία στην προδιαγραφή. Ως ιδεολόγος προϊόντων, μπορείτε και πρέπει να αφαιρέσετε όλες τις δευτερεύουσες λειτουργίες από το σχέδιο εάν αρχίσουν να χρειάζονται πολύ χρόνο, δηλαδή περισσότερες από μερικές ημέρες.
Μην προσθέτετε νέες εργασίες κατά την ανάπτυξη λογισμικού
Μόλις βυθιστείτε στη διαδικασία ανάπτυξης και έχετε την ευκαιρία να δείτε ενδιάμεσα αποτελέσματα, θα έχετε έντονη επιθυμία να προσθέσετε και να αλλάξετε τη λειτουργικότητα αμέσως. Μην το κάνεις ποτέ αυτό! Η προσθήκη και η τροποποίηση απαιτήσεων ζωντανά είναι το μεγαλύτερο πρόβλημα στο χρονοδιάγραμμα ανάπτυξης. Η μερική εφαρμογή λειτουργικότητας είναι πολύ πιο δύσκολο να αλλάξει.
Στο 95% των περιπτώσεων, είναι καλύτερο να παραμείνετε εντός του αρχικού σχεδίου και να δοκιμάσετε μια νέα δυνατότητα που σχεδιάστηκε σε ζωντανούς χρήστες. Και μετά κάντε αλλαγές με βάση τα σχόλια.
Ελέγξτε τις προσπάθειες των προγραμματιστών
Με την πάροδο του χρόνου, θα εκτιμήσετε πόσο χρόνο διαρκεί μια εργασία και θα είναι πιο ακριβής από το ομάδα ανάπτυξης λογισμικούαποτελέσματα του. Για παράδειγμα, νέες δυνατότητες προστίθενται σχετικά γρήγορα, ενώ ο επανασχεδιασμός παλιών λειτουργιών κατά τη μετατροπή υπαρχόντων δεδομένων χρήστη είναι πάντα αργός και ενοχλητικός. Το να μάθετε να παρουσιάζετε περισσότερο ή λιγότερο ρεαλιστικές προθεσμίες δεν είναι τόσο δύσκολο. είναι πιο δύσκολο να τους επηρεάσεις.
Η τελειομανία είναι μια ψυχολογική ιδιότητα που διακρίνει τους καλούς προγραμματιστές από τους κακούς. Δεν ισχύει μόνο για τις οθόνες και τα κουμπιά ορατών αποτελεσμάτων αλλά και για την εσωτερική υλοποίηση του προϊόντος, δηλαδή τον κώδικα.
Για παράδειγμα, πρέπει να προσθέσετε έναν μηχανικό ενεργειών μπόνους στη σελίδα πληρωμής. Ένας καλός προγραμματιστής θα μπορούσε να εφαρμόσει σε μια εβδομάδα έναν μηχανισμό που υποστηρίζει οποιαδήποτε ενέργεια που διαχειρίζεται από τον πίνακα διαχείρισης, με προσαρμόσιμες συνθήκες, χρονισμό κ.λπ.
Χρειάζεστε όμως μια γρήγορη λύση για να ξεκινήσετε την προώθηση αύριο και να πετάξετε αυτόν τον κωδικό για πάντα μια εβδομάδα αργότερα. Πρέπει να κατανοήσετε ποια εξαρτήματα θα παραμείνουν στο προϊόν σας για μεγάλο χρονικό διάστημα και ποια μπορούν να εφαρμοστούν για σκοπούς απόρριψης και να το κοινοποιήσετε ξεκάθαρα στην ομάδα ανάπτυξης λογισμικού.
Ταξινομήστε τις εργασίες και μην τις ορίζετε όλες ταυτόχρονα
Οι εργασίες για την ομάδα ανάπτυξης λογισμικού χωρίζονται σε μεγάλες (για να δημιουργήσετε μια νέα δυνατότητα) και σε μικρές (για να διορθώσετε τη φόρμα εγγραφής). Ο γενικός κανόνας είναι να μην αποσπάτε ποτέ την προσοχή ενός προγραμματιστή από μια τεράστια εργασία για να λύσετε μια μικρή, ακόμη και μια επείγουσα.
Ορισμένοι μοναδικοί επαγγελματίες μπορούν να εργαστούν αποτελεσματικά σε μια τέτοια λειτουργία, αλλά οι περισσότεροι προγραμματιστές μειώνουν δραστικά την παραγωγικότητα λόγω της συνεχούς εναλλαγής μεταξύ εργασιών. Επομένως, είναι λογικό να έχετε μια εναλλαγή - πρώτα μια τεράστια εργασία και μετά μια εβδομάδα μικρών εργασιών. Καταγράψτε μικρές εργασίες όπως εμφανίζονται, αλλά δώστε τις στην ανάπτυξη λογισμικού για να τις συμπεριλάβετε σε μια λίστα όταν προγραμματιστεί η επόμενη επανάληψη ή κυκλοφορία.
Κάθε προγραμματιστής είναι διαφορετικός
Η διαφορά στην απόδοση μεταξύ μεμονωμένων προγραμματιστών μπορεί να είναι τεράστια. Για παράδειγμα, σε ορισμένες μελέτες, η έκδοση των καλύτερων και των χειρότερων προγραμματιστών με την ίδια περίπου εμπειρία διέφερε δεκαπλάσια.
Πρέπει να καταλάβετε ότι το ίδιο άτομο μπορεί να δείξει εξαιρετική ταχύτητα σε εργασίες εντός ενός σχεδίου (π.χ. επεκτάσεις διεπαφής) και καταστροφικά χαμηλή ταχύτητα σε άλλες εργασίες (εργασίες μεγάλης κλίμακας από την πλευρά του διακομιστή). Έτσι σε όλους θα πρέπει να ανατεθούν καθήκοντα με τα οποία αισθάνονται άνετα. Διαφορετικά, η παραγωγικότητα θα μειωθεί.
Γίνετε Βοηθός των Προγραμματιστών
Ένα σημαντικό πράγμα θα σας βοηθήσει να μιλάτε την ίδια γλώσσα με τους προγραμματιστές. Οι περισσότεροι τεχνικοί άνθρωποι έχουν πολύ οργανωμένο και λογικό μυαλό. χωρούν σε ένα λογικό σχήμα. Αλλά αυτό το σχήμα δεν θα είναι πάντα βολικό για τους χρήστες σας.
Ως μη τεχνικό άτομο, έχετε ένα πλεονέκτημα — είναι πιο εύκολο για εσάς να υπερβείτε το πλαίσιο που προτείνει η υλοποίηση και να επικοινωνήσετε με τους προγραμματιστές το σωστό όραμα. Αλλά να θυμάστε: για να μεταδώσετε την άποψή σας στην ομάδα ανάπτυξης λογισμικού, θα πρέπει να αποδείξετε τις ιδέες σας σωστές με λογικά επιχειρήματα.
Αφιερώστε χρόνο για εσωτερικές αλλαγές
Πρέπει να θυμάστε ότι υπάρχουν χρονοβόρες εργασίες που δεν μπορείτε να δείτε από έξω σε κανένα έργο, αλλά πρέπει να τις κάνετε. Είναι το λεγόμενο τεχνικό χρέος. Πώς σχηματίστηκε; Με την προσθήκη νέων χαρακτηριστικών, το έργο αποκτά δεκανίκια και στηρίγματα.
Πολλές εργασίες επιλύονται γρήγορα αλλά με αναξιόπιστο τρόπο. Για παράδειγμα, εάν δεν φέρνετε τακτικά σε τάξη τον κώδικά σας (αυτή η διαδικασία ονομάζεται refactoring) και δεν αναπτύξετε την αρχιτεκτονική του έργου, θα αυξάνονται συνεχώς τα σφάλματα μετά από κάποιο χρονικό διάστημα.
Μπορεί να προκύψουν κατά την προσθήκη νέων λειτουργιών ή ακόμα και κατά την επιδιόρθωση παλαιών σφαλμάτων. Εάν δεν αφιερώσετε χρόνο στην ανάπτυξη της αρχιτεκτονικής του έργου, δεν θα μπορείτε να αντιμετωπίσετε τον αυξανόμενο αριθμό χρηστών αργά ή γρήγορα.
Οι εργασίες τεχνικού χρέους πρέπει να προγραμματιστούν και να εκτελεστούν, αλλά πώς βρίσκετε τη σωστή ισορροπία μεταξύ αυτών και της ανάπτυξης προϊόντων; Φυσικά, η εστίασή σας ως χρηματοδότη και μη τεχνικό άτομο θα μετατοπιστεί σε νέα χαρακτηριστικά. Αλλά από την άλλη πλευρά, οι προγραμματιστές τείνουν να βελτιώνουν τον υπάρχοντα κώδικα απεριόριστα και είναι λιγότερο ενθουσιώδεις με τη νέα λειτουργικότητα.
Επομένως, πρέπει ακόμα, τουλάχιστον σε βασικό επίπεδο, να κατανοήσετε την τεχνολογία και τη δομή του προϊόντος σας για να βρείτε μια ισορροπία στις συζητήσεις με τους προγραμματιστές. Οι τεχνικές εργασίες πρέπει να καταλαμβάνουν περίπου το 20% των ωρών εργασίας της ομάδας ανάπτυξης λογισμικού και να συμβαδίζουν με την ανάπτυξη νέων λειτουργιών και τη διόρθωση σφαλμάτων.
Μάθετε για την τεχνολογία
Για να αναπτύξετε ένα προϊόν, πρέπει να μελετήσετε τη δομή του και την τεχνολογία γενικότερα, τουλάχιστον σε βασικό επίπεδο. Είναι ζωτικής σημασίας γιατί η τεχνολογία μπορεί να είναι ακόμα ζωντανή αλλά όχι αρκετά κατάλληλη για τις εργασίες σας. Και είναι συχνά αδύνατο να το ανακαλύψετε πριν ξεκινήσετε το σύστημα σε λειτουργία μάχης — με πραγματικούς χρήστες και κάτω από μεγάλα φορτία.
Συνοψίζοντας, δεν μπορείτε ακόμα να κάνετε χωρίς να εμβαθύνετε στην τεχνολογία και την ανάπτυξη λογισμικού ως χρηματοδότης. Επιπλέον, αυτή η γνώση θα σας δώσει μια καλύτερη κατανόηση του τρόπου με τον οποίο αναπτύσσεται το έργο σας.
