Come misurare il tempo perso a causa di problemi ambientali?

Quello che sembra che stia facendo è tentare di misurare la produttività. Misurare la produttività è notoriamente difficile. Ecco come me ne occupo ...

Ho scoperto che non vuoi affrontare la situazione misurando perdite , vuoi misurare i guadagni di potenziali soluzioni. Da un punto di vista puramente filosofico, il primo implica che stai facendo qualcosa di sbagliato, che potrebbe non essere vero.

Le cose cambiano e, periodicamente, qualcuno (come te stesso, sembra) deve dare un'occhiata al paesaggio e vedere se tali cambiamenti possono fornire un ambiente migliore. Detto questo, guardo:

Cose che non esistono

• Strumenti (ad esempio computer, controllo della versione)
• Pratiche (ad es. TDD)
• Processi (ad es. recensioni di codici, agile)

Questo è un problema comune e ho sostenuto con successo l'adozione di alcune cose basate su:

Documentazione del prodotto e informazioni di vendita

Questo è sempre il primo punto di partenza. Se il prodotto costa denaro, la documentazione di vendita è quasi sempre mirata o formulata per tipi di gestione. È facile da trovare, facile da accedere e un umano che lavora per il venditore è quasi sempre disponibile per fornire altre risorse come le seguenti ...

Case study

Un buon esempio che ho è il libro "Best Kept Secrets of Peer Code Review" è stato scritto da Jason Cohen (fondatore di Smart Bear IIRC) che contiene casi di studio al fine di rendere il caso per le revisioni del codice. Certo, il libro è stato fondamentalmente scritto dal venditore, ma gli studi di casi erano legittimi.

Proofs of Concept

Se si tratta di un'implementazione potenziale (pensando a CI, sistema di compilazione, TCM o qualsiasi altro processo o strumento di automazione), il modo migliore per farlo è ottenere una prova e configurarla. Dopo aver eseguito alcune indagini iniziali (ad esempio, utilizzandolo su progetti fasulli) potrebbe essere una buona idea provarlo in un piccolo progetto, o eventualmente in coppia con la soluzione esistente.

Per i processi, è simile. Questo è fondamentalmente il modo in cui molti sviluppatori introducono i test unitari. Mantengono i loro test per un po 'e quando la "BAM! Regression Caught!" Critica colpi di scenario, eseguono la rivelazione e mostrano come ha salvato il progetto. Un po 'drammatico, sì, ma ha senso. Le persone hanno bisogno di vedere i benefici con i loro occhi.

Cose che esistono ma sono rotti / inefficienti

Questa sarà quasi sempre un'analisi comparativa. Se ti avvicini in questo modo, dovresti essere in grado di ottenere numeri con cui lavorare.

Le informazioni di vendita del venditore non funzionano sempre bene qui, a meno che non si tratti di un prodotto che compete direttamente e ovviamente con la soluzione attualmente implementata - in questo caso, di solito è possibile che il fornitore ti aiuti qui. (Sto pensando a SourceGear Vault vs SourceSafe come esempio)

Ho scoperto che raramente esistono studi di casi che mettono a confronto strumenti / pratiche ma esistono per i processi (si pensi agli studi Agile vs. Waterfall).

Nella mia esperienza, le dimostrazioni di concetto sono spesso i modi più efficaci per convertire la gestione / gli sviluppatori da uno strumento o una pratica a un'altra. Devono vederlo funzionare e, cosa ancora più importante, vederlo funzionare meglio di ciò che già esiste. Poi li colpisci con i numeri. "Questo sistema, che è solo un POC, è ancora x volte più veloce del nostro precedente, il che si traduce in una riduzione delle ore di lavoro e della riduzione di overhead" Ricorda che a volte i POC possono essere fatto su piccoli progetti per testare un processo, di solito dopo che sono state fornite sufficienti prove di potenziali guadagni.

Cose che non abbiamo un'idea

Ecco dove entrano in gioco sondaggi e questionari ... ma questi ti porteranno alle categorie sopra descritte.

Suppongo che intenda i tempi di inattività dell'ambiente e la perdita di produttività quando gli ambienti di sviluppo e test diminuiscono o hanno bisogno di tempo per gli sviluppatori per il debug dei problemi ambientali.

Crea un semplice strumento di monitoraggio che sia così facile da usare che gli sviluppatori non debbano pensarci. Ogni volta che un problema di ambiente viene sottoposto a debug da uno sviluppatore o semplicemente non può funzionare a causa di esso, ho creato uno strumento simile al cronometro con qualcosa di semplice come AutoHotKeys (uno strumento che consente di mappare rapidamente e facilmente combinazioni di tasti a uno script) ha iniziato un timer. Al termine del tempo di inattività, premi nuovamente la combinazione di tasti e AutoHotKeys invierà una semplice richiesta GET a una pagina PHP che ho configurato sul server web. Ha semplicemente calcolato i totali in millisecondi e li ha memorizzati in un file.