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
Hola,
si aceptaron el trabajo es porque:
1.- Uds tienen experiencia en ese sector o
2.- incluirán en el equipo a alguien foráneo que pueda explicarles cómo funciona ese sector o
3.-confian en la habilidad del analista para poder extraer toda la información posible acerca de cómo funciona dicho sector.
Pero generalmente para proyectos en sectores nuevos, se apoyan en el punto 2, y creo que culpa del jefe que no se haya incluido a un experto en ese sector.
Saludos.
Hola @zSegundo, lo primer gracias por opinar,
El sector era completamente nuevo, para la empresa y pienso que se tendría que haber realizado la opción 2, indepentendiemtente del nivel del Analista, somos informaticos no somos de su sector, y nunca llegaremos a estar al nivel que está el cliente.
Si se hubiera «fichado» un consultor específico, el tiempo de Analisis, y por lo tanto el de desarrollo, hubieran disminuido considerablemente, porque el énfasis se hubiera aplicado de mayor manera al analisis y desarrollo, y no a conocer tanto el Sector.
Un saludo.
Muy buenaaaaas! 😉
El «equipo» de proyecto debe ser transversal a proveedor y cliente.
Muchos de los proyectos fracasan porque se tiene la mentalidad de que el cliente «simplemente contrata» y el proveedor «ya se las apañará» y entregará el proyecto final.
La figura del Product Owner, es decir aquel que es responsable de «velar por los intereses del cliente» (y por lo tanto, por definición, entiende de la problemática del cliente) es esencial. Y en mucho casos puede y es recomendable que sea alguien del propio cliente (por eso lo de que el equipo es transversal).
No sólo eso, sinó que el éxito real, se consigue cuando se transforma la relación de compra-venta de software en una relación de colaboración entre cliente y proveedor: en el fondo ambos tienen el mismo interés, que el proyecto salga dentro de plazos y costes. Pero muchas veces nos olvidamos de esto. Y pasa lo que pasa…
Saludos! 😉
Buenas Eduard!!
Estoy de acuerdo en que el equipo de trabajo debería ser transversal.
También estoy de acuerdo que que la relación debería ser colaborativa. Pero eso no depende solo del equipo de trabajo.
No se si habrá sido por un fallo de mi equipo, o de mi empresa, aunque creo que no, la relación con el cliente es de Cliente-Proveedor.
Para el cliente somos una empresa, que si fuera otra empresa, creo que pasaría lo mismo por desgracia.
Ojala fuese así, de verdad en tantos clientes.
La verda es que lo ideal es que tengamos el análisis terminado para empezar con el desarrollo aunque creo es más importante estar proactivos y dispuestos a recibir esos cambios que en todos los proyectos y en todos los análisis recibimos.
Igual sería mejor plantearse empezar paso a paso con los requerimientos del cliente, analizando y empezando a programar módulo a módulo, siempre con un diseño previo de la arquitectura.
Alberto, lo que comentas, me parece una gran idea. El ir modulo a modulo y sus posteriores integraciones.
La verdad, es que este desarrollo que empezó hace algo mas de 3 años, me ha ayudado a mejorar profesionalmente, y si hoy en día tuviera que empezar de cero en este proyecto, lo enfocaría una manera mucho mas ágil y provocaría mucha mas interacción del cliente
Hola, Yo creo que más importante que ninguna habilidad tecnica es poder entender el negocio del cliente. Eso hace toda la diferencia entre un equipo de desarrollo intercambiable y con resultados regulares a unos consultores de confianza construyendo relaciones de largo plazo con los clientes. La experiencia en analisis sistematico de muchos negocios, aplicar soluciones de otras industrias en el cliente, y poder sintetizar mucho mejor que el propio cliente el negocio es lo que llevan a contratar empresas, de otra forma mejor lo contrato internamente y lo hago in-house. La unica aproximación que creo que logra que un proyecto de años sea exitosos es anular por completo cualquier «fase» de meses de analisis de requerimientos y construccion de documentacion. es mejor prototipo tras prototipo, y que los producto owner le metan pruebas a la cosa.
Juan, estoy de acuerdo contigo, debido a que en el tiempo que llevo aquí he cogido grandes conocimientos del sector de mi cliente y los tiempos de analisis de los nuevos requerimientos e han visto notablmente reducidos.
Pero sigo pensando, que al menos en España, gran numero de los clientes de las empresas consultoras perteneces a las administraciones publicas y los contratos al final se van cambiando de unas manos a otras, por lo que o te vas a la nueva empresa, o finalmente te iras a otro proyecto que no tendrá nada que ver, o cambiaras de puesto a tener mas responsabilidades y te olvidarás.
Ahora mismo, creo que podría trabajar en cualquier empresa del sector de mi proyecto, y la experiencia, buena o mala, será bien valorada porque mi periodo de adaptación sería realmente corto.
Lo que cuentas aquí es bastante común aunque resulte chocante. Muchas veces los mismos clientes no saben lo que quieren o incluso tienen dificultades para describir los procesos de su sector específico. Son cosas con las que tenemos que lidiar a diario, y el punto está precisamente en lograr resolverlas.
Hay varias formas de mitigar estos problemas, y todas dependen del escenario particular que tengas. Por ejemplo, pudieras (con la ayuda del cliente) conversar con personas de su misma empresa y que conozcan del tema, o visitar el escenario real en donde va a ser utilizada tu aplicación. Por desgracia muchas veces ninguna de las dos anteriores son opciones, asi que esto nos deja con el Plan C:
El Plan C no es más que poco a poco (iterativamente) ir construyendo la aplicación. Paso a paso, sin tratar de abarcarlo todo desde el primer día. Concéntrate en ir programando pequeñas funcionalidades y dejar que el cliente las use y de su opinión. Verás como el sistema irá creciendo poco a poco sin necesidad de que tengas que ser un experto en la materia.
Obviamente se dice fácil, pero habiendo trabajado con clientes desde hace ya 9 años aproximadamente, la experiencia me dice que es la única forma de lograr un resultado satisfactorio.