¿Cuál es el propósito de registrar el trabajo en hojas de horas diarias?

TL; DR

En general, el registro es un síntoma de un proceso de desarrollo no ágil que representa el compromiso activo y la conciencia situacional de un gerente de proyecto. También suele ser una señal de que el proyecto está midiendo algo incorrecto, ya que el "tiempo consumido" rara vez es una medida válida o un predictor de resultados. Cuando no se usa únicamente con fines de facturación contractual, con mayor frecuencia se usa incorrectamente como una herramienta de análisis de responsabilidad o de causa raíz.

El seguimiento basado en resultados es generalmente más efectivo. Por ejemplo, en Scrum, una historia está "terminada" o "no terminada" al final de un Sprint. Cuánto tiempo se dedicó a qué tarea dentro del Sprint es en gran medida irrelevante, aunque los bloqueos y los problemas de cola son ciertamente temas válidos para una Retrospectiva del Sprint.

La falacia de la contabilidad detallada del tiempo

El tiempo de seguimiento es útil para fines de facturación y aparentemente para estimaciones futuras. Sin embargo, en realidad, las hojas de tiempo son una obra de ficción o una sobrecarga innecesaria.

En la fabricación, ciertamente puede valer la pena documentar que lleva x minutos producir y widgets en una línea de ensamblaje. Sin embargo, en el trabajo de conocimiento como la programación, el trabajo rara vez se descompone claramente en incrementos medibles. Además, la programación en particular a menudo se trata de pensar en el problema correcto para resolver, por lo que el mantenimiento de registros demasiado granular que no es una obra de ficción completa podría parecer:

• Pasé 47 minutos pensando en cómo optimizar el frobnitz.
• Pasé 52 minutos escribiendo una especificación para un widget de wibble experimental.
• Pasé 12 minutos codificando un nuevo objeto quux.
• Pasó 17 minutos eliminando un montón de objetos de código, documentación y referencias que deberían eliminarse a favor del objeto quux.
• Pasó 21 minutos esperando que se ejecutara la integración continua.
• Pasé 3 minutos cada cuarto de hora resumiendo el trabajo y 23 minutos y 15 segundos volviendo a la normalidad después de interrumpir mi trabajo para registrar mi tiempo.

Si el registro se mantiene de manera meticulosa y honesta, al final del día el tiempo simplemente no sumará 8 horas debido al cambio de tareas, los gastos generales y (por supuesto) el tiempo dedicado al seguimiento del tiempo a nivel granular. Eso hace que el registro sea menos útil de lo que a los gerentes les gustaría pensar.

El cronometraje sensato tiende a ser menos granular. Una entrada de registro sensata podría decir: "Hoy pasé 6 horas trabajando en el proyecto foo y 2 horas en reuniones, cronometraje y otros gastos generales del proyecto". Sin embargo, este tipo de registro de alto nivel a menudo es imperfecto debido al sesgo cognitivo, los errores de omisión, el filtrado social y otros factores que lo hacen inútil como medida válida.

Gestión de proyectos basada en resultados

Los marcos ágiles como Scrum respaldan implícitamente un entorno de trabajo de solo resultados . Si bien ROWE en sí mismo es una palabra de moda y un término de marketing, el concepto de medir los resultados (por ejemplo, ¿se cumplió o no un objetivo? ) es generalmente más útil que medir los minutos por tarea. Una vez más, los sectores como la fabricación que necesitan medir el rendimiento en realidad pueden necesitar datos de tiempo, pero rara vez necesitan datos de tiempo del tipo recopilado por las hojas de tiempo que está describiendo.

Centrarse en si las tareas se "realizan" o "no se realizan" es un cambio cultural significativo en muchas organizaciones. Requiere confianza entre la alta dirección y el equipo de desarrollo, y el compromiso del equipo de ser transparente sobre las estimaciones, los impedimentos y los objetivos incumplidos. Sin esa confianza y sin ese cambio de cultura, la mayoría de las organizaciones simplemente recurren a métricas inútiles como la contabilidad del tiempo.

Si su organización no está dispuesta a hacer ese cambio cultural, y si encuentra que el registro granular es perjudicial o una carga, entonces puede intentar evangelizar un enfoque más ágil. Sin embargo, lo más probable es que simplemente sea hora de repasar su currículum y buscar una organización que esté menos sumida en el fracaso.

He trabajado en organizaciones que realizan un seguimiento del tiempo en incrementos de 15 minutos y otras que no realizan ningún seguimiento del tiempo.

