Ένα software project μπορεί να μπει σε δύσκολη τροχιά πριν ξεκινήσει το development. Συνήθως δεν φταίει μία μεμονωμένη τεχνική επιλογή. Το ρίσκο μεγαλώνει όταν η ομάδα δεν έχει συμφωνήσει ποιο πρόβλημα λύνει, ποιος παίρνει τις αποφάσεις και πώς θα κρίνει αν η λύση λειτουργεί. Η προετοιμασία δεν χρειάζεται να είναι ατελείωτη. Χρειάζεται όμως να δώσει κοινή κατεύθυνση πριν δεσμευτούν χρόνος και πόροι.
Το αίτημα δεν είναι πάντα το πραγματικό πρόβλημα
«Χρειαζόμαστε μια εφαρμογή» περιγράφει πιθανή λύση, όχι απαραίτητα την ανάγκη. Η πρώτη συζήτηση πρέπει να εντοπίσει ποια εργασία καθυστερεί, ποιος επηρεάζεται και τι συμβαίνει σήμερα. Αν το πρόβλημα είναι ότι δύο υπάρχοντα εργαλεία δεν ανταλλάσσουν σωστά δεδομένα, μια εντελώς νέα εφαρμογή ίσως δεν είναι το σωστό πρώτο βήμα.
Γράψτε μια σύντομη δήλωση προβλήματος που να μπορεί να επιβεβαιώσει και ο άνθρωπος που εκτελεί τη διαδικασία, όχι μόνο η διοίκηση. Προσθέστε τι θα ήταν καλύτερο στην πράξη αν το έργο πετύχει.
Ποιος αποφασίζει και ποιος θα το χρησιμοποιεί;
Οι άνθρωποι που εγκρίνουν το budget, χειρίζονται καθημερινά το σύστημα και το συντηρούν μπορεί να έχουν διαφορετικές προτεραιότητες. Αν αυτές δεν συζητηθούν νωρίς, οι διαφωνίες εμφανίζονται αργότερα ως «αλλαγές απαιτήσεων». Συμφωνήστε ποιος είναι ο υπεύθυνος του έργου από την πλευρά της επιχείρησης, ποιος εγκρίνει αλλαγές και ποιοι χρήστες πρέπει να δοκιμάσουν τα πρώτα αποτελέσματα.
Δεν χρειάζεται κάθε απόφαση να περνά από όλους. Χρειάζεται όμως να είναι σαφές ποιος δίνει πληροφορίες, ποιος αποφασίζει και πότε η ομάδα ζητά επιβεβαίωση.
Ορίστε την πρώτη έκδοση και τα όριά της
Μια λίστα επιθυμητών λειτουργιών δεν είναι ακόμη εφαρμόσιμο scope. Ξεχωρίστε τι είναι απαραίτητο για την πρώτη χρήσιμη έκδοση, τι μπορεί να ακολουθήσει και τι μένει εκτός. Για κάθε βασική λειτουργία, περιγράψτε ένα πραγματικό σενάριο: ποιος ξεκινά, τι εισάγει, ποιο αποτέλεσμα περιμένει και τι γίνεται αν κάτι αποτύχει.
Αυτή η δουλειά βοηθά να διακρίνετε την επιχειρηματική απαίτηση από την τεχνική υπόθεση. Η τεχνική λύση μπορεί να αλλάξει χωρίς να χαθεί ο αρχικός στόχος.
Ελέγξτε δεδομένα και συνδέσεις πριν υποσχεθείτε χρονοδιάγραμμα
Πού βρίσκονται σήμερα τα δεδομένα; Είναι σωστά, διαθέσιμα και επιτρέπεται να χρησιμοποιηθούν στη νέα ροή; Ποιες υπάρχουσες εφαρμογές πρέπει να συνδεθούν και ποιος έχει πρόσβαση στις σχετικές τεχνικές πληροφορίες; Ένα άγνωστο API, μια δύσκολη μεταφορά δεδομένων ή ασαφή δικαιώματα μπορούν να επηρεάσουν τον σχεδιασμό περισσότερο από μια ορατή λειτουργία στην οθόνη.
Καταγράψτε τις αβεβαιότητες ως ερωτήματα προς διερεύνηση. Μην τις κρύβετε μέσα σε μια πρόωρη εκτίμηση.
Δοκιμάστε την υπόθεση με μικρό, ελέγξιμο βήμα
Πριν δεσμευτείτε για ολόκληρη την υλοποίηση, επιλέξτε μια κρίσιμη ροή για πρωτότυπο, τεχνική διερεύνηση ή πιλοτική δοκιμή. Ορίστε τι πρέπει να μάθετε από αυτήν: αν οι χρήστες καταλαβαίνουν τη ροή, αν τα δεδομένα είναι αξιοποιήσιμα ή αν μια σύνδεση λειτουργεί όπως αναμένεται. Το πιλοτικό βήμα δεν είναι εγγύηση επιτυχίας. Είναι τρόπος να πάρετε καλύτερη απόφαση με λιγότερες άγνωστες παραμέτρους.
Στη συνέχεια, συμφωνήστε συγκεκριμένα checkpoints όπου ο πελάτης βλέπει αποτέλεσμα, δοκιμάζει και δίνει feedback. Δείτε πώς δουλεύουμε για τη λογική των σταδίων και της συμμετοχής του πελάτη.
Τι μπορεί να αναλάβει η IDBS;
Η IDBS βοηθά να μετατραπεί η επιχειρηματική ανάγκη σε σαφείς απαιτήσεις, ρόλους, προτεραιότητες και στάδια. Μπορεί να συντονίσει ή να επιβλέψει ένα έργο μαζί με την υπάρχουσα ομάδα σας, χωρίς να είναι απαραίτητο να αντικατασταθούν οι συνεργάτες σας. Η διαχείριση και καθοδήγηση ψηφιακών έργων καλύπτει τόσο νέες ιδέες όσο και έργα που χρειάζονται εκ νέου κατεύθυνση.
Αν το δικό σας έργο βρίσκεται ακόμη στο «ξέρουμε τι μας ενοχλεί, αλλά όχι τι πρέπει να φτιάξουμε», περιγράψτε μας την ανάγκη. Η πρώτη χρήσιμη απόφαση μπορεί να είναι η αποσαφήνιση του προβλήματος, όχι η άμεση έναρξη του development.