En cuanto al desarrollo de software en proyectos complejos, la mayoría de los analistas, miembros del equipo y usuarios se preocupan por la complejidad de los mismos. Sus requisitos parecen completamente únicos para ellos, y por lo tanto parece que se requiere un enfoque muy especial. ¿Cuántas veces ha escuchado: «las herramientas y enfoques utilizados en otros lugares simplemente no funcionarán en este entorno»?
Sin embargo, la verdad es muy diferente: ¡los únicos proyectos de desarrollo de software verdaderamente complejos son aquellos que las personas hacen complejos! Es importante que el analista reconozca que los procedimientos utilizados, sin importar el tamaño del proyecto, deben permanecer fundamentalmente iguales.
El enfoque del analista para la implementación de cada proyecto debe adaptarse individualmente; sin embargo, los procedimientos para esta implementación deben permanecer constantes. Muy a menudo, la organización de entrevistas, la utilización de técnicas como el Desarrollo Conjunto de Aplicaciones (JAD), o la simple incorporación de más desarrolladores al proyecto pueden resolver problemas que parecen insuperables.
De hecho, la mayoría de los innumerables problemas que surgen en el desarrollo de software pueden atribuirse a dos cuestiones fundamentales:
1. Las personas están tratando de resolver el problema equivocado, es decir, el problema identificado no es realmente lo que está mal.
2. La solución al problema real suele ser mucho más sencilla de lo que parece a primera vista.
Debido a que no hemos reconocido estos problemas, la frustración de la industria por desarrollar soluciones de software apropiadas ha sido crónica, y esta situación realmente no ha mejorado en los últimos 25 años. La pregunta es ¿por qué?
Para ser directos, ¡los analistas de sistemas a menudo no hacen bien su trabajo! Tendemos a elaborar planes y cronogramas que están condenados al fracaso desde el principio.
El objetivo final del analista debe tener en cuenta la realidad del entorno en el que se realiza el trabajo. Recuerde, trabaja dentro del entorno. Deje que los usuarios decidan qué grado de cambio es apropiado para su propia operación; no le corresponde exigirles que cambien.
Puede parecer atractivo, pero en realidad el plan de desarrollo de software que describe nunca podría llevarse a cabo. Enfóquese especialmente en la intersección entre el desarrollo de software y las actividades de aseguramiento de la calidad (QA). En un ejemplo de plan se podría especificar que una vez que se termina el desarrollo, los materiales se envían al equipo de QA para realizar pruebas. Sin embargo, esta secuencia asume que QA nunca encontrará un error y que, por lo tanto, los materiales nunca serán devueltos al equipo de desarrollo.
Cualquier analista sabe que este escenario es muy poco probable que ocurra. Una planificación tan deficiente provoca una asignación insuficiente de recursos al proyecto. Si se cumple con el cronograma de desarrollo, es muy probable que los recursos de programación se asignen a otros proyectos. Así, si QA encuentra errores (lo cual sin duda sucederá), reasignar estos recursos de programación se vuelve difícil y problemático. Y recuerde: a los programadores no les gusta regresar a un programa «viejo» para hacer mantenimiento o corregir errores.
Cronogramas de desarrollo de software realistas
No hay absolutamente ninguna razón por la que un cronograma no deba reflejar la realidad de lo que más probablemente ocurrirá. Los resultados son claros: una planificación realista proporciona un cronograma más confiable. Entre los muchos beneficios de un cronograma así están la confianza y el respeto ganados tanto por los usuarios como por el personal de desarrollo. No hay nada como elaborar un cronograma que refleje aquello en lo que todos están seguros de que ocurrirá.
En este punto, sin duda los analistas experimentados se preguntarán: ¿qué sucede cuando la gerencia nos impone cuánto tiempo tenemos y no muestra flexibilidad ante los retrasos? Este problema, desafortunadamente, no es poco común y típicamente se ajusta a uno de estos tres escenarios:
1. La gerencia no tiene conocimiento sobre el análisis y la construcción de sistemas y simplemente no tiene idea de cuánto tiempo se necesita para completar el proyecto de desarrollo de software. En este caso, el analista deberá desarrollar una presentación convincente para la gerencia sobre los detalles de cómo se diseñan y desarrollan los sistemas. La presentación debe estar cuidadosamente documentada y hacer referencia a estadísticas de la industria para proyectos similares en empresas parecidas. Este tipo de documentación añade mucha credibilidad a la discusión. También puede considerar contar con una fuente independiente, como una firma de consultoría respetada, que respalde su posición.
2. La gerencia tiene poca confianza en el equipo de desarrollo. Sienten que elegir una fecha y ceñirse a ella es la mejor manera de terminar el proyecto. ¡Sí, esta es la técnica del matón! Generalmente, esto es el resultado de malas experiencias, probablemente al observar diagramas de Gantt poco realistas. En esta situación, el analista debe tomar medidas para ganarse la confianza de la gerencia. Usar las sugerencias mencionadas anteriormente sería un buen comienzo. Además, necesitará investigar y entender la historia de lo que hicieron sus predecesores para fomentar esta actitud desconfiada y dictatorial por parte de la gerencia, y encontrar una manera diplomática de abordar esos problemas.
3. Lamentablemente, la mala gestión existe. Si no puede obtener ninguna concesión o comprensión por parte de la gerencia, es posible que se encuentre en lo que se conoce como el «escenario sin salida»; la gerencia simplemente no está dispuesta a asignar el tiempo adecuado para la finalización del proyecto de desarrollo de software y no están dispuestos a ser persuadidos de lo contrario. Cuando esta situación existe en el lugar de trabajo, el consejo es directo: puede irse o puede encontrar alguna manera de lidiar con esta limitación. En cualquier caso, tenga en cuenta que bajo el escenario sin salida, hay pocas esperanzas de que el proyecto resulte en el desarrollo de software de calidad. Esta perspectiva no es cínica, sino más bien realista: algunos proyectos están destinados al fracaso antes de comenzar.
Lo importante es que el analista reconozca, lo más temprano posible en el ciclo de vida de desarrollo de software, que el proyecto no puede tener éxito.