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"?
fuente
Respuestas:
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.
fuente
¡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.
fuente
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:
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.
fuente
'Mensajes push' no 'mensajes pull'
Un desarrollador a menudo llegará a uno de los siguientes estados que le interesan:
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.
fuente
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.
fuente
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,
fuente
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.
fuente
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.
fuente
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.
fuente