¿A quién estás tratando de impresionar con tus plazos?

Sugerencia: obviamente no son sus usuarios.

Levante la mano a aquellos cuya empresa ha proclamado la "Orientación al cliente" como uno de sus valores corporativos. Para aquellos de ustedes que leen este texto en Habré y no ven a la audiencia: casi toda la sala levantó una mano, excepto por un par de personas detrás.

Ellos trabajan en Oracle.

La satisfacción del cliente es uno de los valores corporativos de Oracle. Pero los valores corporativos, son como una membresía en un gimnasio, no son suficientes para tenerlos.

La obsesión del cliente es algo útil, pero hay una cosa más con la que muchas empresas están obsesionadas es el tiempo. Los plazos son buenos. "Estará listo cuando termine" puede ser una estrategia excelente (o incluso recomendada) para dos personas que trabajan en la misma aplicación. Pero cuando trabaja en una empresa con más de doscientos empleados, necesita comprender qué está sucediendo; Una idea aproximada de cuándo sus usuarios podrán utilizar sus nuevos silbatos y pedos.

Me atrevo a decir que los plazos establecidos son plazos incorrectos, y si su empresa los tiene, probablemente debería ir aún más lejos y eliminar el elemento de "enfoque al cliente" de la lista de valores corporativos. Porque, lo creas o no, a los usuarios no les importan los sprints llenos de basura.

Los plazos no los necesitan principalmente los clientes, sino la administración.

El objetivo principal es el objetivo

O por qué congelar los requisitos de sprint es una práctica terrible

El tiempo es bueno, crean un sentido de urgencia, aseguran la previsibilidad de sus procesos y, por lo tanto, debe tenerlos.

Pero hay buenos y malos términos. Y hay empresas en las que los plazos se establecen en piedra, y aquellos que cumplen los plazos a un paso del despido. Y entonces comienzan los problemas.

Me refiero a una cultura de desarrollo en la que se acostumbra congelar los objetivos durante el sprint: cuando todos se reúnen al principio, evalúan las tareas, sin duda utilizando solo los números de Fibonacci, y lo que se decida en estas reuniones, todo esto debe hacerse antes de completarse sprint: nada cambia y no se tolera. En teoría, esto suena increíble, pero creo que esa táctica está perdiendo en cualquier escenario:

Situación A. Suponga que un desarrollador supera la ley de Parkinson y cierra las tareas por adelantado. En este caso, el desarrollador no informa esto en la mañana siguiente, porque bueno, no puede decir que no tiene nada que hacer. O su gerente le asigna más tareas al congelar el sprint, porque bueno, no puede tener un desarrollador que no haga nada .

Situación B. El desarrollador, siendo un desarrollador, está retrasado. Los problemas con la configuración del entorno demoraron más de lo esperado y ya no está seguro de tener tiempo para hacer todo antes de que finalice la semana.

Lo que informa en la próxima reunión, a lo que el gerente del proyecto responde: “Está bien, te escuché. Pero nos comprometimos, así que ¿puedes intentar completar todo a tiempo? Al mismo tiempo, la cabeza del gerente escanea una imagen de cómo tiene que explicar el retraso en la liberación en la sincronización semanal con el Vicepresidente de la Compañía de Desarrollo, quien, a su vez, le da el consejo instructivo "Solo hazlo" , por lo que es mejor simplemente colar e intentar hacer.

Entonces, el desarrollador, como desarrollador, se va por un par de noches, o tal vez un fin de semana, y completa el trabajo a tiempo. Y su manager aprecia sus esfuerzos en el próximo rally. Negocios algo.

¿O no es tan suave? Se cumplieron los plazos y el trabajo se realizó con éxito, pero se creó un precedente incorrecto. Un estudiante recientemente contratado con ojos saltones recibió una señal de que el procesamiento los fines de semana es correcto .

Y ni siquiera discutiremos el triste escenario cuando no se cumple el plazo, la tarea pasa al siguiente sprint, y el gerente tiene que justificar el retraso en su próxima sincronización semanal ante el Vicepresidente de Desarrollo y escuchar el consejo moral.

¿Ves un problema? En ningún momento alguien hizo la pregunta: "Escucha, ¿qué pasa si lo pasamos al siguiente sprint y no le damos excusas a nadie? ¿Cómo afectará esto a los usuarios?

Mucho más a menudo de lo que debería ser, los plazos son autohipnosis. Y cómo lidiar con ellos, también.

La solución ideal sería simplemente hablar con las partes interesadas, el equipo del producto o el equipo de ventas, para averiguar si el retraso podría conducir a la pérdida del cliente. Y si este es el caso, definitivamente asigne horas adicionales y tal vez trabaje el fin de semana. En este caso, el joven estudiante recibiría una señal de que la empresa realmente se preocupa por sus clientes y no por sus sprints.

Hay otro problema con los sprints congelados. Suponga que recibió una solicitud de un cliente –– para corregir un error potencialmente trivial y de baja prioridad. El desarrollador lo afrontará en un día. Pero está siguiendo el proceso de ^TM , lo que significa que la tarea se agrega al trabajo atrasado de su equipo y tal vez se recordará después de unos meses. ¡Pero has perdido la oportunidad de complacer al usuario! Puede lidiar con esto en un par de días e informar al usuario por correo electrónico que su problema se ha resuelto. La gente recuerda esos momentos, y son esas cosas las que les hacen recomendar su producto a sus amigos.

No te dejes llevar por los procesos, debido a ellos puedes perder tu objetivo. ¹

También creo que los sprints congelados o cualquier otra práctica restrictiva son un signo de la desconfianza mutua inherente a la empresa, como resultado de problemas más fundamentales a nivel de cultura de comunicación, pero más sobre eso la próxima vez.

¿Por qué son terribles los plazos?

1. Crean falsas expectativas, contrarias a lo que está escrito en sus valores corporativos. Debido a que sus valores corporativos no son sus valores, sus valores reales son expectativas y prejuicios no escritos (tanto buenos como malos).
2. Las personas cortarán esquinas si las pones en condiciones difíciles. Alguien calificará para la prueba, alguien no actualizará la documentación. Envías el lanzamiento a tiempo, pero ¿a qué costo?
3. Nadie acepta pasar tiempo buscando nuevas soluciones mientras los gerentes rezan por las tareas completadas a tiempo. Todos escribirán el front-end en marcos MVC hasta que alguien en Facebook cumpla con algún plazo.

Entonces, ¿trabajar sin plazos?

Por supuesto que no. Establezca plazos, pero hágalos flexibles. Cuán flexibles pueden ser sus plazos es su objetivo. Si el incumplimiento de la fecha límite podría ocasionar la pérdida de un millón de dólares, su flexibilidad debería ser cero. Pero si esta es otra característica, siempre hay margen de maniobra. También puede experimentar con métodos probabilísticos más complejos para estimar fechas, en lugar de jugar números de Fibonacci con el dedo en el cielo. ²

Pero congelar sprints es una decisión regular.

^1. Jeff Bezos habló bien sobre este tema en una carta a los accionistas en 2016 . Aconsejó "resistir los poderes entre las personas dentro de la empresa".

^2. Joel Spolsky habla sobre métodos avanzados para estimar los plazos en su artículo "Programación basada en la evidencia" ( traducción en Habré ).