È come la vecchia barzelletta sul matematico e sull'ingegnere. Qual è la differenza? Un matematico lavora con carta e matita. L'ingegnere lavora con matita, carta e un cestino della spazzatura.

È plausibile che gli sviluppatori impieghino l'80% del loro tempo a tagliare il codice, se hanno specifiche chiare che comprendono completamente e se stanno sviluppando un nuovo software "greenfield". In altre parole, se credono di non commettere mai errori.

Sembra improbabile che quelle condizioni reggano sempre. In caso contrario, ci sono molte ragioni per cui gli sviluppatori utilizzano altri programmi oltre a Visual Studio, Eclipse o anche Blocco note.

• Email / chat: ottenere chiarimenti sulle specifiche, chiedersi reciprocamente.
• Browser web: per sviluppatori web, testare le loro applicazioni.
• Browser web : per tutti gli sviluppatori, che lavorano con sistemi di ticketing e repository di codice in stile GitHub.
• Browser Web: per tutti gli sviluppatori, documentazione di consultazione.
• Il sistema in fase di sviluppo: sviluppatori non Web

I tuoi manager sono costretti a cambiare idea sulla supervisione perché le persone devono lavorare a distanza. Provengono da una mentalità in cui le persone non lavorano a meno che non siano alla scrivania a testa bassa. Quindi, vogliono un qualche tipo di metrica per questo e hanno scelto il time-in-editor.

Vuoi che adottino metriche migliori? In tal caso, tu ei tuoi colleghi dovrete sostenere il cambiamento. Hai una buona opportunità per farlo: hanno detto che non ti puniranno ancora (pagando per meno lavoro) per non aver seguito la metrica dell'80%.

Il tuo caso migliore può essere fatto da dimostrando che sei altrettanto produttivo - finisci tanto lavoro - a casa come in ufficio. Allora forse si fideranno di te. (Sì, giusto.) In caso contrario, possono esaminare la tua attività effettiva e imparare qualcosa su come svolgi il tuo lavoro.

Ovviamente, se alcuni dei tuoi colleghi si rilassano, ciò comprometterà i tuoi sforzi per sostenere il caso.

Sii paziente: cambiare atteggiamento è un lavoro duro (più difficile dello sviluppo).

Buona fortuna. E grazie per aver continuato a lavorare durante questa orribile epidemia.

Dai al tuo capo una copia del vecchio ma ancora pertinente libro di Fred Brooks The Mythical Man-Month . E, forse, leggilo tu stesso.

È una base corretta per calcolare l'orario di lavoro o segnare la loro presenza sulla base dei fattori sopra menzionati?

No, non lo è. Ma non sei responsabile.

Non sono corretti, ma è abbastanza facile da giocare

Non credo che troverai qualcuno qui che sia d'accordo con il modo in cui misurano la produttività. Tuttavia, se la direzione fosse costantemente intelligente nel valutare le persone, non avremmo molte domande qui, vero?

Sarei propenso a giocare con il sistema. Non abbandonerei mai il mio IDE durante la giornata lavorativa e troverei varie soluzioni alternative per fare la stessa cosa, solo in modo non tracciabile. La mia esperienza con il software di monitoraggio del tempo è che si preoccupa principalmente della finestra attiva su una macchina e / o se c'è un input periodico in quella finestra attiva, poiché non può dire se stai ottenendo qualcosa in quella finestra. Altri hanno anche il monitoraggio video, ma "stavo pensando" è una scusa molto valida e se in realtà insistono per sfornare codice ogni minuto di ogni giorno, ecco un link che può aiutare:

https://ca.indeed.com/m/jobs?sameQ=1&radius=25&q=Software+Developer&l=&from=searchOnSerp

