Πλατφόρμες και cloud
Τι χρειάζεται μια πλατφόρμα πριν από τον κώδικα
Πριν γραφτεί κώδικας, μια πλατφόρμα χρειάζεται γραπτά τον σκοπό της, τους χρήστες, τους κανόνες, τα όρια, τα δεδομένα της και τους ελέγχους που δείχνουν ότι λειτουργεί. Έτσι η κατασκευή απαντά στις ερωτήσεις που έχει πραγματικά η επιχείρησή σας.
Όταν μια πλατφόρμα ξεκινά χωρίς γραπτή προδιαγραφή, οι ερωτήσεις που δεν τέθηκαν εμφανίζονται αργότερα, ως διορθώσεις. Εδώ βλέπετε ποια έξι σύντομα κείμενα αρκούν για να τις απαντήσετε εγκαίρως, και τι κερδίζει η κατασκευή όταν τα έχει.
Γιατί βοηθά να γραφτούν πρώτα οι απαντήσεις;
Βοηθά επειδή κάθε ερώτηση που απαντιέται νωρίς δεν χρειάζεται να απαντηθεί αργότερα, από έναν προγραμματιστή, στη μέση της δουλειάς. Όταν είναι γραμμένο πώς ακυρώνεται ένα τιμολόγιο ή ποιος βλέπει τον φάκελο ενός πελάτη, η πλατφόρμα χτίζεται από την πρώτη φορά όπως το εννοεί η επιχείρησή σας.
Η διαφορά φαίνεται καθαρά στις ανακατασκευές παλιών συστημάτων. Ο κώδικας συνήθως είναι σωστός. Αυτό που λείπει είναι μια γραπτή περιγραφή του τι έπρεπε να κάνει. Όταν υπάρχει αυτή η περιγραφή, κάθε συζήτηση για ένα «σφάλμα» γίνεται απλή: ελέγχουμε τι γράφει και ξέρουμε αμέσως τι ισχύει.
Η καταγραφή των απαντήσεων παίρνει μία ή δύο εβδομάδες. Κοστίζει όμως πολύ λιγότερο από έναν κανόνα που ανακαλύπτεται τον τέταρτο μήνα, όταν οι οθόνες και τα δεδομένα στηρίζονται ήδη σε μια λάθος υπόθεση. Γι' αυτό η διαδικασία μας ξεκινά με ένα στάδιο απαιτήσεων. Το εγκρίνετε εσείς πριν αρχίσουν η δομή, ο σχεδιασμός ή η κατασκευή.
Ποια στοιχεία γράφονται πρώτα;
Γράφονται έξι στοιχεία, και κανένα δεν χρειάζεται τεχνική γλώσσα. Ο πίνακας δείχνει το καθένα, την ερώτηση που απαντά και ένα σύντομο παράδειγμα απάντησης, αρκετά σαφές ώστε να χτιστεί κάτι πάνω του. Μια απάντηση που χωρά σε λίγες απλές προτάσεις δείχνει ότι το θέμα έχει γίνει κατανοητό από όλους.
Στοιχείο | Η ερώτηση | Παράδειγμα χρήσιμης απάντησης |
|---|---|---|
Σκοπός | Ποια δουλειά ή απόφαση διευκολύνει η πλατφόρμα; | «Οι ασθενείς κλείνουν ραντεβού online και τα ιατρεία τα διαχειρίζονται σε ένα σημείο.» |
Χρήστες και ρόλοι | Ποιος τη χρησιμοποιεί και τι βλέπει ο καθένας; | «Το προσωπικό βλέπει μόνο το δικό του ιατρείο· ο διαχειριστής τα βλέπει όλα.» |
Κανόνες | Τι πρέπει να ισχύει πάντα ή να μη συμβαίνει ποτέ; | «Ένα ραντεβού δεν μπορεί να επικαλύπτει άλλο στον ίδιο χώρο.» |
Όρια | Ποιοι περιορισμοί ισχύουν: νομικοί, τεχνικοί, λειτουργικοί; | «Τα δεδομένα αποθηκεύονται σε διακομιστές εντός ΕΕ και η υποστήριξη λειτουργεί τις εργάσιμες ημέρες.» |
Δεδομένα | Τι αποθηκεύεται, για πόσο, ποιος το διαχειρίζεται; | «Οι φάκελοι πελατών κρατιούνται ώς το τέλος της σύμβασης και μετά διαγράφονται.» |
Έλεγχοι αποδοχής | Πώς ξέρουμε ότι δουλεύει; | «Ένας νέος χρήστης ολοκληρώνει κράτηση σε λιγότερο από δύο λεπτά, δοκιμασμένο σε κινητό.» |
Η τελευταία γραμμή είναι η πιο σημαντική. Μια απαίτηση έχει αξία όταν μπορεί να ελεγχθεί. Γι' αυτό κάθε γενική επιθυμία την ξαναγράφουμε μαζί σας, μέχρι να γίνει ένας σαφής έλεγχος.
Πώς γίνονται οι απαντήσεις προδιαγραφή;
Γίνονται προδιαγραφή με σταθερή σειρά πέντε βημάτων. Κάθε βήμα τελειώνει σε ένα κείμενο που μπορείτε να διαβάσετε και να εγκρίνετε. Η κατασκευή ξεκινά αφού εγκρίνετε το πέμπτο βήμα. Ό,τι μένει ακόμη ανοιχτό εκείνη τη στιγμή γράφεται ως ανοιχτό, ώστε να το αποφασίσετε εσείς και όχι όποιος κατασκευάζει.
Μιλάμε με όσους θα τη χρησιμοποιούν. Ακούμε τον ιδιοκτήτη της επιχείρησης, αλλά και όποιον θα τη χρησιμοποιεί κάθε μέρα. Εκείνος ξέρει τις εξαιρέσεις.
Γράφουμε τους κανόνες σε απλές προτάσεις. Ένας κανόνας σε κάθε πρόταση. «Η επιστροφή χρημάτων πάνω από ένα όριο θέλει έγκριση» είναι σαφής κανόνας, που μπορεί να ελεγχθεί.
Ορίζουμε τους ρόλους και τι βλέπει ο καθένας. Ένας απλός πίνακας με ρόλους και ενέργειες εντοπίζει τα περισσότερα λάθη στα δικαιώματα πριν εμφανιστούν.
Καταγράφουμε τα όρια και τα ανοιχτά ερωτήματα. Τα νομικά, τεχνικά και λειτουργικά όρια γράφονται σε μία σελίδα. Κάθε ερώτημα που περιμένει απάντηση παίρνει υπεύθυνο και ημερομηνία.
Συμφωνούμε τους ελέγχους αποδοχής. Κάθε κανόνας παίρνει τουλάχιστον έναν έλεγχο. Διαβάζετε τη λίστα και την εγκρίνετε.
Το αποτέλεσμα είναι ένα γραπτό πεδίο εφαρμογής που περιγράφει την επιχείρησή σας με ακρίβεια. Από αυτό δουλεύουν και τα δικά μας εργαλεία κατασκευής. Γι' αυτό η προσοχή σε αυτό το στάδιο φαίνεται σε όλη τη συνέχεια του έργου.
Τι σημαίνει ότι η τεχνολογία έρχεται μετά;
Σημαίνει ότι επιλέγουμε την τεχνολογία αφού ξέρουμε τι χρειάζεστε. Οι απαιτήσεις ορίζουν τι πρέπει να κάνει η πλατφόρμα, πόσοι θα τη χρησιμοποιούν και με ποια συστήματα πρέπει να συνδεθεί. Μετά διαλέγουμε τα εργαλεία που ταιριάζουν σε αυτά τα δεδομένα. Εξηγούμε γραπτά γιατί τα διαλέξαμε, ώστε να έχετε πάντα την αιτιολόγηση.
Ένα μικρό εσωτερικό εργαλείο για δέκα συναδέλφους και μια πλατφόρμα για χιλιάδες πελάτες από πολλούς οργανισμούς είναι διαφορετικά έργα, ακόμη κι όταν οι οθόνες μοιάζουν. Το πρώτο θέλει απλή εγκατάσταση που παραδίδεται εύκολα. Το δεύτερο θέλει χωριστά δεδομένα για κάθε πελάτη, προσεκτικούς κανόνες πρόσβασης και παρακολούθηση. Όταν ξέρουμε από την αρχή ποιο από τα δύο χρειάζεστε, το σύστημα έχει ακριβώς το μέγεθος που απαιτεί η δουλειά σας.
Στη σελίδα για τις πλατφόρμες SaaS και επιχειρηματικές εφαρμογές θα βρείτε τι περιλαμβάνει ένα τέτοιο έργο. Το στάδιο των απαιτήσεων είναι ο πιο καθαρός τρόπος να βρούμε μαζί τη σωστή λύση για τη δική σας περίπτωση.
Ποιες απαιτήσεις αξίζουν ιδιαίτερη προσοχή;
Αξίζουν προσοχή οι απαιτήσεις που δεν φαίνονται σε καμία οθόνη: ασφάλεια, προσβασιμότητα, χειρισμός σφαλμάτων, παράδοση. Συνήθως δεν τις ζητά κανείς, αλλά κάνουν μεγάλη διαφορά στην καθημερινή χρήση. Τις περνάμε μία μία από την αρχή, γιατί τότε γράφονται εύκολα, ενώ σε έτοιμο προϊόν προστίθενται με μεγαλύτερο κόστος.
Ασφάλεια. Ποιος μπορεί να συνδεθεί, πώς φυλάσσονται οι κωδικοί, τι γίνεται μετά από πολλές αποτυχημένες προσπάθειες. Το OWASP Application Security Verification Standard είναι ανοιχτό πρότυπο με τεχνικές απαιτήσεις ασφάλειας. Το χρησιμοποιούμε ως λίστα ελέγχου για να δούμε ποιες αφορούν τη δική σας πλατφόρμα.
Προσβασιμότητα. Αν η πλατφόρμα πρέπει να εξυπηρετεί άτομα με αναπηρία, αυτό γράφεται από τώρα. Το WCAG του W3C είναι το διεθνές σημείο αναφοράς, με επίπεδα A, AA και AAA. Έτσι ο στόχος γράφεται ως απαίτηση που μπορεί να ελεγχθεί.
Χειρισμός σφαλμάτων. Ο πάροχος πληρωμών δεν απαντά, ένα αρχείο είναι πολύ μεγάλο, ο χρήστης κλείνει το παράθυρο στη μέση. Για κάθε περίπτωση συμφωνούμε τι ακριβώς θα γίνει.
Παράδοση. Πώς παραδίδονται οι λογαριασμοί, ο κώδικας και τα δεδομένα την ημέρα που ολοκληρώνεται το έργο.
Αύξηση της χρήσης. Δεν χρειάζεται πρόβλεψη, μόνο μια ερώτηση: αν οι χρήστες γίνουν δέκα φορές περισσότεροι, τι πρέπει να συνεχίσει να λειτουργεί;
Τι ελέγχεται πριν υπάρξει το προϊόν;
Ελέγχονται περισσότερα απ' όσα περιμένει κανείς. Ένα γραπτό πεδίο εφαρμογής διαβάζεται για αντιφάσεις. Ένας πίνακας ρόλων δοκιμάζεται με πραγματικά σενάρια. Οι έλεγχοι αποδοχής γίνονται αυτόματα τεστ πριν υπάρξει η λειτουργία που ελέγχουν. Αυτή είναι η λογική του «πρώτα το τεστ»: ο έλεγχος είναι η ίδια η προδιαγραφή, σε μορφή που εκτελείται.
Την ίδια προσέγγιση ακολουθούμε και στη δική μας δουλειά. Η μελέτη περίπτωσης του Planner δείχνει πώς μια γραπτή προδιαγραφή γίνεται εφαρμογή, με ελέγχους σε κάθε βήμα και σε πραγματικό browser. Δείχνει επίσης τι γίνεται δυνατό όταν τα κείμενα είναι τόσο ακριβή που μπορεί να τα ακολουθήσει ένα εργαλείο.
Αν έχετε ήδη σημειώσεις, ένα υπολογιστικό φύλλο ή ένα παλιό σύστημα, φέρτε τα. Είναι πολύτιμο υλικό για την προδιαγραφή, ακόμη κι όταν δεν είναι οργανωμένα. Μπορείτε να ξεκινήσετε με ένα αίτημα έργου και να μας πείτε τι ξέρετε ήδη και τι θέλετε να ξεκαθαρίσουμε μαζί.
Ποιος αποφασίζει τι σε ένα έργο πλατφόρμας;
Εσείς αποφασίζετε τον σκοπό, τους κανόνες, τα δεδομένα και τις προτεραιότητες, γιατί είναι επιχειρηματικές αποφάσεις. Εμείς προτείνουμε λύσεις, εξηγούμε τα υπέρ και τα κατά, ενώ καταγράφουμε κάθε απόφαση. Την τεχνική προσέγγιση την αποφασίζουμε εμείς, αφού εγκριθούν οι απαιτήσεις, και την εξηγούμε σε απλή γλώσσα.
Έτσι οι ευθύνες μένουν σαφείς. Αν ένας κανόνας χρειαστεί αλλαγή αργότερα, υπάρχει γραπτό αρχείο για το ποιος τον όρισε και γιατί. Η διόρθωση γίνεται μια απλή, ήρεμη συζήτηση. Αν μια τεχνική επιλογή χρειαστεί αλλαγή, το ίδιο αρχείο δείχνει ποια απαίτηση εξυπηρετεί.
Συχνές ερωτήσεις: Τι χρειάζεται μια πλατφόρμα πριν από τον κώδικα
Πόσο διαρκεί το στάδιο των απαιτήσεων;
Η διάρκεια εξαρτάται από το πόσα είναι ήδη ξεκάθαρα και από το πόσους ανθρώπους πρέπει να ακούσουμε. Μια μικρή πλατφόρμα με μία ομάδα χρηστών καταγράφεται γρήγορα. Μια πλατφόρμα με πολλούς ρόλους, πολλούς οργανισμούς ή νομικά όρια θέλει περισσότερο χρόνο, επειδή πρέπει να συμφωνήσουν περισσότεροι. Σας λέμε την αναμενόμενη διάρκεια στην αρχή του σταδίου.
Ξεκινά η κατασκευή με ανοιχτά ερωτήματα;
Ναι, όταν το ανοιχτό θέμα αφορά ένα μικρό, ξεχωριστό κομμάτι. Το καταγράφουμε καθαρά, του δίνουμε υπεύθυνο και το κρατάμε χωριστά από όσα εξαρτώνται από αυτό. Έτσι κάθε απόφαση παίρνεται συνειδητά από εσάς και ελέγχεται πριν γίνει μέρος του προϊόντος.
Τι γίνεται αν αλλάξουν οι απαιτήσεις;
Οι αλλαγές είναι φυσιολογικές σε κάθε έργο. Κάθε αλλαγή γράφεται, εξηγούμε πώς επηρεάζει τα υπόλοιπα και την εγκρίνετε πριν συνεχιστεί η δουλειά. Το γραπτό πεδίο εφαρμογής είναι το σημείο αναφοράς, ώστε όλοι να βλέπουν τι άλλαξε και γιατί.
Χρειάζονται τεχνικές γνώσεις για τις απαιτήσεις;
Όχι. Οι απαιτήσεις περιγράφουν τι πρέπει να κάνει η πλατφόρμα για τους ανθρώπους, με τα λόγια της επιχείρησής σας. Τη μετατροπή σε τεχνική γλώσσα την αναλαμβάνουμε εμείς. Αν μια πρόταση είναι σαφής μόνο για έναν προγραμματιστή, την ξαναγράφουμε μέχρι να είναι σαφής και για εσάς.
Τι γίνεται με την προδιαγραφή στο τέλος;
Η προδιαγραφή περιγράφει τους κανόνες και τις αποφάσεις της επιχείρησής σας. Γι' αυτό παραδίδεται σε εσάς μαζί με την υπόλοιπη τεκμηρίωση του έργου, ώστε να τη χρησιμοποιείτε σε κάθε μελλοντική αλλαγή.