Agile for dummies - Continuous Feedback with Customer Demos ( Greek Version )

Εισαγωγή

Δεν είναι λίγες οι φορές που οι περισσότεροι από εμάς έχουν αγανακτήσει για τη δυσκολία που έχει ο πελάτης στο να αποφασίσει τι τελικά χρειάζεται από ένα σύστημα, αλλά και την άνεση με την οποία αλλάζει τις προδιαγραφές. Ενώ αυτό θα έπρεπε να μας χαροποιεί, μας δημιουργεί αναστάτωση και με το πρώτο μήνυμα αλλαγής προδιαγραφών,ειδικά σε προχωρημένες φάσεις ενός project, έρχεται η καταστροφή. Και φυσικά για όλα τα παραπάνω φταίει αυτό το ανικανοποίητο και αναποφάσιστο πλάσμα που το ονομάζουμε «πελάτης». Όσες φορές κι αν προσπαθήσαμε να «κλειδώσουμε» τις προδιαγραφές στα πρώτα στάδια του project είτε επειδή έτσι το προβλέπει η σύμβαση μαζί του, είτε επειδή «πρέπει να ξέρουμε εκ των προτέρων τι έχουμε να υλοποιήσουμε», το μόνο που καταφέραμε είναι να έρθουμε σε ρήξη από την αρχή του project και να «επιτύχουμε» τα αντίθετα αποτελέσματα. Είμαστε τελικά δέσμιοι των ορέξεων των πελατών; Φυσικά και όχι. Ο σκοπός μας είναι, ή τουλάχιστο πρέπει να είναι, η παράδοση ενός συστήματος που καλύπτει όσο το δυνατόν καλύτερα, και πάντα μέσα στο budget, τις επιχειρησιακές του ανάγκες. Υπάρχει τρόπος να τα καταφέρουμε, και δεν είναι δύσκολος.

Η εφαρμογή της πρακτικής

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

• Από την αρχή του project, λοιπόν, τον ενημερώνουμε για την τακτική που έχουμε σκοπό να εφαρμόσουμε και προσπαθούμε να εξηγήσουμε την ανταποδοτικότητά της, ότι γίνεται δηλαδή για να κατανοήσουμε καλύτερα τις ανάγκες του, αλλά και για να καταλάβει ο ίδιος τι ακριβώς χρειάζεται από το σύστημα.
• Σε περίπτωση που υπάρξει δυσαρέσκεια για την ύπαρξη τόσων πολλών «εκδόσεων», είναι καλό να αποσαφηνίσουμε ότι δεν είναι πραγματικές εκδόσεις, αλλά εσωτερικά demos, τα οποία δε θα διανεμηθούν σε όλους τους χρήστες.  Είναι πολύτιμα ωστόσο για την έγκαιρη διάγνωση λανθασμένων προδιαγραφών
• Σεβόμαστε τους διαθέσιμους χρόνους των πελατών. Προσπαθούμε να βρούμε μία προσέγγιση που να εξυπηρετεί όλους. Αν ο πελάτης δεν μπορεί να συμμετάσχει στην παρουσίαση στο τέλος κάθε iteration (για παράδειγμα κάθε δύο ή τρεις εβδομάδες) του αντιπροτείνουμε ένα demo κάθε μήνα (είναι το μέγιστο χρονικό διάστημα το οποίο πρέπει να επιδιώκουμε)
• Εξασφαλίζουμε ότι έχουμε πραγματικά να δείξουμε κάτι. Νέα χαρακτηριστικά, νέες λειτουργίες, είναι απαραίτητες να υπάρχουν και συνάμα να μην έχουν προβλήματα.  Αν ο πελάτης απογοητευτεί από ένα μη σταθερό demo, τότε το πιο πιθανό είναι να χάσει την εμπιστοσύνη του στην ομάδα ανάπτυξης και να δυσπιστεί σε κάθε προσπάθεια επόμενων παρουσιάσεων.
• Η παρουσίαση γίνεται αποκλειστικά από ένα μέλος της ομάδας ώστε να καθοδηγήσει τον πελάτη στα σημεία που χρήζουν προσοχής και σχολιασμού. Δεν αφήνουμε τον πελάτη να «παίξει» με την έκδοση. Του υπενθυμίζουμε ευγενικά το σκοπό της πρακτικής και ότι το demo δεν είναι κατάλληλο για beta testing.
• Ξεκαθαρίζουμε πριν από κάθε παρουσίαση ότι το προϊόν / σύστημα είναι ακόμα υπό ανάπτυξη και δεν είναι η τελική έκδοση που θα διανεμηθεί. Προσπαθούμε να εστιάσουμε σε ουσιαστικά σχόλια επιχειρησιακών αναγκών, χωρίς αυτό να σημαίνει ότι αγνοούμε προτάσεις για τη χρηστικότητα, το user interface κτλ.

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

• Η δημιουργία video επίδειξης στα οποία θα παρουσιάζονται τα νέα χαρακτηριστικά των συστημάτων σε κάθε έκδοση – πριν από την επίσημη ανακοίνωσή της. Κάτι σαν pre-release announcement. Το βασικότερο πλεονέκτημα αυτής της προσέγγισης είναι ότι με ελάχιστο κόστος, μπορούμε να δείξουμε σε πολύ μικρό χρονικό διάστημα (η διάρκεια του video δεν πρέπει να ξεπερνάει τα 3 λεπτά), τα συγκεκριμένα χαρακτηριστικά που χρειαζόμαστε για να διαφημίσουμε την νέα έκδοση και να λάβουμε ανάλογο feedback από τους πελάτες μας.
• Η δημιουργία demo sites στα οποία οι πελάτες ( υφιστάμενοι και υποψήφιοι ) έχουν τη δυνατότητα να δοκιμάζουν τις νέες εκδόσεις (Beta versions , Release Candidate versions ) και να αποστέλλουν με μία καθορισμένη διαδικασία τα σχόλιά και τις παρατηρήσεις τους.

Τα οφέλη της πρακτικής

Συνοψίζοντας τα παραπάνω παρουσιάζω ενδεικτικά μερικά από τα οφέλη της πρακτικής:

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