1. Ti consigliamo un IDE completo . Un IDE può impedire molte ricerche su Google per piccole cose. Invece di cercare qualcosa nella documentazione, puoi leggere i nomi delle funzioni quando il completamento automatico ti offre alcune opzioni. Perderai molte buone pratiche, ma la direzione evidentemente non la apprezza. Questa metrica punirà anche qualsiasi sviluppatore che preferisce un editor di testo o utilizza un client git da riga di comando, poiché sospetto che l'utilizzo di altri strumenti sarà in "altro" piuttosto che in "editor". Un IDE completo consente anche di visualizzare le immagini, quindi invece di leggere un requisito nel tuo bug tracker, puoi fare uno screenshot, aprirlo nel tuo IDE come immagine e rispettare le regole in questo modo. Hai un PDF di documentazione da leggere? Eseguilo attraverso un convertitore da PDF a jpg e leggilo nel tuo IDE.

2. Ti consigliamo un secondo computer. Il software di monitoraggio del tempo si basa sul presupposto che non puoi fare un'altra cosa dopo aver fatto clic sul pulsante ogni 10 minuti circa. Avere un altro computer ti consente di andare su Stack Overflow senza apparentemente mai lasciare il tuo IDE. Se la mia direzione lo facesse, configurerei uno dei miei monitor per funzionare a tempo pieno sul mio Mac e utilizzerei il Mac per Google e utilizzerei il mio laptop principale per il lavoro effettivo.

In questo modo, potresti probabilmente ottenere il 90% del tempo IDE senza cambiare realmente il modo in cui fai lo sviluppo.

Non sarei felice di questa configurazione, ma è il tipo di stupida iniziativa di gestione in cui la soluzione non è eccessivamente onerosa, ma solo un po 'irritante.

le linee guida affermano: questo monitoraggio dell'utilizzo dell'applicazione non sarà la base per tagliare le nostre ore / presenze "per ora".

Questa linea fa Penso che stiano arrivando i licenziamenti, quindi è per questo che vorrei rotolare così facilmente e concentrarmi sul rispetto della metrica.

Pensa alle cose che devono accadere nell'ambito dello sviluppo del software. Analizzare e comprendere le esigenze e le aspettative degli utenti. Scomporre i requisiti in unità di lavoro. Elaborare o apportare modifiche a un'architettura o un progetto per supportare le esigenze degli utenti. Documentare l'architettura e il design del software. Scrittura del codice, incluso il codice di prova. Test manuale. Lavoro collaborativo. Revisione tra pari. Apprendimento: lettura della documentazione del sistema esistente, documentazione di strumenti o tecnologie, prototipazione.

Di questi, solo alcuni verranno eseguiti all'interno di un editor di codice. Scrivere codice e test automatizzati e creare prototipi sarà sicuramente in un editor di qualche tipo. La lettura del codice esistente per il sistema che stai sviluppando può essere eseguita all'interno del tuo editor, ma potrebbe anche essere eseguita tramite un'interfaccia web al tuo repository di codice sorgente. Le revisioni del codice, a seconda del processo e degli strumenti, possono essere eseguite nel tuo editor, ma probabilmente verranno eseguite tramite uno strumento diverso.

Non scrivo più (molto) codice al lavoro, ma quando l'ho fatto , la maggior parte del tempo non era nel mio editor di codice. E anche se il mio editor di codice era aperto, potrei essere stato multitasking con altre cose aperte: un tracciatore di problemi, un wiki, un browser web per accedere alla documentazione. Dato che ho lavorato su un'applicazione web, utilizzerei anche un browser web per accedere al mio sviluppo locale o uno dei server di sviluppo o test che eseguono una versione dell'applicazione. Con le sessioni remote, aumenterà anche l'uso di strumenti come Skype e Slack per accoppiare programmi tramite la condivisione dello schermo.

Un'altra cosa da considerare è che ci sono alcuni numeri in giro (vorrei poter citare un'unica fonte attendibile) sul fatto che il tempo produttivo è intorno al 60%. Ciò significa che in una giornata lavorativa di 9 ore, ti aspetteresti di avere un tempo di lavoro produttivo di circa 5-5,5 ore. Le organizzazioni altamente ottimizzate possono fare meglio del 60%. Anche se l'ipotesi che uno sviluppatore sia produttivo solo quando in un editor è vera, 7 o 8 ore di un turno di 9 ore rappresenterebbero un tempo di produttività superiore al 78%.

