Visur

1. Jose Luis Benito
y Gabriel Jimena
Los requisitos como
proceso Social

2. El origen
Servicio
• Un medio para aportar VALOR – Garantía de disponibilidad del
a los clientes, facilitando los servicio: que asegura al cliente que
Resultados que los clientes dispondrá de la funcionalidad en el
momento y forma en que lo
quieren conseguir sin asumir necesite. (Disponibilidad, Capacidad,
costes y riesgos específicos Continuidad y Seguridad)
Valor para el cliente es la
conjunción de:
– Utilidad para el negocio:
funcionalidad que el cliente
recibe orientada a alcanzar sus
metas
2

3. El origen
¿Pueden las relaciones
sociales ser la causa del
fracaso de proyectos y
servicios?
3

4. El origen
Éxito en la Gestión
• Proporcionar servicios:
– Que aporten valor al
cliente
– A coste previsto
– En el plazo planificado
• Aportar valor al cliente
significa:
– Hacer mas eficaces a sus
activos
4

5. El origen
El analista tiene la responsabilidad de documentar en
Requisitos la forma de aportar valor al negocio:
• Funcionalidad adecuada en el tratamiento de la información
• Garantía de servicio
para que el resultado final satisfaga al cliente con la eficacia requerida.
Si la identificación de los requisitos no es adecuada se produce:
• Frustración en cliente y en proveedor
• Desconfianza del uno en el otro
• Fracaso de los proyectos y de los servicios
5

6. El problema
• No se acaba en plazo
• Se excede el presupuesto
• No satisface expectativas del cliente
• Requisitos incompletos: 13%
• Poca participación de los
Requisitos
Éxito usuarios: 12%
Fracaso 52%
• Expectativas poco realistas:
28% 72% Otros...
10%
48%
• Cambios a los requisitos: 9%
• Requisitos innecesarios: 8%
Fuente: Standish Group, CHAOS CHRONICLES
6

7. El problema
¿Qué hay de común detrás de estas causas?
• Requisitos incompletos: 13%
• (M y H)
• Poca participación de los usuarios: 12%
• (H)
• Expectativas poco realistas: 10%
• (H)
• Cambios a los requisitos: 9%
• (M y H)
• Requisitos innecesarios: 8%
• (M y H)
LA NECESIDAD DE BUENAS RELACIONES SOCIALES

8. Investigación de requisitos
Los errores en la fase de toma de requisitos son los más:
 numerosos (más del 50% de promedio)
 costosos de reparar
 5 a 10 veces más en la fase de codificación
 100 a 200 veces más en la fase de mantenimiento
Tiempo invertido en esta fase es inferior al 15% del total
del proyecto
Las recientes herramientas para Ingeniería de Requisitos
han tenido escaso impacto en la calidad de los
requisitos obtenidos del usuario.
8

9. Beneficios de una buena
Investigación de Requisitos
• Sienta expectativas comunes y se documenta el acuerdo
Cliente – Proveedor:
 Alcance del proyecto o servicio
• Optimiza el tiempo de desarrollo
• Optimiza la productividad de los desarrolladores
• Minimiza la necesidad de cambios a destiempo
• Base de referencia para evaluar los cambios posteriores
• Mejor estimación de costes y plazos
• Mayor efectividad en las pruebas de aceptación
• Reduce el tiempo de pruebas
9

10. Defectos en los requisitos
• No están todos
• Hay requisitos incorrectos
• No se entiende la
redacción
10

11. Obstáculos en los Analistas
• Se enfoca en aspectos técnicos y no ve al usuario como cliente
• No entiende el lenguaje de usuario y se producen errores de
interpretación
• Acepta requisitos tal cual, no filtra contra negocio ni contrasta
distintas fuentes
• No tolera ni gestiona la ambigüedad, no sabe cómo encararla
• Le gusta ser independiente
• Cree conocer la solución enseguida, piensa que él suple las carencias
de información y hace uso de cierta arrogancia
• Hace presunciones basadas en otras experiencias
• No entrevista a todos los afectados
• Evita entrevistas desagradables
• Investiga sin método, por instinto
• No reconoce indicios de que falta algo
11

