Gli ingegneri del software dovrebbero anche fungere da supporto tecnico? [chiuso]

Questo è un problema classico nelle aziende che hanno una componente di sviluppo software nel loro lavoro, indipendentemente dal fatto che siano aziende di software o meno. Mi sforzo sempre con questo.

Coinvolgimento degli sviluppatori nel supporto alla produzione

Pro

• Sindrome "Sviluppo nel vuoto" . È utile acquisire visibilità su come gli utenti utilizzano l'app. Finché non ho visto questo come uno sviluppatore giovane, non mi rendevo conto di quanto fossi uno sviluppatore UI schifoso. Tutto quello che mi importava era la codifica e non il design, l'analisi o la prospettiva dell'utente.
• Gli sviluppatori che non sono bravi come pensano di essere possono essere umiliati (anche se non è garantito che otterrai questo vantaggio, alcuni sviluppatori sono veramente ignari, egoisti e testardi).
• Gli sviluppatori acquisiranno conoscenze di dominio . Questo è fondamentale se i tuoi sviluppatori devono eventualmente migliorare nell'individuare e colmare le lacune della fase di analisi aziendale (supponendo che ce ne sia qualcuno).
• Un buon supporto è un punto di marketing. Se lo fai bene, i clienti lo apprezzeranno. E uno sviluppatore a tutto tondo con capacità di comunicazione e conoscenza del dominio è in grado di farlo bene. Tuttavia, preferirei comunque che le applicazioni siano di qualità sufficientemente elevata da non richiedere supporto. La qualità superiore è la sua forma di supporto al cliente (e anche un punto di marketing).

Contro

• Fattore di interruzione . Questo è l'errore numero uno nel mescolare lavoro di progetto e lavoro di supporto, nessuno escluso. I progetti interferiscono con il supporto e il supporto interferisce con i progetti. I progetti dipendono da stime e progressi della pietra miliare, il supporto è imprevedibile e può implicare un'urgenza improvvisa. I progetti sono basati su pianificazione, il supporto è basato sull'interruzione. Non una combinazione felice e molto frustrante per gli sviluppatori.
• Non tutti sono bravi a supportare . Qualcuno che ha meno esperienza con l'app o il business o qualcuno la cui personalità o capacità di comunicazione è tale da essere meglio protetto dall'accesso dell'utente potrebbe non funzionare bene in supporto.
• Uso inefficiente delle risorse . Frank Shearar ha osservato nei commenti che uno sviluppatore che fa un supporto banale può essere più costoso di un tecnico di supporto di livello uno.

Nella mia esperienza, alla maggior parte degli sviluppatori non piace il supporto. Avendo prestato servizio sia per il progetto che per il supporto, posso simpatizzare. Quando si devono fare entrambe le cose contemporaneamente, il fattore attenuante è spesso straordinario, solitamente non retribuito, per far fronte alle emergenze di supporto e comunque rispettare le scadenze del progetto. I project manager amano gli straordinari non pagati perché vuol dire fare le date senza spendere di più, ma per gli sviluppatori è solo una grande scossa.

Tuttavia, credo anche che se gli sviluppatori avessero fatto un lavoro migliore creando sistemi affidabili e intuitivi, avresti avuto meno supporto. Quindi questo crea uno strano argomento circolare per mescolare i due. Quello che penso che dovresti fare se devi fare entrambe le cose è trovare modi per evitare di renderlo simultaneo.

Penso che gli sviluppatori indossino già due cappelli. Il supporto è più simile a un filtro utilizzato per proteggere lo sviluppo da problemi banali come il non aver collegato il computer. Tuttavia, dovrebbe esserci un accoppiamento stretto tra sviluppo e supporto. Alcuni clienti hanno problemi legittimi che potrebbero essere il risultato di un bug. Dovrebbe essere responsabilità dello sviluppo aiutare a risolvere questi problemi il prima possibile. Quindi in un certo senso gli sviluppatori fanno già parte del team di supporto ... chiamalo supporto per il livello 2.

Emphatically, no.
Sappiamo tutti quanto può essere difficile dover interrompere ciò che stai facendo per ask rispondere a una domanda. Rispondo ai telefoni per un help desk e scrivo alcune applicazioni di utilità.

