In questo articolo condividerò la mia esperienza nella selezione di idee per lo sviluppo della funzionalità dei nostri prodotti e ti spiegherò come mantenere i principali vettori di sviluppo.
Stiamo sviluppando un sistema di regolamento automatizzato (ACP) - fatturazione. Termine
La vita del nostro prodotto è di 14 anni. Durante questo periodo, il sistema si è evoluto dalle prime versioni di un sistema tariffario industriale ad un complesso modulare composto da 18 prodotti che si completano a vicenda. Uno degli aspetti più importanti della longevità dei programmi è lo sviluppo costante. E lo sviluppo richiede idee.
Идеи
fonti
Ci sono 5 fonti:
- L'amico principale di uno sviluppatore di sistemi informativi aziendali è cliente. E il cliente è un'immagine collettiva di decisori, sponsor di progetti, proprietari ed esecutori di processi, specialisti IT interni, utenti ordinari e un gran numero di individui interessati a vari livelli. Per noi è importante che ciascuno dei rappresentanti del cliente sia potenzialmente un fornitore di idee. Nel peggiore dei casi riceviamo solo feedback negativi sui problemi del sistema. Nel migliore dei casi c’è una persona al fianco del cliente che è una fonte costante di spunti di miglioramento, fornendo informazioni strutturate sulle esigenze del cliente.
- Il nostro venditori e account manager sono la seconda fonte più importante di idee per il miglioramento. Comunicano attivamente ed ampiamente con i rappresentanti del settore e ricevono domande di prima mano sulla funzionalità di fatturazione da potenziali clienti. Venditori e account devono essere consapevoli di tutti i cambiamenti significativi nelle loro funzionalità e degli ultimi aggiornamenti ai software della concorrenza ed essere in grado di giustificare i pro e i contro delle diverse soluzioni. Sono i nostri dipendenti i primi a intuire se alcune funzionalità di fatturazione diventano uno standard di fatto, senza il quale il software non può essere considerato completo.
- Proprietario del prodotto — uno dei nostri top manager o un project manager di grande esperienza. Tiene presenti gli obiettivi strategici dell'azienda e adegua i piani di sviluppo del prodotto in conformità con essi.
- architetto, una persona che comprende le capacità e i limiti delle soluzioni tecnologiche scelte/utilizzate e il loro impatto sullo sviluppo del prodotto.
Team di sviluppo e test. Persone direttamente coinvolte nello sviluppo del prodotto.
Classificazione delle richieste
Riceviamo dati grezzi da fonti: lettere, biglietti, richieste verbali. Tutto
i ricorsi sono classificati:
- Consultazioni con il significato “Come si fa?”, “Come funziona?”, “Perché non funziona?”, “Non capisco...”. Le richieste di questo tipo vanno alla Linea di supporto di livello 1. È possibile riqualificare la consultazione verso altre tipologie di richieste.
- incidenti con il significato “Non funziona” ed “Errore”. Elaborato da 2 e 3 linee di supporto. Se sono necessarie correzioni tempestive e il rilascio di una patch, queste possono essere trasferite dal supporto direttamente allo sviluppo. È possibile riclassificarla come richiesta di modifica e inviarla al backlog.
- Richieste di modifiche e sviluppo. Entrano nel product backlog, aggirando le linee di supporto. Ma per loro esiste una procedura di elaborazione separata.
Esistono statistiche sulle richieste: subito dopo il rilascio il numero di richieste aumenta del 10-15% per un breve periodo. Le richieste aumentano anche quando un nuovo cliente con un gran numero di utenti accede ai nostri servizi cloud. Le persone stanno imparando a utilizzare le nuove funzionalità del software e hanno bisogno di consigli. Anche un piccolo cliente, quando inizia a lavorare nel sistema, brucia facilmente più di 100 ore di consultazioni al mese. Pertanto, quando colleghiamo un nuovo cliente, riserviamo sempre del tempo per le consultazioni iniziali. Spesso selezioniamo anche uno specialista specifico. Il prezzo dell'affitto, ovviamente, non copre questi costi di manodopera, ma col tempo la situazione si livella. Il periodo di adattamento dura solitamente da 1 a 3 mesi, dopodiché la necessità di consulenza è significativamente ridotta.
In precedenza, utilizzavamo soluzioni autoprodotte per archiviare le richieste. Ma gradualmente siamo passati ai prodotti Atlassian. Innanzitutto abbiamo trasferito lo sviluppo per facilitare il lavoro secondo Agile, quindi il supporto. Ora tutti i processi critici risiedono in Jira SD, inoltre sono supportati da vari plugin per Jira, oltre a Confluence. Le soluzioni autoprodotte sono rimaste solo per i processi che non erano critici per le attività dell’azienda. Si scopre che ora i nostri compiti sono trasversali e possono essere trasferiti dal supporto allo sviluppo senza passare da un sistema all’altro.
Da questo collegamento possiamo ottenere dati su tutte le attività, costi di manodopera pianificati ed effettivi, utilizzare varie opzioni di prezzo per i clienti e generare documentazione per esigenze interne e reporting per i clienti.
Elaborazione delle richieste di modifica
In genere, tali richieste si presentano sotto forma di requisiti di funzionalità. Il nostro analista studia la richiesta, crea un capitolato e specifiche tecniche di primo livello. Trasferisce le specifiche e le specifiche tecniche alla persona che ha presentato questa richiesta di approvazione: dobbiamo essere sicuri di parlare la stessa lingua con il cliente.
Dopo aver ricevuto conferma dal cliente che ci siamo capiti correttamente, l'analista inserisce la richiesta nel product backlog.
Gestione delle funzionalità del prodotto
Il backlog accumula richieste in arrivo di cambiamento e sviluppo. Il consiglio tecnico, composto dal direttore, dai responsabili del supporto, dello sviluppo, delle vendite e dall'architetto di sistema, si riunisce ogni sei mesi. In un formato di discussione, il consiglio analizza e dà priorità alle domande dal backlog e concorda 5 attività di sviluppo da implementare nella prossima versione.
In effetti, il consiglio tecnico risponde alle richieste dell'industria e del mercato esaminando le esigenze espresse nelle domande. Tutto ciò che ha poca rilevanza resta nell'arretrato e non raggiunge lo sviluppo.
Classificazione delle richieste di modifica e finanza
Lo sviluppo è costoso. Pertanto, ti indicheremo immediatamente quali opzioni potremmo avere se la richiesta di modifica provenisse da un cliente e non da un dipendente.
Classifichiamo le richieste di modifica come segue: necessità del settore o caratteristica individuale dell'impresa; una quantità significativa di nuove funzionalità o una correzione minore. Correzioni minori e richieste individuali vengono elaborate senza fronzoli. Le richieste individuali vengono calcolate e implementate per un cliente specifico come parte del lavoro di progetto con lui.
Se questa non è un'enorme esigenza del settore e il volume delle funzionalità è elevato, è possibile prendere la decisione di sviluppare un nuovo modulo separato che verrà venduto in aggiunta alla funzionalità principale. Se tale richiesta viene ricevuta da un cliente, possiamo coprire i costi di sviluppo del modulo, fornire al cliente il modulo gratuitamente o con pagamento parziale e mettere in vendita il modulo stesso. In una situazione del genere, il cliente si assume parte del carico metodologico e essenzialmente conduce su se stesso un'implementazione pilota del modulo.
Se si tratta di un'enorme esigenza del settore, è possibile prendere la decisione di includere nuove funzionalità nel prodotto di base. I costi in questo caso ricadono interamente su di noi e la nuova funzionalità appare nella versione attuale dei programmi.
Ai vecchi clienti viene fornito un aggiornamento.
Può anche darsi che diversi clienti abbiano un'esigenza simile, ma ciò non si qualifica per un prodotto di massa. In questo caso, possiamo inviare le specifiche a questi clienti e offrire di dividere tra loro i costi di sviluppo. Alla fine vincono tutti: i clienti ricevono funzionalità a basso costo, noi arricchiamo il prodotto e dopo un po' di tempo anche altri partecipanti al mercato possono ottenere la funzionalità per il loro utilizzo.
DevOps
Lo sviluppo prepara due major release all'anno. In ogni versione, il tempo è riservato per l'implementazione di 5 compiti ricevuti dal consiglio tecnico. Pertanto, nel mezzo della routine, non dimentichiamo mai lo sviluppo del prodotto.
Ogni versione è sottoposta a una serie adeguata di test e documentazione. Successivamente, questa versione viene installata nell'ambiente di test del cliente corrispondente, il quale, a sua volta, controlla meticolosamente tutto e solo dopo la versione viene trasferita in produzione.
Oltre al sistema di rilascio, esiste un formato per la correzione rapida dei bug in modo che i clienti non convivano con errori per sei mesi. Questo formato intermedio ti consentirà di rispondere rapidamente agli incidenti di prima priorità e di soddisfare gli SLA stabiliti.
Tutto quanto sopra vale principalmente per il settore aziendale e per le soluzioni on-premise. Per i servizi cloud rivolti al segmento delle PMI, non esistono opportunità così ampie per i clienti di partecipare allo sviluppo del prodotto. Il formato di noleggio PMI non presuppone nemmeno questo. Invece di una richiesta di modifica sotto forma di requisiti chiari da parte dell'azienda, qui ci sono solo feedback e desideri ordinari per il servizio. Cerchiamo di ascoltare, ma il prodotto è enorme e il desiderio di un cliente di portare qualcosa di familiare dal suo vecchio sistema storico può contraddire la strategia di sviluppo del sistema nel suo complesso.
Fonte: habr.com