¿Cómo realiza un seguimiento de lo que usted y su equipo están trabajando día a día?

61

Me cuesta saber cómo hacer un seguimiento de lo que yo y las personas de mi equipo hacemos en realidad cada día. Obtengo una buena visión general revisando las tarjetas completadas cada semana y los stand-ups ayudan un poco, pero siento que no tengo un buen manejo del trabajo diario de mi equipo. Las tarjetas permanecerán en progreso durante días sin una actualización en el stand-up diario, y algunos ingenieros son mi equipo no son los más comunicativos.

He pensado implementar algún tipo de registro diario que todos llenen (a través de una lista de correo o un documento compartido de Google), pero esto parece bastante engorroso y manual.

El monitoreo de la actividad de GitHub funciona bien, pero puede ser un poco abrumador con la cantidad de correos electrónicos que envía todos los días. He pensado en tratar de construir un sistema de resumen para él, pero no tengo tiempo de sobra.

¿Qué estrategias ha implementado para mantenerse al tanto de lo que hace su equipo todos los días para que pueda medir el trabajo en tareas "en progreso"?

Brian Brunner
fuente
55
Es mejor preguntarlo en work.se.
mattnz
39
@mattnz: no lo sé. La respuesta variará bastante significativamente entre un programador y un jugador de baloncesto y un cartero.
Telastyn
17
Eso debería cubrirse en el stand-up diario. Donde trabajo, cada uno de los desarrolladores declara en qué estamos trabajando actualmente y en qué pretendemos trabajar mañana. El truco para esto es que los participantes no deben sentir que están siendo 'rastreados', si cree que un desarrollador puede estar retrasado, NO lo mencione en el standup, en lugar de eso mantenga esa conversación privada.
JuStDaN
55
@mattnz - Bien, reemplace los ejemplos con Contador y Abogado. O médico y político. O fontanero y secretario. Al final, no hay una respuesta única de "cómo hacer un seguimiento de lo que está haciendo un equipo de profesionales" porque las diferentes profesiones necesitan enfoques diferentes, y por lo tanto no encajan bien en el lugar de trabajo.
Telastyn

Respuestas:

108

Yo hablo con ellos

La tecnología no puede resolver problemas sociales. Tienes paradas cortas por la mañana. ¿Qué hiciste ayer? ¿Qué vas a hacer hoy? Cualquier impedimento?

Si algo suena sospechoso (o tengo curiosidad), me detengo y hago preguntas: "Estuviste trabajando en XYZ ayer, ¿cómo resultó?". Esto obliga a las personas a prestar atención y saber realmente lo que está sucediendo. También te mantiene al frente del equipo (prestando atención y sabiendo realmente lo que está sucediendo). Esto debe ser puntual y corto (10 minutos como máximo ). Cualquier otra cosa y la gente no "dejará de lado" el trabajo. Se detendrán y esperarán el standup y luego se tomarán el tiempo para comenzar de nuevo. Algunos lo harán de todos modos, pero es en gran medida inevitable.

Luego paso por el escritorio de todos por la tarde. No todas las tardes (aunque podría ser más que todas las tardes para personas nuevas), no al mismo tiempo, sino más o menos al mismo tiempo (por lo que es informal y regular). "¿Algún problema? ¿Algún impedimento?"

Te sorprenderá la frecuencia con la que encontrarás problemas cuando las personas son uno a uno.

Si la gente no tiene problemas, genial; volver al trabajo. Si no tienen problemas en toda la semana ? Problema. No los estás desafiando lo suficiente, o no se están abriendo. Pregunte cómo va XYZ (que mencionaron en standup). Haz que expliquen cosas.

Esto no es microgestión. No les estás diciendo cómo hacer su trabajo. No los estás cuidando. Estás allí para eliminar los impedimentos de su día a día. Necesitas información para hacer eso. Siempre y cuando mantenga a su equipo fuera de las reuniones y a los gerentes de proyecto fuera de sus cubos, una persona que lo visite una vez al día no les causará dolor. Pero todas estas interacciones deben provenir de la vena "Estoy aquí para ayudarte".

