Todos sabemos que cuanto mayor sea la ayuda de los usuarios en un
proyecto de desarrollo de software, mayores serán las probabilidades de
éxito que tenga el mismo.
No obstante es importante hacer algunas matizaciones:
1) El proyecto no se hace sólo, porque incluso existiendo una gran
ayuda por parte de los usuarios, si no se consigue interpretar con
precisión lo que quieren y no se dinamiza un feedback continuo de los
mismos durante todo el proceso de desarrollo, se incrementarán las
posibilidades de que algún requisito funcional no se haya recogido
adecuadamente o de que se haya realizado un software con una usabilidad
incómoda para los usuarios.
Estas circunstancias son fuente de innumerables problemas en las
fases finales del proyecto y provocan retrasos, sobrecostes y grandes
dificultades para cerrar el proyecto, además de crear conflictos con el
cliente que pueden perjudicar las relaciones futuras con el mismo. Esto
hace que sea fundamental el papel que desempeñan tanto el jefe de
proyectos, como el equipo de analistas funcionales y analistas
programadores.
2) Es importante que entre el grupo usuarios asignados al proyecto
haya usuarios que vayan a estar implicados en el futuro uso del sistema
de información, es decir, no es suficiente que el equipo de usuarios
esté formado por “ideólogos” o “teóricos” que se nutrirán del resultado
del trabajo de la herramienta, sino que es fundamental que participen
usuarios que después se tengan que poner el mono de trabajo y vayan a
trabajar con el software. Es importante conseguir la combinación de
ambos tipos de usuarios (tampoco es positivo que en el grupo de usuarios
no participen usuarios directores, ya que pueden existir conflictos
entre usuarios que éstos deben solucionar y también es recomendable que
el software no sólo se diseñe para el corto plazo, sino que sirva para
tareas de gestión, planificación, etc… y esta visión la proporcionan
principalmente los usuarios directores), por lo que el jefe de proyectos
debe poner en conocimiento del cliente esta necesidad, como es lógico
explicando los riesgos de que no se aplique esta estrategia.
3) Los analistas están para ayudar y para colaborar con los usuarios
en la especificación y diseño de la solución, pero no están para “dar
lecciones” a los usuarios y enseñarle cómo deben hacer su trabajo. Si
los usuarios hacen su trabajo de una determinada manera, aunque no sea
la más ortodoxa, siempre tendrá una justificación que sólo se entendería
si realmente estuviéramos haciendo su trabajo durante un tiempo y
viéramos los problemas con los que se enfrentan cotidianamente. La clave
por tanto está en la colaboración y en el diálogo, es decir, se pueden
proponer cosas al usuario, se le pueden dar ideas, pero no se le puede
dar una vuelta al calcetín de cómo hacen sus tareas, salvo que ellos
mismos lo soliciten y procurando en estos casos y en consenso con los
usuarios que los cambios sean tranquilos.
4) Es fundamental documentar el proyecto, en primer lugar con la
documentación que se especifique en las normativas de desarrollo de la
organización para la que se realiza el servicio, con las matizaciones
que indique el Director del Proyecto, en segundo lugar con la
documentación que establezcan las normativas internas de calidad de tu
organización (no requerirá un sobreesfuerzo, ya que en la mayor parte de
los casos coincidirá) y a todo lo anterior sumarle toda la
documentación de trabajo que sea necesaria para trabajar con los
usuarios, que no tienen por qué entender de modelos de datos, de
diagramas de casos de uso, etc…, es más, es un error trabajar con los
usuarios utilizando dichas herramientas, ya que estas son de utilidad
técnica y no hablan el mismo lenguaje de los usuarios. Este tipo
documentación, por tanto, no tiene por qué tener los formalismos de la
técnica y tiene como objetivo que el usuario capte lo que el analista
está interpretando y se pueda ir perfilando a partir de esto, tanto
requisitos, como casos de uso, interfaces, etc… Es muy importante
trabajar todo esto, ya que comenzar demasiado pronto con la
construcción, es algo muy arriesgado, ya que los costes de modificar
algo en las distintas fases de la construcción pueden ser muy
importantes y provocar que se tengan que reconstruir varias veces
distintas funcionalidades de la aplicación.
http://jummp.wordpress.com/2010/02/13/el-papel-de-los-usuarios-en-un-proyecto-de-desarrollo-de-software/
No hay comentarios.:
Publicar un comentario