Πώς να γράψετε ένα καλό έγγραφο σχεδιασμού λογισμικού

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

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

Το άρθρο χωρίζεται σε 4 ενότητες:

  • Γιατί να γράψετε ένα έγγραφο σχεδιασμού
  • Τι να συμπεριλάβετε σε ένα έγγραφο σχεδίασης
  • Πώς να το γράψετε
  • Η διαδικασία γύρω από αυτό

Γιατί να γράψετε ένα έγγραφο σχεδιασμού;

Ένα έγγραφο σχεδιασμού - επίσης γνωστό ως τεχνική προδιαγραφή - είναι μια περιγραφή του τρόπου με τον οποίο σκοπεύετε να λύσετε ένα πρόβλημα.

Υπάρχουν ήδη πολλά γραπτά για το γιατί είναι σημαντικό να γράψετε ένα ντιζάιν πριν από την κατάδυση στην κωδικοποίηση. Το μόνο που θα πω εδώ είναι:

Ένα έγγραφο σχεδίασης είναι το πιο χρήσιμο εργαλείο για να βεβαιωθείτε ότι γίνεται η σωστή εργασία.

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

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

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

Τι να συμπεριλάβετε σε ένα έγγραφο σχεδίασης;

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

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

Τίτλος και άτομα

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

ΣΦΑΙΡΙΚΗ ΕΙΚΟΝΑ

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

Συμφραζόμενα

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

Στόχοι και μη στόχοι

Η ενότητα στόχων πρέπει:

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

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

Ορόσημα

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

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

Start Date: June 7, 2018

Milestone 1 — New system MVP running in dark-mode: June 28, 2018

Milestone 2 - Retire old system: July 4th, 2018

End Date: Add feature X, Y, Z to new system: July 14th, 2018

Προσθέστε μια [Update]υποενότητα εδώ, εάν αλλάξει το ETA ορισμένων από αυτά τα ορόσημα, έτσι ώστε οι ενδιαφερόμενοι να μπορούν εύκολα να δουν τις πιο ενημερωμένες εκτιμήσεις.

Υφιστάμενη λύση

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

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

Προτεινόμενη λύση

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

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

Εναλλακτικές λύσεις

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

Δοκιμή, παρακολούθηση και προειδοποίηση

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

Επιπτώσεις μεταξύ ομάδων

Πώς θα αυξηθεί αυτό το κόστος κατά την κλήση και τα dev-ops;

Πόσα χρήματα θα κοστίσει;

Προκαλεί παλινδρόμηση στο σύστημα;

Εκθέτει τυχόν ευπάθειες ασφαλείας;

Ποιες είναι μερικές αρνητικές συνέπειες και παρενέργειες;

Πώς μπορεί η ομάδα υποστήριξης να το κοινοποιήσει στους πελάτες;

Ανοιχτές ερωτήσεις

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

Λεπτομερής εμβέλεια και χρονοδιάγραμμα

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

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

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

Πώς να το γράψετε

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

Γράψτε όσο πιο απλά γίνεται

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

  • Απλές λέξεις
  • Σύντομες προτάσεις
  • Λίστες με κουκκίδες ή / και αριθμημένες λίστες
  • Συγκεκριμένα παραδείγματα, όπως "Η Χρήστης Αλίκη συνδέει τον τραπεζικό της λογαριασμό και μετά ..."

Προσθέστε πολλά γραφήματα και διαγράμματα

Τα διαγράμματα μπορεί συχνά να είναι χρήσιμα για τη σύγκριση αρκετών πιθανών επιλογών και τα διαγράμματα είναι γενικά ευκολότερα στην ανάλυση από το κείμενο. Είχα καλή τύχη με το Google Drawing για τη δημιουργία διαγραμμάτων.

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

Συμπεριλάβετε αριθμούς

Η κλίμακα του προβλήματος καθορίζει συχνά τη λύση. Για να βοηθήσετε τους αναθεωρητές να κατανοήσουν την κατάσταση του κόσμου, συμπεριλάβετε πραγματικούς αριθμούς όπως # σειρών DB, # σφαλμάτων χρήστη, καθυστέρηση - και πώς αυτές οι κλίμακες με τη χρήση. Θυμάστε τις σημειώσεις Big-O;