Otra cosa que haré es revisar los conjuntos de cambios (por mí mismo, de manera informal). Entonces puedo ver con qué frecuencia las personas se registran, qué tan grandes son sus conjuntos de cambios, cómo eso coincide con lo que informaron, con qué frecuencia vuelven a hacer las cosas, cuántas correcciones de errores tienen, etc. Un elemento de trabajo que cambia de estado a "hecho" no tiene sentido. Mira el código ¿Parece hecho?

nota: Un punto secundario extremadamente serio: ¿qué tan grande es su equipo? ¿Son más de 7 personas? Por supuesto, no podrá realizar un seguimiento de todo lo que sucede si su equipo es demasiado grande.

Telastyn
fuente
31
+1 Los equipos que no se comunican no son equipos y no realizan el trabajo.
11
Me gusta esto. "Estás allí para eliminar los impedimentos de su día a día. Necesitas información para hacerlo". Podríamos ser mejores en esto donde trabajo.
Robert Harvey
33
Guau. ¡Revolucionario! ¿Tengo que hablar realmente? ¿O puedo tener una aplicación para eso?
andy256
77
@Snowman: Tu comentario no es más que un falso tópico. He estado en muchos, muchos tipos diferentes de equipos a lo largo de los años y no he visto que tu lugar sea un factor clave para el éxito o el fracaso de ninguno de esos equipos. Algunos equipos han sido extremadamente eficientes y exitosos con la nariz hacia abajo, hazlo, no me molestes gente (en realidad, los equipos más exitosos en los que he estado han sido así). Mientras que otros equipos han sido completamente fracasados ​​con la comunicación hasta el ying-yang.
Dunk
55
RE: "¿Si no tienen problemas en toda la semana? Problema". - También puede ser que no eres la persona adecuada para resolver el problema. Tal vez otro desarrollador, Internet u otra cosa ya está trabajando para eliminar el impedimento.
sixtyfootersdude
143

¡No microgestiones a tus desarrolladores!

El desarrollo de software productivo requiere largos períodos de esfuerzo mental concentrado. No es realista esperar que produzcan resultados constantes. Si comienza a medirlos a diario, reestructurarán su trabajo para que siempre produzcan algunos artefactos discernibles para que los vea todos los días. Eso puede o no tener un impacto positivo en la calidad de su software. Es casi seguro que tendrá un impacto negativo en la eficiencia de sus desarrolladores.

Robert Harvey
fuente
27
¡Desafortunadamente solo tengo un voto a favor para esto! "Si comienzas a medirlos a diario, reestructurarán su trabajo para que siempre produzcan algunos artefactos discernibles para que los veas todos los días": para tareas complejas, incluso un punto de control semanal (sprints de una semana) puede tener esto efecto: terminas trabajando para producir un resultado visible en lugar de enfocarte en resolver los problemas reales.
Giorgio
44
Cuando llega la hora de la verdad, me paso el primer día recogiendo la fruta baja para jugar el juego de los números. ¡Mira cuánto hemos hecho en un día! Ahorro un poco para que otros días pueda eliminar algunos requisitos / comentarios a primera hora de la mañana y luego pasar el resto del día trabajando en las cosas importantes .
66
Uno podría argumentar que el trabajo sin un artefacto discernible no es útil para sus clientes, y por lo tanto para su empresa </ devil's advocate>
Telastyn
14
@Telastyn: Claramente, necesitas artefactos discernibles que sean útiles para tus clientes. El punto es con qué frecuencia usted y su cliente los necesitan. No existe una regla general, pero monitorear el proceso de desarrollo muy de cerca puede perturbar el proceso en sí, ralentizarlo y reducir la calidad de los resultados. Como ejemplo provocativo, cuando caminas, ¿verificas que vas en la dirección correcta después de cada paso?
Giorgio
3
Estoy de acuerdo con el contenido de esto, pero no estoy de acuerdo con que sea una respuesta a la pregunta. Realizo un seguimiento del progreso diario, pero la gestión es un proceso interactivo. Esa interacción normalmente la reservo para el final del sprint. Incluso si gestiona estadísticas de alto nivel, esas estadísticas se realizan mediante la recopilación de puntos de datos individuales. No aparecen mágicamente en mi escritorio.
MSalters
9

