Come "vendere" il supporto come opzione di carriera [chiuso]

Non

Per me l'opzione migliore qui non è quella di separare gli sviluppatori in supporto e non-supporto in primo luogo. IMHO ci sono tre ragioni principali:

• le persone che scrivono cose che sono difficili da supportare non imparano finché non devono supportare queste cose.
• le persone che fanno solo supporto di solito intraprendono il percorso di minor resistenza nel correggere un errore anche se ostacolano il lavoro futuro.
• i risparmi di tempo teorici per rimanere in linea con il nuovo sviluppo avendo gli sviluppatori di supporto separati è sempre più che consumato dal dover fornire istruzioni o ripetere il lavoro.

All'interno del team di sviluppo è possibile avere persone che hanno compiti di manutenzione o adottare un approccio per lasciare che le attività di manutenzione siano il terreno di allenamento per i nuovi membri del team, ma se si tenta di venderlo come obiettivo a lungo termine della posizione attirerà solo persone che ti daranno bruciore di stomaco o persone che presto andranno via.

C'è sempre bisogno di essere un percorso chiaro per uscire da un ruolo di supporto al 100% e / o una certa percentuale di nuovo lavoro di sviluppo per mantenere le persone interessate interessate.

Non vuoi attrarre il tipo di persone che sono felici in quel ruolo indefinitamente e non convincerai mai gli altri sviluppatori a prendere quel ruolo e mantenerlo a lungo termine a meno che tu non stia offrendo quel tipo di paga che non sarebbe mai invitali a considerare una mossa di carriera.

Make the support job fun and valuable to your developers.

Mi piace fare supporto per i seguenti motivi:

• Parlo con persone di tutto il mondo. Ho fatto molti amici in questo modo. Pochi anni fa, uno dei miei clienti mi ha invitato al suo matrimonio! Avevo una mappa del mondo nel mio ufficio con spilli che li localizzavano.
• Il supporto è quasi il migliore ottenere gratificazioni per il tuo lavoro. Quando rendi felici gli utenti, ti rende davvero più felice.
• I reclami sono utili come migliorare te stesso. Prendo qualsiasi lamentela seriamente e, nella maggior parte dei casi, posso convertire qualcuno arrabbiato in un cliente / utente felice che alla fine spargerà la voce.
• Mi aiuta a capire di cosa hanno bisogno i clienti / utenti. Quindi posso creare un software migliore.

Questo è solo un paio di motivi.

Per quanto riguarda il supporto stesso, suggerisco di implementare un processo facile da gestire.

Quando riceviamo un caso di supporto, facciamo quanto segue:

• Se si tratta di un bug riproducibile, lo aggiungiamo nel backlog e ne forniamo l'ID al cliente / utente. Prendiamo anche l'ID del cliente / utente per informarlo di risoluzioni e rilasciare personnaly. Questo è facile se raccogli la sua email direttamente.
• Se si tratta di un problema nell'utilizzo del software, consideriamo questa opportunità come un'opportunità per migliorare la documentazione. Qualsiasi risposta è scritta come un articolo di knowledge base che aggiungiamo successivamente al nostro database. Ci vuole il triplo del tempo per scrivere, ma non lo ripetiamo più tardi (la maggior parte degli utenti preferisce navigare in KB).
• Se si tratta di una richiesta di funzionalità, colleghiamo l'utente direttamente al proprietario del prodotto. Questo è molto prezioso. Naturalmente usiamo sistemi come uservoice.com, ma parlare direttamente con l'utente è molto meglio.
• Se si tratta di un reclamo, cerchiamo di gestirlo al di fuori del processo. Persone a cui lamentarsi sono considerate importanti (anche se il reclamo è banale)

Perché non pagare gli sviluppatori di supporto 5 o 10k in più rispetto alla build e dimenticare gli sviluppatori?

Allegando un premio extra per supportare i ruoli; in riconoscimento delle ulteriori sfide del "customer liasion" e "production code maintenance"; non solo fornirai una motivazione in più, ma soprattutto i ruoli saranno considerati più prestigiosi. Dopotutto uno stipendio più alto deve significare un ruolo più importante e anche se così non fosse, sarà considerato in questo modo.

Se pensi che il supporto sia un lavoro di secondo livello, probabilmente avrai problemi ad assumere persone per questo. Se lo tratti come un lavoro che limita la carriera e non funziona, non otterrai buoni candidati.

Il supporto non è generalmente tanto divertente quanto il nuovo sviluppo, e se hai team di sviluppo e supporto separati, i team di supporto devono prendere ciò che lo sviluppo offre loro, cosa che spesso non è divertente. (Ho lavorato in un luogo in cui R & D ci consegnava un software che faceva qualcosa di interessante, ma che in genere richiedeva la riprogettazione della qualità di produzione, e non abbiamo avuto abbastanza tempo per farlo, per ragioni politiche. divertente.)

