Todos quieren saber cuánto tiempo llevará el proyecto. En este artículo, explicaremos cómo proporcionar al gerente un pronóstico preciso e incierto al mismo tiempo usando tiempos de ciclo y contando historias, así como consejos sobre cuándo evitar las estimaciones por completo.

Celeste sintió la presión. Su manager Barry quería hacer un pronóstico trimestral de su equipo. La tarea fue complicada por el hecho de que el grupo de Celeste trabajó en más de un producto: Barry quería obtener un pronóstico para tres a la vez. Cada uno de ellos era parte de un proyecto diferente.

Los programadores del grupo Celeste no tenían suficiente información para hacer al menos algún pronóstico, especialmente para todo el trimestre.

Celeste decidió confesarle a Barry y ver a qué venían. Ella hizo una cita al día siguiente y recopiló datos.

La niña llegó a la oficina de Barry exactamente a las 10 a.m. Cuando llamó a la puerta, Barry seguía hablando por teléfono. Le indicó que entrara y levantó un dedo para dejarlo claro: estará listo en un minuto.

Ella se sentó en una silla de visitas frente a su escritorio.

Barry colgó y se volvió: "Bueno, discutamos el momento de los proyectos, ¿verdad?"

Celeste asintió y dijo: "Sí. Eso parece ser lo que se puede hacer en tal situación ".

Barry frunció el ceño. "¿Parece?" Necesito compromisos específicos. No "parece"!

Celeste se sentó cómodamente: "Barry, ¿estás siendo presionado para lanzar estos tres productos?"

"¿Cómo te enteraste?" - Barry sacudió la cabeza. - Si escuchas a los chicos de ventas y marketing, entonces ocurrirá un desastre si no los lanzamos ahora. No sé qué responder, excepto que todo lo será ".

"Pero el mes pasado, discutiste una cartera de proyectos", recordó Celeste. "Pensé que el producto A era la máxima prioridad".

"Lo es", dijo. "Y los productos B y C también son de máxima prioridad".

Celeste puso los ojos en blanco: "Pero sabes que solo puede haber una prioridad principal, ¿verdad?"

"Lo sé, y tú sabes", dijo. "Pero mis colegas no lo saben". Necesito un pronóstico de lo que puedes hacer, bueno, obligaciones, y luego puedes respirar un poco en silencio ".

"¿En qué producto deberíamos trabajar en primer lugar?", Preguntó Celeste.

"Producto A, por supuesto", dijo. "Es el que más ha pagado".

"Bueno, eso es lo que haremos", dijo Celeste. "Estamos tensos y lanzaremos A dentro de un mes". Su tarea es lograr que estas personas agradables asistan a nuestras presentaciones todas las semanas. Deberían ver lo que hacemos en una semana. Si no vienen a la demostración, me niego a darles ninguna información ".

Barry se echó hacia atrás: "Espera. Entendí sobre la demostración. ¿Y qué hay de los otros dos meses? ¿Y por qué no les das ninguna información?

Celeste dijo: “Si trabajáramos en un solo producto, podría calcular la calificación en función de nuestro ciclo de desarrollo. Para el producto A, publicamos tres o cuatro historias [código para tareas personalizadas] por semana. Pero no conocemos el ciclo de desarrollo real de los productos B y C. "

Barry asintió: "¿Por qué no?"

"Los productos B y C están planificados en dos y tres meses", dijo Celeste. - Está bastante lejos para el marketing. El problema es que cuanto más avanza el trabajo, menos "tiempo" trabaja el departamento de marketing con el propietario del producto para aclarar las historias. No tenemos idea de qué funciones deberán implementarse en dos y tres meses. Tendríamos que hacer suposiciones con base científica desde cero (conjetura científica, SWAG). Esto es normal, me gusta hacer esto con mis muchachos, pero necesitamos más detalles. Lo que no es ".

"Entonces, ¿por qué no les dices nada si no vienen a la manifestación?" Preguntó Barry.

"Si no es importante para ellos observar nuestro progreso y proporcionar comentarios, entonces no les importa mucho el tiempo", dijo Celeste. "Quieren que nos comprometamos sin dar nuestras obligaciones a cambio". ¿Por qué debería pasar tiempo evaluando si no quieren contribuir? "

Barry acordó "vender" la "caja de tiempo" mensual a los gerentes que lo presionaron para establecer plazos. Celeste se asegurará de que el equipo se concentre solo en el producto A. Y ha programado reuniones semanales para demostraciones para que el equipo muestre su trabajo y reciba comentarios.

