Πρότυπο συλλογής απαιτήσεων: 7 κόλπα που χρησιμοποιώ στα έργα

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

Κάποτε είδα ένα έργο έξι ψηφίων να καταρρέει επειδή κανείς δεν έκανε σωστά τις απαιτήσεις. Ο πελάτης περίμενε ένα πράγμα. Η ομάδα ανάπτυξης έφτιαξε άλλο. Όλοι έγιναν αποδιοπομπαίοι τράγοι και τότε με κάλεσαν.

Το μοτίβο δεν είναι ασυνήθιστο. Η έκθεση Pulse of the Profession του PMI για το 2014 σχετικά με τη διαχείριση απαιτήσεων διαπίστωσε ότι το 47% των ανεπιτυχών έργων δεν πέτυχε τους στόχους του λόγω κακής διαχείρισης απαιτήσεων. Το έχω δει να επαναλαμβάνεται δεκάδες φορές.

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

Η εταιρεία ενός φίλου ξόδεψε 350 χιλ. $ σε ένα ειδικό CRM που δεν το χρησιμοποιεί κανείς. Οι πωλήσεις χρειάζονταν ένα πράγμα, το μάρκετινγκ ήθελε άλλο και οι προγραμματιστές έφτιαξαν ό,τι νόμιζαν ότι ήθελαν όλοι.

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

Η καθυστερημένη ανακάλυψη κοστίζει ακριβά. Μια μελέτη της NASA για την κλιμάκωση του κόστους σφαλμάτων διαπίστωσε ότι ένα σφάλμα απαιτήσεων που εντοπίστηκε στην ολοκλήρωση και στις δοκιμές κόστιζε από 21 έως 78 φορές περισσότερο για να διορθωθεί από ένα που εντοπίστηκε κατά τις απαιτήσεις. Όταν εντοπίστηκε στη λειτουργία, το πολλαπλάσιο κυμαινόταν από 29 έως περισσότερο από 1.500. Σε ένα εταιρικό πρόγραμμα, αυτή είναι η διαφορά ανάμεσα σε ένα workshop και ένα αίτημα αλλαγής αξίας εκατοντάδων χιλιάδων.

1. ΑπαιτήσειςΤο βασικό κόστος διόρθωσηςΕντοπίζεται όσο οι απαιτήσεις ακόμη γράφονται
2. Ολοκλήρωση και δοκιμές21 έως 78 φορές το κόστοςΕντοπίζεται όταν το σύστημα έχει χτιστεί και δοκιμάζεται
3. Λειτουργία29 έως περισσότερο από 1.500 φορές το κόστοςΕντοπίζεται αφού το σύστημα έχει τεθεί σε λειτουργία

Πηγή: Μελέτη της NASA για την κλιμάκωση του κόστους σφαλμάτων

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

1. Εκτελεστική περίληψη με πλαίσιο υπογραφών

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

2. Χαρτογράφηση ρόλων και επιρροής

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

3. Επιχειρηματικοί στόχοι, όχι τεχνικές απαιτήσεις

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

4. Λειτουργικές απαιτήσεις που μπορούν να χρησιμοποιήσουν οι προγραμματιστές

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

5. Μη λειτουργικές απαιτήσεις

Επιδόσεις, ασφάλεια, συμμόρφωση, διαθεσιμότητα, κλιμακωσιμότητα. Αυτή είναι η ενότητα που σχεδόν όλοι παραλείπουν και μετά το σύστημα καταρρέει υπό φορτίο ή αποτυγχάνει σε έλεγχο ασφάλειας. Άκουσα για ένα έργο λιανικής όπου το σύστημα δούλευε άψογα μέχρι τη Black Friday, όταν κατέρρευσε υπό φορτίο επειδή κανείς δεν είχε προδιαγράψει απαιτήσεις επιδόσεων. Γράψτε τους χρόνους απόκρισης, τη διαθεσιμότητα (uptime), τα φορτία αιχμής χρηστών και τις υποχρεώσεις συμμόρφωσης ως αριθμούς.

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

