Feb
13
2013

Las 5 Realidades de los Requisitos de Usuario que un Jefe de Proyecto debe conocer (NICAS)

Los requerimientos de usuario no tienen una única representación, no son una única realidad sino que en verdad hay una serie de distintas versiones de los requisitos atendiendo al momento del desarrollo en el cual nos fijemos y por ello el jefe de proyecto debe conocerlas para poder gestionarlas mejor.

 

Imagen de feryswheel
Imagen de feryswheel

Cuando me refiero a que no tienen una única representación, no me refiero a que los podamos subdividir o agrupar en distintas partes que tienen sentido por si solas: Facturación, Cobros, Empleados,… sino a que la totalidad de los requerimientos solicitados tienen una composición diferente en función del momento del desarrollo en el que el jefe de proyecto se focalice: visión del cliente, visión del jefe de proyecto,…

 

Las 5 Realidades


Para que quede más claro veamos las 5 realidades de los requisitos de usuarios que todo jefe de proyecto debe conocer.
 

  • Necesidad. Los requerimientos de un proyecto surgen debido a una necesidad de los usuarios (simplifiquemos tomando que usuario y cliente son el mismo actor). Esa necesidad abstracta como tal, si la pudiéramos conocer, formaría un conjunto determinado de requisitos.
  • Interpretación. El usuario entiende la necesidad que tiene de una determinada forma e interpreta cual es el conjunto de requisitos de usuario que la pueden satisfacer.
  • Comunicación. Con la idea que ha interpretado el usuario de su necesidad, trata de comunicarla al Jefe de Proyecto y a su equipo de desarrollo y logra transmitir otro conjunto de requisitos que puede ser diferente al que él había interpretado.
  • Asimilación. El equipo de desarrollo junto al Jefe de Proyecto en función de su destreza, experiencia, conocimientos y formación se forma una idea del conjunto de requerimientos que no tiene por qué coincidir con la idea usuario.
  • Solución. El software instalado en producción da soporte a un conjunto determinado de requerimientos de usuario que en función de la pericia de los desarrolladores y del Jefe de Proyecto y de las capacidades de los usuarios pueden no coincidir con los anteriores.

 

Capacidad de Análisis, Capacidad de Comunicación


La situación ideal sería que todos los conjuntos de requerimientos fueran iguales pero lo normal es que se vayan diferenciando unos de otros.
Cuanta mayor capacidad de Análisis tenga el cliente, mejor entenderá la necesidad que tiene y cuanto mejores sean sus capacidades de comunicación mejor la transmitirá al Jefe de Proyecto y a su equipo de desarrollo.

La labor importante del Jefe de Proyecto es la de ser capaz de encontrar la verdadera necesidad aunque el propio usuario la desconozca total o parcialmente.

Debe ser capaz de identificarla y de implementar una solución software que satisfaga completamente los requisitos de esa necesidad, es decir Necesidad = Solución.

¿Quieres llevar tus Proyectos a otro nivel?

En tu mano tendrás 15 Lecciones sobre liderazgo, equipo, motivación, planificación, éxito,... extraídas de Juego de Tronos y explicadas de forma sencilla y práctica.
¿Las vas a dejar escapar? ¡Quiero ser el mejor! ¡Quiero ser la mejor!
¡Las quiero!

Si no podemos lograr que sean iguales cuanto más cercanos estén una de otra mejor será la aproximación que hayamos obtenido.



¿Crees que el Jefe de Proyecto logra acercar los Requisitos de la Solución a los Requisitos de la Necesidad en los desarrollos que conoces?

 

Consigue Más de 100 Libros gratis

Suscríbete a nuestro newsletter por email y conseguirás Más de 100 Libros Gratis sobre Gestión de Proyectos, Innovación, Emprendimiento, Empresa, etc. directamente en tu correo


The following two tabs change content below.
Te Ayudo a Dirigir tus Proyectos al Éxito. Sólo puedes ir más rápido, juntos podemos ir más lejos ¿Conectamos?