¿Estaría tentado a hacer las cosas de manera diferente?

Estimación de términos - trabajo no trivial

Estimar plazos también es trabajo. Muchos equipos ponen esa rutina en su horario de trabajo regular. Sin embargo, una estimación trimestral precisa a menudo requiere más de una o dos horas de trabajo.

Existen al menos dos problemas para evaluar el desempeño trimestral. Con demasiada frecuencia, los requisitos no están completamente definidos y, como con el equipo de Celeste, la evaluación separa al equipo del trabajo urgente en el proyecto.

El problema es que planificar el desarrollo de software no es como planificar un viaje por carretera. Si su ciudad tiene más de un semáforo, entonces está familiarizado con las fluctuaciones del tráfico. Vivo en un suburbio de Boston, desde donde un viaje al aeropuerto puede tomar 20 y 90 minutos. Muy a menudo de 30 a 45 minutos. Esta es una variación significativa para un viaje de 13 km.

Y no hay innovación en tal viaje. Fui al aeropuerto muchas veces y conozco varias formas de llegar allí. Tengo aplicaciones móviles que me ayudan a encontrar la ruta más rápida, incluso en el camino. Aunque algunas opciones son un poco más predecibles, ninguna de ellas puede garantizar que este viaje finalice en 20 minutos.

El viaje al aeropuerto se realiza en una ruta predeterminada y con obstáculos bien entendidos. Pero el desarrollo de productos es una cuestión diferente. Esto es innovación. En otras palabras, no hemos hecho nada como esto antes. Si no fuera así, entonces no tendríamos que escribir una nueva aplicación o actualizar un sistema desactualizado ; usaríamos la anterior.

Para una evaluación razonable, tenemos varias opciones. En realidad tres:

• Puedes estimar el orden de magnitud. Creo que esto es útil para todo el proyecto. “Esperamos de cinco a nueve meses de trabajo. Sabremos mejor cuando respondamos estas preguntas y terminemos esta parte del complejo trabajo ”. SWAG es muy adecuado para tales evaluaciones.
• Puede recopilar suficiente información sobre los requisitos y proporcionar una estimación razonable. Es posible que el equipo necesite trabajar con historias de usuarios para hacer un pronóstico con una extensión de tiempo bastante pequeña.
• Hay una opción para evaluar el trabajo por un período corto, por ejemplo, por una semana o dos. Puede resultar que el pronóstico final no sea del todo correcto. Pero generalmente está lo suficientemente cerca del resultado como para no decepcionar a las personas que pidieron hacerlo.

¿Qué pronóstico necesitas para un gerente?

Me di cuenta de que los gerentes a menudo necesitan una estimación del orden de magnitud. En este caso, el equipo puede hacer un pronóstico e informarlo de la siguiente manera:

“Creemos que este proyecto llevará cinco meses con un 50% de confianza en la precisión de este pronóstico. Tenemos un 80% de confianza en la evaluación de ocho meses. Diez meses es 90% de confianza ".

Esto ayuda a los gerentes a comprender que existe un rango de confianza. Si quieren 100% de certeza, esto puede llevar más de 14 meses.

Puede usar el método espiral: “Nos enfocamos en el primer trimestre del próximo año. No sabemos cuándo exactamente en el primer trimestre, pero creemos que podemos manejarlo ". A medida que avanza el proyecto, usted especifica: "Estamos actualizando la estimación para un período entre mediados de enero y mediados de marzo". Después de haber aprendido aún más, diga: "En algún lugar de febrero, si no se produce una tormenta de nieve". Luego, en enero, puede decir: "La tercera semana de febrero".

También recomendaría un rango de tres fechas: “La fecha optimista es enero. Lo más realista es finales de febrero. Lo más pesimista es a finales de abril ".

En cualquier caso, nunca dé una evaluación inequívoca. Tenta a St. Murphy (de la Ley de Murphy) a retomar su proyecto y hacer cosas desagradables.

En algunos casos y en algunos comandos, el cliente puede requerir información adicional. Aquí puede discutir con él las funciones específicas que se implementan para comprender las incertidumbres.

Use el tiempo del ciclo en lugar de la evaluación

