Briefing Document: Γιατί και πώς μπορεί να σου γλιτώσει πάρα πολύ χρόνο!

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

Σήμερα θα μιλήσουμε για κάτι που αφορά όλα τα seniorities!

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

Αν και συνεχίζω να το πιστεύω ακράδαντα αυτό, σήμερα θα το πάμε ένα βήμα παραπέρα για να δούμε πώς το να χρησιμοποιήσεις 30' για ένα briefing document μπορεί να σου γλιτώσει αρκετή ώρα από back and forth κατά το implementation.

Είτε γράφεις εσύ τον κώδικα είτε ένα LLM, δεν έχει σημασία, γιατί, αν γράψεις εσύ τον κώδικα, θα δεις πόσα πράγματα που δεν έχεις σκεφτεί θα προκύψουν ενώ, αν το δώσεις σε ένα LLM, θα έχει πολύ καλύτερη κατεύθυνση και δεν θα κάνει assumptions που θα οδηγήσουν σε κάκιστο κώδικα, patches και prompts like "ΤΙ ΕΙΝΑΙ ΑΥΤΑ ΠΟΥ ΚΑΝΕΙΣ;"

Ωραία όλα αυτά στη θεωρία, αλλά πώς θα το δημιουργήσουμε στην πράξη;

Τα πράγματα είναι απλά:

• Καταγράφουμε την γενική εικόνα αυτού που σκεφτόμαστε να κάνουμε και ζητάμε από ένα LLM να μας κάνει ερωτήσεις πάνω σε αυτό.
• Καταγράφουμε τις απαντήσεις και μετά από 2-3 iterations, δίνουμε το τελικό αποτέλεσμα σε ένα άλλο session για να μας φτιάξει ένα briefing document.
• Προαιρετικά και εφόσον έχουμε χρόνο και διάθεση, δίνουμε το document σε ένα άλλο LLM για review.

Αυτή είναι η ραχοκοκκαλιά, αλλά εδώ έρχεται το ερώτημα τι πρέπει να περιέχει ένα τέτοιο document;

Εξαρτάται από αρκετά πράγματα, αλλά ας δούμε μερικές ιδέες:

• Σκοπός και πλαίσιο του project. Τι φτιάχνουμε και γιατί.
• Πρόβλημα που λύνει και τι σημαίνει επιτυχία.
• Χρήστες και βασικά use cases.
• Λειτουργικά requirements. Τι πρέπει να κάνει το σύστημα ή το προϊόν.
• Μη λειτουργικά requirements. Απόδοση, ασφάλεια, ποιότητα, περιορισμοί.
• Scope και Out of scope. Τι περιλαμβάνεται και τι όχι.
• Constraints και assumptions. Χρόνος, budget, τεχνολογία, παραδοχές.
• Κριτήρια επιτυχίας και αποδοχής. Πώς κρίνεται ότι ολοκληρώθηκε σωστά. Acceptance criteria, ρίσκα και ανοιχτά θέματα.
• High-level tech stack και αρχιτεκτονική.

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

Μάλιστα, ειδικά αν πας για vibe coding, θα με θυμηθείς!