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

Troviamo relativamente facile assumere sviluppatori per lavorare su vari progetti.

Il problema sorge quando il progetto è finito ma deve ancora essere supportato.

Combattiamo davvero per convincere le persone a unirsi al team di supporto. È visto come un vicolo cieco, un limite alla carriera, noioso, di seconda classe ecc.

Attualmente, ci aggiriamo facendo in modo che il team del progetto assegni un po 'del loro team al team di supporto per un po'. Parte del compito è fare una "discarica" ​​del progetto in modo che il team di supporto lo capisca. Funziona finché il compito è solo per un periodo fisso.

Cercare di assumere persone per lavorare a tempo pieno nel supporto è un problema. Esistono poche applicazioni e il calibro non è particolarmente elevato.

(La realtà finanziaria è che il supporto può essere molto redditizio per un'azienda e una volta che si ottiene una reputazione, vieni avvicinato da altre aziende a fare il loro supporto anche se non eri coinvolto nello sviluppo originale.)

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 sostenere non imparano fino a quando non devono sostenere queste cose.
• le persone che fanno solo supporto di solito prenderanno la strada della minor resistenza nel correggere un errore anche se ostacola il lavoro futuro.
• i risparmi di tempo teorici nel rimanere nei tempi previsti nel nuovo sviluppo avendo gli sviluppatori di supporto separati sono sempre più che consumati dal dover fornire istruzioni o ripetere il lavoro.

All'interno del team di sviluppo puoi avere persone che hanno attività di manutenzione o adottare un approccio per lasciare che le attività di manutenzione siano i motivi di addestramento per i nuovi membri del team, ma se provi a venderlo come obiettivo a lungo termine della posizione attirerai solo persone che ti daranno bruciore di stomaco o persone che presto saranno in fuga.

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

Non vuoi attirare il tipo di persone che sono felici in quel ruolo a tempo indeterminato e non riuscirai mai a convincere gli altri devoti devoti ad assumere quel ruolo ea mantenerlo a lungo termine a meno che tu non offra il tipo di retribuzione che non li prenderebbe mai in considerazione una mossa di carriera.

Rendi il lavoro di supporto divertente e prezioso per i tuoi sviluppatori.

Mi piace fare supporto per i seguenti motivi:

• Parlo con persone di tutto il mondo. Ho fatto molti amici così. Pochi anni fa, uno dei miei clienti mi ha invitato al suo matrimonio! Avevo una mappa del mondo nel mio ufficio con spille che le localizzavano.
• Il supporto è quasi il migliore per ottenere gratificazioni per il tuo lavoro. Quando rendi felici gli utenti, diventa anche più felice.
• I reclami sono un modo utile per migliorare te stesso. Prendo sul serio qualsiasi reclamo 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 costruire un software migliore.

Questo è solo alcuni dei 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 forniamo il suo ID al cliente / utente. Prendiamo anche l'ID del cliente / utente per informarlo delle risoluzioni e rilasciare personalmente. Questo è facile se raccogli direttamente la sua email.
• Se si tratta di un problema durante l'utilizzo del software, lo cogliamo come un'opportunità per migliorare la documentazione. Ogni risposta è scritta come un articolo della knowledge base che aggiungeremo successivamente nel 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 direttamente l'utente al proprietario del prodotto. Questo è molto prezioso. Ovviamente utilizziamo sistemi come uservoice.com, ma parlare direttamente con l'utente è molto meglio.
• Se si tratta di un reclamo, proviamo a gestirlo al di fuori del processo. Le persone che lamentano amano essere considerate importanti (anche se il reclamo è banale).

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

Allegando un premio extra per supportare i ruoli; in riconoscimento delle ulteriori sfide poste dalla "liasion del cliente" e dal "mantenimento del codice di produzione"; non solo fornirai ulteriore motivazione, ma soprattutto i ruoli saranno considerati di maggior prestigio. Dopotutto uno stipendio più alto deve significare un ruolo più importante e anche se non è così sarà prevenuto in quel modo.

Se pensi che il supporto sia un lavoro di seconda classe, probabilmente avrai difficoltà ad assumere persone per questo. Se lo consideri un lavoro che limita la carriera e un vicolo cieco, non otterrai buoni candidati.

Il supporto non è generalmente considerato 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, che spesso non è divertente. (Una volta ho lavorato in un posto in cui la R&S ci consegnava un software che faceva qualcosa di interessante, ma che in genere aveva bisogno di essere riprogettato per essere di qualità di produzione, e non abbiamo avuto abbastanza tempo per farlo, per motivi politici. divertimento.)

Se il supporto è davvero fondamentale per l'azienda, 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 i soldi che stai guadagnando con il supporto, in parte per la loro autostima, in parte per far capire agli altri il loro valore, in parte in modo che possano mettere cifre in dollari per le loro attività sui loro curriculum. Stabilire standard e consentire ai team di supporto di fornire informazioni sulla possibilità che un progetto sia pronto per passare dallo sviluppo al supporto. Poiché il lavoro è meno divertente e forse più importante, pagali meglio. (Avrei più simpatia con i manager che si lamentano "non possiamo ottenere i candidati di cui abbiamo bisogno" se di solito non si traduce come "non possiamo i candidati di cui abbiamo bisogno a buon mercato".)

Mentre sono d'accordo sul fatto che il supporto in genere fa schifo, molti sviluppatori potrebbero effettivamente godere del prestigio che accompagna la "proprietà" del progetto, anche se non hanno scritto il software da soli. Quel programmatore diventa il goto su quel progetto e diventano davvero un prezioso esperto del sistema. Mentre sono principalmente coinvolto in nuovi sviluppi nell'azienda per cui lavoro, molti dei miei colleghi che sono più che competenti in realtà sono abbastanza rispettati per la manutenzione del nostro software più mission-critical. Dopotutto, il software attualmente supportato è probabilmente quello che sta attualmente facendo soldi (un uccello in mano vale due nella boscaglia).
Direi solo che non tutti vedono il supporto come un terribile lavoro sotterraneo per i programmatori sub-par e giocherò con quel sentimento per attirare più persone.

Alcuni pensieri:

1) Dici che è visto come un vicolo cieco e un limite alla carriera. Se questo non è vero e le persone hanno continuato ad altre cose (sviluppo, gestione del progetto, gestione del team), sono sicuro che hai degli esempi che puoi usare. Se non si hanno esempi, è possibile che si debba accettare che si tratta di un vicolo cieco e di una limitazione della carriera e della necessità di affrontare questi problemi.

