Blogs

¿Desea tener éxito en la adopción de un proceso de desarrollo de software?

¿Cuáles son las razones por las que comúnmente estos proyectos fallan?

En los últimos 18 años hemos visto y apoyado esfuerzos para adoptar metodologías, y prácticas de ingeniería de software en los departamentos de tecnologías de información (TI), tanto para implementar metodologías estructuradas como el Rational Unified Process como metodologías ágiles como SCRUM.

Es muy común ver en el portafolio de proyectos de los directores de TI, planes para ordenar la "casa", adaptar o personalizar  "tropicalizar" métodos que permitan hacer el desarrollo de software predictivo, estándar, automatizado, en general más "ágil" para optimizar el uso de sus recursos y poder cubrir de mejor manera los requerimientos del negocio.

En muchos casos, estos esfuerzos han terminado en definiciones que son adoptadas y aplicadas en un bajo porcentaje, algunas de ellas son abandonadas del todo, simplemente termina siendo papeleo que no aporta mejoras en la práctica.

A continuación enumeramos las principales razones de fallo que hemos encontrado:

1. Esfuerzo aislado de TI sin participación y compromiso del negocio: 

Es es quizás la principal causa. La participación del personal del negocio para i) transmitir las necesidades y requerimientos, ii) participar en la gestión del proyecto y iii) gestionar la aceptación  es vital, cualquier práctica que se implemente y los involucre de contar con el respaldo de los conocedores de negocio. Por ejemplo:

a. si se desea implementar taller de definición (sea historias de usuario, casos de uso o la técnica que se establezca), hay que capacitar al personal, planificar las sesiones, contar con la participación del equipo.

b. si se requiere tener una adecuada priorización y gestión del alcance: los usuario dueños de producto deben ser parte del equipo, ser consiente de la complejidad de las soluciones y el esfuerzo técnico requerido, entender la capacidad del equipo  de manera que pueda gestionar el alcance de manera realista.

2. Distribución de responsabilidades a los usuarios que no les corresponde:

Si bien es cierto, las técnicas de levantamiento de requerimientos y metodologías de pruebas pueden ser enseñadas a los usuarios conocedores del negocio, se ha cometido el error de dar la responsabilidad completa del levantamiento del requerimientos a los usuarios, que en la mayoría de los casos, aunque con muy buenas intensiones y de manera diligente,  no logran traducir sus necesidades al lenguaje que requiere el equipo de trabajo o no identifica todo el alcance de una solución informática. 

Tal vez hayan tenido la experiencia de recibir una definición de un requerimiento para el registro de un trámite en su organización y el personal de TI indique que no es suficiente o falta información, ya que no considera aspectos como: necesidades de reportes, mantenimiento de catálogos o parámetros requeridos para el trámite, reglas de negocio o validaciones que no están descritas.

Esto se debe a que la conceptualización de un sistema debe ser acompañada y guiada por el equipo del proyecto (rol de analista de sistemas) teniendo a los usuarios como la fuente y actores principales  para la identificación de requerimientos. 

3. Metodología que no se personaliza de manera práctica a la realidad de la empresa:

Cualquier actividad, rol, entregable, práctica que se defina debe ser adaptada a la realidad de la empresa: preguntarnos cuáles aspectos agregan valor real al proceso de desarrollo, así como aquellos que deben estar presentes por temas de cumplimiento y regulación.

Para aquellos que se preguntan ¿cómo puede implementarse un esquema práctico y ágil en organizaciones donde los controles son estrictos por ejemplo a nivel de auditoría y el equipo no puede decidir sobre qué usar y qué no?, la recomendación es poder establecer escenarios donde el equipo pueda tomar decisión (por ejemplo establecer que el equipo puede escoger entre historias de usuario y casos de uso dependiendo del tipo de proyecto, ya se por complejidad, si es mantenimiento o desarrollo nuevo, si se desarrolla en casa o se subcontratado).

4. Carencia de una estrategia para dar continuidad al proceso de adopción:

Este es uno de los aspectos a los que se le presta poca atención pero es esencial para el éxito de este esfuerzo. En muchas ocasiones la organización no establece cómo va replicar el conocimiento y asegurar que se aplique en cada nuevo proyecto, no existen personas asignadas para esta labor o bien aquellas que tienen la responsabilidad no pueden por la carga de labores llevar esta actividad.

 

Conclusión

Sin importar, el marco de trabajo (ágil o tradicional), para ser efectivos en la mejora de los procesos de TI en el desarrollo de software es necesario considerar:

  • un enfoque que involucre personal de negocio y TI, aún más un enfoque donde la idea de los cambios y mejoras del proceso sean patrocinados por la gerencia y mandos medios.
  • cada equipo de desarrollo debe contar con un rol de analista de sistemas que pueda guiar la conceptualización de un sistema, asegurando que se obtenga la vista completa de alto nivel ("big picture"). En metodologías ágiles, en un taller de historias de usuario, el mismo equipo podrá participar en el taller donde el dueño del producto indicará sus requerimientos y los miembros del equipo se encargarán de preguntar sobre diferentes perspectivas para asegurar ese entendimiento de la vista completa del problema y su alcance.
  • cada nuevo proyecto debe asegurar que los miembros del equipo conozcan la metodología defina y que existan responsables de asegurar que el método se cumpla y que se retroalimente con la experiencia para mejorarlo continuamente de manera que se filtren aquellos aspectos que son útiles y los que no agregan valor puedan ser eliminados. En metodologías ágiles como SCRUM este es el rol que juega un Scrum Master, en metodologías tradicionales es un rol jugado por personal de Control de Calidad.

 

 

00

Añadir comentarios