Ενότητα	Τι περιλαμβάνει	Υπεύθυνος	Εγκρίνεται από
1. Εκτελεστική περίληψη	Πρόβλημα, επιχειρηματικός αντίκτυπος, χρονοδιάγραμμα, πόροι, αναμενόμενο όφελος. Μία σελίδα με πλαίσιο υπογραφών	Χορηγός, σύνταξη από τον επικεφαλής BA	Χορηγός και οικονομικά
2. Εύρος και βάση αναφοράς υλοποίησης	Εντός και εκτός εύρους, περιορισμοί. Για το SAP: public edition, private edition ή on-premise	Διευθυντής προγράμματος	Επιτροπή καθοδήγησης
3. Χάρτης ρόλων και επιρροής	Τμήματα, εκπρόσωποι, επίπεδο επιρροής, διαβούλευση ή ενημέρωση	Επικεφαλής BA	Χορηγός
4. Επιχειρηματικοί στόχοι	Κάθε στόχος με KPI, τη σημερινή βάση αναφοράς και έναν στόχο	Ιδιοκτήτες διαδικασιών	Χορηγός
5. Λειτουργικές απαιτήσεις	ID (π.χ. REQ-FUN-023), περιγραφή, προέλευση, προτεραιότητα, κριτήρια αποδοχής, απόφαση fit-to-standard	Επικεφαλής λειτουργικών	Ιδιοκτήτες διαδικασιών
6. Μη λειτουργικές απαιτήσεις	Επιδόσεις, ασφάλεια, συμμόρφωση, διαθεσιμότητα, για το SAP η προσέγγιση επέκτασης για κάθε κενό	Αρχιτέκτονας λύσης	IT, ασφάλεια και συμμόρφωση
7. Parking lot	Αιτήματα που αναβλήθηκαν, ποιος τα ζήτησε, ημερομηνία επόμενης αναθεώρησης	Επικεφαλής BA	Κανείς μέχρι την προαγωγή
8. Αρχείο απορριφθέντων	Τι απορρίφθηκε, γιατί, πότε και από ποιον	Επικεφαλής BA	Χορηγός
9. Αρχείο αλλαγών	Κάθε αλλαγή μετά την έγκριση με τον αντίκτυπό της σε χρόνο και κόστος	PMO	Επιτροπή αλλαγών

1. Χρησιμοποιήστε τα Πέντε Γιατί στις συνεντεύξεις με τα ενδιαφερόμενα μέρη

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

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

2. Φτιάξτε ένα parking lot απαιτήσεων

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

3. Εφαρμόστε τον κανόνα του τρία σε όσους αλλάζουν συνεχώς γνώμη

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

4. Χρησιμοποιήστε την τεχνική κατανομής χρηματοδότησης για να επιβάλλετε ιεράρχηση

Δώστε σε κάθε ενδιαφερόμενο μέρος 100 εικονικά δολάρια να τα μοιράσει σε όλες τις απαιτήσεις. Δεν μπορούν να τα έχουν όλα, οπότε βάζουν χρήματα εκεί που μετράει. Το έκανα με έναν πελάτη χρηματοπιστωτικών υπηρεσιών που είχε περισσότερες από 200 «κρίσιμες» απαιτήσεις. Μέσα σε μία ώρα είχαμε το πραγματικό top 20.

5. Αριθμήστε κάθε απαίτηση

Χρησιμοποιήστε μια συνεπή μορφή όπως REQ-FUN-023. Τερματίζει τη σύγχυση «για ποια απαίτηση μιλάμε;» που σπαταλά χρόνο στις συσκέψεις. Καταγράψτε την προέλευση, ποιος τη ζήτησε και γιατί, ώστε να ξέρετε ποιον να πάρετε τηλέφωνο όταν χρειαστεί να κοπούν στοιχεία.

6. Επαναλάβετε τις απαιτήσεις στη γλώσσα του ενδιαφερόμενου μέρους

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

7. Τεκμηριώστε ό,τι απορρίφθηκε

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

Τα επτά κόλπα δουλεύουν σε κάθε έργο. Τα προγράμματα SAP χρειάζονται τρία επιπλέον πράγματα στο πρότυπο.

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

Καταγράψτε το μοντέλο υλοποίησης πριν συλλέξετε λειτουργικές απαιτήσεις: S/4HANA Cloud Public Edition (μέσω GROW with SAP ή RISE), Private Edition (συνήθως μέσω RISE) ή on-premise. Καθορίζει τι είναι εφικτό. Η public edition δεν επιτρέπει καμία τροποποίηση του πυρήνα, επομένως οι απαιτήσεις που βασίζονται σε μη τυπικές διαδικασίες πρέπει να αναδιαμορφωθούν ή να απορριφθούν. Η private edition και το on-premise επιτρέπουν περισσότερα, με αντάλλαγμα την προσπάθεια αναβάθμισης.

