Técnica para facilitar la toma de Requerimientos

Durante la etapa de recopilación de requerimientos debemos de obtener el mayor contexto posible,
para lo cual, durante la entrevista con los Stakeholder deberemos de guiarlos a explicarse correctamente.

La técnica es realizar una serie de preguntas que lleven a obtener la información con mayor valor, para ello se clasifican por tipo se explica de manera  breve de porque la pregunta y se da un ejemplo que puede aplicar para lograr mejor entendimiento del requerimiento

Tipo	Explicación	Ejemplo
Analizar	Para Expresar un entendimiento personal de conceptos, hechos y causas	Podrías de favor indicarme en que contexto se requiere, con ello puedo tener más claro la idea
Comprobar	Para comprobar que se no se mal entendió	Podrías por favor resumirme cual fue tú entendimiento de lo que acabamos de platicar
Clasificar	Para organizar los hechos relevantes	Sería de mucha ayuda para organizar mis ideas, si de favor puedes clasificarme estos puntos
Comparar	Para revelar el conocimiento y entendimiento de hechos similares y echos diferentes	Podemos comparar el requerimiento con uno que tomamos anteriormente
Definir	Para entender la interpretación de los términos	Para que todos entendamos lo mismo, podrás ayudarme a definir este termino
Describir	Para seleccionar y definir características que proporciona una condición o una sitiación del proceso	Puedes describirme una situación típica donde podría aplicar
Argumentar	Para examinar un evento y extender sus implicaciones	Revisemos las implicaciones de esta acción y revisemos sus implicaciones
Explicar	Aclarar mediante demostración el entendimiento	Podrías decirnos como es que llegas a esa conclusión
Ejemplificar	Clarificar mediante ejemplo el entendimiento	Podrás darnos uno o dos ejemplo de como trabaja esto
Incitar	Para obtener mas información	Que otra cosa pasa a parte de ello Que mas pasa
Ondar	Para obtener mejor calidad	A que te refieres con...
Redireccionar	Para cambiar el tema al punto de discusión	Muy buen punto, podemos ponerlo en la lista, sin embargo el caso es...
Re-plantear	Para demostrar lo que se ha entendido	En otras palabras lo que tú quieres decir es...
Revisar	Recapitular o cuestionar	Podemos revisar los puntos que acabamos de platicar
Verificar	Proveer información para sustentar el requerimiento	Como podemos verificar que se ha cumplido el requerimiento

fuente: http://www.iag.biz/                                        

Las 4 fases del Analista de Negocio (Como son descubiertos)

Los Analistas de Negocio (Business Analysts BA’s) pasan por 4 fases hasta que son vistos con claridad por la organización.

La primera fase, la organización se encuentran con los ojos cerrados, los BA’s son imperceptibles a la organización descontrolada, esto se da por el ambiente actual donde cada sistema siembra su propio deterioro y destrucción.

La segunda fase, Los ojos empiezan abrirse, los BA´s son percibidos en blanco y negro, existen procesos declarados, plantillas y lista de requerimientos aislados y sin estructura alguna; ellos son detectados y los proyectos susurran acerca de ellos, ellos no tienen voz en los proyectos o sus comentarios son escuchados pero no se les entienden, el cliente no entiende para que están ahí, solo se percibe que quieren cargar más el costo del proyecto.

La tercera fase, en el movimiento del mundo externo, hace que la organización los identifique y los señale como recurso con habilidades y metodologías, que colaboran para converger las prácticas y tendencias, se ven en color tanto por la organización como por los clientes, se empiezan a trabajar con herramientas más sofisticadas que Excel y Word.

Ellos realizan sorprendentes estructuras para entender las necesidades del cliente, ayudan a entender en base a diferentes modelos la necesidad clave, haciendo más efectivo el trabajo de los demás, se ubican como una comunidad que participa dentro del proyecto.

La cuarta fase, Los BA´s son la fortaleza y los músculos de la organización, su habilidad de abstracción, analítica y creativa facilita las planeaciones y ejecuciones de los proyectos, son colaborativos con otras disciplinas y buscan el bien común, sobre cualquier interés personal, establecen un ambiente de comunicación continuo y de agilidad para alcanzar los objetivos.

