I ruoli scritti del responsabile dello sviluppo software [chiuso]

62

Sappiamo tutti che cosa fa un gestore di sviluppo software, ma temo che lo conosciamo solo vagamente . Pensiamo di sapere cosa sta facendo, ma elencare esattamente qual è l'ambito del lavoro è un po 'difficile.

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

    
posta Graviton 16.11.2010 - 07:44
fonte

1 risposta

100

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

  • Mantieni il team di sviluppo sulla giusta strada (e, se possibile, felice) - sposta le cose a modo loro, bloccandole dove possibile, spiega perché non è possibile dove non possono essere spostato per cercare di ridurre lo stress risultante (le persone sono più propense ad accettare le cose se almeno lo comprendono). In definitiva, 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 fornire progetti / prodotti, non come leader sindacale. L'ovvia abilità consiste nel ridurre al minimo la frequenza con cui ciò accade.

  • Assicurati che il team comunichi 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 capiscono completamente (piuttosto che fare solo ipotesi che potrebbero non essere corrette). Gli sviluppatori sono molto grandi nell'assicurarsi che il cliente non li disturbi e, occasionalmente, dimentichino che il cliente potrebbe avere qualcosa di utile da aggiungere.

  • Pianificazione e definizione delle priorità dei progetti 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 corretto prima che venga spedito, ma quello può uscire come un problema noto.

  • Gestisci il lato commerciale dello sviluppo - ovvero assicurandoti che le cose che dovrebbero essere addebitate e addebitate e che non stiamo cercando di addebitare per le cose che dovrebbero essere coperte sotto supporto.

  • Sii la voce del team nel business e nel business all'interno del team - aiuta tutti a comprendere la posizione dell'altro e aiuta a risolvere le differenze laddove si presentano. Questo tende in gran parte a coprire i conflitti culturali tra i bisogni / bisogni delle squadre e le organizzazioni più grandi e le questioni di budget. Questo in realtà è piuttosto schifoso perché 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 . Assicurati che questi processi vengano seguiti e adeguati in base alle esigenze. Parte di questo è fare in modo che il team definisca i processi (ad esempio per cose tecniche che capiscono meglio di me), alcuni li stanno definendo personalmente (per cose che capisco meglio di loro - pianificazione, stima e così via). La parola importante qui è sufficiente: non vuoi processare per il processo, ma ci sono cose che devono accadere e processare è il modo migliore per ottenerlo in modo coerente.

  • Assicurati che ogni membro del team stia lavorando ad almeno un livello ragionevole , e idealmente oltre. Lavora con loro per aiutare a risolvere eventuali problemi che impediscono loro di raggiungere questo livello. Mi piacerebbe dire che il mio ruolo è quello di farli essere il meglio che possono essere, ma mentre questo è vero a un certo livello altre richieste (progetto, budget, tempo) significano che questo sarà quasi sempre compromesso in misura maggiore o minore.

  • Esecuzione di tutte le amministrazione e contenuti richiesti dall'organizzazione (e dalla legge)

Nel complesso è la parte di mentoring, parte di segreteria, parte project management, parte account management e parte PR (per la squadra). Ci sono molte cose che gli sviluppatori non devono pensare o che non pensano di fare, e alcune che si assicurano che facciano le cose che devono fare ma non vogliono farlo.

Ciò di cui non si tratta è il miglior sviluppatore (in genere sei troppo lontano per rimanere aggiornato per molto tempo, quindi devi accettare che la gente ne saprà più di te - l'abilità è sapere dove è più lunga ma obsoleta più rilevante della loro esperienza più breve ma più recente) o di essere una sorta di dittatore. A tale riguardo, il modo migliore per pensarci non è che tu sia più anziano, solo che hai responsabilità diverse. A volte ciò comporterà la chiamata finale a qualcosa (che potrebbe andare contro i punti di vista della squadra), ma più spesso dovrebbe riguardare il consenso o il compromesso.

    
risposta data 16.11.2010 - 11:05
fonte

Leggi altre domande sui tag