viernes, diciembre 11, 2015

¿Qué me molesta de los proyectos de software?

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?

1 comentario:

Alejandro Díaz dijo...

Uno nunca sabe cuando va a leer lo que otros escribieron :)

Algunas aristas adicionales al problema, sólo los puntos principales, la verdad es que cada una da para harto más:

1) Por que esencialmente lo que se hace hoy (en particular en chilito) como ingeniería de software no es más que artesanía de software [base del argumento: mediciones de productividad indican que dos programadores, con nivel de conocimientos y experiencia equivalentes pueden tener diferencias de productividad de 1 a 18, ergo, lo que uno de ellos hace en un día de trabajo, el otro lo hace en 18, que es casi un mes, esas diferencias de productividad no se dan en un proceso controlado e ingenieril, eso ocurre en el artesano]

2) Otro punto del mismo argumento, pero desde la perspectiva del recurso humano que hoy se desempeña en los proyectos de software, normalmente, el que programa tiene una preparación deficiente, realmente básica, por lo que el resultado esperado es de baja calidad e independiente del tiempo disponible.
Hay una visión burocrática de las tareas (y esos gerentes lo ven así), curiosamente basada en datos reales, de que el "trabajo" es como un gas, se expande y/o contrae para ajustarse a los plazos, es decir, si hay una carga de trabajo y se dan más días, al final se hará el mismo trabajo, ni más ni menos (esto tiene el nombre de una ley, pero no recuerdo cual).
En los proyectos de software termina siendo cierto, tanto es así, que la mayoría de las veces la estimación inicial, que otros recortan, tampoco tiene mucho sustento en si.
Nótese que esto en realidad se resume como "el resultado será malo e independiente del tiempo, por lo que si lo tenemos antes, mejor, porque así antes comenzamos a arreglarlo".

3) Nuevamente con el tema de la capacitación, startups, google, microsoft, demases, en otras partes del mundo, lo hace gente que tiene grado universitario, en muchos casos masters y doctorados, o por el otro lado, real experiencia en proyectos de primera linea, en ese contexto, diferentes metodologías, incluyendo las ágiles, si dan espacio para proyectos en tiempo, ajustados y efectivos (aunque no evita casos como Word para Windows 1.0, planificado originalmente para 12 meses, al final de los 12 meses los desarrolladores estimaban que aún les faltaban entre 11 a 12 meses más, y ni así estuvieron en lo correcto).