La mayoría de los proyectos de software exigen una planificación de los trabajos previa al diseño de solución técnica. ¿Soy el único ingeniero que piensa que esto está fundamentalmente mal?
Sumemos otro hecho, que prácticamente sin importar cual sea este "plan" (ya imperfecto) los gerentes osan pedir rebajas de los plazos, y en la más absoluta ignorancia técnica (recordemos que no existe un diseño técnico a esta altura) recortan tareas para lograr su plazo perfecto, que ya está muy viciado a esa altura, de inicio de proyecto.
Los proyectos de software deben tener una etapa de revalidación de plazos según el diseño técnico, y este nuevo plazo es el que debe valer. De lo contrario no existe forma alguna, salvo que sea la repetición de un trabajo ya hecho, de poder cumplir los plazos, ¿por qué?
Si alguien no entiende por qué es difícil estimar plazos de desarrollo sin un diseño técnico es porque en su vida a programado una línea de código, ni si quiera "Hola Mundo".
El trabajo de programar significa pensar, crear soluciones, abrir caminos dónde no hay nada (no es juntar dos ladrillos, es inventarlos). Y es el colmo que se subestime este esfuerzo y que más encima se castigue un retraso como si se tratara de un crimen.
Aun no he visto una metodología real de proyectos de software que se haga cargo efectivo de los problemas y esto ocurre porque los problemas son siempre nuevos, o ya tendríamos todo el código escrito. Hay programadores muy geniales que colocan una vara muy alta para sus pares (o no pares), pero son excepcionales y por lo general les sobra el trabajo y ganan por sobre el valor del mercado.
Se que hay gente muy inteligente que siempre dice que tal o cual problema lo resuelven en 2 minutos, pero jamas les he visto resolverlo en ese tiempo (han tardado más, lo he visto), y aún así se creen con el derecho de imponerle a los demás plazos incumplibles, para luego culparles.
¿A alguien le parece que estoy molesto?
