Como primer punto de este post de opinión, voy a exponer los motivos de porque lo escribo:
– El otro día por Twitter hablaba con Jorge Serrano (http://geeks.ms/blogs/jorge/ o http://twitter.com/#!/J0rgeSerran0) acerca de obviar “cosas” a la hora de realizar Documentos de Análisis de Requisitos, cosas que se dan por supuesto (porque tienen que ser así…)
– El otro motivo, pese a no ser un “experto” en ALM, me he encontrado con situaciones muy curiosas durante los 3 últimos años.
Me encuentro trabajando en un cliente desde hace algo mas de 3 años. La situación del proyecto desde el principio no fue la ideal, porque para mi desgracia, mientras estábamos analizando tuvimos que empezar a desarrollar ( y no quiero hablar de tecnología que ese es otro cantar).
Nunca había trabajado en el sector del cliente en el que estoy trabajando, por lo que he aprendido muchos nuevos conceptos, y aun me queda porque es un no parar de aparecer nuevos conceptos.
El empezar a desarrollar cuando los documentos funcionales, y requisitos no están cerrados del todo, puede generar millones de errores.
En este cliente tenemos todo tipo de documentos, ARS (Análisis de Requisitos), DTS (Diseño Técnico del Sistema), EF (Especificación funcional), Documentos de Prueba…
ARS y EF están muy ligados, puesto que el segundo digamos que implementa el primero.
Para que fuera todo mas perfecto, a parte de tener que esperar a finalizar los documentos de Análisis para empezar a desarrollar, lo que sería estupendo sería que el Cliente lea y apruebe los documentos para que realmente sepa lo que se va a hacer y que si algo no está claro o este mal definido se reanalice.
Me he encontrado en numerosas ocasiones con las siguientes situaciones:
- El cliente a pesar de haber “leído y aprobado” los documentos, no conoce una parte concreta de la aplicación.
- Un requerimiento definido, “obvia” datos que el equipo de desarrollo debe conocer, puesto que el Cliente piensa, que todo el equipo de Desarrollo es “EXPERTO” en su sector.
- El desarrollador implementar de manera errónea un requerimiento.
Después de tanto tiempo, se hace muy difícil acordarte de todas las funcionalidades implementadas en el sistema, porque ha ido creciendo de forma anual, cambios, etc. En parte entiendo, que el Cliente, pueda no conocer partes de la aplicación porque es una aplicación bastante grande, separada en módulos, y hay partes que se usan a lo mejor de forma anual.
Lo que no logro entender, y es una discusión que mantengo a menudo con mi Jefe, es que el cliente nos considere “Expertos” en su Sector. Lo primero decir es que nunca me podré considerar experto en nada, ni siquiera en programación, porque ya sabéis como es nuestro mundillo, que siempre está evolucionando, y segundo, si el mismo cliente tiene dudas acerca de su Sector, ¿como pretenden que alguien ajeno a su Sector, sea de su mismo nivel?
El tercer punto prefiero no comentarlo, porque son cosas que no deberían ocurrir, pero que si un programador no lee la documentación técnica pasa lo que pasa.
Bueno, me gustaría que dejéis vuestras opiniones y cosas con las que os hayáis encontrado a lo largo de vuestra experiencia profesional.
Saludos