Desde la perspectiva de un PM, prefiero mucho el primero, porque es casi imposible estimar objetivamente el esfuerzo futuro si no tienes un historial del tiempo real invertido. En mi organización actual, tenemos que pasar por todo tipo de contorsiones para determinar cuántos proyectos se pueden implementar, cómo se deben priorizar, etc., etc. Sería mucho más fácil iniciar una conversación sobre la priorización de proyectos si pudiéramos ir a nuestro liderazgo y decir "Tenemos XX cuerpos cálidos, en nuestra experiencia podemos ejecutar con éxito YY proyectos con ese nivel de personal".

Secundo los pensamientos de David sobre esto. Tuve que registrar el tiempo durante 8 años, primero hasta media hora y luego hasta una hora, y la única vez que fue "doloroso" cuando ayudé a otra persona en un asunto con el que no tenía nada que ver, por lo tanto, no pude para registrar cualquier hora allí.

Desde la perspectiva del proyecto, tiene algunos beneficios, porque el equipo/PM sabrá cuánto esfuerzo se ha puesto en el proyecto y verá si todavía están dentro del presupuesto o no.

Esto también puede ser un dato útil para que los clientes potenciales vean quién está involucrado en muchas cosas y ayude a reducir las causas del cambio de contexto del dolor.

Los compañeros de equipo discutieron mucho que les tomó demasiado tiempo completar, y cuando en realidad medimos fue de aproximadamente 10 minutos un viernes para completar la semana. El segundo argumento fue sobre la confianza, como ya mencionaste. Solo conocí a un PM que usó las hojas de tiempo para averiguar qué estaba haciendo la gente, en lugar de ir allí y verlo por sí mismo, otros trataron de solucionar los problemas. Tampoco estaban tan interesados ​​en los detalles. Los ingenieros dedicaron mucho tiempo a llenar las hojas con mucha precisión, lo que nunca se les pidió que hicieran. El PM estaba interesado en los números aproximados solo para ver dónde está el proyecto.

Al igual que otros aquí, tuve que controlar mi tiempo al nivel de 1/4 de hora durante años como consultor. Al principio lo odiaba, pero aprendí a abrazar el esfuerzo debido a la información que proporciona en el futuro. ¡No descuides los comentarios!

Como desarrollador, tengo que decir que estoy de acuerdo en que esto puede ser un dolor de cabeza. Está bien si está asignado a un solo proyecto, o si los fragmentos son grandes, digamos un día en esto, un día en eso.

El problema ocurre cuando tienes que trabajar en varias cosas al azar en un solo día y simplemente no encajan en el buen sistema de cronometraje ordenado que se ha configurado.

Digamos, por ejemplo, que estoy en un equipo BAU, implementando características de un tablero Scrum. Tengo mi tarea para el día y puedo asignarle tiempo sin problemas. así que estoy trabajando y el gerente Bob se me acerca para preguntarme sobre un posible error que un usuario ha informado. Probablemente no sea nada, pero ¿puedo investigar? Luego, el desarrollador Jim quiere preguntarme sobre un código que programé la semana pasada, Sales Jane pregunta, ¿puedo ir a una reunión para discutir la interfaz para el nuevo cliente Z? HR Sam no puede cargar su hoja de cálculo en la herramienta interna Y, ¿puedo generar un informe rápido sobre algo de la base de datos? etcétera etcétera

"¡Pero!" dices, ¡estamos haciendo scrum/kanban/agile de la semana! deberías decir "¡No!" a todas estas cosas y al Scrum master para que intervenga redactando tareas y priorizándolas!

Desafortunadamente, el efecto práctico de esto obliga a los desarrolladores a elegir entre ser 'policía scrum', trabajar horas extras, tener horas que no suman en el sistema o 'redondear' esas horas.

Además, las empresas tienden a confiar en esta "TI en la sombra" que empuja a los desarrolladores a ser una "unidad de estilo de trabajo, solo realizan tareas en el tablero". . exactamente lo contrario de lo que quería la empresa.

Me atrevería a decir que aquellos que piensan que no se confía en ellos probablemente tengan algo que ocultar.

La recopilación de datos a diario es importante tanto para medir el rendimiento en comparación con las líneas base de costos y cronogramas como para los aportes a proyectos futuros que sean similares. Se realiza diariamente para aumentar la exactitud y la precisión porque, si se realiza semanalmente, lo más probable es que los datos sean una suposición óptima, lo que hace que los datos sean inútiles. Los trabajadores deben capturar con la mayor exactitud y precisión posible las horas trabajadas en relación con un paquete de trabajo en particular.

Todos capturamos nuestro tiempo, desde trabajadores que fichan hasta profesionales que registran horas para facturar a sus clientes.

Es absolutamente necesario para gestionar proyectos y negocios. Si esto te ofende, echa un vistazo detenidamente a lo que podrías estar escondiendo de tu jefe.