Come uscire dal solco di supporto e iniziare a rimborsare il debito tecnico!

L'organizzazione del tuo amico ha un disperato bisogno di qualcuno che gestisca il cambiamento. Questa persona o gruppo prenderà richieste di modifica e correzioni di bug e darà la priorità a loro in base all'impatto sul business e all'impegno richiesto. In questo modo, le attività che sono più importanti per l'organizzazione nel suo complesso, verranno eseguite per prime, al contrario delle attività che sono più importanti per chiunque stia disturbando il tuo amico al momento.

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 business-critical che non funziona. Se c'è qualcosa che l'azienda può fare per aggirare il problema, questo riduce la gravità al livello successivo. Se l'applicazione non è business-critical, ciò rende la gravità ancora più bassa. Le richieste di nuovi miglioramenti sono normalmente prioritarie separatamente.

Fai in modo che qualcun altro prenda le chiamate e cambi la linea da

We'll get to that right away.

a

Very good suggestion. I'll create a feature request to begin work on it as soon as possible. If you'd like to follow the progress on your request, you can track it here: [link to case tracker ticket]. In the future, you can also submit requests for futures in the same way as I am here: [link to case tracker]

Questo è probabilmente il modo più semplice ed efficace per farlo secondo me. L'ultima parte cerca di ridurre lo stress su questa persona rispondendo alle chiamate nel tempo.

Il problema che stai riscontrando con il sistema di "priorità" corrente è che quando tutto è una priorità, niente è una priorità . Per questo, il tuo amico ha un disperato bisogno di ascoltare il consiglio di @Larry Coleman - persone separate dallo sviluppo che gestiscono le richieste di cambiamento. Idealmente, il tuo amico non dovrebbe nemmeno sapere di una richiesta di funzionalità, fino a quando quel gruppo separato ha convenuto che dovrebbe essere prioritario per il lavoro. Potrebbe anche essere questa nuova persona che sta rispondendo alle chiamate ora che le dà la priorità, a patto che capiscano il business e ne capiscano 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 momento del lancio. Inizialmente ha avuto successo (per un business solista-prenatale), ma suppongo che tutto abbia funzionato dal 2003 al 2007. Ho cercato di farlo da personale, ma ho imparato a fondo che assumere personale di qualità è costoso e per nulla facile. Suppongo che il tuo amico si trovi in una situazione simile.

Nel mio caso è stato subito chiaro che a un certo punto le cose sarebbero andate in discesa. L'attività era ancora in crescita, ma la concorrenza stava crescendo, il mercato sembrava in via di restringimento, c'erano segnali precoci (metà 2006) che si stava verificando un rallentamento economico, ecc. Fondamentalmente un certo numero di fattori ha portato a 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 come quelle che ho fatto male, ma qui c'è un breve asporto:

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

2. Usa controllo versione / test unità / tutto il trambusto relativo alle best practice. Sembrano tutti sciocchi / ridicoli / disinteressati quando vengono insegnati all'università, ma di solito sono le migliori pratiche per buone ragioni.

3. Assumi almeno un ragazzo di vendita / marketing, soprattutto se sei un tecnico. (Perché se così fosse, avrai la naturale tendenza a dedicare più tempo alle questioni tecnologiche che al marketing, anche se hai una rete di affiliati).

4. Crowd-source il tuo supporto. Crea un forum, in modo che gli utenti possano dare una mano. Configura un sistema di ticketing e invita i tuoi utenti esperti (in genere gli utenti del forum frequenti) a entrare 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, così puoi concentrarti sul quadro più grande.

5. Massimizza i tuoi sforzi per ridurre la quantità di supporto che stai offrendo. Meno supporto hai, più tempo dovrai fare cose più interessanti. Nel momento in cui il prodotto è a prova di manichino, i clienti saranno grati e anche le vendite e il personale di supporto.

6. Chiedi agli sviluppatori di fare un po 'di supporto (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 reingegnerizzazione / modifica del prodotto ( Interfaccia utente, funzionalità) se identificano qualcosa che li farà spendere meno tempo in supporto. L'idea è che, se sono ripetutamente tormentati dagli utenti per gli stessi motivi, vorranno risolvere le cose al più presto in modo che possano sbarazzarsi delle chiamate di supporto. E quelli più intelligenti lo fanno davvero, ed è esattamente quello che vuoi.

7. Se senti che il prodotto sta per morire, decidi di ucciderlo qua e là e lavora al passaggio successivo. Lascia morire, davvero. Una vacca da mungere è una vacca da mungere; quando ha raggiunto il suo scopo, mandalo dal macellaio. Fallo con delicatezza (per i clienti), ma non lasciare che la sua estesa sopravvivenza diventi troppo del tuo tempo se il sovraccarico di manutenzione è tale per cui la concorrenza, con il vantaggio di essere ritardatari e l'aver accumulato un certo debito tecnico , implementerà nuove funzionalità più velocemente di quanto tu possa comunque.

Una riga alla volta. Prendi un po 'più di tempo per ogni correzione, ripulisci gli hack e aggiungi test automatici man mano che procedi. Spesso, fare qualcosa di giusto finisce per essere molto più veloce dell'aggiunta di un altro hotfix. Se il management spinge il tuo amico a lavorare più velocemente, come spesso preferisce fare alla dirigenza, dovrebbe sviluppare una skin più grossa e passare alla modalità "when it done".

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 ciò che verrà fatto non cambierà di solito durante lo sprint. Quindi ci sono alcune regole su cosa si farà e cosa potrebbe non essere fatto subito. L'altra domanda è in che misura il management supporta il suo desiderio di non trovarsi in una carreggiata di supporto? Questo potrebbe anche essere importante in quanto una gestione apatica può essere un po 'una campana a morto per il progetto del tuo amico.

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

• Disegna un rapporto su ogni problema nel sistema e il ragionamento dietro perché sono cattivi. I problemi di progettazione dovrebbero essere evidenziati e la quantità di refactoring necessaria.
• Le scadenze dovrebbero essere date per risolvere i problemi
• Il rapporto dovrebbe essere consegnato ai suoi manager e quindi ai detentori di quote nel sistema
• Tutti gli sviluppi delle funzionalità dovrebbero essere interrotti durante il periodo di fixing.

Molti progetti lo fanno. Se la direzione non può essere convinta, è un caso perduto, ma se sono d'accordo il sistema potrebbe essere rimesso in forma nel lungo periodo.