Se il supporto è davvero business-critical, devi trattarlo come tale. Se insisti per avere team di supporto separati, ed è importante averne di buoni, devi affrontare questi problemi. Assicurati che ci sia un percorso di carriera. Pubblicizza il denaro che stai facendo da supporto, in parte per la loro autostima, in parte per far sì che le altre persone ne comprendano il valore, in parte in modo da poter mettere le cifre del dollaro per le loro attività sui loro curriculum. Stabilire standard e consentire ai team di supporto di fornire indicazioni sul fatto che un progetto sia pronto per passare dallo sviluppo al supporto. Dal momento che il lavoro è meno divertente e forse più importante, pagalo meglio. (Avrei più simpatia per i manager che si lamentano "non possiamo ottenere i candidati di cui abbiamo bisogno" se di solito non si traducono in "non possiamo i richiedenti di cui abbiamo bisogno a buon mercato".)

Alcuni pensieri:

1) Dici che è visto come un vicolo cieco e una carriera che limita. Se questo non è vero e la gente è passata ad altre cose (sviluppo, gestione del progetto, gestione del team), sono sicuro che hai degli esempi che puoi usare. Se non hai esempi, dovresti accettare che è un vicolo cieco e una carriera che limita e devi affrontare questi problemi.

2a) Se il supporto include la risoluzione dei bug, perché sono separati? Se qualcuno lo ha codificato male per cominciare, allora cosa stai insegnando loro dando il loro casino a qualcun altro per risolverlo. Inoltre, se gli sviluppatori di supporto non sono considerati validi come gli sviluppatori, come mai puoi aspettarti che risolvono ciò che gli sviluppatori non potrebbero ottenere nel modo giusto? Seriamente la regola dovrebbe essere che l'hai scritta, la aggiusti.

2b) Se il supporto non include il bug fixing allora sono lavori molto diversi e danno risalto a diverse abilità. Non dovresti preoccuparti di attraversare qui più di quanto ti preoccupi di attraversare tra lo sviluppo e la pulizia.

3) Dici che è redditizio per l'azienda, quindi rendilo redditizio per le persone coinvolte. Questo potrebbe essere ottenuto con soldi migliori, un addestramento migliore, un kit migliore e dando loro tutto ciò di cui hanno bisogno per fare queste cose davvero bene. Se ci sono soldi disponibili, fai un ottimo lavoro.

Il problema di leggere il tuo post è che non sembri credere che sia un buon lavoro. Se è vero, non c'è da meravigliarsi se non puoi venderlo come tale.

Il supporto è un lavoro difficile, nessun corpo ama ascoltare le persone che si lamentano tutto il giorno. Trovare persone brave può richiedere tempo, ma una volta che hai bisogno di tenerli con

1. Paga un buon prezzo, anche ben al di sopra dei tassi del settore per mantenere le persone buone
2. Fornire un buon ambiente di lavoro, piccole cose come il pranzo offerto dal lavoro e le bevande aiutano
3. Non stipare tutto il personale di supporto in una stanza piccola e rumorosa

Penso che zappos.com abbia dimostrato che un lavoro non deve essere schifoso quando lavori per una buona compagnia. La parte peggiore di essere in supporto non è essere in grado di aiutare qualcuno. Se hai rovinato gli utenti con il contratto di assistenza stampa fine o il software buggy spedito che non verrà risolto in qualsiasi momento presto, il supporto farà schifo. Devono essere incoraggiati a trovare soluzioni ai problemi; una specie di programmazione simile.

Ho sostenuto per un paio d'anni la mia prima azienda al di fuori del college. Quello che mi ha fatto iscrivere per un paio d'anni è stato:

1. Il percorso di carriera richiesto per diventare un ingegnere del software.
2. Avevo bisogno del tempo per rispolverare il lingua principale della compagnia (Fortran, Circa 1989)
3. Non ero sposato, quindi potrei smettere se Ho trovato che non mi piaceva la compagnia o il lavoro.

Che ne dici di un misto di sviluppo e supporto (ruoli divisi)? Penso che farai ancora fatica ad ottenere un buy-in per questo a causa di ragioni già menzionate (sviluppatori! = Persone che supportano il prodotto). Ma se il tuo prodotto si basa su una vasta conoscenza della tecnologia interna, forse l'80% di sviluppo, il 20% di supporto sarebbe un compromesso equo. Oppure una sorta di guida / ombreggiamento per i nuovi dipendenti per garantire che ricevano informazioni corrette sul prodotto.