No me gustan las previsiones sobre el plazo de implementación de proyectos de software u otros proyectos de TI, especialmente Agile. En cambio, prefiero que el equipo publique historias muy pequeñas o evalúe el trabajo por tiempo de ciclo.

Si no está familiarizado con la terminología:

• Las historias de usuarios describen cómo un cliente o usuario usa un producto para un propósito funcional ("Quiero reservar un lugar" o "Necesito publicar datos de ciudades inteligentes para cumplir con los requisitos de transparencia"). Las historias son diferentes de las de un desarrollador que mira un producto en términos de bases de datos y API.
• El tiempo de ciclo se refiere al tiempo total que le toma a un equipo publicar el trabajo en una historia. Esto incluye tanto el tiempo de desarrollo activo como el tiempo de inactividad cuando el trabajo espera algo.

La idea es comprender el tiempo promedio que se tarda en producir algo útil (historia).

En el caso de Celeste, ella sabía que un equipo podía producir tres o cuatro historias por semana para el producto A. Para muchos equipos, el conteo de historias funciona igual que otros métodos de evaluación.

Si el equipo nunca ha trabajado en un producto similar, el tiempo de ciclo anterior no será aplicable a este nuevo producto. Es posible que el equipo no sepa cómo refinar y dividir historias para producir varias por semana. Además, es posible que no conozca el estado del código y la disponibilidad de un número suficiente de pruebas. Si su equipo ha estado trabajando en historias durante más de tres días, no se moleste en predecir. Cuente las historias y no intente hacer más de lo habitual.

Cuando un equipo comenzó a lidiar con historias en uno o dos días, tampoco es necesario que realice una evaluación. A menudo, un cálculo simple es más fácil y más preciso.

¿Por qué no usar la velocidad?

Ha notado que recomiendo el tiempo del ciclo y el conteo de historias, en lugar de la velocidad para estimar el tiempo del proyecto. Porque la velocidad es un sustituto.

Por ejemplo, camino todos los días para mantenerme en forma. Sigo la misma ruta todos los días, rastreando mi velocidad relativa. En un lindo día soleado, camino unos 5.6 km por hora. En un día lluvioso o caluroso y húmedo, la velocidad baja a 4 km / h. En nieve o hielo no puedo salir, en este caso mi velocidad es 0.

Voy por la misma ruta. (Sí, es aburrido, pero es mi problema). Aunque viajo la misma distancia, el viaje toma diferentes tiempos dependiendo de las condiciones. Aquí las condiciones son similares a la base del código y las pruebas de su equipo.

Si las historias son lo suficientemente pequeñas, la velocidad corresponde al tiempo del ciclo. Pero con demasiada frecuencia, los gerentes intentan evaluar proyectos con historias muy grandes. El conteo será más simple: “Podemos terminar una o dos historias en un ciclo. ¿Cuál o dos historias quieres elegir?

Negarse a evaluar no es un engaño

Cuando Barry discutió los problemas con sus colegas, uno de ellos dijo: "¡Negarse a evaluar los plazos es una estafa!"

Barry respondió: "No es cierto. Quieres que lancemos un producto, ¿verdad?

La respuesta fue "Por supuesto. Tanto B como C. "

"El problema es que deben hacerse a su vez", respondió Barry. - Si realmente necesita el producto A, ¿cuál es el punto de hacer un pronóstico para el resto? Podemos ponernos a trabajar y mostrar nuestro progreso. Cuando hayamos hecho lo suficiente, repetiremos el procedimiento para B y C. Además, tendrá tiempo para aclarar los requisitos de B y C para prepararnos historias ”.

El equipo de Celeste completó la mayor parte del Proyecto A en un mes. El lanzamiento del producto B tardó más, cerca de dos meses. Y dado que la compañía recibió ingresos suficientes por el lanzamiento de los productos A y B, redujo la presión sobre el lanzamiento del producto C.

Sepa qué grado necesita su gerente. Preséntala como lo necesite. Y si tienes poco tiempo, ponte a trabajar.

Evaluación de proyectos de TI: lecciones

• No incluya números o fechas específicos. En cambio, dé un estimado de orden de magnitud con confianza en un lanzamiento oportuno. O sugiera estimaciones a corto plazo basadas en factores bajo su control.
• Divida los objetivos del proyecto en historias de usuarios que definan la funcionalidad del software. Luego, haga sus estimaciones en función de la cantidad de historias de usuarios que puede procesar.
• Asegúrese de comprender los requisitos antes de comprometerse.