In che modo un manager non tecnico aggiunge valore al team di sviluppatori di software automotivati?


63

Vedo molti programmatori allontanarsi dai ruoli di gestione e amministrazione. Vogliono costruire cose. Di conseguenza, molte di queste posizioni sono occupate da persone non tecniche. Non riesco a vedere come aggiungono valore. Pianificare riunioni, prenotare fuori sede e altri lavori amministrativi è sufficiente per giustificare il loro ruolo?


10
Quale percentuale di tutti i team di software pensi possa operare in questo modo senza che gli ego e gli ordini del giorno si frappongano?
ozz,

30
Dal Tao della Programmazione : Un novizio ha chiesto: "Nell'est c'è una grande struttura ad albero che gli uomini chiamano 'Corporate Headquarters'. È gonfio fuori forma con vice presidenti e ragionieri. Emette una moltitudine di memo ... Come può essere un'entità così innaturale? " / Il maestro rispose: "Tu percepisci questa immensa struttura e sei turbato dal fatto che non ha uno scopo razionale ... Non ti piace la facilità senza problemi della programmazione sotto i suoi rami di protezione? Perché sei disturbato dalla sua inutilità?"
apsillers,


2
La scrittura piuttosto recente di Rands ruota attorno ad alcuni di questi problemi; Gli do un sigillo di raccomandazione. (Per non parlare del fatto che ha anche molti altri grandi scritti sulla gestione!)
Jari Keinänen,

Risposte:


112

Non riesco a vedere come attualmente aggiungono valore e la pianificazione delle riunioni, la prenotazione di siti esterni e altre attività amministrative funzionano abbastanza per il loro ruolo?

Non sottovalutare la quantità di interazione che il tuo manager fa con altri dipartimenti. Gestiscono budget, piani di formazione, scartoffie per le risorse umane. Proteggono gli sviluppatori dall'essere risucchiati nelle riunioni con altri dipartimenti e forniscono un fronte unificato per il tuo gruppo.

In breve, il loro compito è proteggere gli sviluppatori auto-motivati ​​da tutte le altre cose demotivanti che esistono nel mondo degli affari.


4
E faranno un lavoro molto migliore difendendo un salario / aumento.
JeffO,

20
Molto +1. Occasionalmente riceviamo "perdite" attraverso il sistema e una piccola idea di ciò che passano i nostri manager e in particolare il nostro Product Owner. Io non voglio fare con questo tutti i giorni.
Izkata,

1
So che sono importanti, ma non ottengo la relativa importanza nel team di sviluppo software e il valore per questi.
Senthil Kumaran,

17
@SenthilKumaran Come sviluppatore, preferiresti trascorrere due ore con un manager di un altro dipartimento per discutere del perché il software non è completo o preferiresti passare quelle due ore a scrivere codice? Sai quanto sia difficile spiegare i problemi tecnici al tuo manager. Immagina di provare a spiegarlo a qualcuno che conosce anche meno del tuo manager non tecnico. I migliori gestori non tecnici impediscono ai loro sviluppatori di tutte le cose che perderebbero il tempo degli sviluppatori che è meglio spendere codifica e test.
David Navarre,

5
Questo ancora e ancora. Anche per un responsabile tecnico, questa è ancora la parte più importante del loro lavoro.
Earlz,

36

I migliori manager sono maghi. Fanno scomparire il resto dell'azienda per i loro sviluppatori. Non riesco a ricordare la citazione esatta di Joel, ma è stato qualcosa per il fatto che il compito del management è assicurarsi che ci sia una grossa pipa Internet, una bestia di una macchina e molta caffeina, quindi tutti gli sviluppatori devono preoccuparsi è ciò che fanno meglio.

Un buon manager è la voce del tuo gruppo per il resto dell'azienda.



29

Dato che si applica specificamente allo sviluppo del software, ci sono due tipi di ruoli a valore aggiunto per i manager: project management e team leader.

Un project manager si interfaccia con i clienti e il middle management, risparmiando tempo per gli sviluppatori. Spesso ci sono chiarimenti o cambiamenti di ambito che emergono nei progetti ed è utile per i clienti e il middle manager avere un unico punto di contatto. Cercare di rispondere alle domande di ogni membro di un team di sviluppo porta a decisioni di progetto non registrate e impegni privi di documenti, la rovina della gestione dell'ambito.

Dall'altro lato, un team leader è coinvolto nello sviluppo della carriera / delle competenze, assicurando che il carico di lavoro sia adeguatamente distribuito tra i membri del team e fornendo risorse e premi commisurati ai singoli contributi e bisogni.

Nessuno di questi ruoli richiede un programmatore a testa in giù, in realtà al contrario. Un programmatore spesso passa a un'attività di scrittura del codice come prima risposta a una domanda o crisi, ed è utile avere qualcuno il cui compito è chiedere se tale attività deve davvero essere eseguita.


6
Gli sviluppatori vedono alberi. I loro manager vedono la foresta.
David Navarre,

9
@DavidNavarre - I manager non tecnici dell'IMO hanno difficoltà a vedere qualcosa ...
Vector

13
@Vettore: ciò a cui ti riferisci non sono manager non tecnici, ma manager incompetenti.
Lie Ryan,

@Vettore: mi viene in mente il PHB di Dilbert , ma non penso che sia lo stesso di un manager non tecnico.
Hardmath,

