Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Plazos, cambios en requerimientos y equipos ágiles ¡Dios mío!

Escrito por Sarah McCasland y traducido por Victoria Ubaldo para Code Like a Girl. Encuentra la versión original del artículo en inglés aquí.

No hay muchas garantías en la vida, pero el cambio es definitivamente lo único que está garantizado. Por lo tanto, no es ninguna sorpresa que mientras se construyen productos los requerimientos regularmente cambien. Bien sea que los cambios se basen en nuevos descubrimientos de los usuarios o del mercado, opiniones de los líderes de producto y los grupos de interés, o debido a algo totalmente diferente, la mayoría de los proyectos van a requerir cambios frente al “plan” original.

Re-prioriza regularmente

Cuando los proyectos son gestionados usando los principios ágiles, los cambios pueden incorporarse más fácilmente. Cuanto antes en el proceso nos demos cuenta de los cambios que están llegando, mejor podremos prepararnos. Todo lo contrario al método cascada, en el cuál se crea un documento de especificaciones gigante todos los requerimientos deben estar aceptados antes de que el proyecto inicie. Las metodologías ágiles se centran en trabajar en las prioridades más altas en primer lugar y ajustarlas iterativamente. Estas prioridades se establecen con el líder de producto y los grupos de interés y ayudan a determinar de antemano un mínimo producto viable (MVP por sus siglas en inglés). Independiente de si estás usando vanilla agile, scrum, lean, kanban, etc., la metodología escogida determina las características de mayor prioridad antes de que cada ciclo de trabajo inicie.

Fija de manera inteligente metas del producto y fechas

Lo anterior no significa que no haya un plan pensado para el producto. Un líder de producto debería crear una hoja de ruta e incluso podría tener un plan de lanzamiento con fechas tentativas basadas en estimaciones de alto nivel de desarrolladores, diseñadores y QA. Todo esto suena muy bien, pero como muchos de nosotros sabemos: las personas de negocio aman las fechas. Y tienen sus razones, pues es necesario entender qué valor se está comprando con el costo que están invirtiendo en la construcción del producto. Las fechas ayudan a entender cuando algo será enviado. Además, muchas veces otros departamentos tendrán que estar involucrados, como mercadeo o ventas, así que tener una línea de tiempo es esencial.

Donde tendemos a ver problemas es cuando las fechas son determinadas por las personas equivocadas. La elección de fechas basadas en las demandas de los clientes, por ejemplo, es un hábito peligroso para entrar. Especialmente cuando las fechas, o los plazos, se determinan sin ser evaluadas desde el lado técnico o de producto. Muchas veces, cuando se establecen fechas poco realistas, el equipo de entrega fallará . La frase “nueve mujeres no pueden tener un bebé en un mes” viene a la mente. No importa cuán grande sea el equipo técnicamente, cuántas horas extras están dispuestos a invertir y cuán maravillosamente se está manejando el proyecto, algunas fechas no son factibles.

Determina lo qué sí se puede hacer

Dicho esto, no sugiero que digas simplemente “no” a una fecha. En su lugar, determina qué se puede entregar en la fecha deseada. ¿Hay características que pueden esperar a una inmediata fase 2? Suponiendo que la segunda fase ocurra;). ¿Se pueden cambiar las prioridades de una manera que haga que el desarrollo sea más rápido? ¿Pueden acortarse las iteraciones, de modo que las características se pueden entregar más rápidamente?

Hay muchas más cosas en un proyecto, producto y proceso que el equipo puede analizar para ver cómo y a qué puede “sí”

Cuando la prioridad de las características cambian dentro de un proyecto, las metodologías ágiles permiten un ajuste rápido. El mayor desafío es cuando se agregan nuevas características y se convierten en prioridad. Nuevas características son malos elementos. Pero hay que sopesarlas con las prioridades actuales. La eliminación de las funciones de menor prioridad ayudará a equilibrar el alcance. A partir de ahí, las líneas de tiempo, presupuestos y el estrés correspondiente deben ser modificados, comunicados y acordados. Comprometerse a fechas difíciles por adelantado enlaza tus manos a una fecha y no a un conjunto de características. Aunque más personas se puedan agregar al equipo, y el equipo pueda trabajar horas extras (que también es una solución horrible a largo plazo con efectos secundarios duraderos), muchas veces no será suficiente. Además, todos los requisitos y cambios adicionales no se crean iguales. La mejor manera de entender los impactos es trabajar directamente con el equipo del producto; quienes pueden explicar mejor los riesgos y los obstáculos.

Mantén las necesidades de los clientes por delante de las tuyas

Cuando se determine que las nuevas características son de mayor prioridad, el líder de producto y los grupos de interés deben acordar cuáles características ya no se incluirán en el lanzamiento inicial. Esta es una conversación difícil, ya que muchas veces, el equipo ya ha determinado las características requeridas para el mínimo producto viable. Para decepción del equipo de desarrollo, algunas características del producto superarán las características técnicas “agradables de tener”, y serán movidas a una fase dos. Por último, el cliente / usuario final debe mantenerse al frente y centro, y cualquier cosa que impacte su adopción debe ser una meta clave del MVP.

En conclusión, lo mejor es aceptar los cambios a medida que se introducen. Para ayudar a que esto suceda sin problemas, la comunicación es clave. Las nuevas características deben ser examinadas con relación a las características actuales para ver qué se puede empujar para la fase dos, especialmente cuando hay plazos. Una vez que se hayan acordado estos cambios, es muy importante asegurarse de que todos los equipos entiendan la nueva dirección que el líder de producto ha comprometido. Para ayudar a aliviar la lentitud que se pueda generar, es mejor tener toda la ayuda del equipo del producto para establecer fechas, de modo que sean más realistas sin tener que cambiar el presupuesto, el alcance (con la excepción de las prioridades de cambio) o el tamaño del equipo.

Si te gusto este artículo, compártelo con alguien a quién creas que puede ser útil