Data la natura dello sviluppo del software , Non vedo come possa essere ragionevole formulare ipotesi sulla produttività. Poche persone o organizzazioni raggiungono una produttività del 78% o superiore durante una giornata lavorativa. Anche se lo fossi, l'uso di un editor non è una buona misura della produttività dello sviluppatore di software poiché ci sono un gran numero di attività che non vengono eseguite all'interno dell'editor.

Ogni volta che la direzione vuole fare qualcosa del genere, dovrebbe sempre chiedersi: da cosa sto incentivando i dipendenti?

In questo caso ... potresti avere uno sviluppatore che ha un problema che probabilmente potrebbero risolvere in 20 minuti con qualche ricerca su Google ... ma perché? Saranno colpiti dalle prestazioni. Meglio passare 4 ore a sbattere una testa contro un muro e provare cose casuali finché non funziona. O forse potresti avere uno sviluppatore che non è del tutto sicuro di cosa deve fare con alcuni aspetti del loro progetto attuale. Loro potrebbero programmare una riunione Skype e fare un rapido sit-down ... tranne che conterà per la loro metrica di rendimento. Meglio sbattere fuori qualcosa e sperare che sia ciò che si vuole - certo, potrebbe risultare in un sacco di lavoro sprecato ... ma questo è lavoro sprecato in un IDE che non conta contro di me. Ecc., Ecc.

La direzione mi ha effettivamente messo in una posizione simile anni fa:

"Kevin, per la tua valutazione del rendimento, ho dovuto ti aggancia per l'eccessivo utilizzo del Web negli ultimi 6 mesi. "

" Aspetta, cosa? "

" Sì, stavi navigando sul Web un'ora in più al giorno rispetto la media del dipartimento. "

" Sì, perché ero immerso nelle erbacce cercando di capire come scrivere il pulsante di estensione per il client di posta Thunderbird. È un mix di Java, un linguaggio che non conosco Non lo so davvero - e un insieme proprietario di comandi che non hanno una buona pagina di riferimento. Ci sono state settimane in cui stavo letteralmente girando intorno a siti di esempio di codice per la maggior parte della giornata cercando di mettere insieme comandi e far funzionare quella cosa. "

"Stai dicendo che tutta la tua navigazione web era correlata al lavoro?"

"La stragrande maggioranza. Voglio dire, potrei aver visitato un non - sito di lavoro di tanto in tanto, ma fai apparire l'elenco dei siti che ero sopra. Scommetto che google, stackoverflow e Thunderbird Chrome Language board sono i tre siti più grandi ".

"... beh, dato che stai riconoscendo che parte di questa navigazione eccessiva è personale, lascio che il 'Miglioramento necessario' rimanga".

Ora .. ti interessa indovinare quanto fossi ansioso di fare quel tipo di programmazione in futuro? Voglio dire, prima di cogliere al volo l'opportunità di sviluppare un programma chiave in un ambiente / linguaggio nuovo ed entusiasmante. Vuoi indovinare per quanti progetti come quello mi sono offerto volontario in futuro? Vuoi indovinare quante volte mi sarei offerto volontario per problemi difficili / impossibili che non avevo già un'idea molto chiara di come risolvere?

Quando in qualsiasi posizione di autorità, chiediti sempre: quali comportamenti questo incentiverà / stimolerà?

Esiste una percentuale di utilizzo dell'editor di codice ideale?

No, non esiste.

Fai sviluppatori / programmatori di software produttivi trascorrono circa il 70-80% del loro tempo di lavoro in editor di codice?

Non in generale, ma alcuni probabilmente corrisponderanno a quel numero almeno a volte.

È una base corretta per calcolare l'orario di lavoro o segnare la loro presenza sulla base dei fattori sopra menzionati?

No.

Perché non esiste una percentuale di utilizzo dell'editor di codice ideale?

Perché

