Come uscire dalla routine di supporto e iniziare a rimborsare il debito tecnico!

Ho un amico". Sì, buon inizio, lo so, ma sinceramente non sono io!

Fondamentalmente sta lavorando a un progetto di successo da circa 4 anni, la difficoltà è che il debito tecnico ha raggiunto e sta trovando quasi impossibile smettere di supportare il prodotto (modificando questo e quello) e andare avanti con un vero sviluppo.

Ho fatto vari suggerimenti, ho registrato tutto il tuo tempo, creato biglietti, non rispondere alle e-mail, ecc. Ecc. Il problema è che sembra solo ricordare che non sta facendo nulla di "utile".

Il debito tecnico si è in gran parte verificato perché in primo luogo è stato un grande vantaggio per il prodotto, ricevere richieste e telefonate dagli utenti e implementarle rapidamente.

Quello che vorrei sapere è che qualcuno ha qualche suggerimento su come uscire da questa routine, gran parte del quale cambierebbe le percezioni degli utenti in modo che non pensino di poter semplicemente suonare e aspettarsi che qualcosa essere fatto allora e lì.

Va benissimo dire pianificare meglio, anche se capisco che è molto difficile pianificare lo sviluppo effettivo dato il requisito di supporto e le relative pressioni degli utenti (vedi sopra).

L'organizzazione del tuo amico ha un disperato bisogno di qualcuno che gestisca il cambiamento. Questa persona o gruppo accetterebbe le richieste di modifica e le correzioni degli errori e le darebbe la priorità in base all'impatto aziendale e alla quantità di sforzi richiesti. In questo modo, i compiti che sono più importanti per l'organizzazione nel suo complesso verrebbero svolti per primi, al contrario dei compiti che sono più importanti per chiunque al momento disturbi il tuo amico.

EDIT: come esempio di come funzionerebbe, la maggior parte delle organizzazioni ha una scala di gravità. Il livello di gravità più elevato è un'applicazione o una funzione critica per l'azienda che non funziona. Se c'è qualcosa che l'azienda può fare per aggirare il problema, ciò riduce la gravità al livello successivo. Se l'applicazione non è critica per l'azienda, ciò rende la gravità ancora più bassa. Le richieste di nuovi miglioramenti vengono normalmente assegnate le priorità separatamente.

Fai qualcun altro rispondere alle chiamate e fai cambiare la linea

Ci arriveremo subito.

per

Ottimo suggerimento Creerò una richiesta di funzione per iniziare a lavorarci il prima possibile. Se desideri seguire l'avanzamento della tua richiesta, puoi seguirla qui: [link al ticket tracker del caso]. In futuro, puoi anche inviare richieste di futures allo stesso modo in cui sono qui: [link al tracker del caso]

Questo è probabilmente il modo più semplice ed efficace per farlo secondo me. L'ultimo bit cerca di ridurre lo stress di questa persona che risponde alle chiamate nel tempo.

Il problema che stai riscontrando con l'attuale sistema "prioritario" è che quando tutto è una priorità, nulla è una priorità . Per questo, il tuo amico ha un disperato bisogno di seguire il consiglio di @Larry Coleman: persone separate dallo sviluppo che gestiscono le richieste di modifica. Idealmente il tuo amico non dovrebbe nemmeno sapere di una richiesta di funzionalità, fino a quando quel gruppo separato non ha concordato che dovrebbe essere prioritario per il lavoro. Potrebbe anche essere questa nuova persona che sta rispondendo alle chiamate ora che le dà la priorità, purché capiscano il business e comprendano lo sviluppo.

Anch'io ho vissuto una situazione simile. Il prodotto è stato costruito su stringhe di scarpe ed è stato il primo nel suo mercato al lancio. Inizialmente ebbe successo (per un'azienda solista), ma suppongo che tutto abbia funzionato dal 2003 al 2007. Ho cercato di assoldarlo, ma ho imparato a fondo che assumere un buon personale è costoso e per nulla facile. Suppongo che il tuo amico si trovi in ​​una situazione simile.

Nel mio caso è emerso presto che le cose sarebbero andate in discesa ad un certo punto. Il business era ancora in crescita, ma la concorrenza si stava alzando la testa, il mercato sembrava che si stesse restringendo, c'erano i primi segnali (metà 2006) che si stava verificando un rallentamento economico, ecc. Fondamentalmente una serie di fattori ha portato io per decidere che il prodotto sarebbe morto alla fine; più tardi, meglio è (per i clienti e per me).

In retrospettiva, probabilmente ho preso tante buone decisioni quante ne ho fatte di cattive, ma ecco una breve cosa da asporto:

