it-swarm.it

Gli ingegneri del software dovrebbero anche fungere da supporto tecnico?

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 possibilità di scrivere software se il tempo di un ingegnere fosse occupato dal supporto tecnico.

49
Brian

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

Pro

  • 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 bravi come pensano che possano 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 ce ne siano).
  • n 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).

Cons

  • 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 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.
  • so 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.

74
Bernard Dy

Penso che gli sviluppatori indossino già due cappelli. Il supporto è più simile a un filtro usato 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.

18
Pemdas

Enfaticamente, no.
Sappiamo tutti quanto sia difficile dover interrompere ciò che stai facendo chiedi rispondi ad 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 lavoro mai 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.

18
IAbstract

Non metterei mai uno sviluppatore come supporto di prima linea. Il numero di interruzioni e la quantità 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.

10
Berin Loritsch

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 più supporto di altri, a seconda di una serie di fattori come quanti prodotti hanno sviluppato/spedito, quanto sono corretti i loro prodotti e quanto sono efficaci sono al 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 riduzione della produttività, 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 ottenere 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 creano un'immagine più positiva della tua azienda, che di solito porta a più clienti. Ed è per questo che, come ingegnere del software, mi piace il supporto tecnico.

9
badgerr

Gli sviluppatori dovrebbero essere l'ultima linea di supporto.

Solo quando l'helpdesk e il nostro dipartimento di controllo qualità 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.

3
Carra

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

3
user1842

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. Mentre questo processo procede, 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.

2
David Thornley

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!

2
Bmw

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.

2
talonx

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.

2
JeffO

Anche se non penso sia appropriato usare gli sviluppatori come supporto tutto il tempo, penso che ci sia qualcosa da dire per avere uno sviluppatore che fa il supporto iniziale di un'applicazione. Ciò dovrebbe includere specificamente 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.

1
dietbuddha

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 totale semplicemente 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.). Puoi fare in modo che la persona di supporto funga da "liason", ma trovo che di solito sia più un problema di quanto valga la pena.

1
Jason Baker

Idealmente no per le ragioni sopra esposte, ma sì mentre il progetto sta nascendo, perché gli sviluppatori possono fornire risoluzioni rapide, spesso attese dalle imprese, che offrono supporto al miglioramento continuo 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. Quindi dovrebbe dipende dal tempo, dal talento e dal desiderio e 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.

0
Kit

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.

Non accettare ruoli se non ti piacciono o non ti interessano.

0
Stranger