Λίστα ελέγχου ανάπτυξης προϊόντων | TCGen
März 11, 2023Λίστα ελέγχου ανάπτυξης προϊόντων
Στη δουλειά μας ως σύμβουλοι ανάπτυξης προϊόντων με εταιρείες όπως η Apple, η Amazon, η Abbott, η Mozilla, η Cisco, η HP, η IBM, η Roche, η 3M και άλλες, είδαμε να επιλύονται πολλά προβλήματα που μπορούσαν να αποφευχθούν. Συχνά βλέπουμε τον ίδιο μικρό αριθμό προκλήσεων να επαναλαμβάνονται ξανά και ξανά – ζητήματα που θα μπορούσαν να είχαν επιλυθεί με μερικές απλές αλλά ισχυρές διακρίσεις και απλές πρακτικές που τις κάνουν πράξη. Χρησιμοποιούμε μια πιο λεπτομερή μορφή αυτής της λίστας ελέγχου κατά την αξιολόγηση α ΑΝΑΠΤΥΞΗ ΝΕΟΥ ΠΡΟΪΟΝΤΟΣ διαδικασία, επίσης.
«Τι κοινό έχουν οι χειρούργοι του Johns Hopkins, οι ανώνυμοι μεγάλοι επενδυτές και οι πιλότοι του Β‘ Παγκοσμίου Πολέμου; Όλοι χρησιμοποιούν λίστες ελέγχου για να αποφύγουν την καταστροφή».
— «Checklist Manifesto» του Atul Gawande
Η λίστα ελέγχου ανάπτυξης προϊόντων με δυνατότητα λήψης παρακάτω βασίζεται στην εργασία των πελατών μας. Έχει σχεδιαστεί για να σας βοηθήσει να εστιάσετε γρήγορα στις προκλήσεις. Αυτή η λίστα ελέγχου υπογραμμίζει επτά τομείς για βελτίωση στην ανάπτυξη προϊόντων:
- Στρατηγική Προϊόντος – Ένα ξεκάθαρο και κατανοητό στρατηγική προϊόντων επιβάλλεται. Οι ομάδες προγραμματιστών και οι λειτουργίες (Marketing, Engineering, Finance, κ.λπ.) πρέπει να κατανοούν την εταιρική στρατηγική και πώς η δουλειά τους εντάσσεται στις εταιρικές προτεραιότητες.
- Διαδικασία Ανάπτυξης Προϊόντος – Το καλύτερο διαδικασίες ανάπτυξης προϊόντων είναι εγγενώς ευκίνητοι. Δίνουν τη δυνατότητα στους δημιουργικούς ανθρώπους να κάνουν τη δουλειά τους, και μετά ξεφεύγουν από τη μέση και τους αφήνουν να την κάνουν. Οι πιο αποτελεσματικές διαδικασίες ανάπτυξης προϊόντων προσελκύουν πελάτες από νωρίς και στη συνέχεια επαναλαμβάνουν πρωτότυπα για να παρέχουν πραγματικές λύσεις.
- Ορισμός προϊόντος – Οι ομάδες που μεταφράζουν τη φωνή του πελάτη σε εξαιρετικούς ορισμούς προϊόντων δημιουργούν νέα προϊόντα που κερδίζουν. Έχουν σαφείς απαιτήσεις προϊόντος και το εισερχόμενο μάρκετινγκ τις κοινοποιεί στην ομάδα του Dev. Πολλές εταιρείες δεν αφιερώνουν αρκετό χρόνο στον καθορισμό προϊόντων, ενώ εφαρμόζουν έννοιες όπως το Design Thinking. Οι πολλαπλές λειτουργικές ομάδες πρέπει να αλληλεπιδρούν με πελάτες (ακόμα και μη πελάτες) για να μην φιλτράρουν τα στοιχεία τους.
- Κριτικές – Οι καλύτερες στην κατηγορία εταιρείες βλέπουν τις κριτικές ως check-in. Είναι ένας τρόπος για να γίνουν και να προστατευτούν οι επενδύσεις, κατά το πρότυπο των κεφαλαίων επιχειρηματικού κινδύνου. Όταν μια ομάδα είναι ναυλωμένη, συνάπτει μια απλή σύμβαση υψηλού επιπέδου με τη διοίκηση που ορίζει τις πιο σημαντικές διαστάσεις τρεις έως πέντε για το έργο και το προϊόν γύρω από μεταβλητές όπως χαρακτηριστικά, χρονοδιάγραμμα, κόστος προϊόντος και ποιότητα. Όσο η ομάδα παραμένει εντός των ορίων αυτής της συμφωνίας, η διοικητική ομάδα την αφήνει ήσυχη. Εφαρμογή διαχείριση εξαιρέσεων για την ανάπτυξη προϊόντων κρατά τα check-in λίγα, μακριά μεταξύ τους και εστιασμένα στα βασικά.
- Πόροι – Ένα από τα πιο κοινά προβλήματα που βλέπουμε είναι ομάδες που δεν διαθέτουν πόρους. Όχι μόνο οι οργανισμοί αναλαμβάνουν πάρα πολλά έργα, αλλά συχνά οι βασικές δεξιότητες όπως η διαχείριση προγραμμάτων και προϊόντων είναι ελλιπείς. Η έλλειψη επικοινωνίας μεταξύ της ομάδας Dev και των λειτουργιών συχνά αφήνει τις ομάδες χωρίς κατάλληλους πόρους. Είναι βέλτιστη πρακτική να υπάρχουν λίγα έργα ανά διαχειριστή έργου και όλα τα έργα απαιτούν ισχυρή υποστήριξη από τη Διαχείριση προϊόντων.
- Ρόλοι και ευθύνες – Ένα από τα προβλήματα που μπορούν να αποφευχθούν περισσότερο στην ανάπτυξη προϊόντων είναι οι ασαφείς ρόλοι και οι ευθύνες της ομάδας. Το πιο σημαντικό πλεονέκτημα της διευκρίνισης των ρόλων είναι ότι η ομάδα κατανοεί ποιος είναι ο DRI (Directly Responsible Individual) για τα βασικά παραδοτέα. Ενα απλό Διάγραμμα RACI αυτό δείχνει ΠΟΥ είναι άμεσα υπεύθυνος για τι Το παραδοτέο μπορεί να βοηθήσει πολύ προς την επίλυση αυτού του βασικού (αλλά εξοργιστικού) ζητήματος.
- Παραδοτέα – Τα παραδοτέα που παράγει η ομάδα για τη διαχείριση κατά τη διάρκεια του ταξιδιού του Dev θα πρέπει να είναι λίγα και ισχυρά. Ένα κοινό πρόβλημα που βλέπουμε είναι ότι τα παραδοτέα έχουν διογκωθεί, με περιττές πληροφορίες που δεν βοηθούν τους διευθυντές να λαμβάνουν αποφάσεις καλύτερα ή πιο γρήγορα. Έχετε μερικά συμφωνημένα έγγραφα, όπως ένα Σχέδιο Έκδοσης, Συμφωνημένο Εκκρεμές και Σχέδιο Δοκιμών, και μείνετε σε αυτά.

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