Σε αυτό το άρθρο, θα μοιραστώ την εμπειρία μου στην επιλογή ιδεών για την ανάπτυξη της λειτουργικότητας των προϊόντων μας και θα σας πω πώς να διατηρήσετε τους κύριους φορείς ανάπτυξης.
Αναπτύσσουμε ένα αυτοματοποιημένο σύστημα διακανονισμού (ACP) - τιμολόγηση. Ορος
Η διάρκεια ζωής του προϊόντος μας είναι 14 χρόνια. Κατά τη διάρκεια αυτής της περιόδου, το σύστημα έχει εξελιχθεί από τις πρώτες εκδόσεις ενός συστήματος βιομηχανικών τιμολογίων σε ένα αρθρωτό συγκρότημα που αποτελείται από 18 προϊόντα που αλληλοσυμπληρώνονται. Μία από τις πιο σημαντικές πτυχές της μακροζωίας των προγραμμάτων είναι η συνεχής ανάπτυξη. Και η ανάπτυξη απαιτεί ιδέες.
Ιδέες
πηγές
Υπάρχουν 5 πηγές:
- Ο κύριος φίλος ενός προγραμματιστή εταιρικών πληροφοριακών συστημάτων είναι πελάτης. Και ο πελάτης είναι μια συλλογική εικόνα υπευθύνων λήψης αποφάσεων, χορηγών έργων, ιδιοκτητών και εκτελεστών διαδικασιών, εσωτερικών ειδικών πληροφορικής, απλών χρηστών και μεγάλου αριθμού ενδιαφερόμενων ατόμων σε διάφορους βαθμούς. Είναι σημαντικό για εμάς κάθε εκπρόσωπος του πελάτη να είναι δυνητικά προμηθευτής ιδεών. Στη χειρότερη περίπτωση, λαμβάνουμε μόνο αρνητικά σχόλια σχετικά με προβλήματα στο σύστημα. Στην καλύτερη περίπτωση, υπάρχει ένα άτομο στο πλευρό του πελάτη που είναι μια συνεχής πηγή ιδεών για βελτίωση, παρέχοντας δομημένες πληροφορίες για τις ανάγκες του πελάτη.
- Το δικό μας πωλητές και διαχειριστές λογαριασμών αποτελούν τη δεύτερη πιο σημαντική πηγή ιδεών για βελτίωση. Επικοινωνούν ενεργά και εκτενώς με εκπροσώπους του κλάδου και λαμβάνουν ερωτήσεις από πρώτο χέρι σχετικά με τη λειτουργία χρέωσης από πιθανούς πελάτες. Οι πωλητές και οι λογαριασμοί πρέπει να γνωρίζουν όλες τις σημαντικές αλλαγές στη λειτουργικότητά τους και τις πιο πρόσφατες ενημερώσεις στο λογισμικό των ανταγωνιστών και να μπορούν να αιτιολογούν τα πλεονεκτήματα και τα μειονεκτήματα των διαφορετικών λύσεων. Αυτοί είναι οι υπάλληλοί μας που είναι οι πρώτοι που αντιλαμβάνονται εάν ορισμένες δυνατότητες τιμολόγησης γίνονται de facto πρότυπο, χωρίς το οποίο το λογισμικό δεν μπορεί να θεωρηθεί ολοκληρωμένο.
- Ιδιοκτήτης προιόντος — ένας από τους κορυφαίους διευθυντές μας ή ένας πολύ έμπειρος διαχειριστής έργου. Κρατάει κατά νου τους στρατηγικούς στόχους της εταιρείας και προσαρμόζει τα σχέδια ανάπτυξης προϊόντων σύμφωνα με αυτούς.
- Αρχιτέκτονας, ένα άτομο που κατανοεί τις δυνατότητες και τους περιορισμούς των τεχνολογικών λύσεων που επιλέγονται/χρησιμοποιούνται και τον αντίκτυπό τους στην ανάπτυξη προϊόντων.
Ομάδες ανάπτυξης και δοκιμών. Άτομα που εμπλέκονται άμεσα στην ανάπτυξη προϊόντων.
Ταξινόμηση αιτημάτων
Λαμβάνουμε ακατέργαστα δεδομένα από πηγές - επιστολές, εισιτήρια, προφορικά αιτήματα. Ολα
Οι προσφυγές ταξινομούνται:
- Διαβουλεύσεις με τη σημασία «Πώς να το κάνω;», «Πώς λειτουργεί;», «Γιατί δεν λειτουργεί;», «Δεν καταλαβαίνω...». Αιτήματα αυτού του τύπου πηγαίνουν στη Γραμμή Υποστήριξης Επιπέδου 1. Είναι δυνατό να επανεκπαιδεύσετε τη διαβούλευση σε άλλους τύπους αιτημάτων.
- Περιστατικά με την έννοια «Δεν λειτουργεί» και «Σφάλμα». Επεξεργάζεται από 2 και 3 γραμμές υποστήριξης. Εάν είναι απαραίτητες οι άμεσες διορθώσεις και η απελευθέρωση μιας ενημέρωσης κώδικα, μπορούν να μεταφερθούν από την υποστήριξη απευθείας στην ανάπτυξη. Είναι δυνατό να το επαναταξινομήσετε ως αίτημα αλλαγής και να το στείλετε στο ανεκτέλεστο.
- Αιτήματα για αλλαγές και ανάπτυξη. Μπαίνουν στο ανεκτέλεστο προϊόν, παρακάμπτοντας τις γραμμές υποστήριξης. Υπάρχει όμως ξεχωριστή διαδικασία επεξεργασίας για αυτά.
Υπάρχουν στατιστικά στοιχεία σχετικά με τα αιτήματα: αμέσως μετά την κυκλοφορία, ο αριθμός των αιτημάτων αυξάνεται κατά 10-15% για μικρό χρονικό διάστημα. Υπάρχουν επίσης αυξήσεις στα αιτήματα όταν ένας νέος πελάτης με μεγάλο αριθμό χρηστών έρχεται στις υπηρεσίες cloud μας. Οι άνθρωποι μαθαίνουν να χρησιμοποιούν νέες δυνατότητες λογισμικού, χρειάζονται συμβουλές. Ακόμη και ένας μικρός πελάτης, όταν ξεκινά να εργάζεται στο σύστημα, καίει εύκολα περισσότερες από 100 ώρες διαβουλεύσεων ανά μήνα. Επομένως, όταν συνδέουμε έναν νέο πελάτη, διατηρούμε πάντα χρόνο για αρχικές διαβουλεύσεις. Συχνά επιλέγουμε ακόμη και έναν συγκεκριμένο ειδικό. Η τιμή ενοικίασης, φυσικά, δεν καλύπτει αυτά τα εργατικά κόστη, αλλά με την πάροδο του χρόνου η κατάσταση εξομαλύνεται. Η περίοδος προσαρμογής διαρκεί συνήθως από 1 έως 3 μήνες, μετά την οποία η ανάγκη για συμβουλευτική μειώνεται σημαντικά.
Προηγουμένως, χρησιμοποιούσαμε αυτογραμμένες λύσεις για την αποθήκευση αιτημάτων. Σταδιακά όμως στραφήκαμε στα προϊόντα Atlassian. Πρώτα, μεταφέραμε την ανάπτυξη για να διευκολύνουμε την εργασία σύμφωνα με το Agile και μετά την υποστήριξη. Τώρα όλες οι κρίσιμες διεργασίες βρίσκονται στο Jira SD, καθώς και υποστηρίζονται από διάφορες προσθήκες για το Jira, συν το Confluence. Οι αυτογραμμένες λύσεις παρέμειναν μόνο για διαδικασίες που δεν ήταν κρίσιμες για τις δραστηριότητες της εταιρείας. Αποδεικνύεται ότι οι εργασίες μας είναι πλέον διατομεακές και μπορούν να μεταφερθούν μεταξύ υποστήριξης και ανάπτυξης χωρίς να μεταπηδούν από το ένα σύστημα στο άλλο.
Από αυτόν τον σύνδεσμο μπορούμε να λάβουμε δεδομένα για όλες τις εργασίες, το προγραμματισμένο και πραγματικό κόστος εργασίας, να χρησιμοποιήσουμε διάφορες επιλογές τιμολόγησης για πελάτες και να δημιουργήσουμε τεκμηρίωση για εσωτερικές ανάγκες και αναφορά στους πελάτες.
Επεξεργασία αιτημάτων αλλαγής
Συνήθως, τέτοια αιτήματα έχουν τη μορφή απαιτήσεων λειτουργικότητας. Ο αναλυτής μας μελετά το αίτημα, δημιουργεί προδιαγραφές και τεχνικές προδιαγραφές ανώτατου επιπέδου. Μεταφέρει τις προδιαγραφές και τις τεχνικές προδιαγραφές στο άτομο που υπέβαλε αυτό το αίτημα για έγκριση - πρέπει να είμαστε σίγουροι ότι μιλάμε την ίδια γλώσσα με τον πελάτη.
Έχοντας λάβει επιβεβαίωση από τον πελάτη ότι καταλάβαμε ο ένας τον άλλον σωστά, ο αναλυτής εισάγει το αίτημα στο ανεκτέλεστο προϊόν.
Διαχείριση λειτουργικότητας προϊόντος
Το ανεκτέλεστο συσσωρεύει εισερχόμενα αιτήματα για αλλαγή και ανάπτυξη. Το τεχνικό συμβούλιο, που αποτελείται από τον διευθυντή, τους επικεφαλής υποστήριξης, ανάπτυξης, πωλήσεων και τον αρχιτέκτονα συστημάτων, συνεδριάζει κάθε έξι μήνες. Σε μορφή συζήτησης, το συμβούλιο αναλύει και ιεραρχεί τις εφαρμογές από το ανεκτέλεστο και συμφωνεί σε 5 εργασίες ανάπτυξης για εφαρμογή στην επόμενη έκδοση.
Στην πραγματικότητα, το τεχνικό συμβούλιο ανταποκρίνεται στις απαιτήσεις της βιομηχανίας και της αγοράς εξετάζοντας τις ανάγκες που εκφράζονται στις αιτήσεις. Ό,τι έχει μικρή σημασία παραμένει στο υστέρημα και δεν φτάνει στην ανάπτυξη.
Ταξινόμηση Αιτημάτων Αλλαγών και Οικονομικών
Η ανάπτυξη είναι ακριβή. Επομένως, θα σας ενημερώσουμε αμέσως ποιες επιλογές μπορεί να έχουμε εάν το αίτημα για αλλαγή προήλθε από πελάτη και όχι από υπάλληλο.
Ταξινομούμε τα αιτήματα αλλαγής ως εξής: ανάγκη του κλάδου ή ατομικό χαρακτηριστικό της επιχείρησης. μια σημαντική ποσότητα νέας λειτουργικότητας ή μια μικρή επιδιόρθωση. Μικρές διορθώσεις και μεμονωμένα αιτήματα διεκπεραιώνονται χωρίς περιττά στοιχεία. Τα μεμονωμένα αιτήματα υπολογίζονται και υλοποιούνται για έναν συγκεκριμένο πελάτη ως μέρος της εργασίας μαζί του.
Εάν αυτό δεν είναι μια τεράστια ανάγκη του κλάδου και ο όγκος της λειτουργικότητας είναι μεγάλος, τότε μπορεί να ληφθεί απόφαση για την ανάπτυξη μιας νέας ξεχωριστής ενότητας που θα πωλείται επιπλέον της κύριας λειτουργικότητας. Εάν ληφθεί ένα τέτοιο αίτημα από έναν πελάτη, μπορούμε να καλύψουμε το κόστος ανάπτυξης της ενότητας, να παρέχουμε στον πελάτη τη μονάδα δωρεάν ή με μερική πληρωμή και να διαθέσουμε την ίδια την ενότητα προς πώληση. Σε μια τέτοια περίπτωση, ο πελάτης αναλαμβάνει μέρος του μεθοδολογικού φορτίου και ουσιαστικά πραγματοποιεί μια πιλοτική εφαρμογή της ενότητας στον εαυτό του.
Εάν αυτή είναι μια τεράστια ανάγκη του κλάδου, τότε μπορεί να ληφθεί απόφαση να συμπεριληφθούν νέα λειτουργικότητα στο βασικό προϊόν. Το κόστος σε αυτήν την περίπτωση βαρύνει αποκλειστικά εμάς και η νέα λειτουργικότητα εμφανίζεται στην τρέχουσα έκδοση των προγραμμάτων.
Στους παλιούς πελάτες παρέχεται ενημέρωση.
Μπορεί επίσης να συμβαίνει ότι αρκετοί πελάτες έχουν παρόμοια ανάγκη, αλλά δεν πληρούν τις προϋποθέσεις για ένα μαζικό προϊόν. Σε αυτήν την περίπτωση, μπορούμε να στείλουμε τις προδιαγραφές σε αυτούς τους πελάτες και να προσφέρουμε να μοιράσουμε το κόστος ανάπτυξης μεταξύ τους. Στο τέλος, όλοι κερδίζουν: οι πελάτες λαμβάνουν λειτουργικότητα με χαμηλό κόστος, εμπλουτίζουμε το προϊόν και μετά από κάποιο χρονικό διάστημα, άλλοι συμμετέχοντες στην αγορά μπορούν επίσης να αποκτήσουν τη λειτουργικότητα για τη χρήση τους.
DevOps
Η ανάπτυξη προετοιμάζει δύο μεγάλες εκδόσεις το χρόνο. Σε κάθε έκδοση, δεσμεύεται χρόνος για την υλοποίηση 5 εργασιών που λαμβάνονται από το τεχνικό συμβούλιο. Έτσι, μέσα στη ρουτίνα, δεν ξεχνάμε ποτέ την ανάπτυξη προϊόντων.
Κάθε έκδοση υποβάλλεται σε ένα κατάλληλο σύνολο δοκιμών και τεκμηρίωσης. Στη συνέχεια, αυτή η έκδοση εγκαθίσταται στο δοκιμαστικό περιβάλλον του αντίστοιχου πελάτη, ο οποίος με τη σειρά του ελέγχει σχολαστικά τα πάντα και μόνο μετά από αυτό η κυκλοφορία μεταφέρεται στην παραγωγή.
Εκτός από το σύστημα έκδοσης, υπάρχει μια μορφή για γρήγορες επιδιορθώσεις σφαλμάτων, ώστε οι πελάτες να μην ζουν με σφάλματα για έξι μήνες. Αυτή η ενδιάμεση μορφή θα σας επιτρέψει να ανταποκριθείτε γρήγορα σε περιστατικά πρώτης προτεραιότητας και να εκπληρώσετε τις δηλωμένες SLA.
Όλα τα παραπάνω ισχύουν κυρίως για τον εταιρικό τομέα και τις λύσεις on-premise. Για τις υπηρεσίες cloud που απευθύνονται στο τμήμα SMB, δεν υπάρχουν τόσο ευρείες ευκαιρίες για τους πελάτες να συμμετέχουν στην ανάπτυξη προϊόντων. Η μορφή ενοικίασης SMB δεν το υποθέτει καν. Αντί για αίτημα αλλαγής με τη μορφή σαφών απαιτήσεων από το εταιρικό μέρος, εδώ υπάρχουν μόνο συνηθισμένα σχόλια και επιθυμίες για την υπηρεσία. Προσπαθούμε να ακούσουμε, αλλά το προϊόν είναι τεράστιο και η επιθυμία ενός πελάτη να φέρει κάτι οικείο από το παλιό ιστορικό του σύστημα μπορεί να έρχεται σε αντίθεση με τη στρατηγική ανάπτυξης του συστήματος στο σύνολό του.
Πηγή: www.habr.com