Brief έργου λογισμικού: πώς παίρνετε συγκρίσιμες προσφορές

Ένα brief υπάρχει για να κάνει τις απαντήσεις συγκρίσιμες

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

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

Ξεκινήστε από το επιχειρησιακό πρόβλημα και από το πώς θα κρίνετε την επιτυχία

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

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

Περιγράψτε χρήστες, συστήματα και δεδομένα πριν από τις λειτουργίες

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

• Χρήστες: ποιοι είναι, περίπου πόσοι, πού δουλεύουν και σε ποιες συσκευές.
• Υπάρχοντα συστήματα: ποια είναι, σε ποιον ανήκουν, και αν προσφέρουν τεκμηριωμένο API ή μόνο βάση δεδομένων και εξαγωγές αρχείων.
• Δεδομένα: ποια είναι προσωπικά, εμπιστευτικά ή ρυθμιζόμενα, πού βρίσκονται σήμερα και πόσα πρέπει να μεταφερθούν.
• Λειτουργία: ποιος θα λειτουργεί το λογισμικό μετά την κυκλοφορία, και ποιους κανόνες φιλοξενίας ή cloud έχει ήδη η εταιρεία σας.
• Περιορισμοί: γλώσσες, ανάγκες προσβασιμότητας, πρότυπα ασφάλειας και κάθε προθεσμία που δεν μπορεί να μετακινηθεί, μαζί με τον λόγο της.

Δώστε ένα εύρος προϋπολογισμού και την προθεσμία που πραγματικά μετρά

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

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

Σημειώστε τι είναι δεδομένο και αφήστε τα υπόλοιπα ανοιχτά

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

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

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

Λάθη που κάνουν τις προτάσεις αδύνατο να συγκριθούν

Πολλές άχρηστες προτάσεις είναι απαντήσεις σε ένα brief που τις προκάλεσε. Αφαιρέστε αυτά τα μοτίβα πριν στείλετε το δικό σας.

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

Προσκαλέστε ερωτήσεις και διαβάστε τες ως μέρος της αξιολόγησης

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

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

Συχνές ερωτήσεις