Como sugiere Robert Harvey , no administres micro a tu equipo. Dele al equipo algunas tareas priorizadas con un valor comercial concreto y permita que su equipo descubra la mejor manera de entregar este valor comercial.

Si el equipo ofrece valor comercial, entonces debería estar contento. La forma en que se aseguran de que entregan las funciones solicitadas debe depender de ellos.

Sin embargo:

Las tarjetas permanecerán en progreso durante días sin una actualización en el stand-up diario

Esto podría indicar que hay una deficiencia en el proceso.

Podría ser el equipo que realmente no funciona como un equipo, y no interviene para ayudarse mutuamente cuando están atrapados. También podría ser la comunicación con el negocio. Las tareas son demasiado grandes, por lo que se hace difícil determinar qué se necesita. Las especificaciones no son claras.

También podría ser que no hay ningún problema real en absoluto. Tal vez el equipo simplemente funciona bien con tarjetas que representan las principales piezas de trabajo que lleva días completar, y tal vez el equipo está trabajando bien para lograr esto.

Creo que es válido usar la retrospectiva como plataforma para expresar su preocupación. A veces es bueno recibir observaciones del exterior.

Pero deje que el equipo descubra si hay un problema y cuál es la causa de esto. Y esté listo para aceptar que tal vez necesite ajustar la forma en que las tareas se entregan al equipo.

Recuerde que el stand up diario es una herramienta para que el equipo los ayude a organizar el trabajo; NO es una herramienta para que los gerentes hagan un seguimiento de lo que está haciendo el equipo.

Pete
fuente
6

'Mensajes push' no 'mensajes pull'

Un desarrollador a menudo llegará a uno de los siguientes estados que le interesan:

  1. Yaaay, hice X!
  2. Estoy trabajando en X, pero parece que llevará un tiempo prolongado ...
  3. Estoy atrapado en el problema Y, lo estoy investigando pero podría necesitar consejos;
  4. Estoy bloqueado porque estoy esperando a A, B y C.

Idealmente, desea tener una información razonablemente actualizada sobre estos estados sin interrumpir la productividad real. Constante "¿Ya llegamos?" es contraproducente, pero puede ser que usted puede hacer algo útil para los estados 2-4, por lo que necesita estar informados acerca de ellos.

Lo que funcionará es una cultura de 'mensajes push', preferiblemente de forma automatizada. Es posible que no necesite ver todo el registro de confirmación, pero puede hacer un "tablero" donde vea la última confirmación o el último ticket resuelto (para errores o características) de cada miembro del equipo. Para el resto de las situaciones, puede hacer que le envíen un correo electrónico de manera proactiva con dichas actualizaciones (es de esperar que sean más raras que las confirmaciones) o ir y preguntarles si no está viendo un progreso continuo en cualquier tablero, si tiene un acuerdo interno de que debe atascarse debe plantearse (puede ser que alguna característica no sea necesaria si resulta que cuesta 80 horas, no 8 horas), entonces lo mantendrán actualizado o lo molestarán.

Alternativamente, puede hacer una cultura de algo como https://idonethis.com/ informes diarios para todo el equipo, esto asegurará que otros también estén en la misma página.

