Sembra che l'OP sia “preso nel mezzo”: un “subordinato” si è lamentato con i funzionari aziendali che un responsabile di progetto/direttore di squadra lo sta mettendo in dubbio. Per vari motivi questo sembra un team di software. Anche se non è strettamente rilevante, quello che potrebbe essere un problema è che ci si aspetta che qualcuno in un ruolo ‘ingegneristico’ gestisca il suo tempo come potrebbe fare un impiegato del commercio al dettaglio - dentro alle 8:00 AM e fuori alle 17:00 PM. Sembra che ci siano altri problemi anche qui, ma non sono dettagliati.
La domanda, così come è stata posta, è “Cosa devo dire al senior management? Questo suggerisce che la prima preoccupazione dell'OP è come viene percepito dai suoi stessi dirigenti. Dal punto di vista del senior manager, due ego sono in una lotta tra gatti - uno che scrive codice e l'altro che gestisce un progetto. Ciò implica una certa distanza sociale tra lo "sviluppatore” e il “supervisore”. Il supervisore sembra cercare di dire al subordinato: “sei stato assunto per fare quello che ti viene detto - non mettere in discussione l'autorità”. Mentre la posizione reale non è evidente dal contenuto, questo suona come un negozio da qualche parte in Asia.
Quello che il senior management vuole sentire è che i due belligeranti hanno trovato il modo di fare il loro lavoro con un minimo di attrito. “deve portare tutti i punti negativi del suo superiore o cosa?” sarebbe una pessima mossa - davvero pessima. Tutto ciò che gli anziani vedono a questo punto è che due dipendenti stanno discutendo piuttosto che fare il loro lavoro.
Quindi, a rischio di “non rispondere alla domanda”, proporrei che:
- 1. L'OP capisce quali sono le metriche applicabili per misurare le prestazioni dello sviluppatore. Non è probabile che si tratti di un orologio in entrata e di un orologio in uscita. È probabile che si tratti della produzione di deliverable - codice, documentazione, correzioni e supporto all'utente in un ragionevole lasso di tempo. Ciò potrebbe applicarsi altrettanto facilmente ad altre forme di ingegneria - progettazione di chip, progetti architettonici o ponti. Tutti questi hanno complessi mix di “progettazione del nucleo”, documentazione, revisioni e risposta al feedback dei consumatori. 2. Dopo aver individuato le metriche, applicarle allo sviluppatore/ingegnere. 3. Scrive il codice, risolve i problemi e supporta gli utenti in modo soddisfacente? Se sì, smettete di provocarlo con cose che ovviamente gli danno fastidio. Vedete se è possibile identificare problemi di tempo che non sono visibili durante l'orario di lavoro, come le telefonate a tarda notte, il lavoro nei fine settimana o altre attività che disturbano la normale settimana di 40 ore. 3. C'è un certo valore nell'introspezione. L'OP si impegna in un gioco di potere solo per stabilire o mantenere il “rango”? Le persone che ricoprono ruoli di ingegneria si scontrano continuamente con i ‘manager di linea’ a causa dell'abbigliamento, delle pause, del linguaggio, degli orari di lavoro e dei protocolli di contatto con gli utenti o con i clienti. Gli ingegneri considerano il comportamento dei manager come ostruzionista - più preoccupati delle apparenze e dei prerequisiti che di come fare le cose. L'OP potrebbe sfruttare questa opportunità per capire se le abitudini acquisite in un diverso tipo di organizzazione (o struttura familiare) sono controproducenti in questo caso.
Avendo fatto queste cose, è il momento di sedersi con lo sviluppatore - idealmente fuori dall'ufficio - diciamo a pranzo. Incoraggiare e permettere allo sviluppatore di parlare di come il tempo viene speso giorno per giorno - i pezzi disponibili per la codifica / progettazione, le interruzioni da parte dei supervisori, le interruzioni da parte degli utenti, i problemi che lo tengono occupato durante le ore non lavorative, i cambiamenti speculari “all'improvviso”, ecc. Non sorprendetevi se la conversazione divagherà - se così fosse - delicatamente.
Da questo, cercate di capire quali particolari eventi scatenerebbero qualcuno che si presentasse in ritardo o si prendesse una lunga pausa - tra le cose che scatenano il primo (per mia esperienza personale) c'è solo una vaga comprensione di cosa fare dopo. Spesso me ne stavo seduto nella mia poltrona reclinabile a casa per due o tre ore a pensare a come strutturare qualcosa, poi, quando arrivava la risposta, mi mettevo a lavorare e lo facevo. Ho avuto molti supervisori che si lamentavano del mio orario di arrivo - nessuno della qualità di ciò che facevo.
Se l'ingegnere viene interrotto spesso, il compito degli OP è quello di capire come intercettarli in modo che ce ne siano meno. Questo significa, in particolare, non crearne di più arbitrariamente. Da dove vengono le interruzioni, e possono essere diminuite? Questo è spesso ciò che i supervisori devono fare: tenere i ponti liberi, in modo che i programmatori/designer/ingegneri possano concentrarsi per far uscire le loro cose.
Se lo sviluppatore non è davvero in grado di spiegare dove va a finire il suo tempo, allora potrebbe esserci un problema di competenza. Anche in questo caso, questo è focalizzato sull'output, non sull'orologio del tempo. Le scadenze non vengono rispettate perché non si fa nulla o perché qualcun altro continua a cambiare idea? Se il programmatore deve continuare a ricominciare da capo, allora non verrà fatto nulla. Se è così, perché sta succedendo questo? Ci si aspetta che i supervisori blocchino i requisiti in modo che il team possa lavorare su un obiettivo fisso.
Se tutte queste cose dovessero accadere, il Il supervisore potrebbe riferire al senior management che la produttività sta migliorando e che gli utenti stanno ottenendo l'infrastruttura informatica di cui hanno bisogno.