Αν συλλέξετε απαιτήσεις πριν από αυτή την απόφαση, θα ξαναγράψετε πολλές από αυτές όταν ληφθεί.

Μια απόφαση επέκτασης για κάθε κενό

Η προσέγγιση Clean Core της SAP σημαίνει ότι κάθε κενό χρειάζεται μια καταγεγραμμένη απόφαση: παραμετροποίηση, επέκταση με δημοσιευμένα (released) APIs (on-stack με ABAP Cloud ή side-by-side στο SAP BTP) ή απόρριψη. Στην public edition αυτό επιβάλλεται από το ίδιο το προϊόν. Στην private edition και στο on-premise είναι ισχυρή καθοδήγηση της SAP και κάθε τροποποίηση που επιτρέπετε γίνεται αργότερα δουλειά αναβάθμισης. Βάλτε την απόφαση στην ενότητα 6 του προτύπου, δίπλα στις επιδόσεις και στην ασφάλεια, και δώστε σε έναν αρχιτέκτονα την εξουσία να την εγκρίνει. Ο οδηγός μου για το Clean Core εξηγεί τα επίπεδα.

Η AI συντάσσει, οι άνθρωποι αποφασίζουν

Η AI βοηθά πλέον με τη γραφειοκρατία. Το SAP Cloud ALM προσφέρει μια λειτουργία παραγωγής απαιτήσεων που συντάσσει απαιτήσεις από απομαγνητοφωνήσεις workshops fit-to-standard σε ένα πρότυπο, με χρέωση μέσω μονάδων AI (AI units). Γενικοί βοηθοί όπως το Microsoft Copilot συντάσσουν περιλήψεις και πρακτικά από σημειώσεις συσκέψεων.

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

Ανάπτυξη λογισμικού. Προσθέστε τεχνικούς περιορισμούς, σημεία ενοποίησης, ροές χρηστών (τα πραγματικά βήματα που κάνουν οι χρήστες, όχι μόνο οι λειτουργίες) και κριτήρια αποδοχής επιτυχίας/αποτυχίας. Το παραβλέψαμε σε ένα έργο πύλης πελατών και περάσαμε τρεις μήνες διαφωνώντας για το αν οι λειτουργίες «δούλευαν σωστά».

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

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

Για μικρότερα έργα: Trello για να κινούνται οι απαιτήσεις μέσα από τα στάδια έγκρισης, Google Docs με σχόλια για την αναθεώρηση και Miro για τη χαρτογράφηση διαδικασιών στα workshops.

Για εταιρικά προγράμματα: Jira με πρόσθετο διαχείρισης απαιτήσεων, Confluence για ζωντανά έγγραφα (οι λειτουργίες AI του ανήκουν πλέον στη μάρκα Rovo της Atlassian) και Modern Requirements αν τρέχετε Azure DevOps. Στα προγράμματα SAP, το SAP Cloud ALM κρατά απαιτήσεις, user stories και test cases σε ένα σημείο, συνδεδεμένα με τον οδικό χάρτη του SAP Activate.

Το εργαλείο μετράει λιγότερο από τη σύνδεση. Συνδέστε τις απαιτήσεις με το σχέδιο του έργου και με τα test cases και στείλτε αυτόματες ειδοποιήσεις όταν αλλάζει μια απαίτηση. Το «δεν ήξερα ότι άλλαξε» σκοτώνει περισσότερα έργα από τα κακά εργαλεία. Μόλις εγκριθούν οι απαιτήσεις, ο οδηγός μου για την αποφυγή του scope creep στις υλοποιήσεις SAP καλύπτει το πώς θα μείνουν έτσι και οι πύλες ποιότητας SAP δείχνουν πού χωράει η έγκριση απαιτήσεων στον κύκλο διακυβέρνησης.

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

Ποια είναι τα 5 στάδια της συλλογής απαιτήσεων;

