De todos es sabido que cuanto antes se solucione un problema en un
proyecto de desarrollo de software, menos coste tiene para el mismo y de
ello salen beneficiados tanto proveedor como cliente.
Por ese motivo resulta esencial que un proyecto sea sólido desde la
base, siendo la misma el análisis funcional, lo que hace que sea muy
importante la figura del analista que es la persona o grupo de personas
(si el proyecto es grande) que se tienen que encargar de entender,
interpretar y traducir lo que el usuario demanda, sentando las bases de
los posteriores procesos de diseño y construcción del sistema de
información.
Hacer un buen análisis es una tarea bastante compleja, ya que resulta
muy complicado obtener todos los requerimientos del usuario desde
etapas muy tempranas, ya que por regla general el usuario empieza a
descubrir el detalle de todo lo que quiere cuando empieza a utilizar el
producto ya construido con ejemplos reales de su día a día de trabajo
(también suelen comentar nuevos requisitos o enmendar requisitos
previos, en otras etapas conforme se le vaya presentando la evolución
del proyecto, de hecho no es malo que se corrijan, ya que cuanto más
avanzado esté el proyecto, el esfuerzo de hacer los cambios es mucho
mayor). De hecho es prácticamente inevitable no hacer evolutivos que
solventen esos flecos que no se detectaron en análisis para dejar el
producto lo más próximo posible a lo que los usuarios necesitan y
demandan. Como consecuencia de lo anterior, y como es lógico, se puede
considerar que un análisis funcional es más bueno conforme sea menor el
número de ajustes que haya que hacer en etapas posteriores del proyecto.
Es importante matizar que un proyecto de desarrollo de software no es
una barra libre y que es importante que el usuario conozca sus
responsabilidades en el proceso de definición del sistema y que no se
pueden estar cambiando de requisitos continuamente, como tampoco podría
estar cambiando frecuentemente de opinión si le están construyendo una
casa. Todo lo anterior además hay que compatibilizarlo con que todas las
partes están interesadas en el que el proyecto vaya a buen término, por
lo que tampoco es una buena política ser inflexibles en la modificación
del catálogo de requisitos, porque si el resultado final no es el que
quiere el usuario, el sistema de información tendrá muchas papeletas
para no ser utilizado. Equilibrio complicado: evitar que los usuarios
modifiquen continuamente requisitos y tener un poco de mano izquierda
cuando se planteen esos cambios. Como ese equilibrio es complicado de
mantener y es fuente frecuente de conflictos, hay que intentar que el
análisis tenga la mayor calidad posible.
Hacer un análisis funcional por tanto es una tarea compleja, a lo que
hay que sumar que en muchos casos hay que aprender mucho sobre el
proceso de negocio que se pretende informatizar, para entender de mejor
manera lo que el usuario demanda, ya que resulta todo más fácil si el
lenguaje que se utiliza es el mismo. En muchas ocasiones esos procesos
de negocio son tremendamente complejos y además se dispone también de
poco tiempo para entenderlos, teniendo en cuenta que por regla general y
como he comentado muchas veces en mi blog, los proyectos informáticos
suelen estar infravalorados (por el que contrata y/o por el que es
contratado (para conseguir el contrato)).
Dado que el análisis funcional consiste en abstraer un conjunto de
necesidades de los usuarios es muy importante la implicación de los
mismos y eso no siempre se consigue. Si los usuarios no están
implicados, por muy buen analista funcional que tenga el proyecto, las
probabilidades de que este salga mal crecen exponencialmente.
Evidentemente un buen analista puede paliar esos huecos que deja el
usuario e incluso conseguir una mayor participación de los usuarios,
pero más tarde o más temprano los problemas aparecerán y al final
siempre termina pagando el proyecto (en primera instancia) y el que lo
desarrolla (en segunda). Por todo lo anterior, se puede pedir que un
analista funcional aprenda un proceso de negocio complejo, que consiga
extraer de los usuarios lo que buscan y necesitan y que además lo haga
en un tiempo record, pero lo que no se le puede pedir es que haga magia y
resuelva problemáticas que le trascienden, como el caso que he
comentado de la inacción de los usuarios en determinados proyectos,
siendo esa falta la implicación la primera causa de que un análisis no
salga bien y por tanto una de las causas más importantes del fracaso de
un proyecto y no se trata en este caso de tirar pelotas fuera y ponerme
del lado de mis colegas de profesión, se trata de algo que he podido
vivir en diferentes proyectos de manera muy directa.
Nadie es infalible y un analista funcional tampoco lo es. Habrá
errores (independientemente de que la causa de los mismos sea provocada
por circunstancias adversas en el proyecto o no), puede que en este
proyecto sean muy pocos y que en otros sean mayores, por eso es
importante que el analista lo tenga asumido desde un principio, como
también lo es que de esos errores se debe aprender y que resultarán
fundamentales en la formación del mismo. Al final esos errores terminan
curtiendo y permiten que cada vez los análisis que se realicen sean
mejores. Por tanto, la experiencia resulta importante. En cualquier
caso, suponer un análisis perfecto es suponer que en un proyecto se dan
circunstancias ideales y que todas las variables que pueden influir en
que las cosas vayan mejor o peor, están todas a favor.
De todo lo comentado en los párrafos anteriores se extrae que es
importante que un analista funcional sea un buen comunicador, primero
con el usuario ya que resulta fundamental que el usuario conozca todo lo
que hemos entendido y cómo se pretende llevar a cabo (no conseguir eso
es ir a ciegas) y segundo con el equipo de proyecto ya que tiene que
trasladar a documentación y hacerles entender la interpretación de lo
que el usuario quiere y cómo lo quiere.
Un buen análisis funcional no asegura el éxito del proyecto, ya que
la ejecución técnica del mismo también tiene un peso importante, pero lo
que sí es seguro es que si el análisis funcional no es bueno, la
ejecución técnica difícilmente puede salvar las deficiencias del mismo y
tocará corregir el producto una vez construido y además, por regla
general, en diferentes evoluciones, lo cual es muy costoso y tampoco
asegura que ese árbol que empezó torcido, termine por enderezarse.
http://jummp.wordpress.com/2009/11/28/la-importancia-de-un-buen-analisis-funcional/
No hay comentarios.:
Publicar un comentario