Pedro es
fuente
1
Intentamos usar idonethis durante aproximadamente 2 meses, no funcionó, porque realmente tenía que tomarse un momento para ir a otro lugar, y solo para actualizar su estado, la mayoría de nosotros olvidamos que existía
Izkata
Ciertamente utilizo nuestros sistemas de seguimiento de problemas y sistemas de gestión de cambios al compilar informes de mitad de año / fin de año sobre lo que he estado haciendo, y utilizamos el "tablero" de Jazz para administrar la actividad como departamentos y en los proyectos en general. Las reuniones de Scrum comunican en qué estamos trabajando en este momento, pero no mantienen un historial detallado. También me ha resultado útil, por mi propio bien, reunir una pequeña herramienta de línea de comandos que me permita lanzar rápidamente una nota de una línea con sello de tiempo para mí; eso es útil para registrar la actividad y los detalles que no son fácilmente visibles a través de los otros sistemas.
keshlam
@Izkata Siento lo mismo por el software de administración del tiempo que estoy usando en mi lugar actual, eventualmente configuré un recordatorio para que se active a las 4 p.m. (para los días que comienzo temprano) y a las 6 p.m. (para los días que comienzo tarde) todos los días para recuérdame actualizar el sistema. Hasta ahora me he olvidado con mucha menos frecuencia para actualizar el sistema. Puede valer la pena considerar si desea continuar utilizando dicho sistema.
scragar
5

Una alternativa a algunas de las otras respuestas (centradas en la comunicación) es que quizás las tareas en sus tarjetas de notas se pueden dividir en partes más pequeñas de las que luego podría obtener comentarios antes.

Con piezas más pequeñas, el equipo siente que está logrando algo todos los días que debería reflejarse en el stand-up.

El inconveniente es que estas cartas separadas probablemente dependerán mucho entre sí. Un equipo que puede comunicarse fácilmente entre sí es beneficioso aquí, o las piezas pueden no combinarse tan bien como deberían. También es posible que deba retener algunas de las tarjetas si necesita hacer ciertas cosas primero.

Dicho esto, las personas se quedarán estancadas o descubrirán que una tarea es mucho más desafiante de lo que ellos o usted anticipan de vez en cuando. Es por eso que sigue siendo útil discutir los problemas abiertamente en el stand-up donde otros pueden ofrecer consejos sin juzgar a la persona que tiene problemas.

Para responder al tema de la microgestión, como han surgido algunas de las otras respuestas: a pesar de que las personas realizarán pequeñas tareas cada día, se necesitará una visión más amplia de su trabajo realizado para tener una idea de cuánto está haciendo cada persona, en lugar de juzgarlos por sus logros diarios.

Sugiero esto porque trabajo en un equipo de 8, donde la comunicación es muy fácil y la gente es muy accesible. Se nos asignan tareas que nunca se espera que lleven más de dos días de trabajo. A veces, estas tareas están estrechamente relacionadas y debemos mantenernos actualizados sobre cómo hacemos cada uno nuestra propia pieza. Todos somos responsables de informar a nuestro gerente lo que hemos logrado cada dos semanas.


Después de leer la pregunta nuevamente, me doy cuenta de que es posible que se lo pregunte como miembro del equipo, no como líder, por lo que es posible que no tenga control sobre sus tareas.

  1. Podría sugerirle a su líder que rompa más las tareas
  2. Si su trabajo se está bloqueando o depende del trabajo de otro miembro del equipo, no dude en consultarlo y tomar una tarea diferente si es necesario.
Doble doble
fuente
1
Romper las cosas en una jerarquía de piezas más pequeñas y rastrear las dependencias entre ellas es una de las cosas en las que Jazz / RTC es bueno.
keshlam
3

En primer lugar, debe analizarse en términos de su tiempo y habilidades. Si usted es una persona técnica con alguna experiencia práctica previa, las cosas pueden ser diferentes a las de si es solo un gerente (no con un sólido conocimiento técnico sobre en qué están trabajando realmente sus desarrolladores) que solo necesita asegurarse de que se cumplan los plazos .

El punto común en ambos casos es que necesita poder facilitar a su equipo y crear la sensación de que confía en ellos. No está juzgando su desempeño, pero está tratando de ser empático y útil para hacer que su experiencia sea divertida y fácil.

