Analistas Funcionales 2: ¿El AF tiene la culpa?

Tiempo atrás escribí un post llamado El analista funcional no es [solamente] u documentador que tuvo bastante éxito (éxito = se leyó mucho).

En estos días encontré un interesante artículo relacionado con el tema llamado A practical approach to recognising and improving competencies in your business analysts. Su lectura me disparó varias reflexiones:

1. Me gustó la defensa que hace de los gerentes de proyectos, típicos chivos expiatorios a la hora de señalar a los culpables de un proyecto fallido.

In the survey mentioned later on, an overwhelming 50 per cent of respondents cited poor requirements definition as their biggest challenge, thus raising a new question.

2. Cuando decía en mi post que “no podemos reducir las habilidades de un AF a documentar” no estaba equivocado. El modelo citado en el artículo involucra varias competencias más, además de la de crear el documento de requerimientos.

3. En particular menciona al análisis estructurado como una de ellas. Es decir la capacidad de modelar el problema.

Structured analysis refers to the art of modeling. In business analysis, modeling is used to support and enhance text-based requirements, help identify and validate requirements, document and communicate requirements and, finally, organise information into coherent ideas.

Mi hipótesis, que va reforzándose con los años, es que no otorgamos suficiente atención al momento de definición de los requerimientos y a partir de ello, condenamos al fracaso al proyecto.

4. Notar que el artículo habla de analistas de negocios. Otro término que se utiliza mucho como sinónimo de analista funcional.

NOTA: Si quieren leer el primer post de la serie pueden ir aquí.

Seguimos pensando..

Apartado “ágil”: Para mi selecto grupo de lectores “ágiles” aclaro que este post es totalmente compatible con tener un ciclo de vida ágil para desarrollo del software. El hecho de que estemos documentando ágilmente y que tengamos un product owner no significa que no debamos prestar atención a los requerimientos que estaremos incluyendo en nuestro desarrollo/sprint.