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

Un ingegnere del software dovrebbe anche fungere da supporto tecnico? Cioè, se un'azienda dovesse consentire ai propri ingegneri di indossare sia l'ingegnere del software che i cappelli di supporto tecnico. Sembra che eliminerebbe la capacità di scrivere software se il tempo di un ingegnere fosse occupato dal supporto tecnico.

Questo è un problema classico nelle aziende che hanno un componente di sviluppo software nel loro lavoro, siano esse società di software o meno. Faccio fatica con questo tutto il tempo.

Avere gli sviluppatori coinvolti nel supporto alla produzione

Professionisti

• Combatte la sindrome dello "sviluppo nel vuoto" . È utile ottenere visibilità su come gli utenti utilizzano l'app. Fino a quando non ho finalmente visto questo come un giovane sviluppatore, non mi rendevo conto di che schifo sviluppatore dell'interfaccia utente ero. Tutto ciò che mi interessava era la codifica e non la progettazione, l'analisi o la prospettiva dell'utente.
• Gli sviluppatori che non sono così bravi come pensano di essere possono essere umiliati (anche se non c'è garanzia che otterrai questo vantaggio; alcuni sviluppatori sono davvero ignari, egoisti e testardi).
• Gli sviluppatori acquisiranno la conoscenza del dominio . Questo è fondamentale se i tuoi sviluppatori alla fine saranno in grado di identificare e colmare le lacune che mancano alla fase di analisi aziendale (supponendo che ci siano).
• Un buon supporto è un punto di marketing. Se lo fai bene, i clienti lo apprezzeranno. E uno sviluppatore a tutto tondo con capacità comunicative 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 assistenza clienti (e anche un punto di marketing).

Contro

• Fattore di interruzione . Questo è l'errore numero uno nel mescolare il lavoro di progetto e il lavoro di supporto, tranne nessuno. I progetti interferiscono con il supporto e il supporto interferisce con i progetti. I progetti dipendono da stime e progressi fondamentali, il supporto è imprevedibile e può comportare un'urgenza improvvisa. I progetti sono basati su pianificazione, il supporto è basato su interruzioni. Non è una combinazione felice e molto frustrante per gli sviluppatori.
• Non tutti sono bravi nel supporto . Qualcuno che ha meno esperienza con l'app o l'azienda, o qualcuno le cui personalità o capacità comunicative sono tali da essere meglio protetti dall'accesso degli utenti potrebbe non funzionare bene nel supporto.
• Uso inefficiente delle risorse . Frank Shearar ha osservato nei commenti che uno sviluppatore che fa un supporto banale può essere più costoso di una tecnologia di supporto di livello uno.

Nella mia esperienza, alla maggior parte degli sviluppatori non piace il supporto. Avendo prestato servizio sia a livello di progetto che di supporto, posso simpatizzare. Quando si devono fare entrambe le cose contemporaneamente, il fattore attenuante è spesso gli straordinari, di solito non retribuiti, per far fronte alle emergenze di supporto e ancora rispettare le scadenze dei progetti. I project manager adorano gli straordinari non retribuiti perché significa fissare appuntamenti senza costare più denaro, ma per gli sviluppatori è solo una grande scodella.

Tuttavia, credo anche che se gli sviluppatori facessero un lavoro migliore creando sistemi affidabili e intuitivi, avresti 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 insignificanti come non avere il computer collegato. Tuttavia, dovrebbe esserci un forte accoppiamento 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 di livello 2.

Enfaticamente, no.
Sappiamo tutti quanto sia difficile può essere quello di smettere di cosa si sta facendo per porre 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 sollevare il telefono. Nessuno dei due lavori viene svolto nel miglior modo possibile perché penso costantemente a cosa posso fare per risolvere un problema e non sto mai lavorando sulla programmazione abbastanza a lungo da implementare completamente qualsiasi soluzione potrei avere.

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

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

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

Questo non è un ambiente in cui desideri mantenere buoni sviluppatori. È utile che uno sviluppatore interagisca con un cliente su un problema particolarmente difficile che va oltre "perché il mio portabicchieri non funziona più"? Assolutamente. Ma è dopo che la richiesta di supporto è stata controllata attraverso le linee di supporto di primo e secondo livello.

Dipende dalla compagnia.

Il mio lavoro è esattamente così . Sono uno sviluppatore di software, ma poiché siamo una società abbastanza piccola, ogni sviluppatore assume un ruolo di supporto "non ufficiale", solitamente basato sul proprio software. Alcuni sviluppatori devono fornire un supporto maggiore rispetto ad altri, a seconda di una serie di fattori come il numero di prodotti che hanno sviluppato / spedito, quanto sono corretti i loro prodotti e quanto sono efficaci nel supporto . Se riesci a fornire al cliente esattamente ciò di cui ha bisogno per risolvere il problema, continuerà a tornare da te per risolvere i problemi il più rapidamente possibile. Spada a doppio taglio? Sì. Soffri di una produttività ridotta, ma il cliente è felice e ha maggiori probabilità di rimanere cliente. Questo è importante per le aziende più piccole.

Abbiamo un team di supporto ai sistemi, ma a causa della natura di ciò che facciamo, devono principalmente 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 funzionalità 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 lì e poi, puoi rassicurarli personalmente che implementerai una correzione per il loro bug o considererai la loro richiesta di funzionalità per una versione futura. Puoi ricevere feedback reali direttamente dagli utenti del tuo software, quindi la tua prossima versione può essere persino migliore di quanto pensi già.

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

Non c'è niente di più frustrante del supporto tecnico informatico che non è disposto a collegarti con qualcuno che capisce davvero cosa sta succedendo. Spero che qualsiasi grande azienda di applicazioni abbia alcuni programmatori che lavorerebbero supporto tecnico.

Gli sviluppatori dovrebbero essere l'ultima linea di supporto.

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

Se è un grosso problema, lo sentiremo.

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

Il mio ultimo lavoro è stato esattamente questo. Abbiamo supportato i sistemi esistenti e ne abbiamo anche scritti di nuovi secondo necessità. È stato un disastro totale. Sarei costantemente interrotto. Il mio morale era così basso perché i progetti avviati avrebbero impiegato un'eternità a finire. Inoltre, abbiamo dovuto portare in giro un cercapersone per assistenza fuori orario senza retribuzione 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 insieme agli sviluppatori. Inutile dire che sono durato solo un anno e mezzo fino a quando finalmente sono partito per un migliore lavoro di sviluppo!

Qualche volta, sicuramente sì. Affrontare il cliente offre spesso una prospettiva che manca alla maggior parte delle persone, specialmente ai programmatori. Il modo in cui l'utente utilizza effettivamente il prodotto o pensa effettivamente è spesso molto distante da come pensa il costruttore (l'ingegnere).

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