Ahora suponga que usted es solo un gerente, como dije anteriormente, en ese caso, incluso si algún desarrollador realmente se enfrenta a un problema grave relacionado con el desarrollo, es posible que no pueda ayudarlo. El problema real puede llevar mucho tiempo y también requerirá concentración. Suponiendo además que el desarrollador es realmente sincero con su trabajo y que paga tiempo completo (incluso tiempo extra) para resolver ese problema, pero desafortunadamente todavía no puede resolverlo. Y en tal situación (cuando ni siquiera es capaz de comprender el problema por completo), sigue preguntando sobre el tema progresando todos los días e incluso de manera informal dos veces al día. El resultado sería extrema frustración y molestias para el desarrollador. Ya sea que se trate de una aplicación para recopilar el progreso diario o simplemente una reunión de pie diaria, ambos pueden ser frustrantes.

Por otro lado, manteniendo todos los demás factores iguales, solo asuma que tiene una sólida formación técnica y que ha trabajado en las mismas tecnologías en el pasado. En este caso, tomar el progreso diario o tener reuniones de pie es realmente útil. Los desarrolladores seguramente confiarán en usted y en su experiencia y se sentirán cómodos al discutir el gran desafío que enfrentan. Proporcionará algunas sugerencias que pueden ser útiles o incluso si no son directamente útiles, ayudarán a proporcionar algunos enfoques alternativos.

Sin embargo, en cualquier caso, las reuniones diarias de pie deben crear una sensación de que eres un miembro del equipo, no un jefe / líder / gerente. A menos que los miembros de su equipo lo consideren al mismo nivel que ellos, no podrán comunicar sus inquietudes / sugerencias / problemas / comentarios, etc.
Otro punto a tener en cuentaes el tamaño de su equipo y el tiempo que tiene para administrarlos, antes de pensar en utilizar un software de seguimiento de progreso automatizado o aumentar su interacción Debe asegurarse de que cualquier inquietud que haya planteado su equipo pueda resolverla lo antes posible. Un factor desmotivador importante para un miembro del equipo es que sus preocupaciones / sugerencias / comentarios no se toman en serio o no se valoran. Conocer el progreso diario es importante, pero solo en caso de que esté completamente involucrado en el trabajo en equipo. Si también participa en algunos negocios paralelos, no intente interactuar más con su equipo. Piense en una situación en la que la respuesta de su equipo es abrumadora y están enviando sus tareas mucho antes de tiempo, generando inquietudes y consultas, pero no puede proporcionar comentarios y revisiones oportunas. En tal situación,

arj
fuente
2

Cree y haga buen uso de varias salas de chat de mensajería instantánea para las diversas configuraciones. Algunos pueden ser amplios como @engineers y otros pueden ser específicos como @newFeatureA

Considere hacer una parada diaria que incluya una revisión de los boletos en vuelo.

Utilice un entorno abierto que admita la colaboración y asegúrese de que QE y el propietario del producto principal se sientan en el medio de los desarrolladores. Escucharás mucho y tendrás una idea al ver pantallas a tu alrededor.

Como señala Robert, sobre todo no se considera microgestión (tenga en cuenta el uso de 'ser visto', es decir, independientemente de su intención real).

Finalmente, rastreamos lo que se logra con el tiempo y vemos cuál es nuestra velocidad a partir de eso. Centrarse en el progreso durante el día es contraproducente ya que las personas se desmoralizarán y / o se irán.

Michael Durrant
fuente
2

Me sorprende que nadie aquí haya mencionado aún los mensajes de repositorio "seguidos" o "destacados" integrados en sistemas como GitHub o BitBucket.

Todos nuestros grupos de interés técnicos (líderes de proyectos, gerentes de desarrollo y soporte) siguen nuestro problema y envían historiales de actualización en sus proyectos relevantes. Tenemos un equipo pequeño (15 contratistas FTE +), pero esto parece funcionar para nosotros.

Nadie se mide en ninguna de estas cosas, pero además de los informes de estado semanales de los PM, esto brinda una visión diaria del proyecto para al menos mantener a todos al tanto de las áreas en las que se está trabajando para que nadie se quede sin visibilidad.

También ha ayudado a aumentar la transparencia entre los desarrolladores y contratistas y nuestros enlaces comerciales, lo que ayuda a todos a ser responsables de sus calendarios de entrega.

