it-swarm.it

I ruoli scritti del responsabile dello sviluppo software

Sappiamo tutti cosa fa un manager di sviluppo software, ma temo di saperlo solo vagamente. Pensiamo di sapere cosa sta facendo, ma elencare esattamente qual è lo scopo del lavoro è un po 'difficile.

Secondo te, quali sono i ruoli di un responsabile dello sviluppo software?

62
Graviton

Parlando come qualcuno nel lavoro (che è stato anche uno sviluppatore), le cose chiave che devo fare sono:

  • Mantieni il team di sviluppo in pista (e felice dove possibile) - sposta le cose dalla loro strada che le impediscono di lavorare dove possibile, spiega perché non è possibile dove non possono essere spostate per cercare di ridurre qualsiasi stress risultante (le persone hanno maggiori probabilità di accettare le cose se almeno le comprendono). Alla fine se c'è un conflitto tra il progetto e il team che non può essere risolto, normalmente il progetto vincerà. Questo non ti rende necessariamente popolare con il team, ma sei pagato per consegnare progetti/prodotti, non come leader sindacale. L'ovvia abilità sta nel minimizzare la frequenza con cui ciò accade.

  • Assicurati che il team stia comunicando con il cliente l'importo giusto . Questo tende ad essere parti uguali mantenendo il cliente lontano dal team e assicurandosi che il team stia chiedendo al cliente cose che non comprendono completamente (piuttosto che fare semplicemente ipotesi che potrebbero essere errate). Gli sviluppatori sono molto entusiasti di assicurarsi che il cliente non li disturbi e occasionalmente dimenticano che il cliente potrebbe avere qualcosa di utile da aggiungere.

  • Pianificazione del progetto e definizione delle priorità di conflitti di risorse, richieste dei clienti, problemi di supporto e simili. Tendo ad essere la persona che dice che questo cliente ha la priorità su quello, o che questo bug deve essere risolto prima che venga spedito, ma che si possa risolvere come un problema noto.

  • Gestire il lato commerciale dello sviluppo - che si sta assicurando che le cose che dovrebbero essere addebitate e che vengano addebitate e che non stiamo cercando di addebitare per le cose che dovrebbero essere coperte da supporto.

  • Sii la voce del team nel business e il business all'interno del team - aiuta tutti a capire la posizione dell'altro e aiutano a risolvere le differenze in cui si presentano. Ciò tende in gran parte a coprire i conflitti culturali tra i bisogni/i desideri delle squadre e le organizzazioni più grandi e le questioni di bilancio. Questo è in realtà piuttosto merdoso in quanto significa che quando ci sono disaccordi sei il nemico di tutti.

  • Collaborare con il team per garantire che siano disponibili strumenti e processi sufficienti per soddisfare i requisiti dell'azienda e dei clienti. Assicurarsi che questi processi vengano seguiti e adeguati secondo necessità. Alcuni di questi si stanno assicurando che il team definisca i processi (ad esempio per cose tecniche che capiscono meglio di me), altri li definiscono io stesso (per cose che capisco meglio di loro - pianificazione, stima e così via). La Parola importante qui è sufficiente: non vuoi un processo per il processo, ma ci sono cose che devono accadere e il processo è il modo migliore per raggiungerlo in modo coerente.

  • Assicurati che ogni membro del team lavori almeno a un livello ragionevole e idealmente oltre. Collabora con loro per aiutare a risolvere eventuali problemi che impediscono loro di raggiungere questo livello. Mi piacerebbe dire che il mio ruolo li sta facendo diventare i migliori che possono essere, ma mentre ciò è vero fino a un certo punto altre richieste (progetto, budget, tempo) significano che questo sarà quasi sempre compromesso in misura maggiore o minore.

  • Fare tutto il amministrazione e cose che l'organizzazione (e la legge) richiedono

Complessivamente è in parte tutoraggio, in parte segreteria, in parte project management, in parte gestione account e in parte PR (per il team). Ci sono molte cose che gli sviluppatori non devono pensare o che non pensano di fare, e alcuni si assicurano che facciano le cose che devono fare ma che non vogliono fare.

Quello di cui non si tratta è essere il miglior sviluppatore (in genere sei troppo mani per rimanere aggiornato a lungo, quindi devi accettare che le persone conosceranno più di te - l'abilità è sapere dove la tua esperienza più lunga ma obsoleta è più pertinente di la loro esperienza più breve ma più recente) o essere una sorta di dittatore. Sotto questo aspetto, il modo migliore per pensarci non è che sei più senior, ma solo che hai responsabilità diverse. A volte ciò comporterà la chiamata finale a qualcosa (che potrebbe andare contro le opinioni della squadra) ma più spesso dovrebbe riguardare il consenso o il compromesso.

100
Jon Hopkins