Esistono talenti e competenze necessari per sviluppare software e talenti e competenze necessari per essere efficaci sul supporto di prima linea. Non so che questi talenti abbiano alcuna correlazione.

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

Inoltre, quando rendi il lavoro spiacevole (e non conosco sviluppatori che godono effettivamente del 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. Man mano che questo processo continua, finisci con un negozio pieno di persone meno talentuose, rendendo ancora meno piacevole per i competenti rimanere davanti alla prima offerta di lavoro di qualcun altro.

Per quanto riguarda lo sviluppo serio, dimenticalo se ci sono frequenti interruzioni. Mia moglie si è molto lamentata del fatto che ci si aspetta che facciano sviluppo e supporto agli 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, una startup con tre persone in totale potrebbe non avere le risorse per fornire persone di supporto separate.

Penso che la migliore strategia generale (indipendentemente dalle dimensioni o dalle risorse dell'azienda) sia quella di utilizzare i team di supporto per risolvere i problemi di frutta bassa e i problemi più comuni ("Hai provato a spegnerlo e riaccenderlo?"). Gli ingegneri dovrebbero lavorare con i clienti sui problemi più delicati che richiedono la conoscenza di come funziona il sistema insieme a un supporto più orientato agli sviluppatori (API, strumenti di sviluppo, ecc.). Potresti fare in modo che la persona di supporto funga da "liason", ma trovo che di solito sia più un problema che una pena.

Anche se non penso che sia appropriato usare devs come supporto per tutto il tempo, penso che ci sia qualcosa da dire per avere un dev che fa il supporto iniziale di un'applicazione. Ciò dovrebbe includere in particolare il supporto after hour. Penso anche che può essere utile che vengano programmati per il supporto after hour per le 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 sta nascendo, perché gli sviluppatori possono fornire risoluzioni rapide, spesso attese dalle aziende, che offrono supporto al continuo miglioramento del software. Apprezzo gli sviluppatori che forniscono 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 la gestione che riconosce e formalizza il supporto di primo e secondo livello per scaricare rapidamente gli sviluppatori da quello che dovrebbe essere solo il loro ruolo a breve termine. Gli sviluppatori che mostrano un talento per lo sviluppo e il supporto dovrebbero essere coltivati ​​come supporto di terzo livello o supporto per le persone di supporto. Così dovrebbe dipende dal tempo, dipende dal talento e dal desiderio ed è gestito efficacemente.

Il mio interesse è stato quello di rispondere alle difficili domande di supporto e di prendere ciò che ho imparato dall'esperienza per ridurre la necessità di supporto complessivo, a beneficio sia degli utenti finali che del supporto primario.

Sono entrato in questa trappola quando mi sono unito a 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 l'azienda o l'ambiente su cui sto attualmente lavorando. Ma in realtà supporta il 90% e lo sviluppo del 10%. Sono passati un paio d'anni e ho perso la presa dello sviluppo. Mi dispiace di aver accettato questa offerta.

Ma mi sento come se avessi perso la presa del codice più laggiù un sacco di nuove tecnologie e framework. Ora non so da dove ricominciare. Continuo a prepararmi, 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 un punto morto.

Ti preghiamo di non accettare ruoli se non ti piacciono o non ti interessano.

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

1) Rovinare i tuoi clienti

Se si tratta di supporto di prima / seconda / terza linea (intendo davvero il supporto di linea offuscata) in cui gli sviluppatori si occupano direttamente dei clienti, allora è un grosso problema. Gli sviluppatori hanno le competenze richieste per eseguire il debug dei problemi o sviluppare soluzioni per risolverli. Se i clienti hanno accesso completo agli sviluppatori (linea sfocata) - non si può impedire ai clienti di "abusare" di questo privilegio - risultando in clienti viziati, esigenti e privilegiati che non pagano 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 prerequisito poter mentire a loro. Esiste un bug con una correzione a 1 riga che può essere eseguita in 5 minuti. Una persona dell'assistenza clienti sarebbe stata istruita per gestire le aspettative del cliente, che avrebbe richiesto 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 i problemi tecnici e assicurarti che il sistema funzioni senza intoppi.

3) Il tuo curriculum vitae soffre.

A meno che non passi da Ingegnere software a Analista aziendale / Consulente IT / Gestione progetti, il tuo CV subirà un aspetto tecnico.

Il lavoro di supporto a pagamento che ruota all'interno del team è una storia diversa.

Professionisti

1) Smettere di piagnucolare piagnucolando

Gli sviluppatori che fanno ciò che odiano apprezzeranno molto di più la programmazione. Hai un programmatore che piange costantemente? Metterli sulla hotline per un mese.

Sì, perché lo fanno. Ho letto quando ho letto questa domanda? Ero tipo come sia anche una domanda (non che sto mettendo in discussione il tuo diritto di porre la domanda OP), ma è abbastanza retorico perché quasi ogni Dev che abbia mai incontrato ha avuto un qualche tipo di lavoro di supporto tecnico implicito nel suo o la sua funzione lavorativa. Semplicemente non puoi evitarlo. Nella maggior parte dei casi sei la persona tecnicamente più compatta non solo nel tuo dominio funzionale, ma in termini di IT in generale. È molto difficile evitarlo completamente.