Δύο πειθαρχίες, ένα ενιαίο αποτέλεσμα

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

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

Αρχιτεκτονική πληροφορίας πριν από τις οθόνες

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

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

Λειτουργικές απαιτήσεις με σαφή είσοδο και έξοδο

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

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

Δεδομένα, διασυνδέσεις και ιδιοκτησία λογαριασμών

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

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

Διαχείριση περιεχομένου και καθημερινή λειτουργία

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

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

Λίστα ελέγχου απαιτήσεων πριν αρχίσει ο κώδικας

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

Κριτήρια αποδοχής και έλεγχος κινδύνων

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

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

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

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

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

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

Πώς κρατιέται η ανάπτυξη ευθυγραμμισμένη με τις απαιτήσεις

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

Μικρός έλεγχος ετοιμότητας πριν την έναρξη ανάπτυξης

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

Παράδοση που επιτρέπει συνέχεια

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

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