Non riesco a concentrarmi sulla risoluzione di un problema perché ogni 5 minuti devo prendere il telefono. Né il lavoro viene svolto quanto può essere perché sto costantemente pensando a cosa posso fare per risolvere un problema, e non lavoro mai sulla programmazione abbastanza a lungo da implementare completamente qualsiasi soluzione che potrei avere.

Ancora una volta, non potrei sottolineare abbastanza quanto sia importante essere in grado di concentrarsi su un aspetto o l'altro.

Non metterei mai uno sviluppatore come supporto per la prima linea. Il numero di interruzioni e l'importo che dovrai ripetere te guideranno la maggior parte degli sviluppatori a gridare RTFM e riagganciare alla prossima persona che chiama. Questo non è qualcosa di cui i tuoi clienti hanno bisogno, né questo è qualcosa che vuoi che i tuoi sviluppatori debbano sopportare.

Esiste una certa regola in qualsiasi posizione di servizio al cliente. Per un chiamante irato, la prima persona che risponde al telefono è sbagliata. Non importa se hanno il presidente della società, la persona che ha sviluppato l'app o il responsabile dell'assistenza. Una volta che il cliente ottiene la seconda persona, che può o non può sapere quello che sta facendo, il cliente sarà in grado di calmarsi e spiegare il problema in modo più chiaro.

Questo non è un ambiente che vuoi mantenere buoni sviluppatori. Vale la pena avere uno sviluppatore che interagisce con un cliente su un problema particolarmente difficile che va oltre "perché il mio portabicchieri non funziona più"? Assolutamente. Ma questo è dopo che la richiesta di supporto è stata verificata attraverso le linee di supporto di primo e secondo livello.

Dipende dalla compagnia.

Il mio lavoro è esattamente come questo . Sono uno sviluppatore di software, ma dal momento che siamo un'azienda abbastanza piccola, ogni sviluppatore assume un ruolo di supporto "non ufficiale" solitamente basato sul proprio software. Alcuni sviluppatori devono fare più supporto di altri, a seconda di un numero di fattori come quanti prodotti hanno sviluppato / spedito, quanto sono buggy i loro prodotti e quanto sono efficaci a supporto . Se riesci a fornire al cliente esattamente ciò di cui hanno bisogno per risolvere il problema, continueranno a tornare da te per risolvere i problemi il più rapidamente possibile. Spada a doppio taglio? Sì. Si soffre di una ridotta produttività, ma il cliente è felice e più probabile che rimanga un cliente. Questo è importante per le aziende più piccole.

Abbiamo un team di supporto ai sistemi, ma a causa della natura di ciò che facciamo, per lo più devono affrontare problemi relativi all'hardware. Personalmente, in un'azienda più piccola, questo problema non è così dirompente come si potrebbe immaginare. Certo, ricevi chiamate mentre stai cercando di elaborare alcune funzioni importanti, ma allo stesso tempo, il servizio clienti è molto migliorato; possono avere una voce autorevole che sa (in molti casi) come risolvere il loro problema invece di qualcuno con informazioni di seconda mano e uno script di supporto. Se non riesci a risolvere il problema in quel preciso momento, puoi rassicurarli personalmente che implementerai una soluzione per il loro bug, o prendere in considerazione la richiesta di funzionalità per una versione futura. Puoi ottenere un feedback reale direttamente dagli utenti del tuo software, in modo che la tua prossima versione possa essere persino migliore di quanto tu pensi che sia.

Mi piace pensare che i clienti felici creino un'immagine più positiva della tua azienda, che di solito porta a più clienti . Ed è per questo che, in qualità di ingegnere del software, mi piace il supporto tecnico.

Non c'è niente di più frustrante del supporto tecnico informatico che non è disposto a metterti in contatto con qualcuno che capisce veramente cosa sta succedendo. Mi auguro che qualsiasi azienda applicatrice di grandi dimensioni abbia alcuni programmatori che potrebbero avvalersi del supporto tecnico.

Gli sviluppatori dovrebbero essere l'ultima linea di supporto.

Solo quando l'helpdesk e il nostro reparto di QA non possono aiutare un cliente, saremo infastiditi. E anche in questo caso deve passare attraverso il nostro sistema di tracciamento dei bug prioritario.

Se è davvero un grosso problema, lo sentiremo.

Lo farei solo se si tratta di un nuovo sviluppatore o di uno che non ha familiarità con il dominio e la base clienti. Rendendolo una cosa permanente non è una buona idea.