12. Obstáculos en los Usuarios
• No lo cuenta todo y algunos requisitos no afloran
• Ambigüedad en la descripción, tiene ideas confusas y es incapaz
de concretar
• No entiende el lenguaje/argot técnico
• Tienen distintos requisitos y a veces son incompatibles
• No se fían del desarrollador, tienen miedo y desconfianza
• No informa de todos los afectados
• No suministra toda la documentación
o está desactualizada
• Síntomas vs. Requisitos
• Propone solución en lugar de
comunicar necesidad
12

13. Obstáculos en ambos:
Analistas y Usuarios
• Desconfianza mutua
• No se escuchan el uno al otro
• Ignorar conflictos existentes
• Dificultad de expresión
• Malos modos en el trato
• Personalidades incompatibles
13

14. Premisas para la investigación
de requisitos
Considerar al usuario como Cliente
El proveedor debe ser visto por el cliente como su “asesor de
confianza”
Los requisitos los suministra el cliente/usuario
 Todas las áreas del usuario deben ser consultadas
 El usuario no sabe lo que interesa al proveedor
 El usuario no tiene conocimientos técnicos
 El usuario es como el enfermo: “no conoce su enfermedad pero sabe
que le duele”
14

15. Dificultades a enfrentar en el
proceso
• Analizar pautas para asumir papel de proveedor de servicios
TI a un cliente
• Pensar en crear servicios y no solo en desarrollar software
• Ganarse la confianza de alguien que tiene una idea
preconcebida y posiblemente muchas malas experiencias
• Conseguir espacio para la decisión, no obedecer al dictado
• Saber preguntar
• Vencer las resistencias y re enmarcar la conversación
• Ser capaz de ayudar a identificar problemas sin ofender
• Colaborar a superar diferencias entre usuarios
• Proponer soluciones con visión de negocio
• Ayudar a priorizar requisitos
15

16. Nuestra Propuesta
Utilizar la metodología sistemática y repetible
 Etapas, actividades y entregables prefijados
 Checklist de comprobación.
 Aprobación del cliente
Propiciar la madurez profesional
Desarrollar habilidades sociales
 Relación Cliente Proveedor
 Establecer relación de confianza
 Facilitar la comunicación y resolución de conflictos
16

17. Madurez profesional
Condición “sine qua non” para el éxito en el proceso
• Su éxito está en el éxito de su cliente
• Lo importante no es la calidad técnica sino la satisfacción del cliente
• El objetivo no es responder exactamente a la petición del cliente, sino
resolver su problema
• El Proyecto o Servicio se concibe desde la visión del cliente y no desde
la excelencia técnica
• La tecnología solo es un medio necesario
• Los cambios en el proyecto no son una “violación” del acuerdo sino
una necesidad del negocio
• El cliente “no mete goles”, ajusta el alcance a lo necesario
17

18. Modelo Cliente – Proveedor
Cliente
 Persona que plantea un problema o necesidad
Proveedor
 Persona que propone e implanta una solución
Compromiso
 Colaborar en la resolución, sin utilizar autoridad formal
18

19. Modelo Cliente - Proveedor
Beneficios Retos
• Reduce los Temores • Actitud positiva
• Aumenta la Colaboración • Control Emocional
• Reduce los Conflictos • Trabajo en Equipo
• Facilita el acuerdo • Dar y recibir confianza
• Se toman decisiones
• Se disfruta del trabajo
19

20. Merecer Confianza
1. Hay que darla primero y asumir el riesgo
2. Requiere tiempo
3. Se construye sobre la integridad y
el respeto
4. Se demuestra con lo que hacemos, no
con lo que decimos
5. Se ve en las situaciones difíciles del otro
6. No es permanente
7. Se conquista todos los días
8. Frágil. Fácil de romper y difícil de reparar
9. No se necesita ser perfecto para ser confiable
10. La confianza es la puerta de la credibilidad
Confianza = Credibilidad + Cordialidad + Competencia
20

