Por que fracasan las metodologias de desarrollo de software, proyectos… 5 Noviembre 2009 at Jueves, 5 de Noviembre de 2009

Primero quiero empezar este post enfocándome en las metodologías que existen para construir un producto de software:

>Gestión de proyectos de Software
>Desarrollo de software (ciclo de vida del software)
>Mantenimiento del software (poco o casi nunca utilizadas)

En las metodologías de proyectos de software nos enfrentaremos con los famosos “ENTREGABLES” (formatos, plantillas). Pero lo que existe en este tipo de metodologías esencialmente son: roles, etapas, fases, etc.

Al menos si usas la suite de rational (RequisitePro, ClearQuest, etc) ya vienen listos los generadores de plantillas y con la capacidad de integrarse con la suite de office.

Entonces son los miembros del equipo (personas) del proyecto de software vuelven a diseñar los formatos, redefinen, agregan, quitan cosas de lo que se le conoce como entregable. Aquí es donde se identifica el primer problema, ya que estas personas no son los creadores originales de estos formatos y es donde se empiezan a ver deficiencias al momento de completarlos, desarrollarlos, etc.

Ahora es que quiero resaltar lo siguiente “Las metodologías de gestión son importantes por que éstas
implementan la manera, la forma, del cómo trabajar los proyectos software. Quizá sin saberlo lo que hacemos al definir una metodología es establecer él o los procesos de cómo vamos a trabajar los
proyectos software. Tener una metodología es muy importante por que el proceso queda definido, estructura, homogeneizado e incluso da sentido de pertenencia a cada elemento. Los resultados serán productos software: Planes, actas, software, manuales, casos de pruebas, etc.”

Entonces podemos darnos cuenta que las metodologías de gestión son importantes, muchas veces me ha sucedido y he preguntado que tipo de metodología usan en tu empresa, lo primero que he escuchado es toda la descripción de la metodología y siempre el pero “no la implementamos por a,b,c, bla bla bla …” y cuando se les preguntan por que, suelen decir por que es pesado, no hay tiempo, no es necesario, despues las hacemos, etc. Entonces la moraleja viene a ser “La gente (las personas) no quiere hacer documentos por que es “pesado” para ellos. Entonces es lógico pensar que el proceso (reflejado en las metodologías) no puede ser documentado o llevado a cabo tal cual, en los proyectos,
por que significa mucho trabajo para ellos.”

Sacando conclusiones se puede afirmar que El proceso está escrito (metodología) sin embargo, por lo general, éste no está automatizado. Ahora imaginemos a un usuario definiendo con exactitud, precisión y de manera oportuna sus requerimientos funcionales. Y, que estos requerimientos funcionales puedan ser modelados y diseñados también con exactitud, precisión y de manera oportuna. Es sumamente complicado que las personas hagamos las actividades de procesos de software como si fuéramos máquinas. Las personas somos complejas por naturaleza, tenemos sentimientos,emociones, somos susceptibles, etc. Freud decía que las personas somos 50% buenas y 50% malas, algunas desarrollan más la parte mala o buena, por eso el mundo siempre estará en una lucha constante.

En los procesos software las personas somos “él” proceso. Los modelos de procesos y las metodologías nos ayudan al decirnos “qué” debemos hacer e incluso “cómo” debemos hacerlo pero finalmente somos las personas quienes tenemos la automatización de dichos procesos.

Nadie sabe, por ejemplo, si durante una reunión con usuarios alguno de ellos está triste o apenado, si tiene un problema con su esposa o alguno de sus hijos y eso influirá durante la reunión de toma de requerimientos. Nadie sabe si un programador ha terminado con su enamorada y esto le afecta tanto que ese día, o varios días, no avanzará tal como está programado y después nos dice que no avanzó por x razón, por cualquiera menos por la verdadera causa (en algunas ocasiones lo descrito en el párrafo anterior me ha sucedido, considero que es normal por que soy una persona común y silvestre).

Acotando ante lo descrito “Es sumamente difícil que las personas actuemos como “máquinas” y avancemos según lo planeado.”

Jim Collins en su libro “Las empresas que sobresalen” concluye diciendo que aquellas empresas que han logrado sobresalir durante muchos años, su éxito se ha basado en 3 ejes esenciales: Pensamiento disciplinado, Procesos disciplinados y personas disciplinadas. Si deseamos tener éxito necesitamos una cultura de disciplina, procesos disciplinados y sobre todo personas disciplinadas.

Una de las principales razones por las cuales fracasan la implementación de metodologías es por que no contamos con el
personal apropiado para dicho fin. Por que después de implementada la metodología dichas personas siguen en la institución o no se ha hecho nada por que cambien (si es que tienen cambio).

Una persona disciplinada tiene, entre otras, las siguientes características
fundamentales:
>Capacidad
> Es consecuente (no abandona el proyecto a menos que sea por
una razón esencial)
> Sincero (afronta los hechos no los evita)
> Innovador (propone cambios dentro de los límites del proceso)
> Humildad personal y profesional
> Actitud al cambio
> Es tolerante

La evaluación de las características de disciplina no incluye conocimientos y destrezas por que éstas pueden aprenderse. Existen técnicas para identificar personas disciplinadas.

Muchas veces lo peor no es tener personas disciplinadas sino no hacer nada para que lo sean.

Todo lo anterior escrito esta basado en la experiencia profesional, cursos de capacitación y en el texto de Eric Morán Añazco (MBA. PMP Instuctor en M&T Consulting) que fue mi profesor en el curso de Gestión de proyectos de Software.

One Response to “Por que fracasan las metodologias de desarrollo de software, proyectos…”

  1. Tener metodologias es muy importante por la tremenda falta de talento generalizado, la gente necesita que le digan paso por paso lo que necesitan hacer, y aun asi, muchos proyectos fallan, por que fallan? por que el desarrollo de software tiene el factor humano y se depende de alguna manera tambien del peor del equipo

Leave a Reply