Il mio ultimo lavoro era esattamente questo. Abbiamo supportato i sistemi esistenti e ne abbiamo scritti di nuovi, se necessario. E 'stato un disastro totale. Sarei costantemente interrotto. Il mio morale era così basso perché i progetti avviati avrebbero richiesto un'eternità. Inoltre, abbiamo dovuto portare in giro un cercapersone per il supporto fuori orario senza paga extra (questo era nel campo dell'assistenza sanitaria). Penso che la soluzione (che ho suggerito al mio manager in quel momento), sarebbe stata quella di avere una prima linea di supporto tecnico, e se si tratta di un bug del software, inoltrarlo agli sviluppatori. Inutile dire che sono durato solo un anno e mezzo finché non sono partito per un migliore lavoro di sviluppo!

Alcune volte, sicuramente si. Affrontare il cliente dà spesso una prospettiva che manca alla maggior parte delle persone, specialmente ai programmatori. In che modo l'utente effettivamente utilizza il prodotto, o in realtà pensa che sia spesso molto lontano da come il costruttore (l'ingegnere) pensa di fare.

Dovrebbe essere per brevi periodi periodici, in modo da non interrompere l'effettivo compito di sviluppo.

Ci sono talenti e competenze di cui hai bisogno per sviluppare software, e talenti e competenze che ti servono per essere efficaci nel supporto di prima linea. Non so che questi talenti abbiano alcuna correlazione.

Ciò significa che devi assumere degli sviluppatori basandoti in parte sulla loro capacità di fare supporto telefonico o lasciare che i tuoi clienti parlino direttamente con persone che non sono brave a gestire i clienti e non vogliono farlo nel primo posto. Questo può o non può essere meglio che farli parlare con un ragazzo con un strong accento indiano che legge da un copione educato.

Inoltre, quando rendi il lavoro spiacevole (e non conosco nessuno sviluppatore che apprezzi realmente il supporto di prima linea), alcuni dei tuoi sviluppatori se ne andranno. Questi sono generalmente quelli che possono ottenere altri lavori più facilmente: vale a dire quelli buoni. Mentre questo processo continua, si finisce con un negozio pieno di persone meno talentuose, che rende ancora meno piacevole per il competente superare la prima offerta di lavoro di qualcun altro.

Per quanto riguarda lo sviluppo serio fatto, dimenticalo se ci sono frequenti interruzioni. Mia moglie si è lamentata molto per l'aspettativa di fare sviluppo e supportare gli utenti contemporaneamente.

Penso che molto dipenda dalla compagnia. La tua tipica azienda BigCo di solito può permettersi di avere persone di supporto per isolare gli sviluppatori. D'altra parte, un avvio con tre persone totale potrebbe non avere le risorse per fornire persone di supporto separate.