@hardmath - Capisco :-) La tua risposta è davvero inclusa in ciò che l'OP ha concesso, come da modifica. Il punto che sto cercando di sottolineare è che per quanto riguarda le cose tecniche, devono buttarsi fuori. Ho una certa esperienza amara in queste faccende ... "Un po 'di conoscenza è una cosa pericolosa" - Sono sicuro che avrai la mia deriva. Vedi la mia risposta
Vettore

12

Insieme agli altri benefici citati, il responsabile non tecnico può svolgere un lavoro migliore nel prendere decisioni definitive in caso di impasse tra gli esperti. So che sembra controintuitivo, ma i bravi manager non tecnici comprendono i punti di forza e di debolezza della loro gente.

Esempio: due programmatori discutono su quale server utilizzare per un'applicazione. In una sorta di democrazia fittizia, entrambi ottengono il loro unico voto, quindi non viene presa alcuna decisione. Questa guerra potrebbe continuare all'infinito (e con alcune persone tecniche lo farà). Qualcuno deve intervenire e arbitrare questo disaccordo e portare avanti il ​​progetto. Un buon giudice si appoggerà all'opinione di quello con la maggiore competenza in questo settore.

Solo perché a qualcuno manca il talento, l'abilità o la conoscenza in un'area non significa che non possano identificare quelli che lo fanno. Riconoscere il talento è un talento.


1
Inoltre, è disponibile un manager non tecnico per rispondere alle esigenze del team anziché scrivere codice.
JeffO,

1
"Insieme agli altri benefici citati, il responsabile non tecnico può fare un lavoro migliore nel prendere decisioni definitive quando c'è un punto morto tra gli esperti." I non esperti hanno il minor numero di informazioni su un argomento specifico. Può solo "schierarsi" con uno con la maggiore competenza in questo settore (o scegliere una soluzione che ritiene migliore). Ma ciò non significa che la sua decisione sia giusta. La soluzione di un programmatore meno esperto può essere migliore ma il non esperto non può saperlo. joelonsoftware.com/items/2006/08/08.html
Christian P

In una situazione del genere, una parte della gestione spesso sottovalutata non sempre consente alle persone migliori di farsi strada. Un buon manager leggerà bene la situazione ed emetterà un giudizio che potrebbe non essere tecnicamente corretto, ma politicamente corretto. Se l'argomento non riguarda qualcosa di importante, il manager può preferire la persona che ha bisogno di più incoraggiamento o viene vittima di bullismo da parte degli altri sviluppatori. È una decisione di giudizio e talvolta difficile, ma è per questo che vengono pagati i soldi.
Stephen,

@Stephen concordato: un buon manager saprà come gestire la sua gente (ad esempio, come hai detto incoraggiando le persone, ecc.) Ma se stiamo parlando strettamente di prendere (importanti) decisioni tecniche, il manager ha la minima quantità di informazioni sul problema ed è probabilmente persona sbagliata per prendere quella decisione.
Christian P

@Stephen: ma sarà politicamente corretto - questo è spesso un ottimo modo per un manager non tecnico di perdere tutta la credibilità con il personale tecnico. IMO molto rischioso.
Vettore

2

Pianificare riunioni, prenotare fuori sede e altro lavoro amministrativo è sufficiente per il loro ruolo?

Sì. Perfettamente sufficiente. Sono anche utili per chiamare la gestione degli edifici in caso di problemi con riscaldamento, aria condizionata, ecc .; assicurarsi che distributori automatici e refrigeratori d'acqua siano ben forniti e mantenuti; portando prelibatezze speciali per noshing; mantenere pulito e ordinato l'ufficio ...

Fai del tuo meglio per pensare ad altri compiti del genere al fine di tenerli occupati e fuori dai guai ...

Il loro ruolo più importante? Stare lontano e non mescolarsi con i programmatori e assicurarsi che altre persone non tecniche facciano lo stesso.

Considera un team di sviluppo come un club di pallacanestro MLB (l'analogia è piuttosto buona IMO): i gestori sono sempre ex giocatori - solo loro sanno come gestire le "mani sulla gestione" di un team di professionisti altamente qualificati, nerd, idiosincratici, chi fa cose che la maggior parte delle "persone normali" non possono.


Hai anche molti manager negli sport che non erano ex giocatori o ex giocatori molto bravi: Arsene Wenger, Jose Mourinho, Andre Villas-Boas? che si rivelano ottimi gestori. Hai bisogno di forti capacità interpersonali e organizzative per essere un buon PM che NON codifica.
bobo2000,

@ bobo2000 - Ho citato MLB , non lo sport in generale.
Vettore,

-1

Nella mia esperienza, i manager non tecnici sono i più adatti a questo ruolo, oltre ad aggiungere valore evitando che le cose dell'azienda interferiscano con il lavoro degli sviluppatori, fomentano la collaborazione tra sviluppatori (perché è risaputo che gli sviluppatori sono introversi http://www.unwesen.de/ 2012/03/16 / introversion-produttività-ambienti-di-lavoro / ), quelli bravi lasciano che il team lavori al proprio ritmo ma attento alla visibilità.


2
La tua risposta sarebbe più forte se citassi alcuni riferimenti esterni o espandessi sui tuoi principi. L'affermazione cause it's well know[n]è una forma debole di prova.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.