Soy un desarrollador de software. Cuando mi equipo se reúne para nuestras reuniones diarias, nuestros analistas de negocios/gerentes de proyectos también asisten a la reunión para medir el progreso del equipo. 9 de cada 10 veces, esto funciona perfectamente bien.
Sin embargo, las últimas dos semanas he estado trabajando en una tarea particularmente difícil. En repetidas ocasiones he pensado, de buena fe, que estaba dentro de un par de días de haberlo completado. Pero cada vez que entraba en mi prueba "final" para el proyecto, aparecía un obstáculo inesperado y agregaba varios días más. Hablé con mi jefe experto en desarrollo al respecto, y está de acuerdo en que he estado haciendo un buen trabajo en el proyecto, es solo uno de esos momentos en los que hemos tenido mala suerte.
Estoy nervioso por cómo se ve esto cuando doy mis actualizaciones durante los standups. Durante el último par de semanas, he brindado actualizaciones entusiastas diciendo que casi he terminado con mi proyecto, solo para aparecer en la próxima reunión diciendo que surgió algo y que necesitaré más tiempo. Comunicar los detalles de lo que está sucediendo es útil para los desarrolladores de mi equipo, pero esto no puede verse bien para los gerentes de proyecto. Tampoco es la primera vez que me encuentro en esta situación. Estoy nervioso de que podría estar desarrollando una reputación de poco confiable.
¿Cuál es la mejor manera de comunicar mi progreso en situaciones como estas, donde una tarea repetidamente me toma más tiempo de lo esperado por razones que no podrían haberse previsto? Mis objetivos son ser honesto con los gerentes de proyecto, pero también brindarles información que les sea útil en lugar de hacerles perder el tiempo con detalles demasiado técnicos y evitar presentarme de una manera que parezca escamosa.
Siento que la raíz del problema a menudo es romper el mismo compromiso varias veces seguidas. Casi todo el mundo sabe que casi todos los desarrolladores están haciendo todo lo posible, por lo que es parte del desarrollo ser bloqueado, pero escuchar a alguien en el diario decir que una tarea específica se completará mañana y luego escuchar a la misma persona repitiendo lo mismo al día siguiente. la tarea específica se completará mañana y no hacer que suceda está arruinando la credibilidad de esta persona y enfatiza el fracaso.
En nuestros equipos, cuando las personas enfrentan impedimentos, generalmente los alentamos a compartir pequeñas victorias o lo que aprendieron el día anterior para compartir y sentir una progresión y enfatizar en adquirir nuevos conocimientos.
Ejemplo:
Ayer me enfrenté a este impedimento relacionado con este tema técnico.
Aprendo eso, eso y aquello.
Hoy continuaré implementando esta función.
Estamos tratando de no comprometernos a tiempo simplemente declarando el hecho: "Estoy trabajando en esta función" en lugar de "Esta tarea se realizará mañana".
Esto también te convierte en un referente de este tema técnico. Tan pronto como otra persona se encuentra con el mismo impedimento, existe una alta probabilidad de que acuda a ti.
Además, quien tenga el rol principal advertirá al propietario del producto que existe la posibilidad de que no se completen todas las tareas durante el sprint actual, por lo que es posible que deban priorizarse nuevamente.
El propósito de las reuniones de pie (de un libro de texto de desarrollo de software ágil) es ayudar al equipo a comunicarse mejor. Los gerentes en la sala pueden obstaculizar la comunicación abierta solo porque alguien puede tener miedo de discutir los problemas y quizás sus propias deficiencias abiertamente.
Una solución a esto es separar los informes para la gerencia y las reuniones del equipo. Suponiendo que está utilizando sprints, involucre a los gerentes en la planificación de sprints y en la revisión de los resultados de los sprints. Lo que sucede dentro del sprint se queda con el equipo.
De esta forma, obtiene algo de margen para las tareas que toman más tiempo de lo esperado y no tiene que dar explicaciones todos los días. Si una tarea no cabe en un sprint, tal vez debería dividirse. Si los impedimentos vienen de arriba, la revisión del sprint es un buen momento para escalar el problema.
Si está desarrollando una reputación como "poco confiable", es probable que no se base en el hecho de que siguen apareciendo obstáculos (ya que todos los desarrolladores saben que esto ocurre), sino que está haciendo un trabajo muy pobre al tenerlos en cuenta. su estimación de dificultad o compleción, especialmente en esta tarea en particular que ha demostrado ser difícil de estimar.
No menciona la experiencia que tiene, pero parte del proceso de maduración de un desarrollador implica desarrollar una idea de qué proyectos o tareas tienen muchos riesgos conocidos y desconocidos, y desarrollar estrategias para mitigarlos. Por supuesto, es posible que se equivoque, pero si lo hace repetidamente, su equipo podría comenzar a pensar que usted es "poco confiable" en su capacidad para estimar la dificultad de un proyecto.
Este proyecto ya ha ilustrado que su estimador difícil está desafinado; La próxima vez que se le pida que proporcione una estimación de este tipo, tómese un poco de tiempo para pensar realmente dónde podrían estar los "trampas" e intente idear algunas estrategias para obtener una mejor estimación del trabajo por delante.
Estas reuniones son para decir lo que hiciste ayer y lo que vas a intentar hoy. Así que hazlo, incluso si el resultado neto no fue nada. Hable con tantos detalles como pueda sin descarrilar los límites de tiempo de la reunión, por ejemplo:
No pude hacer que los datos se cargaran correctamente, desarmé la biblioteca de subprocesos, encontré un error en ella, desafortunadamente eso no ayudó. También trabajé con Sam, ya que tocó este código hace unas semanas. No llegué a ninguna parte. También intenté reescribir la función de lectura de socket, aún no solucionó la corrupción.
Hoy creo que mi siguiente mejor suposición es agregar controles de depuración más fuertes para la biblioteca de serialización y ver si eso ayuda.
No prometes nada, tus compañeros y tu jefe empiezan a entender que en realidad estás haciendo mucho, y se dan cuenta de la dificultad, y encuentro que un pequeño detalle puede despertar algo en tus compañeros de trabajo.
Además, planteé este punto exacto en mis revisiones de desempeño: "Me siento mal si no tengo nada que mostrar dentro de un día hábil de mi último standup". Algunos de nosotros argumentamos que es un obstáculo para la I+D, que tenemos demasiado miedo de ir y pasar unos días investigando soluciones listas para usar para un problema, la gerencia escuchó y las reuniones de pie se trasladaron a dos veces por semana. .
En primer lugar, las estimaciones de cuánto trabajo llevará completar una historia son solo eso: estimaciones . Siempre existe cierto nivel de riesgo de que la estimación sea incorrecta y requerirá más trabajo.
Las estimaciones se basan tanto en el estado actual del código (como mejor lo conoce su equipo) y el conocimiento del equipo sobre cómo implementar la historia. (Esta es la razón por la cual la misma historia puede tener diferentes estimaciones de una iteración a otra: en una iteración posterior, es posible que tenga un nuevo código en el código base o conozca una nueva técnica o biblioteca que podría usarse para reducir el trabajo de implementación).
En este caso particular, parece que el equipo carecía de conocimiento sobre la historia en la que está trabajando y, al no saber sobre algunos problemas que podrían surgir, estimó mal (en retrospectiva) la historia.
Para evitar la apariencia de ser escamoso, al dar el estado de una historia en la que está trabajando, no solo quiere explicar que la estimación fue incorrecta, sino también mostrar que está haciendo una gestión de riesgos, ahora y para el trabajo futuro. Entonces, cuando se encuentre con un problema que aumente la cantidad de trabajo que necesita hacer, analice un poco para descubrir por qué la estimación fue incorrecta, qué impacto debería tener este nuevo conocimiento en su estimación actual para esta y otras historias, y qué técnicas se deben utilizar para mitigar este riesgo.
Como ejemplo, si los problemas con los que se encuentra se deben a que una biblioteca que está utilizando tiene errores, podría decir:
Esta historia ahora ha excedido su estimación varias veces debido a errores en la biblioteca X que descubrí solo al final del proceso de implementación. Parece claro que la biblioteca X no es muy confiable y, a la luz de esto, deberíamos revisar cualquier estimación de las cosas que dependen de ella. Además, estoy abordando esto ahora escribiendo algunas pruebas de unidades básicas para mostrar el comportamiento real de las API que uso en X, probablemente sería una buena idea hacer lo mismo para otras historias que dependen de X, y probablemente deberíamos considerar las estimaciones de las historias que se basan en X son bastante inexactas hasta que se escriben las pruebas que confirman el comportamiento necesario de X.
Esto muestra que, aunque hubo problemas imprevistos, está tomando medidas no solo para abordarlos ahora, sino también para asegurarse de que los riesgos recién descubiertos que ha encontrado se manejen mejor en el futuro.
Una cosa más sobre las reuniones de pie: no son solo para dar estado, sino también para compartir información (como los problemas con la biblioteca X arriba) y solicitar y ofrecer ayuda. Vale la pena decir, cuando tenga problemas: "Si alguien aquí tiene alguna idea sobre cómo manejar esto mejor, comuníquese conmigo después de la reunión para que podamos discutir los detalles". (Esto es especialmente cierto si no está satisfecho con sus técnicas de mitigación; puede ser difícil pensar en buenas y otros en el grupo pueden tener buenos consejos al respecto, o incluso estar dispuestos a trabajar en ello).
Estoy nervioso por cómo se ve esto cuando doy mis actualizaciones durante los standups.
no seas Las reuniones de pie no son evaluaciones de desempeño. Están destinados a transmitir estatus.
¿Cuál es la mejor manera de comunicar mi progreso en situaciones como estas, donde una tarea repetidamente me toma más tiempo de lo esperado por razones que no podrían haberse previsto? Mis objetivos son ser honesto con los gerentes de proyecto, pero también brindarles información que les sea útil en lugar de hacerles perder el tiempo con detalles demasiado técnicos y evitar presentarme de una manera que parezca escamosa.
Simplemente transmite brevemente el estado de una manera que sea comprensible para todos.
Si alguien pregunta o quiere más detalles, lo invita a una reunión de seguimiento donde puede profundizar en los motivos según sea necesario. De esa manera, no perderás el tiempo de todos.
erik
Kevin