Bien, entonces voy a seguir adelante y decirlo:
Es imposible estimar con precisión un proyecto de software de importancia.
Ahora, muchos de ustedes leerán esa oración y pensarán que estoy loco. Y tal vez lo sea. Pero alguien tiene que decir lo que todos sabemos que es verdad pero no queremos admitir.
Mire, se han escrito innumerables libros, se han celebrado innumerables conferencias, se han adquirido innumerables horas de consultoría y se han escrito infinitas publicaciones en blogs sobre cómo mejorar la estimación de proyectos de software. Lo entiendo. Todos trabajamos seriamente para dar nuestro mejor esfuerzo en un intento de aplacar a los jefes hambrientos que quieren saber cuándo estará lista una nueva característica. Todos fijamos plazos basados en la fecha de la conferencia y no en cuándo el software estará realmente listo.
Pero la conclusión es que simplemente no podemos hacerlo. Bueno, podemos hacerlo (de hecho, lo hacemos todo el tiempo), pero no podemos hacerlo bien. En otras palabras, siempre nos equivocamos.
Quiero decir, seguimos gastando el dinero, yendo a seminarios y leyendo blogs y libros. Contratamos consultores altamente remunerados que actúan como si supieran de lo que están hablando. Pero nunca mejora. No lo hacemos bien y seguimos pensando que podemos mejorar y que la próxima moda realmente será la solución milagrosa. Pero no admitiremos ante nosotros mismos lo que sabemos que es cierto: no podemos estimar proyectos de software con mucha confianza.
Todos hemos realizado proyectos que pensábamos que tomarían una determinada cantidad de tiempo y luego terminan tomando el doble o el triple de tiempo. Es posible que hayas estado involucrado en un proyecto que terminó en la mitad del tiempo esperado. Pero es un proyecto raro y extraño que finaliza dentro de un estrecho margen en torno a la estimación original real. Y luego, cuando aplicamos la ley de Hofstadter (“Siempre lleva más tiempo de lo esperado, incluso cuando se tiene en cuenta la ley de Hofstadter”) y duplicamos la estimación, eso también resulta incorrecto.
Hay razones para que este sea el caso. El más destacado, y con el que creo que a la mayoría de la gente le resulta más difícil, es que todos y cada uno de los proyectos de software son únicos y tienen su propia y larga lista de “incógnitas desconocidas”. Puedes planificar, diseñar estrategias, fragmentar, plegar, desmenuzar y mutilar un proyecto durante incontables horas-persona, y aún así no sabrás las dificultades que se avecinan al escribir el código. Algunas cosas que cree que serán un desafío resultarán fáciles. Pero lo más frecuente es que subestimes drásticamente el desafío que planteará algún aspecto particular del proyecto.
Por supuesto, esto sucede porque el administrador de software promedio siempre creerá que el camino tomado será una carretera plana y recta con un clima agradable hasta el destino. Y ese simplemente nunca es el caso. Los requisitos cambian, sin hacer nunca el proyecto más pequeño. La gente toma un permiso de trabajo inesperado. Otros proyectos o prioridades interfieren. El departamento de ventas necesita este pequeño ajuste para cerrar un trato importante. Nada es vientos favorables y mares siguiendo de principio a fin. Alguna vez.
Tengo un amigo con un título sofisticado en ingeniería informática que se enoja mucho conmigo cuando digo esto, pero el verdadero problema es que el desarrollo de software no es una disciplina de ingeniería. Más bien, es un proceso atrapado en el cambio de los deseos humanos, la interacción de personalidades y dinámicas, el cambio en la comprensión del cliente y soluciones no científicas. El desarrollo de software es un proceso creativo, no científico, y los esfuerzos creativos no pueden resumirse en pasos conocibles y en un sistema repetible.
Oye, entiendo que esto es difícil de escuchar. Las empresas (y con esto me refiero a los clientes) no quieren escuchar: «Bueno, realmente no estamos seguros de cuándo tendremos eso para ustedes». Buscarán proveedores que les digan lo que quieren oír, incluso si es una completa tontería. Las empresas tienen que ganar dinero y, para ello, necesitan producir valor lo antes posible. Esa demostración de la nueva función en realidad debe realizarse en esa conferencia en esa fecha en particular.
Y tenemos que descubrir cómo aceptarlo y vivir con esto. Digo esto porque creo que, como industria, hemos estado en una búsqueda durante décadas del santo grial de la estimación de software, y siempre lo estaremos. Pero nunca lo resolveremos. Simplemente no lo haremos. Hasta que lleguemos a un acuerdo con eso, lucharemos, nos agitaremos y continuaremos diciéndonos algo que sabemos que simplemente no es cierto.
No tengo una solución y dudo que la haya. Aceptar esto es el primer paso para aceptar un problema que simplemente nunca desaparecerá.
Copyright © 2024 IDG Communications, Inc.
