Hay que tener en cuenta siempre el objetivo principal, conseguir implementar un software que alcance el valor mínimo para el cliente en un tiempo determinado.
Los pasos normales para establecer las como se va acometer el desarrollo, como se va a estructurar los recursos del proyecto y que tiene que hacer cada individuo, es establecer una estructura y luego pedirle a los individuos (programadores, analistas, funcionales, responsables, etc...) que se adapten a ella. Este método parece lo mas lógico pero muestra algunos fallos:
- El método no tiene en cuenta las características individuales de cada miembro del equipo. El método puede parecer bueno sobre el papel pero ser lo peor si se analiza a los miembros del equipo individualmente.
- El método no tiene en cuenta la consecución del objetivo principal. El método puede parecer bueno sobre el papel pero no estar en nada alineado con el objetivo principal.
El gran problema es que sobre el papel algo parezca bueno ( pero no funcionar en la realidad) y los responsables no querer cambiarlo nunca. Si algo no funciona, va a seguir sin funcionar por mucho que nos empeñemos en hacer siempre lo mismo.
Si las reglas del juego no tienen en cuenta a los miembros del proyecto ni el objetivo principal del proyecto entonces los fracasos puntuales seran constantes. Cuando se suman muchos fracasos puntuales se obtiene un proyecto con dinamicas incorrectas y ambiente toxico.
La formas mas correcta es ver cual es el objetivo principal del proyecto y quienes tienen que acometerlos y establecer una estructura de proyecto acorde a estas características.
Esto no significa que no se pueden incluir características formales para hacer una mejor estructura de proyecto pero aposteriori. Es decir, primero una estructura de proyecto que se ajuste a los miembros del equipo y al objetivo del proyecto y cuando este establecida y funcionando entonces se pueden incluir aspectos de mejora y los pasos necesarios para incluir esas mejoras. Por ejemplo, si quieres que todos los miembros del proyecto utilicen el ingles como lenguaje de documentación cuando los miembros del equipo no saben ingles lo mas incorrecto que se puede hacer es poner a los miembros del equipo a documentar en ingles y que "salga lo quesea". Es mas lógico que:
- Que documenten correctamente en castellano.
- Que aprendan ingles.
- Que analicen la forma comun de documentar.
- Que documenten en ingles.
Son varios pasos, cualquiera puede fallar y dar a entender que la mejora no es posible.
Estos son los pasos correctos.