21. Temores fruto de la
desconfianza
USUARIO - CLIENTE ANALISTA - PROVEEDOR
1. No obtener lo que quiero 1. Le culpará de cualquier fallo
2. El analista no entiende mi 2. El cliente no transigirá con nada
negocio 3. El cliente tiene una idea fija
3. El analista no entiende mis sobre una solución concreta
limitaciones (ej. Presupuesto) 4. El cliente no sabe lo que
4. El analista no es competente necesita
5. El proveedor no terminará en 5. Plazos de finalización no
plazo realistas “para ayer”
6. Que no le guste el analista 6. El comportamiento cliente es
7. Parecer incompetente por parte del problema
desconocer informática 7. El Cliente no querrá
comprometerse a nada
8. Parecer incompetente en
negocio
21

22. La comunicación
Comunicación es el proceso mediante el cual se consigue que
los participantes tengan un entendimiento común sobre un
asunto determinado
• No es lo que decimos, sino lo que el interlocutor entiende.
• Sabemos lo que entiende a través de su respuesta
• Obtenemos su respuesta escuchando
• La comunicación es sensible a
 Contenidos
 Posición social de los interlocutores
 Carga emocional
22

23. Percepción y realidad
• El mapa no es el territorio
• Nuestra realidad es lo que
percibimos
• Dos personas pueden tener
visiones diferentes de un
mismo asunto (estar en
desacuerdo y…. llevar ambos
“razón”)
Julian Beever
23

24. El consenso para resolver
Conflictos
1. Conflicto entre interesados
Ej.: Dos o más interesados tienen requerimientos
incompatibles
2. Proveedor - Usuario
Ej.: Algunos interesados exceden el alcance
Resolución:
Se busca el consenso
24

25. Técnicas a aplicar (1)
Entrevistas de identificación de requisitos
Reuniones de puesta en común de expectativas y de resolución
de conflicto de intereses y de limitación de alcance
Técnica de preguntas adaptadas a conocer necesidades y
procesos en términos de negocio
Observación de ambientes de trabajo sin injerencia ni generar
desconfianza
Cuestionarios
Análisis de procesos de información y separar de procesos
industriales o productivos
25

26. Técnicas a aplicar (2)
Generación de Informes convincentes y claros sobre el alcance
y objetivos identificados en requisitos
Presentaciones de alcance cubierto por el proyecto o servicio
dando relevancia a los asuntos presentados por cada uno de
nuestros interlocutores de modo que cada uno se sienta
identificado con lo que se presenta.
Técnica para alcanzar el acuerdo sobre la cobertura del servicio
a generar y sobre las prioridades asignadas a las distintas
funciones y requisitos.
Mantener la llama de la cordialidad
26

27. Cómo se consigue el éxito
El éxito de un servicio empieza
en LA ARMONIA E INTERES
EN TRABAJAR EN EQUIPO,
éxito de la relación
interpersonal entre Cliente
(área de Negocio) y
Proveedor (TI) que induce a
tener objetivos comunes en
el trabajo y al adecuado
nivel de implicación.
27

28. Nuestra propuesta
formativa
La Experiencia demuestra que recordamos:
• 20% de lo que oímos
• 30% de lo que vemos
• 50% de lo que oímos y vemos
• 70% de lo que hacemos

29. Nuestra propuesta
formativa
Técnica Docente:
• Metodología repetible de educción de requisitos en 8
etapas
• Teatralizar situaciones frecuentes en captura de requisitos
• Simulación de comportamientos y entornos habituales del
analista
• Entrenamiento de dificultades de relación en requisitos
• Descubrimiento de carencias y oportunidades de mejora en
la conducta con usuarios

30. Preguntas
30

31. Los requisitos como proceso
Social
MUCHAS GRACIAS
31