Hace unos días pregunté a unos amigos ¿cómo estimáis un proyecto de software? queriendo saber no las tarifas, precios o costes específicos a tener en cuenta sino el proceso y los factores a tener en cuenta y comprobar si lo hacía bien o mal, ¿cómo lo estimáis vosotros?
En principio tengo que decir que la principal motivación de este artículo fue el problema de haber estimado de forma no solo errónea sino muy dañina un par de proyectos de software realizados dentro de mi empresa en los últimos meses. Lo cual no solo ha costado dinero sino también la estabilidad de la propia empresa.
En ese momento comencé a preguntarme, ¿estimo bien los proyectos? sabiendo que por los resultados obtenidos era obvio que no. Algo estaba haciendo mal. Muy mal. Por lo que pedí ayuda y consejo a varias personas.
No es oro todo lo que reluce
O dicho de otra forma, hay que saber decir no. El problema que tuve en diciembre fue no saber decir que no a un proyecto que descompensaba el nivel y ritmo de trabajo de la empresa. Supuso una carga adicional no compensatoria y mermó en el ánimo de todos.
A día de hoy estoy convencido de que si hubiese dicho no al proyecto entrante la verdad actual de la compañía sería diferente.
Es más lo colocaría como principal punto de entrada en la lista de cómo estimar un proyecto de software. Si no puedes con la carga de trabajo, ni lo intentes. Ni comiences la estimación. Rechaza la carga extra de trabajo. Merece más la pena mantener un ritmo de trabajo y un buen ambiente de trabajo que cargar de stress tu entorno y a tus trabajadores.
Tener muy en cuenta los riesgos
Otro de los factores a tener en cuenta en las estimaciones es el conocimiento sobre el desarrollo a realizar. Un programador tiene control de los lenguajes en los que está acostumbrado a desarrollar, con las librerías con las que suele desarrollar, los frameworks, los entornos e incluso los elementos que suelen complementar sus desarrollos.
Agregar nuevos elementos como nuevas librerías es un riesgo a tener en cuenta, agregar un nuevo framework es un alto riesgo pero agregar muchos elementos dispares dentro de la infraestructura sobre los que se conoce poco o nada es un riesgo desmesurado.
Intentar estimar sobre un conjunto de elementos desconocidos es igual a adivinar. Como dice Jason Fried en Rework: La Planificación es Adivinación (Planning is Guessing).
En un comentario José Luis Martínez apuntó sobre la estimación y la incertidumbre o riesgo que habría que tenerlo en cuenta en una proporción igual al tiempo de desarrollo planificado (o duración del sprint). Aunque siempre mejor estimar y cobrar por puntos de historia en lugar de horas.
Sobre las formas de coste de un proyecto de software dejo en este artículo algunas pistas.
Análisis previos para minimizar riesgos
Es algo que hacía al principio. Un peritage del proyecto, una planificación en detalle para obtener un conocimiento intrínseco y evitar o minimizar los riesgos e incertidumbre. En estos últimos desarrollos obvie este nivel de estudio inicial y aún así acepté el desarrollo. Visto en restrospectiva y de esta forma se ve obvio mi error. Pero os puedo asegurar de que no era tan obvio en el momento inicial.
Por mi parte soy de los que siempre estoy pensando en que cualquier tecnología enlazada de alguna forma a los elementos que suelo emplear en el día a día de mi trabajo no me llevaría mucho tiempo estudiarla y entenderla. Al dejarme llevar en este sentido consideré algo como: Bueno, sé modificar un Prestashop así que no tendré problemas con un Magento. ¡Qué gran error!
En este asunto creo que una de las mejores respuestas la obtuve de Fernando de Sopinet. Él me señaló cómo lo hacen ellos introduciendo una primera iteración de diseño de producto donde analizan las necesidades del proyecto elaborando toda la documentación. Además y conforme al primer punto Fernando asegura que "con tanta exigencia el 90% de los posibles clientes que nos llegan suele caer". No obstante los clientes que quedan son los que realmente están comprometidos con el desarrollo de su proyecto.
Nunca el todo o nada
Muchos de mis proyectos han fracasado por este enfoque. Todo o nada. O desarrollamos todo o no entregamos nada. Esto es completamente opuesto a las metodologías ágiles. No he tenido éxito nunca con este enfoque y aún así hay veces que por cualquier motivo termino dándome cuenta tarde de que lo estoy empleando.
Lo ideal para no caer en este error es partir el trabajo en tareas cuanto más pequeñas mejor. Si una tarea es tan grande que no permite estimarla dentro de la seguridad de una desviación en horas es porque la tarea es tan grande que puede ser fraccionada en tareas más pequeñas y asumibles.
Muchas tareas pequeñas y de fácil estimación conforman un proyecto más grande y de más fácil estimación. E igualmente nos permite no solo poder estimar el proyecto completo sino también priorizar las tareas y realizar entregables periódicos que permitan al cliente evaluar y poder pivotar o cambiar el trabajo pendiente.
Soporte y Garantía
Como todo servicio prestado o producto vendido debe existir una garantía. En nuestro caso si hemos firmado un proyecto con unos requisitos la garantía debe cubrir el cumplimiento de esos requisitos. Si el desarrollo no cumple esos requisitos la garantía debe cubrir el tiempo nuevo a invertir para arreglarlo.
Hay clientes que se aprovechan de este enfoque e intentan introducir una nueva característica o un mantenimiento adaptativo como si fuese un error del proyecto. Hay que tener cuidado con esto. Para mis proyectos siempre intento vender un soporte que incluya mantenimiento adaptativo y correctivo, pero no evolutivo.
Cuando recibimos una incidencia de un cliente debemos someterla a triage y evaluar qué tipo de petición es para saber si entra dentro del soporte o garantía. Todo lo referente a nuevas características siempre lo tomo como un mantenimiento evolutivo y debe ser atendido con una nueva estimación y la elaboración de un nuevo proyecto. Después esta lista de nuevas características se puede subscribir al soporte ampliándolo y obviamente revisando su precio. No siempre es necesario incrementar o decrementar el valor pero está bien tener presente su revisión.
El precio a cobrar por el soporte depende del proyecto. A mi me gusta medir el valor obtenido por el cliente, además del esfuerzo necesario para el mantenimiento para poder estimar un precio justo. La norma creo que debe ser no exceder con el precio del soporte el valor que proporciona el proyecto al cliente.
Resumiendo...
Creo que una buena práctica consistiría en:
- Evaluar el sistema a realizar para poder investigar y obtener información concreta sobre qué hay que hacer y si podemos abarcarlo o no. Es importante en este paso eliminar tanta incertidumbre como sea posible y si aún así el nivel es importante: rechazarlo. Solo aceptar proyectos con un nivel bajo o inexistente de incertidumbre.
- Estimar las iteraciones de trabajo (sprints) con tareas asumibles, de fácil medida y sabiendo con muy poco margen de error que podrán ser realizables dentro del tiempo estimado. Evitamos el trabajo de una sola y única entrega.
- Cada tarea dentro de cada iteración tiene un valor. Un tiempo asignado también. Lo ideal es valorar y cobrar al cliente por el valor entregado en lugar de las horas trabajadas pero ese es otro dilema con una discusión bastante más larga. Lo simplifico en cobrar al cliente por el valor entregado medido por hora o puntos de historia. Dejo abierta la decisión de cobrarlo de una u otra forma.
- Indicar al cliente la existencia de la garantía y la posibilidad de adquirir un soporte. Este soporte debe ser proporcional al proyecto pero no superior al valor entregado. La idea es dar al cliente la seguridad de un proyecto siempre funcionando pagando un precio justo.
Espero recordarlo y mejorar en los siguientes proyectos.
¿Tú también has tenido tus problemas estimando y planificando? ¿Qué te ayuda más a la hora de estimar un proyecto? ¿Qué ideas que has leído no habías considerado y te interesaría implementar en tu proceso? ¡Déjanos un comentario!