Cuando se combina con fuentes RSS asociadas con repositorios específicos o en toda nuestra organización, hemos podido limitar los correos electrónicos (donde se desea) y ofrecer un conjunto similar de datos en tiempo real y en resumen a través de lectores RSS. Para algunos usuarios, esto es Outlook, por lo que es básicamente un correo electrónico para ellos, aunque ligeramente diferente, pero para otros usuarios usan un cliente RSS completo con todo el filtrado adicional que necesitan para personalizarlo según sus necesidades exactas.

Al principio nos encontramos con preocupaciones similares sobre el volumen del correo electrónico, pero a nuestros usuarios finales se les ocurrió el sistema RSS sin que Engineering Org tuviera que hacer mucho más que sugerir clientes para aquellos que no usan Outlook. Trabajó para nosotros, nuevamente entre 20 y 30 contratistas FTE + durante todo el año en varias oficinas y zonas horarias. YMMV, obviamente.

Bryan 'BJ' Hoffpauir Jr.
fuente
44
El OP señala que siguen los resúmenes de github y es abrumador. En mi experiencia, es una visión muy superficial de las cosas, lo que da una falsa sensación de seguridad.
Telastyn
2
Eso es lo suficientemente cierto si sigues toda la actividad en GitHub. Para ser honesto, utilizamos BitBucket para nuestra empresa y parece ofrecer un control detallado sobre el nivel de actualizaciones por correo electrónico para nuestros equipos pequeños. ¿No está seguro de si GitHub ofrece el mismo nivel de granularidad, tal vez alguien podría compararlo con BitBucket si ha utilizado ambos para ayudar a calificar la configuración y los tamaños de equipo que lo hacen un buen ajuste? ¿Seguir solo emitir actualizaciones en GitHub realmente generaría demasiada actividad? No parece que en BitBucket ... y eso es suficiente para nuestros PM y Leads
Bryan 'BJ' Hoffpauir Jr.
Comentario agregado sobre desarrollos recientes sobre el uso de clientes RSS (o incluso Outlook en algunos casos) para reducir el volumen de correo electrónico y permitir a los usuarios auto-filtrar sus datos, pero aún así mantenerlos como "en tiempo real" y como resumen / final del día / final de semana como quieran. Parece funcionar bien para aquellos que no quieren que se agregue una avalancha constante de correo electrónico a sus bandejas de entrada existentes ...
Bryan 'BJ' Hoffpauir Jr.
0

Esta es una adición muy marginal (y no es específica del programador), pero he tenido un gran éxito con Asana en proyectos recientes.

Para la integración con las herramientas de colaboración en línea existentes, no busque más que Slack . Está construido alrededor de una sala de chat, pero sirve como un centro bastante minimalista para otras herramientas, incluidas Asana, GitHub y Bitbucket. Tiene una buena colección de estos "integraciones", tanto pre-hecha y hecha en la comunidad , utilizando la API que por supuesto le permite construir su propio.

Shadowtalker
fuente
Me gustaría saber por qué esto fue rechazado. Entiendo que la pregunta se refiere a "estrategias" en lugar de "herramientas", pero ¿no es "usar una buena herramienta" en sí misma una estrategia viable?
shadowtalker
ver cómo responder . "Lea la pregunta detenidamente. ¿Qué es, específicamente, la pregunta que pide? Asegúrese de que su respuesta proporcione eso, o una alternativa viable ... La brevedad es aceptable, pero las explicaciones más completas son mejores ..."
mosquito
Vine aquí para sugerir usar Slack . Es una excelente herramienta para realizar un seguimiento de lo que el equipo está haciendo día a día . Que, por cierto, es exactamente la pregunta. Pero después de mirar esta respuesta y los comentarios, tal vez simplemente no entiendo cómo funciona programmers.stackexchange.com (aunque tengo muchos puntos de reputación en otros sitios).
Denilson Sá Maia
@gnat, ¿qué más hubieras querido de esta respuesta? No veo mucho aquí que admita una explicación "más completa"
shadowtalker