Programadores y alcance abierto
Cuando estoy exponiendo un proyecto en el que interviene un desarrollo informático, me gusta explicar que los programadores no son – o somos 😉 – tontos.
La capacidad analítica, de abstracción y optimización que habitualmente tienen permite dar solución a necesidades reales del mundo en el que vivimos. Su mente estructurada y el procesamiento lógico que suelen aplicar hacen que cuando visualizan una solución, avanzan decididamente hacia ella. Y por eso les “contrarian” los cambios.
Lo ideal en mi opinión, sería que los desarrolladores interpretaran la solución que deben implementar y se apropiaran de ella. Deberían poder aportar valor al proyecto desde un punto de vista técnico y de optimización. Al fin y al cabo, el trabajo en equipo es esencial porque son los programadores los que acaban haciendo que la tecnología funcione.
¿Cuál es la realidad?
Todo programador tiene la capacidad de tomar decisiones que afecten a los sistemas. Ya habrás oído decir que les gusta añadir funcionalidades porque les parece que así el sistema será mejor. No te digo que no, pero no estoy hablando de esto.
Estoy hablando de su capacidad para detectar y arreglar las incongruencias que sí o sí acabaran saliendo a la luz. Y es que por muy definidos que estén la arquitectura de los sistemas, las necesidades funcionales, los diagramas de la interacción, etc., no dejan de ser marcos de actuación (más o menos acotados) para acabar desarrollando código.
Es entonces cuando me pregunto, ¿por qué a la hora de contratar un proyecto definido, se hace necesario especificar hasta el más mínimo detalle? La respuesta que encuentro siempre es que, de esta forma, se tiene definido el alcance y se puede hacer una previsión de costes y tiempo. Para mi, lo que pasa es que no se ha contemplado una gestión de proyecto de alcance abierto.
La siguiente pregunta es: ¿Y si en lugar de definir tanto el alcance (tarea que de por sí ya supone un coste) definimos a priori el coste y el tiempo y vamos gestionando el alcance? Y no me refiero ni a modelos lean o agile, ni a metodologías o herramientas de desarrollo. Estoy hablando de gestión de proyecto.
Me he encontrado con empresas consultoras que “regalan” el análisis de requisitos y el funcional en contrapartida de la realización del desarrollo del software. Es curioso que la fase en la que hay que plasmar el valor del proyecto y del negocio salga más barata que las horas de programación… ¿Acaso es menos importante? ¿Es por volumen de horas/coste? ¿Es porque los arquitectos y los programadores tienen más que decir? ¿Es una estrategia de balanceo de costes ;)?
En proyectos de innovación, proyectos que no son réplicas exactas, proyectos que no están puramente sistematizados y probados, es habitual tener cambios. Y la gestión de cambios es cara. Entonces, ¿por qué no conceptualizamos el proyecto como tal, en pos de encontrar el producto o servicio ideal?
Trabajar con alcance abierto
Veo dos aspectos esenciales a la hora de desarrollar un proyecto de esta forma: lo primero es tener una relación estrecha de confianza entre los diferentes componentes del equipo (cliente, partners, etc). El otro, es poner en valor y comunicar de forma transparente todo aquello que se está haciendo.
“Todos los profesionales que participan en un proyecto con alcance abierto deben tener una relación de confianza, para que todos tengan presente el coste del esfuerzo y el valor aportado en base a ese esfuerzo.”
Estoy convencido que trabajando de forma conjunta, dejando que las decisiones y conocimiento de cada profesional pesen más en aquellos puntos del proyecto dónde es experto, y no intentando encuadrarlos en un alcance definido, el producto o servicio del proyecto dará otro tipo de frutos.
Está claro que hay que realizar un análisis y anticipar los problemas, pero también hay que estar preparado para poder gestionar un alcance de forma eficaz.
