Estimando en base a qué

Hola,
Antes de nada, y como aclaración, todo lo que se va a hablar aquí tiene que ver con proyectos de implantación no basados en metologías ágiles, si no en el típico proyecto a alcance y prespuesto cerrado. Donde ante nuevas peticiones se generan las conocidas como “gestiones de cambio”. Después de esta primera aclaración, empezamos.
Uno de los principales problemas en el mundo del software es estimar el coste temporal que puede costar realizar un desarrollo. Obviamente no vamos a dar aquí la fórmula mágica, pero al menos algunas ideas basadas en la experiencia que pueden ayudarnos a orientar la estimación (siempre que nos dejen respetar el modelo).
Una de las principales claves a la hora de estimar, si no la más importante es disponer de un catálogo claro de requerimientos, tanto funcionales como técnicos. Esto es, un documento escrito, donde se describen claramente las necesidades funcionales, a la par que técnicas, del sistema. Insisto en lo de técnicas, ya que uno de los principales errores a la hora de dimensionar es no contar con estas. Ejemplos son un tiempo de respuesta mínimo ante determinadas peticiones, una necesidad de accesibilidad determinada, una tecnología o arquitectura requerida, una integración con un sistema determinado, etc.
Con estos dos documentos de partida tenemos ya parte de lo que necesitamos (dando por hecho que son documentos revisados, trabajados y entendidos por nuestra parte y sobre los cuales hemos podido resolver todas las dudas que nos han surgido al respecto), pero aún no hemos terminado. Nos faltan concretar aspectos clave por nuestra parte como son las actividades que vamos a realizar para conseguir el objetivo.
Como ejemplos de esto último: diseño funcional, plan de pruebas funcional, plan de pruebas de integración entre sistemas, plan de pruebas de carga y estrés, documento de arquitectura, diseño técnico, desarrollo, pruebas unitarias, despliegue, soporte a las pruebas de usuario, manual de usuario, guía rápida de usuario, migraciones de datos, cargas iniciales de datos, manual de despliegue, manual de administración, tareas de seguimiento y control del proyecto así como interlocución con el cliente, etc. A todo esto incorporar adicionalmente los aspectos específicos del cliente y que nos acarrean tiempo, como posibles auditorías de código, de sistemas, certificaciones de calidad… Y cualquier otro punto burocrático que no quede recogido en alguno de los puntos anteriores.
En resumen, todo el conjunto de actividades que consideramos que nuestro proyecto requiere para llegar al éxito. No nos dejemos ninguna sin estimar y si lo hacemos, dejemos bien claro a nuestro cliente que esa actividad en concreto queda fuera del alcance de nuestra colaboración.
Una vez identificadas todas las actividades y con nuestros documentos de requerimientos funcionales y de sistemas disponibles es el momento de ponerse manos a la obra. La pregunta del millón ahora es, ¿cómo empiezo la estimación? ¿cómo traduzco un requerimiento en horas de trabajo? Bajo mi punto de vista tenemos dos formas de hacer esto.
Forma 1, un primer dimensionamiento en base a tablas de estimación
La técnica consiste en base a los requerimientos funcionales empezar a identificar diferente aspectos típicos necesarios en una aplicación de software: número de pantallas, interfaces con otros sistemas, cálculos de negocio, tablas de almacenamientos de datos, migraciones de datos, etc. Todos estos elementos deben catalogarse en torno a una complejidad (alta, media, baja por ejemplo). A cada combinación tipo de elemento/complejidad, le asignamos un valor númerico, pueden ser horas o cualquier valor de referencia, como puntos función. En caso de utilizar la primera opción tendríamos un valor numérico directo traducible a esfuerzo, en el segundo caso tendríamos un número el cual podríamos traducir a continuación a horas en base a un equipo experiencia previa anterior dada. Es importante que por cada criterio de complejidad, tengamos claro qué significa, por ejemplo, una pantalla de complejidad baja tiene menos de tres elementos  y gestiona 2 eventos… una de complejidad media entre 4 y 10 elementos, otra de alta entre 11 y 20… Son ejemplos algo básicos, pero lo importante es que os quedéis con la idea.
Independientemente de que utilicemos puntos función o tablas de valoración por horas (en base a experiencia previa ambos), habremos obtenido el coste de una de las tareas que habíamos identificado anteriormente, la fase de desarrollo. Como punto adicional a tener en cuenta es que estas tablas de valoración deben estar ligadas a una tecnología en concreto (no cuesta lo mismo el coste de construir una aplicación web j2ee, .net, php)… por otro lado, no cuesta lo mismo construir un mismo aplicativo en una misma tecnología, si usamos una solución web o de escritorio. Y, lo más importante, no cuesta lo mismo construir una aplicación con un grupo que cuenta con una media de experiencia en desarrollo de 10 años, que de 3. En fin, que vosotros mismos y aquí la principal dificultad, tendréis que ir adaptando vuestras tablas de valoración en base a vuestra experiencia previa y al contexto de equipo con el que creáis os vais a encontrar para afrontar el proyecto (muy complicado esto último está claro).
A partir de aquí, extrapolamos en base a porcentajes para el resto de tareas, por ejemplo: las pruebas unitarias son un 10% de las horas de construcción, el diseño técnico es un 25% de las horas de construcción, el diseño funcional y el plan de pruebas son un 40 y un 25% respecto al tiempo de construcción; el tiempo de gestión es un 10%, el manual de usuario un 5%… Todos los porcentajes deben ser calculados en base a experiencia previa y/o en base a los requerimientos funcionales o técnicos (es posible que el ámbito funcional del proyecto sea muy complejo y haya que subir el % de diseño funcional o plan de pruebas, o por el contrario, un ámbito funcional sencillo, pero muy complejo a nivel de integraciones con otros sistema y arquitectura de software, por lo que reduciríamos los porcentajes de los documentos funcionales y aumentaríamos los del documento de arquitectura y diseño técnico).
Es una forma, no es la mejor, pero lo que está claro que sirve para dar una primera unidad de medida, un primer tamaño. Que sepamos de qué estamos hablando.
Eso sí, no puede ser la foto única e inamovible, ya que, ¿qué sentido tiene estimar todo en base a horas de construcción si realmente con el nivel de detalle que tenemos, que no olvidemos que es a nivel de requerimientos, lo más sencillo es que nos equivoquemos? Esa pantalla que parecía sencilla a nivel de requerimiento resulta que detrás escondía una complejidad muy importante a nivel de lógica de validación, esa pantalla complejísima luego resulta que no lo es tal ya que tiene muchos campos pero finalmente solo teníamos que comprobar si estaban rellenados para validarlos… eso sí, luego detrás tenía una integración con otros sistema que nadie había detectado en la toma de requerimientos y que nos puede llevar al traste del proyecto. Todo esto por no hablar del conjunto de datos maestros que surge como necesidad mantener, cargas de datos no previstas… vamos, algo que si no manejamos bien puede llevarnos al traste al proyecto, con un señor diciéndonos muy serio que: macho, esto lo estimaste tú, no sé qué te habías fumado.
Para ello, señores/as, no es la solución a todos los problemas, pero está claro que es el siguiente paso recomendado: dimensionemos así el coste de realizar el diseño funcional, el plan de pruebas y el documento de arquitectura, eso sí, una vez estos 3 documentos están listos y firmados por ambas partes, es el momento de volver a estimar el coste de construcción en base a nuestras tablas y ver qué pasa. Ejemplos ya hemos visto antes, ese requerimiento donde solo veíamos 1 pantalla, tras el análisis funcional vemos que se desglosa en 3 pantallas que tiran de unos datos maestros que nadie había identificado antes y provienen de la integración con otros sistemas… esa lógica de negocio no identificada que nos trae problemas de rendimiento y que para desatascar necesitamos conocimiento experto a nivel de base de datos, etc. Por otro lado, y muy importante, este es el momento en el que tenemos ya toda la visibilidad para entender qué es lo que necesita nuestro cliente y poder asegurar si dicho aplicativo ha de ser web, de escritorio, para dispositivos móviles o una combinación de las tres. Y no olvidemos, este es el momento en el que el propio cliente puede ver que alguno de los requerimientos que definió en su día no tienen sentido y eliminarlos, o ajustarlos en su medida.
Fin forma 1.
Forma 2, dimensionamos solo el coste del análisis funcional, plan de pruebas y documento de arquitectura
Nos evitamos todo el paso anterior y estimamos solo los 3 primeros documentos. Por cierto, muy complicado medir lo que nos cuesta hacer solo en papel o en varios diagramas, tiraría aquí de experiencias previas similares. Una vez redactados los documentos, valoramos en base a tablas tal como proponíamos en la forma 1.
Fin forma 2.
Bueno, aquí podríamos preguntarnos, ¿por qué no lo hacemos siempre de la forma 2? Pues porque normalmente nuestros clientes, antes de meterse en un fregado, quiéren saber cuánto puede costarles la broma, así que no está mal tener un dimensionamiento inicial, que aunque sepamos que no es perfecto, puede darnos una idea de coste global. Tened en cuenta que nuestros clientes manejan un presupuesto anual cerrado y lo mejor para ellos entonces es tener una unidad de medida fija con tal de identificar si le pueden dar cabida o no (otra cosa es que jueguen con eso para forzarte a que te pilles los dedos y tires adelante con todas las consecuencias y riesgo asumido en base a una fuente de información claramente insuficiente). Es por esto que plantear una foto inicial y una vez superados los 3 documentos clave restimar, es la que creo mejor de las fotos.
Es además desde el punto de vista de eficiencia de proyecto la mejor, disminuyendo el riesgo para todos. Si resulta que tras elaborar los 3 primeros documentos la estimación de la construcción no se ajusta a lo esperado por el cliente, no pasa nada, se entregan y se facturan como un valor que aportamos. Si nuestro cliente se quiere buscar a otro proveedor para realizar la construcción porque cree que así lo conseguirá hacer más bonito y más barato, adelante. Por otro lado, se puede llegar a la conclusión de que la estimación técnica es adecuada, pero que el problema está en que el coste del sistema en base al beneficio que se espera obtener es desorbitado (ese grupo de usuarios que a partir de 2 problemas generan un mundo de inmensa complejidad para evitarse alguna operación de coste temporal asumible manualmente).
Como os comentaba al principio, no es una fórmula mágica, ni tiene la clave para solucionar todos los problemas, pero al menos en una pequeña guía basada en la experiencia de cómo deberíamos organizar los básicos a la hora de realizar una estimación.
Abrazos.
Miguel.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.