Σε έναν κόσμο όπου μια λειτουργία μπορεί να σχεδιαστεί, προγραμματιστεί και αναπτυχθεί πιο γρήγορα από ποτέ, το μεγαλύτερο πρόβλημα δεν είναι πλέον το ρυθμό της κατασκευής. Το πρόβλημα γίνεται η απόφαση του τι αξίζει πραγματικά να δημιουργηθεί.
Υπάρχει μια στιγμή στη ζωή σχεδόν κάθε αναπτυσσόμενου συστήματος, όταν η λίστα λειτουργιών αρχίζει να ζει τη δική της ζωή.
«Ο πελάτης το ζήτησε.»
«Ο ανταγωνιστής το έχει.»
«Προφανώς δεν θα πρέπει να είναι δύσκολο.»
«Αφού έχουμε ήδη αυτό το module, ας προσθέσουμε ακόμα…»
«Η AI θα το κάνει γρήγορα.»
Και ξαφνικά μια ακόμα λειτουργία μπαίνει στο backlog. Έπειτα άλλη μια. Και άλλη μια. Μετά από μερικά χρόνια η εταιρεία έχει μια εφαρμογή που μπορεί σχεδόν τα πάντα. Μόνο που ο χρήστης όλο και δυσκολεύεται να βρει αυτό που πραγματικά χρειάζεται.
Αυτό δεν είναι αποκλειστικά θέμα UX. Είναι θέμα επιχειρηματικό.
Όταν περισσότερες λειτουργίες σταματούν να σημαίνουν καλύτερο προϊόν
Για χρόνια η ανάπτυξη λογισμικού είχε μια σχετικά απλή λογική: αν οι χρήστες χρειάζονται νέες δυνατότητες, προσθέτουμε νέες λειτουργίες. Ακούγεται λογικό.
Το πρόβλημα αρχίζει όταν η ανάπτυξη προϊόντος περιορίζεται στον αριθμό των παραδοθέντων λειτουργιών. Τότε η ομάδα αρχίζει να βελτιστοποιεί όχι με γνώμονα την αξία για τον χρήστη, αλλά με βάση το πόσα πράγματα κατάφερε να «παραδώσει».
Αναπτύσσεται ο λεγόμενος Feature Factory – ένας οργανισμός που παράγει νέες λειτουργίες, αλλά δεν μετράει αν αυτές πραγματικά λύνουν τα προβλήματα των πελατών.
Το φαινόμενο αυτό δεν είναι νέο. Νέος είναι ο ρυθμός με τον οποίο μπορεί σήμερα να εξελιχθεί.
Η AI συντομεύει σημαντικά το μονοπάτι από την ιδέα στο λειτουργικό πρωτότυπο. Η Atlassian περιγράφει την αλλαγή ευθέως: με τους προγραμματιστικούς agents, ο δρόμος από το «ξέρουμε τι θέλουμε να κατασκευάσουμε» στο λειτουργικό πρωτότυπο μπορεί να μειωθεί από εβδομάδες σε ώρες.
Είναι μια τεράστια ευκαιρία. Αλλά και μια παγίδα.
Διότι αν η κατασκευή γίνεται φθηνότερη και πιο γρήγορη, είναι πιο εύκολο να αρχίσεις να χτίζεις πράγματα που νωρίτερα κανείς δεν θα τολμούσε να ζητήσει.
«Αφού μπορούμε, ας το κάνουμε»
Αυτή είναι μια από τις πιο ακριβές φράσεις στα έργα IT. Όχι επειδή κάθε επιπλέον λειτουργία κοστίζει μια περιουσία. Το πρόβλημα είναι ότι μια λειτουργία δεν τελειώνει τη ζωή της τη στιγμή της ανάπτυξης.
Κάθε νέο module πρέπει να συντηρείται μετά. Πρέπει να δοκιμάζεται. Να λαμβάνεται υπόψη σε μελλοντικές αλλαγές. Να τεκμηριώνεται. Να υποστηρίζονται τα σφάλματά του. Να εκπαιδεύονται οι χρήστες. Να ενσωματώνεται στο UX. Να εξασφαλίζεται η ασφάλειά του. Να ελέγχεται αν οι επόμενες αλλαγές στο σύστημα δεν το σπάνε.
Γι’ αυτό το κόστος μιας λειτουργίας δεν είναι μόνο το κόστος κατασκευής της. Είναι και το κόστος της μελλοντικής της ύπαρξης.
Και συχνά αυτό το κόστος δεν φαίνεται τη στιγμή που κάποιος λέει:
«Μπορούμε να προσθέσουμε κι αυτό…»
Η πιο ακριβή λειτουργία μπορεί να είναι αυτή που κανείς δεν χρησιμοποιεί
Φανταστείτε μια εταιρεία που αναπτύσσει ένα B2B πάνελ.
Οι πελάτες μπορούν να κάνουν παραγγελίες, να ελέγχουν το ιστορικό αγορών, να κατεβάζουν έγγραφα και να επικοινωνούν με τον υπεύθυπο πελάτη.
Συμβαίνει μια ιδέα για ένα εκτεταμένο σύστημα αναφορών. Η ομάδα το σχεδιάζει. Οι developers το υλοποιούν. Δημιουργούνται γραφήματα, φίλτρα, εξαγωγές, συγκεντρωτικοί πίνακες και δεκάδες πρόσθετες παράμετροι. Η λειτουργία πηγαίνει σε παραγωγή.
Και τότε αποδεικνύεται ότι οι περισσότεροι πελάτες θέλουν απλώς να ξέρουν: πόσο αγόρασα, τι είναι σε πορεία και ποια είναι η τιμή.
Όλα τα υπόλοιπα ήταν υπόθεση. Δεν τα χρειάζονται. Αυτή είναι μια σημαντική διαφορά.
Ο πελάτης μπορεί να ζητήσει μια λειτουργία. Αυτό δεν σημαίνει ότι η λειτουργία αυτή είναι η λύση στο πρόβλημά του.
«Ο ανταγωνιστής το έχει»
Κλασσικό δεύτερο.
Η εταιρεία αναλύει τον ανταγωνισμό. Βλέπει ένα νέο module.
Και ξεκινά: «Πρέπει να το έχουμε κι εμείς.»
Μόνο που ο ανταγωνιστής μπορεί να έχει εντελώς διαφορετικό επιχειρηματικό μοντέλο, άλλη ομάδα πελατών, διαφορετικές διαδικασίες πωλήσεων και άλλη στρατηγική προϊόντος.
Μια λειτουργία που έχει νόημα σε ένα σύστημα μπορεί να είναι εντελώς περιττή σε άλλο.
Αυτό είναι ιδιαίτερα σημαντικό σε έργα που έχουν κατασκευαστεί κατά παραγγελία. Δεν υπάρχει ένας γενικός κατάλογος λειτουργιών που θα κάνει κάθε εφαρμογή καλή.
Ένα σύστημα για κατασκευαστή βιομηχανικού εξοπλισμού δεν πρέπει να σχεδιάζεται όπως μια πλατφόρμα για εταιρεία εκπαίδευσης.
Ένα CRM για πωλητές δεν πρέπει να λειτουργεί όπως ένα B2B πάνελ για σταθερούς πελάτες.
Ένα e-shop που πουλάει premium προϊόντα μπορεί να χρειάζεται τελείως διαφορετική εμπειρία αγορών από ένα κατάστημα που βασίζεται στην τιμή.
Το λογισμικό πρέπει να προκύπτει από το επιχειρηματικό μοντέλο, όχι από τον κατάλογο λειτουργιών του ανταγωνισμού.
Η AI αλλάζει τα πράγματα σημαντικά εδώ
Κι ακριβώς γι’ αυτό το θέμα σήμερα είναι ιδιαίτερα ενδιαφέρον.
Μέχρι πριν λίγα χρόνια μια ιδέα για νέα λειτουργία έπρεπε να περάσει από πολλά στάδια πριν ο χρήστης μπορέσει να τη δει.
Ανάλυση.
Σχεδιασμός.
UX.
Ανάπτυξη.
Δοκιμές.
Ανάπτυξη σε παραγωγή.
Σήμερα πολλά από αυτά τα στάδια μπορούν να επιταχυνθούν σημαντικά από την AI. Μπορούμε να φτιάξουμε πρωτότυπα πιο γρήγορα. Να ετοιμάσουμε διεπαφές πιο γρήγορα. Να γράψουμε κώδικα πιο γρήγορα. Να δημιουργήσουμε τεστ πιο γρήγορα. Να αναλύσουμε δεδομένα πιο γρήγορα.
Κι έτσι η ίδια η ταχύτητα του development παύει να είναι αρκετό πλεονέκτημα.
Αν ο καθένας μπορεί να χτίσει κάτι πιο γρήγορα, πλεονέκτημα αποκτά αυτός που επιλέγει καλύτερα τι θα χτίσει.
Η Atlassian στο υλικό της για το μέλλον του product management επισημαίνει αυτό το παράδοξο: η AI αυξάνει τον ρυθμό εργασίας, αλλά η αύξηση του ρυθμού δεν σημαίνει απαραίτητα καλύτερα προϊόντα. Παράλληλα, το 89% των συμμετεχόντων εκπροσώπων διοίκησης ανέφερε αύξηση της ταχύτητας χάρη στην AI, ενώ μόνο το 6% ένιωσε σίγουρο στο να προσδιορίσει το συγκεκριμένο ROI της AI σε οργανωτικό επίπεδο.
Αυτό δείχνει ξεκάθαρα τη διαφορά ανάμεσα στο να κάνεις πιο γρήγορα και στο να πετυχαίνεις καλύτερο αποτέλεσμα.
Πρώτα το πρόβλημα. Μετά η λειτουργία
Η σωστή διαδικασία προϊόντος πρέπει να ξεκινάει από την ερώτηση: Ποιο πρόβλημα προσπαθούμε να λύσουμε;
Όχι: «Τι λειτουργία πρέπει να προσθέσουμε;»
Φαίνεται μικρή διαφορά. Στην πράξη όμως αλλάζει τα πάντα.
Αν ο πελάτης λέει: «Χρειαζόμαστε μια mobile εφαρμογή»,
αξίζει να ρωτήσουμε: Γιατί;
Ίσως πράγματι χρειάζεται εφαρμογή. Αλλά ίσως το πρόβλημα είναι η δυσκολία πρόσβασης στο πάνελ από κινητό. Ίσως αρκεί ένα καλά σχεδιασμένο responsive interface. Ίσως PWA. Ίσως ένα mobile module για μια συγκεκριμένη διαδικασία. Ή μπορεί η εφαρμογή να είναι απαραίτητη — αλλά για εντελώς άλλους λόγους από αυτούς που αρχικά ανέφερε ο πελάτης.
Το ίδιο ισχύει και με τις λειτουργίες.
«Χρειαζόμαστε αυτόματες αναφορές.» — Γιατί;
«Γιατί οι πωλητές χάνουν χρόνο.» — Σε τι;
«Στο να αντιγράφουν δεδομένα από το σύστημα.»
Και ξαφνικά αποδεικνύεται ότι το πρόβλημα δεν είναι η έλλειψη αναφοράς. Το πρόβλημα είναι η έλλειψη ενσωμάτωσης.
Μια καλή ανάλυση μπορεί να εξοικονομήσει μήνες development.
Μερικές φορές η καλύτερη λειτουργία είναι η απουσία λειτουργίας
Ακούγεται παράδοξο, αλλά αυτή πρέπει να είναι η στάση ενός έμπειρου τεχνολογικού συνεργάτη.
Όχι μόνο να υλοποιεί. Αλλά και να αμφισβητεί τις υποθέσεις όταν υπάρχει λόγος.
Αν ο πελάτης έρχεται με μια λίστα είκοσι λειτουργιών, το software house δεν πρέπει αυτόματα να τη μετατρέπει σε τεχνική προδιαγραφή χαραγμένη σε πέτρα.
Πρέπει να ρωτήσει: Ποιες από αυτές τις λειτουργίες λύνουν πραγματικά ένα πρόβλημα; Ποιες είναι κρίσιμες; Ποιες αυξάνουν τις πωλήσεις; Ποιες μειώνουν τον χρόνο εργασίας; Ποιες βελτιώνουν την εξυπηρέτηση πελατών; Ποιες είναι απαραίτητες νομικά ή λειτουργικά; Ποιες είναι απλώς «ένα ωραίο πρόσθετο»;
Και πάνω απ’ όλα: πώς θα καταλάβουμε ότι μια λειτουργία ήταν επιτυχημένη;
Χωρίς αυτή την τελευταία ερώτηση είναι εύκολο να φτιάξεις ένα προϊόν που συνεχώς μεγαλώνει, αλλά ποτέ δεν ξέρεις αν πραγματικά γίνεται καλύτερο.
Το προϊόν πρέπει να ξέρει να λέει «όχι»
Σε καλό product development τόσο σημαντική όσο και η λίστα των πραγμάτων που θα φτιάξουμε είναι η λίστα των πραγμάτων που δεν θα φτιάξουμε. Αυτό απαιτεί θάρρος.
Είναι εύκολο να πεις: «Ναι, θα το κάνουμε.»
Δύσκολο να πεις: «Με βάση αυτά που ξέρουμε, δεν βλέπουμε ακόμα λόγο να πληρώσουμε για αυτό.»
Και ακόμα πιο δύσκολο να το πεις στον πελάτη που μόλις ήρθε με μια έτοιμη ιδέα.
Αλλά τότε αρχίζει η συνεργασία με πνεύμα συνεργάτη.
Το software house δεν πρέπει να είναι μόνο μια ομάδα που μετατρέπει εντολές σε κώδικα. Πρέπει να βοηθάει τον πελάτη να παίρνει τεχνολογικές αποφάσεις.
Μερικές φορές αυτό σημαίνει να σχεδιάσει τη λειτουργία.
Μερικές φορές να την απλοποιήσει.
Μερικές φορές να την αντικαταστήσει με άλλη λύση.
Και μερικές φορές να εγκαταλείψει εντελώς την ιδέα.
Πώς να αναγνωρίσετε μια λειτουργία που πιθανότατα δεν χρειάζεστε;
Δεν υπάρχει ένα μαγικό τεστ, αλλά μερικές ερωτήσεις μπορούν να ψύξουν γρήγορα τον ενθουσιασμό.
Ποιος συγκεκριμένα θα το χρησιμοποιεί;
Αν η απάντηση είναι «όλοι», αξίζει να το διευκρινίσουμε.
Ποιο πρόβλημα λύνουμε;
Αν η απάντηση είναι «θα είναι πιο βολικό», το πρόβλημα πιθανότατα χρειάζεται περαιτέρω ανάλυση.
Πόσο συχνά θα το χρησιμοποιεί ο χρήστης;
Μια φορά το χρόνο; Μια φορά το μήνα; Καθημερινά;
Υπάρχει πιο απλός τρόπος να λύσουμε το ίδιο πρόβλημα;
Αυτή η ερώτηση είναι ιδιαίτερα σημαντική.
Πώς θα μετρήσουμε το αποτέλεσμα;
Περισσότερες πωλήσεις; Λιγότερη εργασία; Μικρότερη διαδικασία; Λιγότερα σφάλματα; Μεγαλύτερη διατήρηση πελατών;
Τι θα συμβεί αν δεν φτιάξουμε αυτή τη λειτουργία;
Αν η απάντηση είναι «ουσιαστικά τίποτα», ίσως μόλις βρήκαμε μια λειτουργία που δεν χρειάζεται να χτίσουμε.
Δεν κάθε αίτημα χρήστη πρέπει να πάει στο backlog
Αυτή είναι επίσης μια σημαντική αλλαγή νοοτροπίας.
Το feedback των χρηστών είναι ανεκτίμητο. Αλλά το feedback δεν είναι αυτόματα προδιαγραφή προϊόντος.
Ο χρήστης μιλάει για το πρόβλημά του από την οπτική της δικής του εμπειρίας.
Μπορεί να πει: «Χρειαζόμαι το κουμπί X.»
Ο ρόλος της ομάδας προϊόντος δεν είναι να φτιάξει ατεκμηρίωτα το κουμπί X.
Ο ρόλος της ομάδας είναι να καταλάβει: γιατί ο χρήστης το χρειάζεται.
Μόνο τότε μπορούμε να αποφασίσουμε αν η καλύτερη λύση είναι πραγματικά το κουμπί X.
Ίσως είναι αυτοματοποίηση.
Ίσως ενσωμάτωση.
Ίσως αλλαγή διαδικασίας.
Ίσως καλύτερο interface.
Ίσως εκπαίδευση του χρήστη.
Και μερικές φορές πράγματι μια νέα λειτουργία.
Αυτή είναι η διαφορά ανάμεσα στο feature delivery και το product development.
Τα δεδομένα επίσης μπορούν να πουν: «αφαιρέστε το»
Η ανάπτυξη προϊόντος δεν πρέπει να τελειώνει με το να προσθέτεις.
Πρέπει επίσης να κοιτάμε τι υπάρχει ήδη.
Ποιες λειτουργίες χρησιμοποιούνται;
Ποιες αγνοούνται;
Πού οι χρήστες αποχωρούν;
Ποιες διαδικασίες καταλαμβάνουν περισσότερο χρόνο;
Ποια στοιχεία δημιουργούν τις περισσότερες αναφορές στο support;
Ποιες λειτουργίες αυξάνουν τη μετατροπή;
Και ποιες απλώς περιπλέκουν τη διεπαφή;
Μερικές φορές το καλύτερο έργο ανάπτυξης δεν είναι να προσθέσεις ένα επιπλέον module. Είναι να αφαιρέσεις τρεις περιττές λειτουργίες. Αυτό μπορεί να βελτιώσει το UX περισσότερο από έναν ακόμη μήνα development.
Η AI μπορεί να βοηθήσει και εδώ
Ενδιαφέρον είναι ότι η AI δεν χρειάζεται να εξυπηρετεί μόνο τη δημιουργία λειτουργιών.
Μπορεί να βοηθήσει και στην ανάλυση του αν οι λειτουργίες έχουν νόημα.
Μπορεί να αναλύει το feedback των χρηστών.
Να ομαδοποιεί αναφορές.
Να εντοπίζει επαναλαμβανόμενα προβλήματα.
Να αναλύει δεδομένα από το support.
Να συνοψίζει συζητήσεις με πελάτες.
Να βοηθά την ομάδα να συγκρίνει υποθέσεις.
Να προτείνει εναλλακτικές λύσεις.
Να στηρίζει την ανάλυση της συμπεριφοράς των χρηστών.
Δηλαδή, παραδόξως, η καλύτερη χρήση της AI στο product development μερικές φορές δεν είναι ότι χάρη σε αυτή θα φτιάξουμε πιο γρήγορα άλλη μια λειτουργία.
Αλλά ότι θα ανακαλύψουμε πιο γρήγορα ότι δεν πρέπει να την χτίσουμε.
Web24: πρώτα ρωτάμε «γιατί;»
Κάθε έργο λογισμικού ξεκινά από μια ανάγκη.
Μερικές φορές ο πελάτης ξέρει ακριβώς τι χρειάζεται.
Μερικές φορές έχει έτοιμη προδιαγραφή.
Μερικές φορές έρχεται απλώς με το πρόβλημα: «Αυτή η διαδικασία μας παίρνει τρεις ώρες τη μέρα.»
Και αυτό είναι ένα πολύ καλό σημείο εκκίνησης.
Διότι τότε μπορούμε να σκεφτούμε όχι πώς θα κωδικοποιήσουμε τη λύση που προτάθηκε, αλλά πώς καλύτερα να λύσουμε το πρόβλημα.
Αυτό ακριβώς διαχωρίζει την κατασκευή προσαρμοσμένου λογισμικού από το να στήνεις ένα προϊόν από έτοιμες λειτουργίες.
Στην Web24 δεν πρόκειται για το να έχει κάθε εφαρμογή όσες περισσότερες δυνατότητες γίνεται.
Πρόκειται για το να έχει τις δυνατότητες που πραγματικά χρειάζονται για τη συγκεκριμένη επιχείρηση.
Γι’ αυτό δύο παρόμοια συστήματα μπορεί να μοιάζουν και να λειτουργούν εντελώς διαφορετικά.
Διότι διαφέρουν οι διαδικασίες.
Διότι διαφέρουν οι χρήστες.
Διότι διαφέρουν οι στόχοι.
Διότι διαφέρει ο τρόπος πώλησης.
Διότι διαφέρει ο τρόπος εξυπηρέτησης πελατών.
Και διαφέρει το πρόβλημα που το λογισμικό πρέπει να λύσει.
Το πιο ακριβό backlog είναι αυτό που κανείς δεν αμφισβητεί
Σε έναν κόσμο με AI μπορούμε να βρεθούμε σε ένα πολύ ενδιαφέρον στάδιο εξέλιξης του λογισμικού.
Η τεχνολογία θα απαντάει όλο και καλύτερα στο ερώτημα: «Πώς να το χτίσουμε;»
Και ο άνθρωπος θα πρέπει να απαντάει όλο και καλύτερα στο ερώτημα: «Αξίζει καν να το χτίσουμε;»
Αυτή μπορεί να είναι μια από τις σημαντικότερες αλλαγές στη δημιουργία λογισμικού.
Διότι αν το κόστος και ο χρόνος υλοποίησης μιας ακόμη λειτουργίας πέφτουν, ο πειρασμός να τις προσθέτεις αυξάνεται.
Και μαζί με αυτό αυξάνεται η σημασία του Product Discovery, του UX, της ανάλυσης δεδομένων, των συνομιλιών με χρήστες και της στρατηγικής προσέγγισης στην ανάπτυξη προϊόντος. Η Gartner επισημαίνει ότι η γρήγορη ανάπτυξη προϊόντων με ώθηση από την AI μπορεί να οδηγήσει μεταξύ άλλων σε προβλήματα στρατηγικής ευθυγράμμισης και αύξησης του technical debt, αν ο ρυθμός τεχνολογικής αλλαγής δεν συνοδεύεται από σωστή διαχείριση προϊόντος.
Γι’ αυτό το μέλλον δεν θα ανήκει αποκλειστικά σε εταιρείες που μπορούν να χτίζουν πιο γρήγορα. Θα ανήκει επίσης σε εκείνες που μπορούν να επιλέγουν καλύτερα τι θα χτίσουν.
Διότι κάποιες φορές η καλύτερη τεχνολογική απόφαση δεν είναι: «Ας φτιάξουμε άλλη μια λειτουργία.»
Αλλά: «Ας ερευνήσουμε πρώτα αν πραγματικά τη χρειαζόμαστε.»