10 Comentarios+ Escribir Comentario

  • Yo a decir verdad estoy con ésto un poco confuso … hablando de roles, la role del PM es algo, y la role del Business analyst o del Business arquitecto es algo diferente (ojo! no estamos hablando de que el PM puede también hacer la role del BAn o BAr (o SAr – Solution Architect)).

    He visto taaaaantos proyectos donde el PM se quiere poner a jugar a hacer la solución y a entender todo en tanto detalle y a querer hablar de los detalles de la solución (porque tiene experiencias prácticas, es verdad, porque tiene miedo de que “no tiene tomados todos los cabos” o porque simplemente quiere mostrar sus conocimientos) y pierde con ello precioso potenciál y tiempo necesario para coordinar, para requerir deliverables, para discutir con el proveedor externo, para controlar facturas y efforts, para (ayudar a) identificar riesgos, monitorearlos, para crear y gestionar teams y comunicar con los team leaders …
    Requerimientos son, en mi opinión (no digo los iniciales que definen el proyecto y son la “orden” para el PM) pero los requerimientos son un deliverable igual que el Solution Design, que un posible análsis y mejora de procesos (por LSS por ejemplo), de una o varias migraciones de datos, de una Data architecture (introduciendo por ejemplo un Data Quality Framework para la domain concreta) y para cada uno de éstos deliverables DEBE EXISTIR un miembro del team responsable y accountable … si lo es el PM, entonces va a fajarse por todo, y teniendo expertos que ganan bastante dinero per sin “accountability” ello deforma la capacidad de acción y dinámica del proyecto. Y créanme que éste tipo de proyectos he visto más de 50, y en ninguno que yo me acuerde no terminó ello muy bien … “separation of concerns” en un principio arquitectónico que yo incluyo también en Gestión de Proyectos…
    (discúlpen mi espaňol, más de 23 aňos que no lo hablo diariamente … )

    • No tienes por que disculparte Erik que se te entiende bien.

      Gracias ante todo por aportar con tu comentario.

      Este tema es dificil porque como bien planteas en cada organización o en cada empresa los roles se separan, se diferencian y se nombrar de formas diferentes. Podemos tenemos un Business Partner y un Solution Manager y tras ellos un Project Manager de un Proveedor que es el que hará el trabajo.
      En cada equipo deberíamos tener un especialista en cada conjunto de requerimientos pero no siempre es así, por eso aglutinamos entorno al Jefe de Proyecto la resposabilidad de los mismos (ya que la responsabilidad última del proyecto es suya) aunque el no puede/debe estar al pie de todos los detalles de un Proyecto pero si debe controlarlos para que no supongan un riesgo. Project Manager aqui puede significar otros roles o incluso más de un rol en otras organizaciones.

      La idea que quería transmitir es cuidado con los Requisitos y la forma en la que se presentan debemos mantener la perspectiva de que estamos dando respuesta a una necesidad y debemos cubrirla satisfactoriamente con la solución que propongamos.

      Saludos.

  • En la medida que el usuario/cliente tenga claro el proceso que esta solicitando se le automatice o se le mejore, la tarea del Jefe de proyecto y su equipo va ser mas llevadero y por su parte el Jefe de Proyecto en la medida que tambien tenga claro el proceso a automatizar y su experiencia automatizando procesos semejantes en otros negocios, seguramente la igualdad Necesidad = solucion va ser mas equivalente. Se da por descontado que las automatizaciones o mejoras a las mismas estan alineadas con los objetivos del negocio, es decir se esta auitomatizando o mejorando lo que va incidir directamente en el resultado del negocio.
    El otro punto importante es la ingenieria de requerimiento (funcionales y no funcionales), si esto no se define detallamdamente y el usuario aprueba lo definido se corre el riesgo que la igualdad Necesidad = Solucion se distancie.
    El acercamiento de la igualdad va depender tanto del usuario dueño del proceso como del Jefe de Proyecto

    • De acuerdo contigo Jose Luis, como comentaba en el artículo, el usuario impacta también de forma importante en la captura de los requisitos aunque por desgracia no podemos elegir al mismo, lo que si podemos hacer es prepararnos como jefe de proyecto para conocer la situación y poder paliarla.

      Gracias por mostrarnos tu visión.

      Saludos.

  • Perdón que me meta en su comentario, yo tengo mas de 40 años desarrollando sistemas (Comencé en 1972), y les puedo decir que, al inicio mucho de lo que comentan se daba, hoy la empresa y todos sus integrantes estamos certificados CMMI-DEV nivel 3, esta metodología nos ha permitido verificar desde un inicio lo que entendemos, directamente con el cliente, y una vez que se ha analizado y diseñado, estos se verifican con el cliente antes de codificar una linea de código, inclusive se valida la matriz de pruebas que se aplicaría una vez terminada la solución.

    Cada documento y cada componente de la solución se valida por otra persona antes de darlo por bueno, Y todos los componentes pasan por las pruebas de una area de QA.

    Todo esto nos ha dado como resultado el obtener productos 100% apegados a las necesidades de los usuarios, y a tiempo.

    Al principio es complicado pero una vez aplicándolo se vuelve mas ágil.

    Espero que mi comentario les sirva

    • Gracias Ricardo por mostrarnos vuestro caso de éxito, habeis podido solventar la situación aplicando CMMi Nivel-3.

      Saludos.

      P.D.: No tienes que pedir perdón por comentar nada, pretendemos que sea un foro abierto en el que cada uno podamos aportar nuestra visión de los hechos pudiendo coincidir algunas veces y discrepar otras pero el debate creo que es bueno para todos.

  • Hola, me ha pasado igual que a Erik. Estaba pensando en roles, y aunque una persona pueda asumir N roles, entre ellos el de Jefe de Proyecto, no veía muy apropiado que el ROL de Jefe de Proyecto se metiera en esos temas.

    Por otro lado, entiendo lo que comenta Ricardo Sánchez, y coincido en que CMMI (en realidad, una metodología basada en ese marco de procesos) es un gran aliado al proporcionar un gran número de puntos de control coherentes y progresivos hacia una solución adecuada.

    Lo que veo más importante, y el artículo deja entrever, es que el usuario no tiene porqué conocer bien su problema, y menos comunicarlo (ni nosotros asimilarlo, interpretarlo ni desarrollarlo). El usuario suele basarse en síntomas percibidos, y tiene su propia política interna que puede complicar los requisitos, al no tener porqué estar estos alineados (cuántas veces una solución software facilita la vida a un departamento y se la complica innecesariamente a otro).

    • Correcto Roberto.

      Gracias por mostrar tu opinión.

      Saludos.

  • Hola Julían

    Muy interesante post, concuerdo con lo que mencionas que no debemos de perder la perspectiva de lo que solicita y tratar de atender las necesidades con las soluciones correctas.

    Sean los roles que interactuen para hacerlo como comenta Erik y Roberto.

    Me quedo con la frase:

    “Debe ser capaz de identificarla y de implementar una solución software que satisfaga completamente los requisitos de esa necesidad, es decir Necesidad = Solución.”

    Saludos

    • Gracias nayeli por tomarte el tiempo de comentar.

      Muchas veces es dificil no perder la perspectiva pero es lo que debemos intentar para concluir con éxito.

      Saludos.

¿Te ha gustado? Pues sólo cuesta un Comentario. ¡Gracias por adelantado!

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

No te pierdas nada de lo que publiquemos…

Comparte lo que te gusta…

¡Síguenos en Twitter!



¡Síguenos por email!

Recibe nuestro contenido exclusivo para suscriptores: Más de 100 Libros gratuitos, notificaciones de nuevo contenido, ventajas, etc.

Únete a otros 12K suscriptores

¡Síguenos por email!

Recibe nuestro contenido exclusivo para suscriptores: Más de 100 Libros gratuitos, notificaciones de nuevo contenido, ventajas, etc.

Únete a otros 12K suscriptores

¡Síguenos por email!

Recibe nuestro contenido exclusivo para suscriptores: Más de 100 Libros gratuitos, notificaciones de nuevo contenido, ventajas, etc.

Únete a otros 12K suscriptores