Los BA´s son claramente vistos por toda la organización y tienen color, forma y nombre por el cual se les ubica, son entes que tienen presencia y sus sugerencias son seguidas por mejorar la eficiencia de los proyectos.

Cono de Incertidumbre

El cono de incertidumbre en las estimaciones

Podemos definir el proyecto en términos del esfuerzo limitado de tiempo que es requerido para lograr un objetivo. El cono de incertidumbre es la herramienta que utilizamos, consiente o inconsciente, para realizar nuestras estimaciones, llamada en ocasiones margen de error o colchón de tiempo.

La incertidumbre se encuentra en función del nivel de definición de las fases del proyecto, y tiene una repercusión directa en la estimación de costos y plazo de ejecución; estos costos pueden variar desde 0.25x hasta 4x, siendo la “x” el costo real final que solo se conoce con certeza al final del proyecto.

La incertidumbre no beneficia a ninguna de las partes y no hace más que transferir el riesgo de una parte (Cliente) a las otra (Proveedor). Un proyecto que se excede en tiempo y costo solo perjudicará a la parte que asume el riesgo.

La figura muestra el cono de incertidumbre que se tiene a la hora de generar una estimación de desarrollo; en donde el eje horizontal contiene los entregables comunes en el desarrollo, dados en función de los requerimientos

En el eje vertical se muestra el grado de error (o incertidumbre) que puede tener una estimación, creada por personas con habilidades para ello. La estimación representa el alcance en términos del esfuerzo, costo y tamaño del proyecto.

Estrechez del cono de la incertidumbre

Unas de las preguntas frecuentes de los Managers y Clientes es: “¿Si te doy algunos días más para trabajar en la estimación, puede disminuir la incertidumbre?”, lo cual es una petición razonable, sin embargo, no será posible cumplirla; varios estudios han encontrado que la precisión en la estimación de software depende del nivel de refinamiento de los requerimientos del Cliente, así como la efectividad de transmitirlos. Entre más refinados los requerimientos y su contexto, se puede obtener mayor precisión en la estimación.

Los desarrollos de software por naturaleza contienen una variabilidad alta y la única manera de bajar la variabilidad es realizando un proceso de Ingeniería de Requerimientos que controle o disminuya dicha variabilidad, con el objetivo que se tenga mejor certidumbre de las expectativas del cliente.

El cono representa la incertidumbre, que se tiene por naturaleza al realizar la estimación por las personas con habilidades para ello, por lo que es muy factible que el cono sea peor (ver Figura anterior) cuando las personas que realizan las estimaciones no tienen las habilidades adecuadas para ello. Es imposible tener mejor exactitud solo es posible tener mejor suerte

La estrechez del cono puede eliminar variabilidad en función de la metodología y prácticas que se sigan, por ejemplo; definir el Documento de Visión, Modelo de contexto, Prototipos (o Wireframes), entre otros, pueden ayudar a estrechar la incertidumbre del cono, ya que ayudan a disminuir los riesgos causados por un pobre nivel de detalle de los requerimientos que entran.

Es importante mencionar, que no se intenta detallar el producto entero, sino lo mínimo necesario para reducir la estrechez

Relación entre el cono y el compromiso

Las compañías de software inapropiadamente sabotean sus propios proyectos al comprometerlos al inicio del cono de la incertidumbre. Si una organización se compromete en la etapa de concepto inicial o durante la definición del producto el factor de error está estimado entre 2x y 4x.

El comprometerlo al principio del cono, hace que el proyecto tenga una predictibilidad indeterminada, incrementando el riesgo, la ineficiencia del proyecto, el deterioro de la administración y el éxito del proyecto.

Por lo que se recomienda que el compromiso no se realice en dichas etapas, donde la amplitud del cono hace que las organizaciones sean ineficientes y absorban los riesgos de ello.

Un buen punto para realizar compromisos puede ser, donde la incertidumbre del proyecto esté cerca del 30% (1.3x), en dicho punto se tiene un mejor control y monitoreo de los entregables y avances del proyecto, mejora sustancialmente la eficiencia de los equipos involucrados en el desarrollo

Referencias


http://www.construx.com/Page.aspx?hid=1648


http://www.measurecontrol.com/cono-de-incertidumbre/