Πορτρέτο του Ξενοφών Απάκη
Ξενοφών Απάκης
Web designer και developer από το 1997

διαχείριση προϊόντων

διαχείριση προϊόντων

· Με δύο λόγια

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

Διαχείριση προϊόντων: από την ανάγκη του πελάτη στην καθημερινή βελτίωση

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

Ο διαχειριστής προϊόντος δεν είναι απλώς συντονιστής εργασιών

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

Ανακάλυψη αναγκών πριν από τη λίστα λειτουργιών

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

Προτεραιότητες με βάση όφελος και προσπάθεια

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

Σχέδιο εξέλιξης που επιτρέπει αναθεώρηση

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

Τι συμβαίνει μετά τη δημοσίευση

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

Ειδική περίπτωση: διαχείριση καταλόγου ηλεκτρονικού εμπορίου

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

Πέντε ερωτήσεις για μια απόφαση ανάπτυξης

  1. Ποιος συγκεκριμένος χρήστης αντιμετωπίζει το πρόβλημα και πώς το γνωρίζουμε;
  2. Ποιο αποτέλεσμα θα βελτιώσει τη ζωή του, όχι απλώς τη λίστα λειτουργιών;
  3. Ποια μικρή δοκιμή μπορεί να μειώσει την αβεβαιότητα πριν από μεγάλη επένδυση;
  4. Ποιες τεχνικές, οικονομικές ή οργανωτικές εξαρτήσεις περιορίζουν την επιλογή;
  5. Ποιος θα παρακολουθήσει το αποτέλεσμα και πότε θα επανεξετάσουμε την απόφαση;

Συνεργασία χωρίς σύγχυση ευθυνών

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

Πότε σταματάμε να προσθέτουμε δυνατότητες;

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

Σημάδια ώριμης διαδικασίας

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

Πότε η έρευνα είναι αρκετή για να ξεκινήσει δοκιμή

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

Παράδειγμα προτεραιοποίησης σε ψηφιακή υπηρεσία

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

Ποιότητα δεδομένων και δικαιώματα ενημέρωσης

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

Επανεξέταση της αξίας με τον χρόνο

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