Introducción a las estimaciones
Una de las preguntas más recurrentes en conferencias y talleres que he impartido en herramientas de desarrollo de software es ¿Cuánto debe de cobrar por un sistema?. Mi respuesta a esta pregunta la realizo basado en dos conceptos: cuánto cobro por hora de desarrollo y cuántas horas me llevará realizarlo. Antes de que me contradigan los defensores de las metodologías ágiles, donde lo más importante es lo que la historia resuelva en lugar del tiempo que lleve, mientras los clientes me sigan preguntando cuánto me costará y cuánto tiempo te llevarás, yo seguiré intentando basar mis predicciones en estas variables. En el momento que los clientes me digan “sí, la historia es realmente importante y le dará muchos beneficios a mi negocio, así que puedes tomarte el tiempo que sea necesario”, entonces consideraré cambiar mi forma de pensar. Todo en nuestra vida implica tiempo y los compromisos se establecen en un periodo, incluso los programadores registran sus tiempos para hacer un análisis de recursos aplicados a un proyecto. Entonces, ¿por qué no utilizar esta variable al momento de definir las historias que son los elementos de división del trabajo en metodologías ágiles?
Calcular costos
El primer concepto, el costo de mi trabajo por hora, implica una serie de factores a considerar que debemos tener muy en cuenta: si la hora trabajada es efectiva o frente a la computadora, si cobro como programador senior o junior, los gastos de operación, entre otros. En cuanto a las horas productivas, como soy certificado en PSP (Personal Software Process), me he acostumbrado a registrar mis tiempos y créanme que estoy realmente sorprendido con mis resultados. En una sesión de 8 horas frente a la computadora, mi promedio de productividad es de 4.5 horas, ¿qué estoy haciendo en las 3.5 horas restantes?. La verdad creí que mi productividad era mayor, pero es complicado estar metido de lleno en la programación, porque si no ya te están interrumpiendo, te pones a revisar tus correos y otras cosas, por lo que yo considero que un promedio de 4 horas productivas es un buen promedio. Yo sé que habrá personas que tienen un promedio mayor, pero seguramente son personas que están más de 10 horas sentados frente a la computadora y eso, puede ser poco saludable. Hablando del nivel, solo quiero recomendarles que no solo tengan en cuenta el tiempo que le dedican al proyecto, también consideren las horas de sueño que perdieron en estudiar y aprender el lenguaje y las metodologías para poder hacer un sistema. Finalmente, el costo por hora debe incluir los gastos de operación, luz, agua, internet y sobre todo la computadora, pues va a llegar un momento en el que tendrán que actualizarla. Gastos de pasaje, personal adicional, como contadores, vendedores son gastos que seguramente cuando tengan su empresa tendrán que considerar en sus proyectos.
El segundo concepto es el que me ha impulsado a crear este artículo que espero sea el comienzo de muchos más, buscando como objetivo encontrar mi propio método de estimación. O quizás el método que pueda ser un estándar para nuestro país o nuestra región latinoamericana (se vale soñar ¿o no?). En los artículos que he escrito he tratado de atacar los temas que presento sin incluir mi punto de vista, con la mayor imparcialidad posible, pero esta serie de artículos no será el caso, pues pretendo ser irreverente, cuestionando cada uno de los métodos existentes y expuestos aquí, no con el objetivo de tirar veneno o tratar de ofender a nadie, sino como reflexionando en voz alta sobre la posibilidad de usarlo en cada uno de mis proyecto. Creo que debemos tomar lo mejor de cada uno y aplicarlos en la práctica con la única finalidad de incrementar nuestra productividad en el trabajo.
Existen muchos métodos de estimación de software, la idea principal es poder definir el tamaño y el tiempo que nos llevará desarrollar una aplicación. Es difícil poder dimensionar una pieza de software, pues en primer lugar es algo que no existe y que difícilmente se tiene idea clara de lo que será en el futuro, pues el cliente tiene una idea, el programador tiene otra, los empleados que lo van a usar tienen otra y se requiere de tiempo para poder crear solo la idea conjunta. Mas con las metodologías ágiles, donde se requieren resultados en el menor tiempo posible y versiones completamente funcionales. Lo importante es hacer un análisis en conjunto en el menor tiempo posible, con una persona como guía que vaya dándole forma a las ideas del cliente, de tal forma que para el programador sea viable su construcción. Este diseño conceptual será la base de la estimación y si está por escrito servirá como contrato entre las partes. Entre más detalle tenga este diseño, menos dolores de cabeza tendremos a la hora de entregar el producto final.
De las metodologías que conozco es importante la división de la solución del problema a resolver mediante el software en elementos lo más pequeños posibles. En SCRUM las historias no deben ser épicas, es decir, deben resolverse de 2 a 3 días. Hay que escoger la forma de dividir el sistema resultante: casos de uso, historias, puntos de función, proxies o cualquier elemento que pueda servir para que el programador defina el tiempo probable de desarrollo. Una vez dividido, cada elemento será estimado de acuerdo a la experiencia en proyectos anteriores. No olvidar agregar un factor de error en la estimación que puede ser un valor “a ojo de buen cubero” (en PSP se agrega un 25 % al tamaño y al tiempo de la estimación, si no existe histórico) o un valor en base a datos históricos (como lo hace el método PROBE de PSP).
El éxito de la estimación, en base a mi experiencia, radica en la forma en que se define el alcance y que tan pequeño sea el elemento en que se divide el sistema. La discusión en la formación del alcance debe ser guiado por el programador, con mente abierta y sin demeritar las ideas del cliente, pero exponiendo las situaciones imposibles en el sistema (todo es posible en un sistema, pero hay situaciones que llevaría mucho tiempo resolverlas). El levantamiento de requerimientos con el cliente es un arte y el programador o ingeniero de requerimientos debe tener la habilidad de llegar a un acuerdo, pues siempre he pensado que una mala definición del sistema es responsabilidad del equipo de desarrollo.
Y ¿todo esto debo saber para proporcionar un costo y un tiempo aun cuando el proyecto sea pequeño? Definitivamente no, todos lleva un proceso, debemos ir aprendiendo poco a poco, pero si tenemos en cuenta estos criterios, seguramente iremos mejorando nuestras estimaciones. Lo que siempre he dicho es si se ha estudiado tanto en este tema, mucho de los métodos desarrollados pueden servirnos para nuestro trabajo, siempre con sentido crítico, observando los resultados obtenidos y no basados en modas o tendencias que quizás en otros equipos de desarrollo funcionen correctamente.