1. ognuno è diverso
2. il mucchio di lavoro di ognuno è diverso
3. la pila di lavoro di tutti contiene oggetti diversi di giorno in giorno
4. l'ambiente di ognuno è diverso

Per 1) A volte mi piace lavorare con una lavagna per inventare algoritmi. Funziona bene per me. Alcuni altri colleghi preferiscono provare a codificare prototipi finché uno non funziona. Un programmatore guarda il DB tramite l'editor di codice, l'altro utilizza un client db a riga di comando. -> Differenze nell'utilizzo medio dell'editor di codice.

Per 2) Uno sviluppatore senior potrebbe eseguire un design più di alto livello e uno junior compiti più piccoli che sono semplici. Uno sviluppatore potrebbe svolgere alcune attività DevOps e scrivere script in un editor di testo o coordinare le implementazioni del software con un altro reparto. → differenze nell'utilizzo dell'editor.

Per 3) Lunedì tutti potrebbero scrivere codice nella prossima versione di rilascio, quando improvvisamente durante la notte, i server con la vecchia versione si bloccano a causa di un bug di memoria. Il giorno successivo tutti saltano sui file di registro, esaminano le voci del database, collegano i debugger o le unità al data center per dare un'occhiata al cablaggio (o chiamarli). → Enorme variazione nell'utilizzo dell'editor di codice.

Per 4) Un collega potrebbe lavorare in un ufficio a casa e gli altri nell'ufficio reale. Le persone dell'ufficio reale possono parlare senza cambiare contesto sul proprio PC e il collega dell'ufficio domestico deve avviare un messenger. Oppure un collega potrebbe avere due monitor mentre un altro ne ha uno nel suo ufficio a casa. La persona con due monitor può lasciare i requisiti aperti sul secondo schermo e la persona con un monitor deve cambiare costantemente. -> diverso utilizzo dell'editor di codice.

Conclusione: a meno che tu non abbia un processo di sviluppo della catena di montaggio molto rigoroso, in cui ogni programmatore dovrebbe funzionare allo stesso modo, ha lo stesso tipo di attività ogni giorno e ha il stessa configurazione e strumenti (senza scelta) di tutti gli altri, non esiste una tale verità universale. E nessun processo di sviluppo che ho incontrato finora era quello "industrializzato" - se lo fosse, non lo chiamerei ingegneria del software ma assemblaggio del software - e probabilmente dovrebbe essere automatizzato per allora.

Ora, d'altra parte. Se vuoi codificare, a un certo punto devi modificare il codice in qualche modo. Quindi, se rendi la misura abbastanza ampia e conti qualsiasi editor che potrebbe essere utilizzato e scegli il numero abbastanza basso, puoi determinare un numero minimo come il 10% a settimana che copre in modo sicuro tutti i programmatori di successo (che sono pagati per sviluppare software piuttosto piuttosto che fare altre attività). A quel punto diventa ovviamente del tutto insignificante - cioè qualcuno che si allenta così tanto da essere rilevato da quella misura, dovrebbe in qualsiasi azienda funzionante essere rilevato molto prima con altri mezzi (ad esempio non avendo nulla di significativo da dire in una riunione quotidiana in piedi per giorni).

Ora c'è un'area grigia in mezzo in cui puoi utilizzare una metrica di questo tipo come indicatore, con altre metriche per vedere se qualcuno ha bisogno di supporto. Ma questo è un altro campo da gioco interamente mirato a una percentuale di utilizzo perfetta. E ancora, ci sarebbero altre metriche che coprono gli stessi casi senza dare ai dipendenti la sensazione di essere monitorati e non fidati.

Pertanto, la tua vera domanda non dovrebbe essere "esiste un numero simile?". La tua vera domanda dovrebbe essere "Come faccio a convincere la direzione a prendersi cura di me cercando di gestirmi come un operatore di linea che funziona solo quando è rigorosamente monitorato?" per convincere la direzione a vedere che questa misura non aiuta nessuno, ma distrugge il lavoro autodeterminato e quindi l'investimento nel lavoro personale insieme a qualsiasi buona volontà e fiducia.