Penso che la migliore strategia generale (senza riguardo alle dimensioni o alle risorse dell'azienda) sia quella di utilizzare i team di supporto per risolvere il problema della frutta bassa e dei problemi più comuni ("Hai provato a spegnerlo e riaccenderlo?"). Gli ingegneri dovrebbero collaborare con i clienti sui problemi più complessi che richiedono la conoscenza del modo in cui il sistema funziona insieme a un maggiore supporto orientato agli sviluppatori (API, strumenti di sviluppo, ecc.). Potresti fare in modo che la persona di supporto agisca come un "liason", ma trovo che di solito è più un problema che ne vale la pena.

Anche se non penso sia appropriato usare gli sviluppatori come supporto tutti il tempo, penso che ci sia qualcosa da dire per fare in modo che uno sviluppatore faccia il supporto iniziale di un'applicazione. Questo dovrebbe includere specificamente il supporto after hours. Penso anche che possa essere utile averli regolarmente in programma per il supporto post-vendita delle loro app su base regolare.

Non c'è niente come più chiamate 3AM per farti capire quale effetto hanno determinate decisioni di progettazione e / o scorciatoie sulla capacità delle persone di supportare e mantenere il tuo codice.

Idealmente no per le ragioni sopra esposte, ma sì mentre il progetto è nascente, perché gli sviluppatori possono fornire risoluzioni rapide, spesso attese dal mondo degli affari, che supportano il miglioramento continuo del software. Apprezzo gli sviluppatori che forniscono il supporto in modo intelligente: quelli che prestano le loro capacità analitiche ad esempio a un team di supporto a tempo pieno più formale e quelli che rispondono al business in modo tale da mostrare uno spirito di servizio e cooperazione. Le chiavi di questo successo includono però il management che riconosce e formalizza il supporto di primo e secondo livello per scaricare rapidamente gli sviluppatori da quello che dovrebbe essere il loro ruolo a breve termine. Gli sviluppatori che mostrano un talento sia per lo sviluppo che per il supporto dovrebbero essere coltivati come supporto di terzo livello o supporto per gli addetti all'assistenza. Quindi dovrebbe dipende dal tempo, dal talento e dal desiderio e gestito in modo efficace.

Il mio interesse è stato quello di rispondere alle domande di supporto difficili e di prendere ciò che ho imparato dall'esperienza per ridurre la necessità di supporto in generale, il che avvantaggia gli utenti finali e il supporto primario allo stesso modo.

Sono entrato in questa trappola quando sono entrato in un'azienda con una buona paga. Durante l'intervista mi è stato detto che ci sarà il 70% di sviluppo e il 30% di supporto e ho accettato l'offerta. Può essere che sia la società o l'ambiente a cui sto lavorando attualmente. Ma in realtà il 90% di supporto e il 10% di sviluppo. Sono passati un paio d'anni da quando ho perso la presa dello sviluppo. Mi dispiace di aver accettato questa offerta.

Ma mi sento come se avessi perso il controllo della codifica di più di molte nuove tecnologie e strutture. Ora non so da dove cominciare di nuovo. Continuo a preparare ma questi esempi di helloworld non sono sufficienti per avere una buona esperienza pratica ed è davvero difficile aggiornare le mie conoscenze ed esperienze. Non posso nemmeno lasciare il mio lavoro per ricominciare a causa di impegni familiari.

Purtroppo sono in una situazione di stallo.

Per favore non accettare ruoli se non ti piacciono o non ti interessano.

Contro: supponendo che tu debba trattare direttamente con i clienti.

1) Viziare i tuoi clienti

Se si tratta di supporto di prima / seconda / terza linea (intendo davvero supporto di linee sfocate) in cui gli sviluppatori trattano direttamente con i clienti, allora è un grosso problema. Gli sviluppatori hanno le competenze necessarie per risolvere i problemi o sviluppare soluzioni per risolvere i problemi. Se i clienti hanno accesso completo agli sviluppatori (linea sfocata), non c'è modo di impedire ai clienti di "abusare" di questo privilegio - con conseguente clienti viziati, esigenti e privilegiati che pagano solo più di qualsiasi altro cliente.

2) Condizionare gli sviluppatori a mentire e inventare storie.

Chiunque abbia avuto a che fare con i clienti sa che è un pre-requisito essere in grado di mentire a loro. C'è un bug con una correzione a 1 linea che può essere eseguita in 5 minuti. Un addetto all'assistenza clienti sarebbe stato addestrato a gestire le aspettative del cliente - ci sarebbero voluti fino a 3 giorni per risolverlo.

Come sviluppatore, se devi trattare direttamente con i clienti, devi pensare a modi creativi per placare o ingannare i clienti quando il tuo compito principale dovrebbe essere quello di risolvere problemi tecnici e assicurarti che il sistema funzioni senza intoppi.

3) Il tuo Curriculum Vitae soffre.

A meno che non stiate passando da Ingegnere software a Analista aziendale / Consulente IT / Gestione progetti, il vostro CV risentirà di un aspetto tecnico.

Il lavoro di supporto a pagamento che ruota tra la squadra è una storia diversa.

Professionisti

1) Stop Whiners from Whining

Gli sviluppatori che fanno ciò che odiano gli faranno apprezzare la codifica molto di più. Hai un programmatore che è costantemente piagnucoloso? Mettili sulla hotline per un mese.

Sì, perché lo fanno. Ho capito quando ho letto questa domanda? Ero come se questa fosse una domanda (non che mi stia interrogando sul tuo diritto di porre la domanda OP), ma è piuttosto retorica perché quasi ogni Dev che abbia mai incontrato ha avuto un qualche tipo di supporto tecnico implicito nel suo o la sua funzione lavorativa. Semplicemente non puoi evitarlo. Nella maggior parte dei casi è la persona più tecnicamente compatibile non solo nel dominio funzionale, ma in termini di IT in generale. È molto difficile evitare completamente.