Προσπαθήστε να είστε αστείοι

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

Εάν εσείς, όπως εγώ, έχετε πρόβλημα να είστε αστείοι, ο Joel Spolsky ( προφανώς γνωστός για τα κωμικά ταλέντα του…) έχει αυτήν την συμβουλή:

Ένας από τους ευκολότερους τρόπους για να είστε αστείο είναι να είστε συγκεκριμένοι όταν δεν απαιτείται [… Παράδειγμα:] Αντί να λέτε «ειδικά ενδιαφέροντα», πείτε «αγρότες αριστερά-αβοκάντο».

Κάντε το Skeptic Test

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

Κάντε το τεστ διακοπών

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

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

Επεξεργάζομαι, διαδικασία

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

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

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

Μετά από αυτό, καθώς αρχίζετε να έχετε κάποια ιδέα για το πώς να κάνετε το έργο σας, κάντε τα εξής:

  1. Ζητήστε από έναν έμπειρο μηχανικό ή τεχνικό ηγέτη στην ομάδα σας να είναι ο κριτής σας. Στην ιδανική περίπτωση, θα ήταν κάποιος που είναι σεβαστός και / ή εξοικειωμένος με τις ακραίες περιπτώσεις του προβλήματος. Αν χρειαστεί, δωρίστε τα με boba.
  2. Πηγαίνετε σε μια αίθουσα συνεδριάσεων με έναν πίνακα.
  3. Περιγράψτε το πρόβλημα που αντιμετωπίζετε σε αυτόν τον μηχανικό (αυτό είναι ένα πολύ σημαντικό βήμα, μην το παραλείψετε!).
  4. Στη συνέχεια, εξηγήστε την υλοποίηση που έχετε στο μυαλό σας και πείστε τους ότι είναι το σωστό να χτίσετε.

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

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

Σε αυτό το σημείωμα, σκεφτείτε να προσθέσετε εξειδικευμένους κριτικούς (όπως SRE και μηχανικούς ασφαλείας) για συγκεκριμένες πτυχές του σχεδιασμού.

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

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

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

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

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

Τέλος, ας πάρουμε πραγματικά meta για ένα δευτερόλεπτο: Πώς αξιολογούμε την επιτυχία ενός σχεδιαστικού εγγράφου;

Ο συνάδελφός μου Kent Rakip έχει μια καλή απάντηση σε αυτό: Ένα έγγραφο σχεδίασης είναι επιτυχές εάν γίνει η σωστή απόδοση επένδυσης. Αυτό σημαίνει ότι ένα επιτυχημένο έγγραφο σχεδιασμού μπορεί στην πραγματικότητα να οδηγήσει σε ένα αποτέλεσμα όπως αυτό:

  1. Ξοδεύετε 5 μέρες γράφοντας το έγγραφο του σχεδιασμού, αυτό σας αναγκάζει να σκεφτείτε διαφορετικά μέρη της τεχνικής αρχιτεκτονικής
  2. Λαμβάνετε σχόλια από σχολιαστές που Xείναι το πιο ριψοκίνδυνο μέρος της προτεινόμενης αρχιτεκτονικής
  3. Αποφασίζετε να εφαρμόσετε Xπρώτα για να διακινδυνεύσετε το έργο
  4. 3 ημέρες αργότερα, καταλαβαίνετε ότι Xείτε δεν είναι δυνατό, είτε πολύ πιο δύσκολο από ότι αρχικά σκοπεύατε
  5. Αποφασίζετε να σταματήσετε να εργάζεστε σε αυτό το έργο και να δώσετε προτεραιότητα σε άλλες εργασίες

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

Παρακαλώ αφήστε ένα σχόλιο παρακάτω εάν έχετε οποιεσδήποτε ερωτήσεις ή σχόλια! Θα ήθελα επίσης να μάθω πώς σχεδιάζετε διαφορετικά έγγραφα στην ομάδα σας.

Δίνοντας πίστωση όπου οφείλεται η πίστωση, έμαθα πολλά από τα παραπάνω συνεργαζόμενοι με μερικούς απίστευτους μηχανικούς στο Plaid (προσλαμβάνουμε! Ελάτε να σχεδιάσετε και να δημιουργήσετε μερικά γλυκά τεχνικά συστήματα μαζί μας) και την Quora.

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