Από τον επιχειρηματικό στόχο στις λειτουργικές απαιτήσεις

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

Λίστα απαιτήσεων πριν ξεκινήσει η υλοποίηση

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

Τι ανήκει στο εύρος και τι πρέπει να μείνει εκτός

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

Πλατφόρμα και λειτουργίες αφού οριστούν οι ανάγκες

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

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

Πίνακας ορισμού εύρους πριν από προσφορά

Κριτήρια αποδοχής που αποφεύγουν παρεξηγήσεις

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

Εξαρτήσεις που πρέπει να εμφανιστούν νωρίς

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

Τι πρέπει να παραδοθεί μαζί με την ιστοσελίδα

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

Έλεγχος πριν υπογραφεί το εύρος

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

Συμπέρασμα

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

Αλλαγές εύρους μετά την έναρξη

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

Παραδοτέο προδιαγραφής που μπορεί να διαβαστεί από όλους

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

Μη λειτουργικές απαιτήσεις που συχνά ξεχνιούνται

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

Πώς γράφεται ένα αίτημα αλλαγής αφού έχει ξεκινήσει το έργο

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

Προτεραιοποίηση απαιτήσεων πριν γεμίσει το έργο εξαιρέσεις

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

Μικρή σύνοψη απαιτήσεων για τελική επιβεβαίωση

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