_{* Nota che queste sono due parti separate : 1) essere trattato come un operatore di linea 2) che è pigro quando non viene monitorato → cioè non sto dicendo che ogni operatore di linea deve essere monitorato.}

Non voglio ripetere ciò che è stato detto in tutte le altre risposte, quindi mi limiterò a questo: quella metrica è ridicola.

Sei uno sviluppatore di software, non un dattilografo. In qualità di sviluppatore di software, sei quello che viene chiamato un lavoratore della conoscenza , vieni pagato per pensare , vieni pagato per la tua creatività , vieni pagato per la tua conoscenza , vieni pagato per la tua esperienza , vieni pagato per la tua competenza . Non vieni pagato per scrivere.

Il tempo che dedichi a digitare nell'editor è esattamente il tempo in cui non fai nessuna delle cose vieni pagato. Il tuo lavoro consiste nel dedicare molto tempo a pensare in modo da poter risolvere il problema con il codice più semplice e più breve possibile.

Se spendi 70 % -80% del tuo tempo di codifica, ciò significa che trascorri solo al massimo il 20% -30% del tuo tempo a risolvere i problemi. In realtà, è molto meno di questo, perché hai anche cose come riunioni, pianificazione, comunicazioni del team, rapporti e ... sì ... monitoraggio del tempo da fare durante le tue ore di lavoro, oltre a tutte le cose relative al progetto che non sono codifiche o problemi -solving (cercando di convincere il cliente a chiarire un requisito, per esempio).

Se trascorri la maggior parte del tuo tempo a programmare e non ci pensi, significa che stai risolvendo problemi banali. Statisticamente, è altamente probabile che questo stesso banale problema sia già stato riscontrato da qualcun altro e che ci sia una soluzione già pronta per questo. Quindi, non dovresti risolvere questo banale problema ma utilizzare invece la soluzione esistente.

Dovresti risolvere i problemi difficili , ma questi richiedono molto più tempo per pensare che per programmare.

Quindi, voglio sapere se i presupposti e la comprensione dell'azienda di cui sopra sono corretti a qualsiasi livello.

Gli sviluppatori / programmatori di software produttivi trascorrono circa il 70-80% del loro tempo di lavoro negli editor di codice?

È una base corretta per calcolare il tempo di lavoro o contrassegnare la loro presenza sulla base dei fattori sopra menzionati?

Ogni azienda deve fare le proprie ipotesi e giudicare gli sviluppatori su qualsiasi base scelgano ... non importa quanto siano ridicoli.

Come sono sicuro già sai, non c'è alcuna base fattuale dietro nessuna delle loro ipotesi.

Chiunque abbia escogitato quella metrica non conosce il lavoro che svolgi a livello di tale microgestione.

Queste misurazioni possono essere utili se hai una linea di base su cui lavorare. Se quando si lavora in ufficio, il tempo trascorso presso l'editore era compreso tra il 75 e l'85%, ha senso aspettarsi lo stesso rapporto e prendere nota se c'è stato un calo per un singolo dipendente.

Supponendo che tutto il resto rimanga lo stesso : ai dipendenti non viene chiesto di assumersi maggiori responsabilità, le specifiche non sono meno definite ora poiché il cliente ora le fornisce in modo diverso, ecc.

