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

Hablo con ellos.

La tecnología no puede resolver problemas sociales. Tienes cortos de pie por la mañana. ¿Qué hiciste ayer? ¿Qué vas a hacer hoy? ¿Algún impedimento?

Si algo suena sospechoso (o tengo curiosidad), me detengo y hago preguntas: "Estabas trabajando en XYZ ayer, ¿cómo resultó eso?". Esto obliga a las personas a prestar atención y saber realmente qué está pasando. También le mantiene al líder del equipo en el bucle (y prestar atención y saber realmente lo que está pasando). Este necesita ser puntual y breve (10 minutos max ). Cualquier otra cosa y la gente no "dejará de funcionar" el trabajo. Se detendrán y esperarán el standup y luego tomarán tiempo para comenzar de nuevo. Algunos lo harán de todos modos, pero es en gran parte inevitable.

Luego paso por el escritorio de todos en la tarde. No todas las tardes (aunque puede ser más que todas las tardes para personas nuevas), no a la misma hora, sino más o menos a la misma hora (por lo que es tanto informal como regular). "¿Algún problema? ¿Algún impedimento?"

Se sorprenderá de la frecuencia con la que encontrará problemas cuando las personas son una en una.

Si la gente no tiene problemas, genial; volver al trabajo. Si no tienen problemas 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 el standup). Haz que expliquen las cosas.

Esto no es microgestión. No les estás diciendo cómo hacer su trabajo. No los estás cuidando. Estás ahí para eliminar los impedimentos de su vida cotidiana. Necesitas información para hacer eso. Mientras mantengas a tu equipo fuera de las reuniones y a los gerentes de proyecto fuera de sus cubos, entonces una persona que venga para ayudar 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 mi cuenta, informalmente). Luego puedo ver con qué frecuencia las personas se registran, qué tan grandes son sus conjuntos de cambios, cómo concuerda con lo que informaron, con qué frecuencia vuelven a hacer las cosas, cuántas correcciones de errores tienen, y así sucesivamente. Un elemento de trabajo que cambia el estado a "hecho" casi no tiene sentido. Mira el código. ¿Parece hecho?

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

¡No administres micro-administradores 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 comienzas a medirlos diariamente, ellos reestructurarán su trabajo para que siempre produzcan algunos artefactos discernibles para que los veas cada día. 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.

Como sugiere Robert Harvey , no administre microcréditos a su equipo. Dele al equipo algunas tareas prioritarias con valor comercial concreto y deje que su equipo descubra mejor cómo entregar este valor comercial.

Si el equipo entrega valor comercial, entonces debería estar contento. La forma en que se aseguren de que entreguen las funciones solicitadas debe estar a su disposición.

Sin embargo:

  

    

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

  

Este 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 la empresa. Las tareas son demasiado grandes, por lo que resulta difícil averiguar qué se necesita. Las especificaciones no son claras.

También podría ser que no haya ningún problema real en absoluto. Tal vez el equipo simplemente funciona bien con tarjetas que representan trabajos importantes que demoran días en completarse, y quizás el equipo esté trabajando bien para lograrlo.

Creo que es válido utilizar la retrospectiva como una 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 prepárese para aceptar que quizás necesite ajustar la forma en que las tareas se entregan al equipo.

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

'Mensajería push' no 'mensajería 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 tomará un tiempo prolongado ...
3. Estoy atascado en el problema Y, lo estoy investigando, pero es posible que necesite un consejo;
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 pueda hacer algo útil para los estados 2-4, por lo que necesita informarse sobre ellos.

Lo que funcionará es una cultura de 'envío de mensajes', preferiblemente de forma automatizada. Es posible que no necesite consultar el registro de confirmación completo, pero puede hacer un "panel" donde vea la confirmación más reciente o el último boleto resuelto (para errores o características) de cada miembro del equipo. Para el resto de las situaciones, puede enviarlos por correo electrónico de forma proactiva con dichas actualizaciones (con suerte son más raras que las confirmaciones) o preguntarles si no ve un progreso continuo en el panel de control, si tiene una El acuerdo interno de que es necesario 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 al día o lo molestarán.

Como alternativa, puede crear una cultura de algo así como los enlace que se envían a todo el equipo, lo que garantizará que otros estén en el la misma página también.

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

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

El inconveniente es que estas tarjetas separadas probablemente dependan mucho una de la otra. Un equipo que es capaz de comunicarse muy fácilmente entre sí es beneficioso aquí, o las piezas pueden no combinarse tan bien como deberían. Es posible que también deba retener algunas de las tarjetas si necesita hacer ciertas cosas primero.