2a) Se il supporto include la correzione di bug, perché sono separati? Se qualcuno ha codificato male all'inizio, allora cosa stai insegnando dando il loro pasticcio a qualcun altro per risolvere. Inoltre, se gli sviluppatori di supporto non sono visti quanto gli sviluppatori, come si può aspettare che risolvano ciò che gli sviluppatori non sono riusciti a ottenere? Seriamente la regola dovrebbe essere tu l'hai scritto, lo aggiusti.

2b) Se il supporto non include la correzione di bug, allora sono lavori molto diversi e sottolineano competenze diverse. Non dovresti preoccuparti di attraversare qui più di quanto ti preoccupi di attraversare tra sviluppo e pulizia.

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

Il problema dalla lettura del tuo post è che non sembra credere che sia un buon lavoro. Se questo è vero, non c'è da stupirsi che non puoi venderlo come uno.

Il supporto è un lavoro difficile, a nessun corpo piace ascoltare le persone che si lamentano tutto il giorno. Trovare brave persone può richiedere del tempo, ma una volta che hai, è necessario tenerle

1. Paga buoni soldi, anche molto al di sopra dei tassi del settore per mantenere buone persone
2. Fornire un buon ambiente di lavoro, piccole cose come il lavoro fornito pranzo e 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 scadente quando lavori per una buona compagnia. La parte peggiore di essere in supporto non è in grado di aiutare qualcuno. Se hai rovinato gli utenti con la stampa fine del contratto di assistenza o il software difettoso spedito che non verrà riparato in breve tempo, il supporto farà schifo. Devono essere incoraggiati a trovare soluzioni ai problemi; una specie di programmazione simile.

Ho supportato per un paio d'anni la mia prima compagnia fuori dal 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 di tempo per rispolverare la lingua principale dell'azienda (Fortran, Circa 1989)
3. Non ero sposato, quindi avrei potuto smettere se avessi scoperto che non mi piaceva la compagnia o il lavoro.

Che ne dici di un mix di sviluppo e supporto (ruoli divisi)? Penso che avrai ancora difficoltà a ottenere il buy-in per questo a causa dei motivi già menzionati (sviluppatori! = Persone di supporto al prodotto). Ma se il tuo prodotto si basa su un'ampia conoscenza della tecnologia interna, forse sull'80% di sviluppo, il 20% di supporto sarebbe un giusto compromesso. O qualche tipo di mentoring / shadowing per i nuovi dipendenti per assicurarsi che ottengano informazioni corrette sul prodotto.