1. Personale correttamente e presto. Ottieni finanziamenti se ne hai bisogno. (Non cercare alcuno è stato il mio più grande errore.) Se hai vendite, troverai denaro.

2. Usa il controllo versione / test unitari / tutti gli hoopla relativi alle migliori pratiche. Sembrano tutti sciocchi / ridicoli / poco interessanti quando insegnano all'università, ma di solito sono le migliori pratiche per buone ragioni.

3. Assumi almeno un addetto alle vendite / marketing, soprattutto se sei orientato alla tecnologia. (Perché in tal caso, avrai una naturale tendenza a dedicare più tempo alle questioni tecnologiche che al marketing, anche se hai una rete di affiliati).

4. Folla il tuo supporto. Crea un forum, in modo che gli utenti possano aiutarsi. Imposta un sistema di biglietteria e invita i tuoi utenti esperti (in genere frequenti utenti del forum) a tuffarsi in una sezione speciale come assistenti virtuali. Lascia che si prendano cura delle moltitudini di clienti che hanno bisogno di questo / quel piccolo compito fatto per pochi dollari, in modo da poterti concentrare sul quadro più ampio.

5. Massimizza i tuoi sforzi per ridurre la quantità di supporto che stai offrendo. Meno supporto hai, più tempo dovrai fare cose più interessanti. Prima che il prodotto sia fittizio, i clienti saranno grati e così anche le vendite e il personale di supporto.

6. Chiedi agli sviluppatori effettivi di eseguire parte dell'assistenza (un'ora o due al giorno, in modo da non perdere il contatto con la realtà) e dare loro una mano libera per suggerire qualsiasi riprogettazione / modifica del prodotto (UI, funzionalità) se identificare tutto ciò che gli farà passare meno tempo in supporto. L'idea è che, se vengono infastiditi dagli utenti più e più volte per gli stessi motivi, vorranno sistemare le cose al più presto in modo da poter sbarazzarsi delle chiamate di supporto. E quelli più intelligenti lo fanno davvero, ed è esattamente quello che vuoi.

7. Se ritieni che il prodotto stia per morire, decidi di ucciderlo qua e là e procedere al passaggio successivo. Lascialo morire, davvero. Una vacca in contanti è una vacca in contanti; quando ha raggiunto il suo scopo, inviarlo al macellaio. Fallo con delicatezza (per i clienti), ma non lasciare che la sua sopravvivenza estesa ti inghiotti troppo del tuo tempo se il sovraccarico di manutenzione è tale che la concorrenza, con il vantaggio di essere ritardatari e di aver accumulato qualche debito tecnico , implementerà comunque le nuove funzionalità più velocemente di quanto tu possa fare.

Una riga alla volta. Prenditi un po 'più di tempo per ogni correzione, ripulendo gli hack e aggiungendo test automatici mentre procedi. Spesso, fare qualcosa di giusto finisce per essere molto più veloce dell'aggiunta di un altro aggiornamento rapido. Se la gestione spinge il tuo amico a lavorare più velocemente, come spesso piace fare alla direzione, dovrebbe crescere una pelle più spessa ed entrare in modalità "quando ha finito".

La chiave è che tipo di metodologia di sviluppo ha intorno a sé per proteggerlo in una certa misura? Ad esempio, in Scrum c'è l'idea che il lavoro che verrà svolto di solito non cambia durante lo sprint. Quindi ci sono alcune regole su ciò che verrà fatto e ciò che potrebbe non essere fatto immediatamente. L'altra domanda è: in che misura il management supporta la sua volontà di non essere in una routine di supporto? Questo potrebbe anche essere importante in quanto una gestione apatica può essere un po 'una campana a morte per il progetto del tuo amico.

La cosa migliore da fare è fermare l'autobus e dare un'occhiata indietro. Il tuo amico dovrebbe

• Redigere un rapporto di ogni problema nel sistema e il ragionamento alla base del perché sono cattivi. Dovrebbero essere evidenziati i problemi di progettazione e la quantità di refactoring necessaria.
• Dovrebbero essere fornite tempistiche approssimative per risolvere i problemi
• Il rapporto dovrebbe essere consegnato ai suoi dirigenti e quindi agli stakeholder nel sistema
• Tutti gli sviluppi delle funzionalità dovrebbero essere interrotti durante il periodo di fissaggio.

Molti progetti lo fanno. Se la direzione non può essere convinta che si tratti di un caso perduto, ma se concordano, il sistema potrebbe tornare in forma a lungo termine.