1. Εξαγωγή απαιτήσεων (elicitation): συλλογή πληροφοριών μέσω συνεντεύξεων, workshops και παρατήρησης
2. Ανάλυση: οργάνωση, ιεράρχηση και επίλυση συγκρούσεων μεταξύ απαιτήσεων
3. Τεκμηρίωση: σύνταξη της προδιαγραφής (BRD, FRD ή user stories, ανάλογα με τη μέθοδο)
4. Επικύρωση: επιβεβαίωση ότι οι απαιτήσεις αντανακλούν πραγματικές ανάγκες και μπορούν να δοκιμαστούν
5. Διαχείριση: παρακολούθηση των αλλαγών για το υπόλοιπο του έργου

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

Ποια είναι η διαφορά ανάμεσα σε ένα BRD και ένα FRD;

Ένα Business Requirements Document (BRD) καλύπτει τις επιχειρηματικές ανάγκες: υπόβαθρο, στόχους, ενδιαφερόμενα μέρη, περιορισμούς και απαιτήσεις υψηλού επιπέδου. Απαντά στο «τι χρειάζεται η επιχείρηση;»

Ένα Functional Requirements Document (FRD) καλύπτει πώς θα συμπεριφέρεται το σύστημα: user stories, συμπεριφορά συστήματος, διεπαφές και κριτήρια αποδοχής. Απαντά στο «τι πρέπει να κάνει το σύστημα;»

Ξεκινώ πάντα με το BRD για να πετύχω επιχειρηματική ευθυγράμμιση πριν από το FRD. Οι ομάδες που πηδούν κατευθείαν στο FRD χτίζουν συχνά ένα τεχνικά σωστό σύστημα που λύνει λάθος πρόβλημα.

Ποιοι είναι οι 3 τύποι απαιτήσεων;

1. Επιχειρηματικές απαιτήσεις: γιατί υπάρχει το έργο, οι στόχοι και τα μέτρα επιτυχίας του
2. Λειτουργικές απαιτήσεις: τι πρέπει να κάνει το σύστημα
3. Μη λειτουργικές απαιτήσεις: πόσο καλά πρέπει να το κάνει (επιδόσεις, ασφάλεια, κλιμακωσιμότητα, συμμόρφωση)

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

Πώς αλλάζει το μοντέλο υλοποίησης SAP τη συλλογή απαιτήσεων;

Καταγράψτε το πρώτο. Το S/4HANA Cloud Public Edition δεν επιτρέπει καμία τροποποίηση του πυρήνα, επομένως οι απαιτήσεις που βασίζονται σε μη τυπικές διαδικασίες πρέπει να αναδιαμορφωθούν ή να απορριφθούν. Η Private Edition και το on-premise επιτρέπουν μεγαλύτερη ευελιξία, αλλά κάθε τροποποίηση προσθέτει προσπάθεια αναβάθμισης.

Αν συλλέξετε λειτουργικές απαιτήσεις πριν από την απόφαση, θα ξαναδουλέψετε πολλές από αυτές. Προσθέστε μια καταγεγραμμένη απόφαση επέκτασης (παραμετροποίηση, επέκταση μέσω δημοσιευμένων APIs ή απόρριψη) για κάθε κενό.

Τι κάνει μια απαίτηση ελέγξιμη;

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

Το δικό μου τεστ: μπορείτε να γράψετε το test case αυτή τη στιγμή, με σαφή κριτήρια επιτυχίας/αποτυχίας; Αν όχι, ξαναγράψτε την απαίτηση. Οι μη ελέγξιμες απαιτήσεις προκαλούν περισσότερες διαφωνίες στο go-live από οτιδήποτε άλλο βλέπω.

Πώς αποτρέπετε τις συνεχείς αλλαγές στις απαιτήσεις;

1. Έλεγχος αλλαγών: κάθε αλλαγή μετά την έγκριση τεκμηριώνει τον αντίκτυπό της σε χρόνο, προϋπολογισμό και πόρους πριν την εγκρίνει κανείς. Κάντε ορατό το κόστος της αλλαγής.
2. Parking lot: τα νέα αιτήματα πάνε στο parking lot, όχι κατευθείαν στο εύρος. Αναθεωρήστε μηνιαία. Τα περισσότερα αιτήματα που φαίνονται επείγοντα δεν αντέχουν την αναμονή.
3. Πύλες ποιότητας: ορίστε τι σημαίνει «απαιτήσεις ολοκληρωμένες» και μην ξεκινήσετε τον σχεδιασμό μέχρι να ικανοποιηθεί.

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