Requisitos de usuario

El xito de un proyecto de tecnologa es el valor final del resultado para el negocio

Los criterios tradicionales para juzgar el xito de un proyecto de tecnologa ya no valen. Una deficiente identificacin de requisitos, la falta de objetivos claros y la inexistencia de anlisis de usuario, son causas frecuentes del fracaso. Los nuevos modelos de desarrollo, iterativos en su naturaleza, asumen que los requisitos van a cambiar en el tiempo por muchas razones. Si cambia el modelo de desarrollo, la definicin de xito tambin debe hacerlo, y fundarse ms en el valor final del resultado del proyecto para el negocio.

Caractersticas de un buen requisito

1. Contiene una idea. Si un requisito tiene ms de una, debera ser troceado en dos o ms requisitos. 2. Es claro. La idea del requisito no est abierta a interpretacin, si no lo fuera, las partes debern clarificarlo. 3. Es genrico. Los requisitos deben contener informacin general, asegurando que las posibilidades del diseo no se encuentren limitadas. 4. Es verificable. Al final del proceso es posible comprobar de forma fcil que el requisito se ha cumplido. Ejemplos de requisitos de usuario:

La pgina web deber visualizarse correctamente para el 95% de nuestros clientes en Mxico. Las noticias que no obtengan ms de 50 visitas nicas al mes sern archivadas automticamente. Las direcciones de Internet debern estar bien construidas y en el idioma del usuario. Se deben reducir los errores al seleccionar los productos con la herramienta. El diseo visual debe cumplir la normativa corporativa existente. El nuevo diseo debe aumentar las visitas a la seccin de productos.

Ejemplos de requisitos del sistema:

El sofware debe ser escrito en un lenguaje compatible con el existente. La base de datos ser Oracle 10 sobre HP-UX.

Identificar y verificar requisitos de usuario implica una relacin y conocimiento entre el diseador y los usuarios del producto. Si en tu empresa el diseador "slo pone colores", tienes muchos puntos para que tu proyecto no produzca ningn beneficio.

Tcnicas de recogida de requisitos

Los requisitos estables son fundamentales para la definicin y evaluacin de un producto
Incluso si existen unos requisitos iniciales, el proceso los clarifica, expande y confirma. Su fin es obtener informacin suficiente, relevante y apropiada. Existen una serie de Tcnicas bsicas que son flexibles y combinables:

Cuestionarios: son buenos para obtener respuestas a preguntas concretas para un grupo amplio de personas. Entrevistas: pueden ser estructuradas, semi-estructuradas y desestructuradas. Grupos de trabajo: renen a un grupo de personas a discutir o trabajar juntas. Observacin directa: se trata de pasar un tiempo en la actividad diaria de las partes implicadas, observando qu ocurre en su actividad diaria. Estudio de documentacin: como manuales, estadsticas o documentos.

Organizar tu primera sesin de recogida de requisitos puede ser desalentadora, algunos consejos:

Cntrate en identificar las necesidades de todas las partes. Aglutina a todas las personas y partes. La visin de concunto es importante. Involucrar a un representante de cada grupo no es suficiente. Usa una combinacin de tcnicas Apyate con prototipos o descripciones de las funcionalidades. Haz pruebas piloto para verificar las sesiones. El mundo ideal no existe, y las limitaciones de tiempo, de recursos o de experiencia te obligarn a tomar decisiones de compromiso. La forma de documentar o grabar es tan importante como la tcnica que utilices.

Desarrollo iterativo
El ciclo de vida iterativo se basa en la amplificacin y refinamiento sucesivos de un sistema software mediante mltiples iteraciones, con retroalimentacin cclica

El sistema se incrementa a lo largo del tiempo, iteracin tras iteracin. La salida de una iteracin no es un prototipo experimental o desechable, ms bien es un subconjunto con calidad de produccin del sistema final. Cada iteracin conlleva la eleccin de un pequeo conjunto de requisitos que permite rpidamente disear, implementar y probar.

Beneficios del desarrollo iterativo

Reduccin temprana de riesgos. Progreso visible desde las primeras etapas. Una temprana retroalimentacin, refinando el sistema a las necesidades reales de los usuarios. Gestin de la complejidad: el equipo no se ve abrumado por la parlisis del anlisis. El conocimiento adquirido en un ciclo se puede utilizar metdicamente para mejorar el propio proceso de desarrollo.

Si creas software las personas son lo primero

El enfoque Taylorista no tiene sentido para un trabajo altamente creativo y profesional como es el desarrollo de software
Uno de los objetivos de las metodologas tradicionales de desarollo de software es crear un proceso donde las personas involucradas sean partes reemplazables. Las personas son como recursos que estn disponibles en varios tipos: analista, diseador, programador, gerente... Los individuos no son tan importantes, slo los roles lo son. De esa manera, en un proyecto no importa qu analista o programador es, slo hay que saber cuntos son para saber cmo afecta al plan. Si esperas que todos los desarrolladores se junten en unidades de programacin compatibles no intentars tratarlos como individuos, eso baja la moral y la productividad. Las personas capaces se buscarn un lugar mejor donde estar y acabars con lo que deseabas: unidades de programacin compatibles. Decidir que las personas son lo primero es una gran decisin que requiere mucha determinacin.

La nocin de persona como recurso est profundamente inculcada en el pensamiento de los negocios. Las races las encontramos en Frederick Taylor. En la administracin de una fbrica el enfoque Taylorista puede tener sentido, pero para un trabajo altamente creativo y profesional como es el desarrollo de software, eso no se sostiene.

Profesionales responsables
La nocin clave del sistema Taylorista es que la gente que hace el trabajo no es la adecuada para entender la mejor manera de hacerlo. En una fbrica puede ser verdad por varias razones:

Porque la mayora de los obreros no son las personas ms inteligentes o creativas. Porque hay una tensin entre la gerencia y los obreros por sus diferentes salarios.

La historia reciente nos demuestra, cada vez ms, lo falso que es esto para el desarrollo de software. Cuando se quiere contratar y retener a gente capaz, hay que reconocer que son profesionales competentes, que son los mejores para decidir cmo dirigir su trabajo tcnico. La nocin Taylorista de un departamento de planificacin separado, que decide cmo hacer las cosas, slo funciona si los planificadores entienden cmo hacer el trabajo mejor que los que lo hacen. Si usted tiene personas brillantes y motivadas que hacen bien su trabajo, eso no se sostiene.

Manejando un proceso orientado a las personas

El liderazgo tcnico es un gran cambio para muchas personas en posiciones gerenciales. Requiere compartir una responsabilidad donde desarrolladores y gerencia tienen un mismo lugar en la direccin del proyecto. La gerencia an juega un papel, pero reconoce la pericia de los desarrolladores. Una razn importante para hacerlo es el ritmo de cambio en nuestra industria: despus de unos aos, el conocimiento tcnico se vuelve obsoleto. La vida media de las habilidades tcnicas no tiene comparacin en otra industria. Entrar a la gerencia significa que tus habilidades tcnicas se marchitarn rpidamente.