Dicho esto, las personas todavía se quedarán bloqueadas o descubrirán que una tarea es mucho más difícil de lo que ellos, o usted, anticiparon de vez en cuando. Es por esto que todavía es ú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 problema de la microgestión como algunas de las otras respuestas han surgido: a pesar de que las personas realizarán pequeñas tareas cada día, tendrán una visión más amplia de su trabajo realizado para obtener una perciba cuánto está realmente haciendo cada persona, en lugar de juzgarlos por sus logros diarios.

Sugiero esto porque trabajo en un equipo de 8 personas, donde la comunicación es muy fácil y la gente es muy accesible. Nos asignan tareas que nunca se espera que tomen más de dos días de trabajo. A veces, estas tareas están estrechamente relacionadas y debemos mantenernos actualizados sobre cómo cada uno de nosotros hace su propio trabajo. Cada uno de nosotros es responsable de informar lo que hemos logrado cada dos semanas a nuestro gerente.

Después de leer la pregunta otra vez, me doy cuenta de que puedes preguntarte esto como miembro del equipo, no como líder, por lo que es posible que no tengas control sobre tus tareas.

1. Puede sugerir a su líder que divida las tareas más
2. Si su trabajo se está bloqueando o depende del trabajo de otro miembro del equipo, siéntase libre de verificarlo y tome una tarea diferente si lo necesita.

Primero que todo, necesitas analizarte a ti mismo en términos de tu tiempo y habilidades. Si usted es un técnico con experiencia previa, las cosas pueden ser diferentes a las que usted tiene en caso de ser solo un administrador (no con un conocimiento técnico sólido sobre lo que son sus desarrolladores trabajando realmente en) quien 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 fácil y divertida.

Ahora suponga que usted es solo un administrador, como dije anteriormente, en ese caso, incluso si algún desarrollador se enfrenta realmente a algún problema serio relacionado con el desarrollo, es posible que no pueda ayudarlo. El problema real puede llevar mucho tiempo y también exigirá concentración. Además, suponiendo que el desarrollador es realmente sincero con su trabajo y paga tiempo completo (incluso tiempo adicional) para resolver ese problema, pero lamentablemente todavía no puede resolverlo. Y en tal situación (cuando ni siquiera eres capaz de entender completamente el problema) sigues preguntando sobre el problema progresando todos los días e incluso informalmente dos veces al día. El resultado sería una frustración extrema y una perturbación para el desarrollador. Ya sea que se trate de una aplicación para reunir el progreso diario o de una simple reunión diaria, puede ser frustrante.

Por otra parte, manteniendo todos los demás factores iguales, solo asuma que tiene una sólida formación técnica y 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 de pie diarias deben crear la sensación de que usted es 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 considerar es el tamaño de su equipo y el tiempo que tiene para gestionarlos, antes de pensar en utilizar algún software de seguimiento de progreso automatizado o aumentar su interacción. Debe asegurarse de que las inquietudes que haya planteado su equipo sean capaces de resolverlas lo antes posible. Un factor desmotivador importante para un miembro del equipo es que sus inquietudes / 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 está involucrado en algunos negocios secundarios, 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, lo que genera inquietudes y consultas, pero no puede proporcionar comentarios y revisiones oportunas. En tal situación, su influencia como líder del equipo se reducirá en gran medida

Cree y haga buen uso de varias salas de chat IM para las distintas configuraciones. Algunos pueden ser amplios como @engineers y otros pueden ser específicos como @newFeatureA

Considere realizar un standup diario que incluya una revisión de los boletos en vuelo.

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

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

En última instancia, hacemos un seguimiento de 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 abandonarán.

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

Nuestras partes interesadas técnicas (líderes de proyectos, gerentes de desarrollo y soporte) siguen nuestro problema y se comprometen a actualizar las historias de 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 da una visión diaria del proyecto para al menos mantener a todos informados sobre 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 programas de entregables.

Cuando se combinan con las fuentes RSS asociadas con repositorios específicos o en toda nuestra organización, hemos podido limitar los correos electrónicos (donde se desee) 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 un poco diferente, pero para otros usuarios utilizan un cliente RSS con todos los filtros adicionales que necesitan para personalizarlo según sus necesidades exactas.

Al principio nos topamos con inquietudes similares sobre el volumen de correo electrónico, pero a nuestros usuarios finales se les ocurrió el sistema RSS sin que la Organización de Ingeniería tuviera que hacer mucho, además de sugerir clientes para aquellos que no utilizan Outlook. Trabajó para nosotros, nuevamente alrededor de 20-30 contratistas FTE + durante todo el año en varias oficinas y zonas horarias. YMMV, obviamente.

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

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 como Asana, GitHub y Bitbucket. Tiene una colección decente de estas "integraciones", tanto pre-made como community-made , utilizando la API que, por supuesto, te permite crear la tuya.