The Written Roles of Software Development Manager [chiuso]

Sappiamo tutti cosa fa un manager di sviluppo software, ma temo di conoscerlo 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?

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

• Mantieni il team di sviluppo sulla buona strada (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 lo stress risultante (le persone sono più è probabile che accetti 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.

• Assicurarsi che il team stia comunicando con il cliente l' importo corretto . 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 , ovvero assicurarsi che le cose che dovrebbero essere addebitate e che siano state addebitate e che non stiamo cercando di pagare per le cose che dovrebbero essere coperte dal supporto.

• Sii la voce del team nel business e nel business all'interno del team : aiuta tutti a capire la posizione dell'altro e aiuta 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 processi e strumenti 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 processo per amor di processo, ma ci sono cose che devono accadere e il processo è il modo migliore per raggiungerlo in modo coerente.

• Garantire che ogni membro del team stia lavorando ad almeno 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 l' amministrazione e tutto ciò 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.