Heh, Anche io probabilmente non conoscerei la giusta percentuale. Stimerei che nel mio lavoro di codifica, passo più tempo su una console o su un browser web che su un editor (anche se recentemente non sto sviluppando funzionalità di grandi dimensioni). Specialmente, quando stai inseguendo uno di quegli insetti difficili da trovare potresti passare ore su un singolo difetto! (ma puoi fare l'altro 80% nel 20% rimasto). E questo non tiene nemmeno conto del tempo speso per costruire il sistema, cosa che dovresti fare molto spesso. I programmatori non lavorano nel vuoto e scrivono un programma dall'inizio alla fine e senza errori. Proprio come uno scrittore non scriverà il tuo romanzo dall'inizio alla fine. (Può essere fatto da persone brillanti se il romanzo / codice è abbastanza breve. Il punto è valido, però.)

Un altro punto sarebbe la quantità di ciò che viene richiesta dai tuoi capi. Come si tengono aggiornati con i membri del team? Solo che potrebbe già bruciare quell'ora che il dipendente può utilizzare per "non utilizzare un editor di codice". E questo non è nemmeno considerato che stavi usando un metodo agile come lo scrum! (suggerimento: se legare le persone ai loro editor di codice fosse il modo migliore per far sì che i dipendenti producano valore per l'azienda, queste metodologie non avrebbero successo)

È anche interessante il modo in cui si aspetterebbero che tu testasse il codice o ne documentassi l'uso. È il ruolo del tuo team QA? Grande. Questa linea guida significa che puoi passare loro codice completamente non testato, che potrebbe non funzionare nemmeno. Chiedi loro di restituire il backtrace in un file .c , in modo da poterlo leggere nel tuo editor di codice. Tuttavia, non è certo un guadagno per la tua azienda.

Oltre a tutto ciò, un punto interessante è che

affermando specificamente che un maggiore utilizzo di Skype mostra mancanza di pianificazione e documentazione.

Mi aspetto che la pianificazione sia fatta dalla direzione e che la documentazione sia la specifica del cliente. Quindi, se hai bisogno di usare molto Skype, puniranno il tuo capo per una cattiva pianificazione? Anche se la consegna del prodotto è puntuale? E se il cliente non riesce a prendere una decisione e cambia costantemente i suoi requisiti? Come considereranno i clienti problematici quando valuteranno la produttività dei loro sviluppatori?

Come menzionato in tutti gli altri post, le metriche proposte non tengono nulla.

Non ripeterò ciò che hanno detto gli altri ma elaborerò alcuni punti non trattati.

Altrimenti, se affretti, rischi di guidare voi dipendenti nella direzione sbagliata. Invece di allinearli maggiormente agli obiettivi aziendali, li induci a imbrogliare la metrica o fornire prestazioni meno ottimali per mantenere la metrica.

Anche se questo è solo uno stratagemma per ottenere una traccia cartacea per tagliare le tue ore dopo , è probabile che se ciò accade con metriche sbagliate / mal comprese, danneggia l'organizzazione perché le persone sbagliate avranno un taglio di ore.

3. In realtà c'è molto materiale in uscita lì su come gestire e tenere traccia della produttività degli sviluppatori. Un modo che ho trovato particolarmente sensato è la "velocità". Si noti che questo non ha lo scopo di misurare le prestazioni individuali, ma ottenere una stima del tasso di progresso dei team. In tempi come questi potresti facilmente vedere, dopo alcune settimane di lavoro a casa, se la velocità dei team è diminuita in modo significativo. Quindi sarebbe il momento di parlare con loro e vedere cosa puoi fare per consentire loro di diventare produttivi come prima, di nuovo.

Allora cosa potresti fare effettivamente, oltre a allacciarlo e / o fingere?

Potresti scrivere un'e-mail al manager responsabile (e solo a lui, non vuoi che si senta esposto e si metta sulla difensiva). Dovrebbe essere composto da 3 parti.

A. Esprimi la tua comprensione e il sostegno del loro obiettivo. Metti in chiaro che sei d'accordo con l'idea generale e sosterrai tutte le iniziative che promettono di aumentare il successo dell'azienda.

B. Esprimere i rischi che gli attuali approcci comporteranno. Attenzione a non ignorare l'idea, ma assicurati di evidenziare il costo che ciò potrebbe comportare per l'organizzazione. Il qualcosa di google in 5 minuti vs lo scoprilo tu stesso nell'editor di codice in 2 ore è un buon esempio per evidenziare le metriche percepite rispetto alla produttività.

C. Proponi un approccio diverso. A nessuno piace no-Sayers. Se non hai niente di meglio da offrire, puoi anche tacere.