1

Escoger uno de los consejos y establecer" una presentacin corta con lo como parte del consejo.
Sugerencia 20: Armas de Influencia - Prueba Social

El pasado mes se debati la coherencia y el compromiso de uno de los seis "armas de influencia",
investigado por Robert Cialdini y documentado de la influencia: ciencia y prctica. Es posible que
no haya corriente directa, pero se puede incrementar su impacto en el ejercicio de la profesin. En
los prximos Consejos rpidos se discuten prcticas, ticas de Bas formas indirectas de ejercer
poder con estos principios.
Prueba Social: Cuando no se est seguro de cmo actuar, tienden a seguir el ejemplo de las
personas que se puede identificar. Las personas que se identifican con un grupo en particular son
ms fuertemente influenciada por ese grupo de personas que se consideran a s mismos los
forasteros. Un miembro del grupo puede ser parte de un partido poltico, una congregacin o un
sindicato. Una persona puede dar la impresin de ser parte de un grupo, pero no se identifican con
el grupo, as como un lder o un rebelde. Prueba Social puede ser un efecto de refuerzo.
Ejemplo: La mayora de las personas son inciertas al unirse a una nueva organizacin o grupo, y
esperamos que las personas que estn a su alrededor seales de comportamiento. Es la poltica
de "puerta abierta" seguro? Los testimonios y las indicaciones de los clientes puede influir en
prueba social.
tica: prueba Social puede ser utilizado para comportamientos deseados en los miembros del
grupo, y puede ser utilizada en muchas maneras, intencional y por error. La empresa quiere
aumentar sus ventas gracias a comentarios de los clientes y un sistema de clasificacin 0-5
estrellas, como Amazon.com. Usted sabe los compradores a menudo creo que, "todas las personas
saben algo!" Esto es tica, siempre que la clasificacin y los exmenes son imparciales. Exmenes
falsos u omitir comentarios negativos son obviamente inmorales. Hay muchas formas de sesgo la
apariencia de popularidad, algunos muy sutiles. Puede introducir un sesgo por:
- Comparando su producto en la parte inferior de la camisa del husillo alternativas,
- Las mesas con los principales o preguntas engaosas,
- Limitar sus comentarios a los consumidores conocidos por favorecer su producto.
Hay algo de verdad en "dress for success" y otros principios basados en prueba social, pero sea
cuidadoso. Puede ser una lnea muy fina entre "fake que "hasta que" y al fraude.
Sugerencias: prueba Social es un efecto importante a tener en cuenta durante el planeamiento y la
gestin del cambio. Los interesados a menudo se agrupan segn sus relaciones con la
organizacin, el proyecto y la solucin. Para aprovechar las ventajas de prueba social, los
interesados deben tambin agruparse en funcin de su relacin con la gente a la que identifica
como compaeros. Esto puede revelar las oportunidades para generar un impulso, y denunciar las
fuentes de resistencia.

2

Sugerencia 21: Armas de Influencia - Gusto

Aprender a compartir su propio QT a http://community.theiiba.org/QT4BBALast meses hemos
hablado prueba social, uno de los seis "armas de influencia", investigado por Robert Cialdini y
documentado de la influencia: ciencia y prctica. Es posible que no haya corriente directa, pero se
puede incrementar su impacto en el ejercicio de la profesin. En los prximos Consejos rpidos se
discuten prcticas, ticas de Bas formas indirectas de ejercer poder con estos principios.
Le gusta: la gente que le guste tener una mayor influencia sobre usted que la gente no le gusta o
de los cuales no tiene ninguna opinin. La fundacin de gusto es el de encontrar algo que
realmente gusta de la gente que est tratando de influenciar. Que sentido la sensacin, y responder
en especie.
Ejemplo: para 12 aos, Joe Girard de GM fue #1 vendedor, vendiendo aproximadamente cinco
coches y camiones por da. Posee el rcord mundial Guinness como el "Mejor vendedor de
coches". Su xito se basa en dos cosas: el precio justo y ser alguien de quien me gust a los
clientes comprar.
Bas eficaces tienen que ser capaces de vender los cambios a los interesados, por lo general una
difcil perspectiva. UNA LICENCIATURA que no gusta no puede gestionar el cambio: sentimientos
negativos sobre el mensajero la perspectiva de los interesados, lo que les hace buscar el lado
negativo. De manera similar, un BA que es querido puede alentar difcil cambiar de una forma
positiva.
tica: no se puede hacer que una persona como usted, pero puede animar a la gente a como una
imagen de usted. Tergiversar esta forma - ser todo para todos, puede tener xito en el corto plazo.
Finalmente, los interesados pueden pensar de usted como falso y de poca confianza, y como que
no me gustara.
Consejos: hay cinco tcnicas generales para animar a la gente a que:
Atractivo: la belleza fsica abre las puertas, y hace que sea ms fcil para que la gente como
usted.
Similitud: coincide con el lenguaje corporal de los actores, las analogas y el tono.
Alabanza: Dar felicitaciones. Incluso cuando no claramente merecido, personas como usted.
Repeticin: Cada encuentro positiva refuerza gusto. Pueden ser breve.
Asociacin: estar en un entorno positivo refleja muy bien de usted.
Recuerde, usar estas tcnicas para expresar el gusto que tiene para los dems y no para
manipular.

3


Sugerencia 22: Armas de Influencia - Autoridad

El ltimo mes hemos discutido gusto -- uno de los seis "armas de influencia", investigado por
Robert Cialdini y documentado de la influencia: ciencia y prctica. Es posible que no haya corriente
directa, pero se puede incrementar su impacto en el ejercicio de la profesin. En esta serie de
Consejos rpidos se discuten prcticas, ticas de Bas formas indirectas de ejercer poder con estos
principios.
Autoridad: se tiende a respetar y obedecer las figuras de autoridad y las personas que se ven como
figuras de autoridad. Generalmente es beneficioso para obedecer a alguien que sabe ms, tiene
ms a la informacin, o tiene ms poder, pero no siempre. Autoridad viene en dos categoras
principales: posicional y personal.
Autoridad posicional es a menudo utilizado para controlar. Se basa en las funciones de
organizacin, la capacidad de premiar y castigar, y puede desvanecerse con familiaridad. Los
ttulos indican cunto autoridad posicional tiene una persona, y el tipo de autoridad (Mdico,
Director del Proyecto). Ropa mostrar pertenencia a un grupo con autoridad (trajes de negocios,
batas de laboratorio, uniformes de la polica). Adornos son lujos, ajustes y contextos especiales
que reflejan la situacin y autoridad (oficina grande, tanto en el escenario).
Autoridad Personal es a menudo utilizado para influir en ellos. Se basa en la idea de que una
persona sea tico, confiable y til, o un experto en la materia. Que se perciben a travs del respeto,
y por lo general se expresa a travs de alto estatus, comportamientos inconscientes (dominante
lenguaje corporal, el tono de voz, discurso lento, de su confianza, serenidad). Estos
comportamientos suelen reflejar lo que cada uno piensa de s mismo, pero que se puede aprender
(facilitadores, actores, personal de ventas).
Ejemplo: Los analistas de negocio a menudo luchan por lograr el apoyo de la gente con autoridad
posicional. Muy a menudo un PM niega un BA el tiempo necesario para obtener los requisitos. Una
de las respuestas es el de discutir los BA plan, explicando los riesgos y beneficios de cada
actividad. Esto demuestra autoridad personal mediante el asesoramiento tcnico. Escalada se basa
tambin en el BA tener autoridad personal; de lo contrario, la situacin puede considerarse
insignificante.
tica: una desconcertante ejemplo del poder de autoridad es la infame Milgram 1963 Estudio del
Comportamiento de la obediencia. Alinear sus objetivos a principios de la organizacin y los
objetivos a fin de garantizar que su camino es el mejor para la organizacin.
Consejos: Despus de cada sesin, analizar la manera autoridad. Autoridad personal y posicional
alinear o conflicto? Fueron los ttulos significativos? Era el lder de carga? Cmo puedo mostrar
autoridad? Qu oportunidades ha echo en falta? Confiar en su experiencia, y mostrar.
Gracias a nuestro patrocinador:
Irise visualizacin proporciona a las empresas una manera poderosa para experimentar
plenamente business software antes que las del desarrollo. Por primera vez, las partes interesadas
pueden ver e interactuar con aplicaciones propuestas en las primeras fases del proceso para
garantizar el derecho que se construyan sistemas. Intente iRise hoy.

4

Sugerencia 24: Requisitos para CUNAS Proyectos
Esta sugerencia fue escrito por Barbara Carkenord, B2T Formacin Estudios cofundador y Jefe
estratega.
Qu tipos de requisitos son necesarios para seleccionar un proveedor/CUNAS paquete?
Los requisitos para la seleccin de una cuna (Commercial Off The Shelf) paquete de software es
diferente de las necesidades de desarrollo de sus propias aplicaciones, aunque una RFP (solicitud
de propuesta) no es ms que una de las necesidades. Estos consejos le ayudarn a los requisitos
de seleccin de paquetes.
Ayude a los usuarios formular sus objetivos y necesidades a nivel alto antes de programar las
demostraciones.
Los proveedores de software ofrecen excelentes demostraciones de sus productos. Ellos muestran
impresionantes funcionalidades, algunas de las cuales los usuarios de la empresa ni siquiera saba
que existieran. Con frecuencia, esto aparte de las necesidades bsicas que se inici la bsqueda
de una cuna. Trabajar con las empresas interesadas en establecer objetivos y utilizar un enfoque
gil estilo priorizacin. Por ejemplo, que las partes interesadas lista las funciones que necesite y, a
continuacin, dar prioridad a la parte superior 5 o 10. Conseguir que se pongan de acuerdo que no
seleccione un paquete que no cumpla estas necesidades, no importa cun impresionante la
demostracin! A estas necesidades a los proveedores para que puedan demo de las necesidades.
Por el lado tcnico, obtener la aplicacin las PYME para articular sus necesidades y limitaciones.
Usted puede ahorrar un montn de tiempo eliminando vendedor paquetes que no encaja con la
empresa plan de arquitectura antes de la demostracin y comienza el proceso RFP.
Requisitos no funcionales son la clave del xito.
Junto con los requisitos no funcionales proporcionados por la empresa, las limitaciones y requisitos
no funcionales mediante la implantacin las PYME son algunos de los requisitos ms importantes
para incluir en la convocatoria. Cada paquete de contabilidad proporciona un plan de cuentas, por
lo que su seleccin se basar en otras necesidades. Por ejemplo
- La rapidez con las cuentas se puede acceder?
- Puede ser cambiado las cuentas?
- Qu nivel de precisin est garantizada para los clculos?
- Ser sencillo hacer informes personalizados?
- Los datos se pueden exportar a otros paquetes?
Las interfaces son caros.
En algunos entornos, las interfaces entre la cuna y el paquete software existente ser la ms
costosa, requiere mucho tiempo parte del proyecto. Identificar todas las interfaces antes de
seleccin y tienen una tcnica manual o estrategia para cada intercambio de datos. Descubrir que
uno de los paquetes no puede hablar con otro despus de implementar es muy costoso error.
Reconocer las diferencias.
Ningn vendedor paquete se reunir cada necesidad del usuario. Discutir las ventajas y
desventajas con todas las partes interesadas y asegurarse de que las expectativas sean realistas.
5


Sugerencia 25: La rpida Caso de negocio

Casos de negocios existen para ayudar a los encargados de tomar decisiones tomar decisiones
informadas, y tomar accin. No siempre son grandes y complejos los documentos elaborados a
travs de un proceso largo, difcil proceso. Cualquier momento que usted necesita para hacer una
recomendacin a un rpido caso de negocio es til. Con la prctica, usted puede crear y presentar
toda la cosa verbalmente en el momento) y que ms tarde. Un caso de negocio habla de:
- Finalidad: el problema o la oportunidad, y por qu es importante.
- Opciones de la solucin: los beneficios, los riesgos y las inversiones necesarias para cumplir
con el propsito.
- Recomendaciones: para orientar a los que toman decisiones a la accin.
Casos de Negocios inicio como muy alto nivel, discusiones informales. Primeros proyectos a
menudo contienen varias opciones de solucin. La versin final puede tener slo una opcin de
solucin, y tiene claras recomendaciones.
Paso 1: Describir el problema o la oportunidad. Obtener o proporcionar esta informacin a proveer
el contexto para este fin.
Paso 2: Definir el objetivo. Por qu es el problema o la oportunidad importante? Cmo funciona
esta alinearse con la visin de la organizacin, su misin, etc. ? Objetivo es por lo general no se
puede medir. Siempre es trazable a nivel superior direccin de la organizacin. No se debe
describir opciones de solucin.
Paso 3: Definir opciones de solucin. Describir brevemente cada una de las soluciones, los
encargados de adoptar decisiones para dar un sentido de lo que son y lo que hacen. Romper cada
uno de ellos en:
A) Ventajas: Cmo va a medir el xito? El dinero es una parte de este, sino que busque
otros valores "intangibles" que la solucin es probable que brinde a la organizacin.
B) Riesgos: Qu puede ir mal en la construccin de la solucin? Si bien apoya la solucin?
Qu puede ir mal si no generar la solucin? Considerar todo lo que pueda de valor de la
empresa no slo perder o desperdiciar dinero.
C) Inversin: Qu recursos de las personas, la tecnologa y la infraestructura sern
necesarios para construir la solucin? Para apoyar en la produccin?
Paso 4: Evaluar opciones de solucin. Qu solucin se ve mejor? Examinar la finalidad, el
mercado, la competencia y la capacidad de su organizacin para ejecutar; la mejor opcin puede
que no sea el que tenga ms beneficios, el riesgo ms bajo o la menor inversin. Qu otros
factores hacen una solucin mejor o peor?
Paso 5: Formular recomendaciones. La mejor opcin en el contexto de la toma de decisiones.
Como asesor de confianza, debe interpretar la situacin, no slo proporcionar informacin.
Paso 6: Estructura del Caso de negocio. Organizar la informacin para ayudar a los tomadores de
decisiones. Poner el problema o la oportunidad, el propsito y las recomendaciones. Realizar un
seguimiento de los detalles de las opciones de solucin.
6

En un nivel alto ejemplo de este tipo de caso de negocio, visite http://IIBA.info/QT4BBA25X

Sugerencia 26: Construir una simple arquitectura de proceso
Utilice esta revelaci t nica para crear una sencilla arquitectura de proceso, mostrando las
relaciones clave entre los procesos y dar sentido a la accin. Muestra los procesos que el proyecto
puede alterar (en el mbito), que en el mbito de los procesos dependen de de entrada (fuera de
alcance), o que hacen su aporte a los procesos en el mbito de (fuera de alcance). En l se
describen los procesos de alto nivel. Por ejemplo, se enumeran los clientes utilizar nombres de los
casos, pero no hay pasos.
Cuando se identifican fuera de alcance los procesos que debera estar en posibilidades de xito de
un proyecto, iniciar un cambio de alcance del proyecto.
Paso 1: Nombre los procesos
A partir de la actual situacin, nombre que las partes interesadas en el mbito de procesos
utilizando la forma " [Alguien] [no] [con algo/a algo] ." Por ejemplo, el Cliente adquiere coche, o de
la empresa externaliza servicios al proveedor. Escribir en el sticky-notas y pegarlas en la pizarra.
Paso 2: Organizar los procesos
i) Mover un importante proceso (A) a una zona abierta en la pizarra.
ii) Encontrar un proceso (B) que depende de una, o que una depende de. Si B depende
de un palo, A. Si B a continuacin A depende de B, stick B anterior.
iii) Dibujar una lnea entre A y B. Nota la naturaleza de la relacin con una breve
declaracin. Si el Gestor realiza Comprobacin de crdito depende de Vendedor
asiste al cliente en saln de ventas, la relacin podra ser etiquetada como cliente
decide comprar coche.
Repita el proceso hasta que todos los procesos estn relacionados. Usted puede descubrir nuevos
procesos o fusionar algunos. Espacio de la pegajosa de notas. Buscar las relaciones entre los
procesos que ya estn dispuestos; por ejemplo, dos procesos que requieren el acceso a la misma
mquina, por lo que no puede suceder al mismo tiempo.
Paso 3: Identificar los agentes adicionales
Cada nombre de proceso por lo menos un actor. Nota de otros actores en el sticky-note. Por
ejemplo, Cliente Manager realiza Comprobacin de crdito necesita un cliente, Bureau de crdito y
un sistema de seguimiento de ventas.
Paso 4: Identificar Flujos de informacin
Informacin de la nota que deben ser intercambiados entre procesos como las entradas y salidas.
Es simple: en el caso de que el Cliente Informacin es suficiente, no se lista el nombre, el apellido,
el color de los ojos...
Paso 5: Definir entradas y salidas externas
Dibujar una lnea alrededor de todos en el mbito de procesos. Algunos de estos tienen relaciones
con fuera de alcance. Definir estas siguiendo los pasos 1-4, en sustitucin de "alcance" con "fuera
de alcance".
Paso 6: Documento
7

Tomar una fotografa de la materia prima arquitectura de proceso de traduccin en otra forma
(Visio, etc. ).
Paso 7: Estado futuro
Ajustar el modelo con un nuevo color, mostrando los cambios del proyecto a los procesos y
relaciones.

Sugerencia 27: Crear su propia comunidad de prctica
El ncleo de una comunidad de prctica es un grupo de personas se concentr en un inters
comn, los unos a los otros su desarrollo y crecimiento. Como practicar BA, hacen de este
personal: la comunidad de prctica es un grupo de personas que le dan soporte, y que obtenga su
apoyo. Usted puede pedir a la gente a darle un reto asesoramiento sobre sus puntos fuertes y sus
debilidades, para ayudarle a aumentar su competencia y desempeo, y a que apoyen cuando usted
est luchando. La comunidad de prctica probablemente incluir bas; tambin puede involucrar a
otros practicantes de los proyectos, los gerentes de producto, gerentes y mucho ms.
La clave para construir su comunidad es su participacin activa. Esto significa hacer preguntas,
buscar asesoramiento, solicitando opinin sincera y el fomento de la socializacin; tambin significa
el voluntariado, vamos a reuniones, con cables, compartir conocimientos y de asistencia. Usted
debe tomar la iniciativa para construir la red. Por lo tanto, cmo empezar?
Una manera de empezar su comunidad es participar en las comunidades existentes. En el inter-net,
puede encontrar grupos activos en LinkedIn, Twitter community.theIIBA.org, (bsqueda de tweets
con el hashtag #MUELLE [Anlisis de Negocio en Twitter] y #IIBA). Fsica en esfera de suelen ser
ms abundantes y ms gratificante y se puede encontrar en los captulos locales IIBA y otros
centrados en los proyectos y organizaciones. Ir a las reuniones. Organizar eventos. Tener
conversaciones. Hacer amigos.
Si la organizacin en la que trabaja es lo suficientemente grande, puede tener una comunidad de
prctica. Si hay un rgano oficial, participar, como se ha indicado anteriormente. Si no hay ningn
grupo formal, para buscar signos de una comunidad informal. Bas revisar el trabajo de cada una
de la otra? Hay mentor/protegido las relaciones? Bas almuerzo todos juntos? Una vez ms, hacen
el esfuerzo por participar. Por ejemplo, configurar una BA Almuerzo y aprender una vez al mes, tal
vez a partir de una conversacin acerca de los retos actuales. Organizar a un grupo si no es tu
fuerte, intentar ofrecer a revisar sus compaeros de trabajo y solicitar su asesoramiento en la suya.
Cuanto ms se invierte en la comunidad de prctica, ms se le dar.

8

Sugerencia 28: cuestionar la autoridad
Ser ms firmes y enrgicas requiere pasin, la humildad, la pericia, la bravura y la tica. Ser
asertivo requiere prctica y paciencia. Revise el Abril de BA: Comunicacin eficaz seminario para
una discusin sobre lo que es autoestima y no lo es. Aqu est una manera de aumentar su
autoestima sin agresin.
Comportamiento Deseado: asertiva las personas a menudo cuestionan la autoridad para
comprender las decisiones, influir en la toma de decisiones, y dar consejos tiles.
Situacin: se encuentra con una decisin de una autoridad. Se siente incmodo con la decisin o
no de acuerdo con ella. Por lo general, la reaccin se inscribe dentro de una de estas categoras:
Conocimientos: Si usted es un experto en los fundamentos, las consecuencias y tema, puede saber
ms de la Autoridad. Que desea promover una decisin diferente. Si no sabemos lo suficiente
acerca de la decisin, se siente incmodo con ella. Usted no sabe si est de acuerdo o no, por lo
tanto, usted desea obtener ms informacin y el contexto.
Confianza: Si usted no confa en el poder, que son sospechosos de todas sus decisiones, incluso
"buena". Desea una autoridad diferente, o una mejor relacin.
Perspectiva: Si su funcin o de la experiencia le ofrece una perspectiva la Autoridad no tiene, si
desea que la autoridad para abordar sus preocupaciones en la decisin. Si el local o supuestos
difieren de las de la Autoridad, que desea promover una decisin diferente.
Medida: a ser ms consciente de su relacin con las autoridades y las decisiones, mantener un
registro de decisin. Cada vez que quiero poner en duda la Autoridad, tomar nota de la decisin, la
categora de su reaccin, lo que hiciste, y sus consecuencias. Anlisis y actualizacin de registro
diario su decisin, aadiendo que se produzcan consecuencias. Este se convertir en un hbito de
su pensamiento crtico, y es muy probable que altere su comportamiento.
Acciones: Para cada reaccin, puede actuar de manera pasiva o agresiva, con firmeza. Un experto
puede exigir una decisin informada o ensear la Autoridad por medio de tiles consejos.
Conocimiento limitado puede ser dirigida al exigir la autoridad para mantener los secretos o de
preguntas y la investigacin.
Desconfianza y puntos de vista diferentes son usualmente ms difciles de tratar. Ello conduce a
una voluntad de cuestin de decisin, pero la decisin no es el problema real. Las relaciones,
premisas e hiptesis raras veces son puramente correcto o incorrecto, y es difcil para dirigir los
debates. Utilice el BA habilidades para plantear cuestiones difciles con compasin y cuidado.
Prctica no har que usted es perfecto, pero se hace la diferencia.



9

Sugerencia 29: Clasificar las necesidades de los interesados
Requisitos son intiles si los interesados no pueden actuar sobre ellos. Requisitos individuales
tienen atributos para poder usarlos. Por ejemplo, los desarrolladores pueden usar identificadores
nicos para gestionar el impacto de los cambios en requisitos sus diseos.
Cuando los requisitos recogidos en los documentos o repositorios que deben ser organizados para
que se puedan utilizar. A menudo, las exigencias son agrupados por un tema: procesos, datos, la
seguridad, el rendimiento, el sistema afectado, etc. Si bien esto es relativamente fcil para el autor
del documento de requisitos, es posible que las necesidades de otros interesados para utilizar.
Clasificar las necesidades sobre la base de la manera har uso de ellos los interesados pueden ser
ms eficaces en general. Por lo general, cada uno de los grupos interesados quiere tener los
requisitos agrupados en base a lo que importa. Estos grupos a menudo en conflicto; por ejemplo, el
Grupo de Seguridad de la informacin que queremos todos los requisitos de seguridad en un lugar,
mientras que el grupo de desarrollo quiere documentarse con cada caso de uso.
Para resolver este problema, obtener respuestas a las preguntas de cada uno de los grupos:
1. En qu trabaja con los requisitos?
2. Cules son los requisitos que se utilizan para hacer este trabajo?
Las opciones para la documentacin dependen de las herramientas que se utilizan para administrar
las necesidades. Si usted tiene un software repositorio de gestin basadas en necesidades, puede
etiquetar cada uno de los requisitos para tomar nota de todas las partes interesadas en la
aplicacin del requisito. La mayora de los repositorios puede generar una lista de los requisitos
pertinentes a cada uno de los grupos de inters.
Si utiliza un documento lineal y tener que elegir una sola estructura, otra pregunta:
3. Si se estructura el documento para cumplir con esta labor de los interesados,
A. Qu tan grave que las consecuencias negativas, y a quien
B. Qu beneficios tendrn las consecuencias positivas, y a quin?
Organizar los requisitos para ser de mayor utilidad para ayudar a las partes interesadas ms
importantes, as como un intento de reducir al mnimo los problemas de los dems. Si usted hace
una lista de cada uno de los requisitos, pueden buscar por requisitos pertinentes. Este es todava
un trade-off, es decir, la administracin las expectativas de muchos interesados.

10


Sugerencia 30: dar mejores presentaciones
Una presentacin es una de las muchas formas de persuadir a una audiencia para actuar. Una
persona se levanta frente a una audiencia y entrega un mensaje destinado a lograr un resultado.
No se trata de una discusin, el debate, el informe o actualizacin.
Buenas habilidades de presentacin son raras, y necesarios para una gestin eficaz anlisis de
competencias, 8.4 ). Parte de esta QT puede sentirse mal porque no puede ver estos
comportamientos en prctica comn. Estar en negrita: presentaciones que son poderosos y se
mueve en lugar de la terrible crisis que se ven normalmente. Prctica comn no siempre funciona;
los mdicos que an dependen de la sangra.
1. Definir el pronstico y conocer su audiencia
Qu accin o decisin desea en esta presentacin? Que tendr la accin o tomar la decisin? Si
no lo s, no me presente. Una presentacin es una manera de convencer por emocin. No se trata
de una plataforma para argumentar con lgica.
2. Elaborar su mensaje y la entrega de los resultados
Hay muchas maneras de hacer esto. "Les voy a decir lo que le dir que, les digo, les digo lo que les
dijo que no inspiran un grupo a seguir su visin. Steve Jobs Estudio de tcnicas y TED
conversaciones en su lugar. Utilizar historias y personajes y la adversidad para ser memorable y
persuasivos. Las actividades y movimientos fsicos mantener la atencin. Las interacciones entre
los miembros de la audiencia construir un sentido de comunidad. Trucos y humor pueden
entretener y revelar la verdad.
3. Usted entregar la Presentacin - las diapositivas No
Ser fiel a s mismo: encontrar su propio estilo. Todos los estilos tienen fortalezas y debilidades.

Las diapositivas son altavoces nunca las notas. Las diapositivas son un colorido, evocadora y
persuasivo teln de fondo para realzar su mensaje. Si se toma ms de cinco segundos para que el
pblico pueda absorber la diapositiva, se pierda impulso. Diapositivas deben centrarse ms en
usted, y no menos. Utilizar imgenes muy poderosas. Uso muy pocas palabras con gran estrecho
marcaje fuentes y ampliado. Utilizar fondos oscuros en persona. Nunca ponga notas de los
oradores en la pantalla.
4. Las presentaciones no son siempre la respuesta
Si necesita revisar una gran cantidad de datos o texto, enviar un informe varios das antes de que
usted presente, o cuando lo haya hecho. Una presentacin puede ser el inicio de una sesin,
seguida de un debate con los documentos de apoyo.
5. Preparar
Prctica su mensaje. Prctica la entrega. Prctica la tecnologa. Tener un plan y las herramientas
de la mano de un muerto proyector, un fallo informtico, y un fallo en el suministro de energa.

11

Sugerencia 31: Consejos para la Facilitacin
Buena bas necesitan una buena habilidades de facilitacin. A menudo, es la sutil comportamientos
que hacen la diferencia. Agregar un nuevo comportamiento de la lista la prxima vez que facilitar, y
anotar los resultados. Una vez que ests cmodo con l, agregar otro.
1. La varita del poder: El pizarra o rotafolios marcador es un smbolo de su autoridad. Recoger
todos los dems marcadores en la habitacin y mantenerlos en la zona de la que se le facilita.
2. Dedo mano/cola: Durante los debates generales unos pocos gestos, puede mantener las cosas
fluyen. Diga a los participantes: "levantar un dedo si tiene algo que agregar a un tema actual. Voy a
llamar en los dedos en el ltimo en primer orden. Un dedo le 15 segundos para hablar - no ms! Si
usted tiene un tema nuevo, distinto del tema actual, levantar la mano. Voy a llamar a las manos de
first-in-first-out." En un breve perodo de tiempo el equipo no necesita con el fin de facilitar el
debate: vigilarn el orden de los oradores.
3. Recompensas sociales para la modificacin de comportamientos perturbadores: Cuando una
persona blathers, poner la varita del poder. No escribir nada de lo que te digan en la pared. Tan
pronto como usted, puede preguntar a la emita a parafrasear sus propias palabras. Tan pronto
como se d una breve respuesta til con impaciencia agarrar el marcador y anotar sus palabras.
Repetir.
4. Presin social para la modificacin de comportamientos: Comienza el primer facilitacin de
desarrollo de "reglas del Patio" o similar (el nombre no es importante). Este tiene tres partes:
Identificar las conductas, definir reglas, y el autocontrol. Antes de empezar, explicar que un
comportamiento es algo que una persona hace, como "repetir los argumentos que ya se han
hecho", mientras que las normas son las declaraciones que restringen o comportamientos directos,
como "slo hablan cuando de facilitador", o "limitar el debate a tres voleas, luego mover tema a
aparcamiento".
A) Identificar las conductas: Iniciar una lluvia silenciosa, en el que todo el mundo escribe ideas
sobre sticky-notes. Durante 90 segundos, escriben los comportamientos que queremos ver en el
grupo. Durante 90 segundos ms, registran comportamientos que no desea ver.
B) Definir las reglas: recopilar todas las notas adhesivas y esparcirlos aleatoriamente de una pared.
Pregunte al equipo a obtener y sin decir nada, fsicamente el grupo de notas adhesivas en
categoras. Una vez hecho esto, llevar un breve debate para crear una sola regla declaraciones que
abordan las categoras ms importantes. Debe tener entre cinco y siete reglas: ms no ser
recordado, y menos no ser lo suficientemente slida.
C) auto-control: Diga al grupo, "ya no voy a ser un ejecutor de la ley. Estas son las reglas del patio
de juego, y que necesita para su mantenimiento. Cmo se puede hacer cumplir estas normas con
unos a otros? ", por ejemplo, la regla de oro "slo hablan cuando pidi a por el facilitador" podra
ser aplicado por el moderador seleccionado al azar en cada una de las reuniones, o por cualquier
persona en el equipo que indica, "no es su turno" para el delincuente.

12

Sugerencia 32: Consejos para la Facilitacin Virtual

El pasado mes hemos hablado en persona y facilitacin. Las interacciones Virtuales son diferentes.
Ocurren cuando cualquier tecnologa es el canal de comunicacin. Esto incluye mensajes de correo
electrnico, foros, telfonos, mensajes instantneos (IM) /chat, SMS, textos, redes sociales,
seminarios web y wikis. Reuniones virtuales a menudo terminan como dolorosa, improductivos
llamadas de conferencia. Estas sugerencias le pueden ayudar a facilitar su reunin y asegurarse de
que logra lo que se supone que tiene que alcanzar.
Presentaciones y reuniones de estado suelen ser una serie de monlogos. En la medida en que
toda persona tiene una copia local de los contenidos, una voz nica llamada de conferencia es
normalmente suficiente. Debe tener un programa claro para que la gente sepa cuando hablar.
Mantener a todo el mundo silencia a menos que estn hablando. Puede mezclar en persona con
canales virtuales siempre que prohben las conversaciones paralelas.
Reuniones de trabajo (incluida la adopcin de decisiones, el contenido y obtencin) son muy
difciles de voz. Otros canales interactivos para que los participantes en el contexto de la reunin.
(Multi-tasking es un hecho de comunicacin virtual en parte porque cada uno de los canales es
demasiado estrecho y demasiado lento para mantener atencin.) Si usted se ve forzado a utilizar
slo de voz, invitar a ms de seis personas. Grupos ms grandes no pueden contribuir.
Uso compartido de Pantalla herramientas son tiles cuando se revisan contenidos o realizar las
demostraciones. No uso excesivo. Participacin en la revisin, a continuacin, parar.
Herramientas de colaboracin permiten edicin simultnea, lo cual es excelente para desarrollar su
contenido. (Google Docs son multiplataforma de MS Office documentos guardados en un Windows
Live SkyDrive o un servidor que tiene Microsoft Office SharePoint Server 2010 tambin admite).
Chat/IM herramientas prcticas y vale. Todos los participantes de un sistema de chat, tales como
Skype, Google Talk, Windows Live Messenger o AIM. Los participantes pueden IM entre s con
indicadores, preguntas, enlaces, y as sucesivamente.
Las videoconferencias pueden considerablemente la velocidad de comunicacin y evitar
interferencias. Los participantes pueden levantar la mano para hablar sin interrumpir, ver las
expresiones faciales, las emociones y el sentido. Google+ agolpa entorno es un chat de vdeo para
un mximo de diez personas (todos necesitamos tener Google+ cuentas). Skype y otros servicios
de pago que hacen esto as.
En todos los casos, asegrese de que todo el mundo tiene los mismos canales: educar a los
participantes sobre el uso de las herramientas; no reservar una sala de reuniones si incluso una
persona ser "marcar".

Sugerencia 33: Objetivo tu carrera
" Dnde te ves dentro de tres aos?" no es una cuestin de carrera til no sin anlisis. La meta en su
carrera es una forma rpida, sencilla y efectiva tcnica. Es el momento de caja; si no ests hecho #5 en 22
minutos lo est haciendo mal.
Materiales: papel, cuatro corrales (negro, azul, rojo, verde), resaltador.
1. Diana (90 segundos)
13

Dibuje un crculo alrededor de 7cm/ 2" a travs de la pgina (negro hasta que nO 4). Dentro del
crculo record de tres a siete cosas le gusta hacer en su funcin actual. Generalmente, estas son las
actividades que realiza. No se trata de dinero; que motivar y ayudar a darle un sentido a su vida. Si su funcin
actual nada tiene que le gusta como esta, nota cmo se cumplen estas unidades (trabajo voluntario,
aficiones, viajes, etc. ). Destacar trabajos no remunerados.
2. Off-Target (2 minutos)
Dibuje un crculo alrededor del ojo de buey, a unos 15cm/ 6" de ancho. Fuera de este crculo , registro de
las actividades de su funcin actual que usted detesta. Se suelen realizar estas actividades mal. Hacer nunca
estas una vez ms, sera un alivio.
3. Al lado de el punto (2 minutos)
Entre los crculos , registro de las actividades, pero no le importa. Puede ser bueno en todos ellos, pero no
son un reto o interesante. Lo que no tendra nunca le molesta a usted a hacer otra vez.
4. La agrupacin (90 segundos)
Presente: Ponga un crculo azul en todo lo que sea necesario para el xito en su funcin actual. La mayora
de las personas buscar un elemento en el centro de la diana, a unos al lado de los de punto, y unos pocos de
su objetivo. Poner un recuadro rojo alrededor todo lo que impide su xito en la funcin actual. Muchas
personas de un elemento en el ojo de buey.
Futuro: destacar las actividades crticas para su xito en el desempeo de su funcin. Algunos pueden ser de
color rojo en caja en su funcin actual. En verde, registro de las actividades que no se hace hoy, pero que
son fundamentales para la funcin deseada. Ponerlos en los medios correspondientes y ponerlas de
manifiesto.
5. Analizar y planificar (15 minutos)
Su objetivo es ahora muestra lo que le interesa y lo que las actividades que usted necesita para detener,
iniciar y continuar para el xito. Es la funcin deseada encaja? Qu papel podra ser mejor? Encontrar el
modo de hacer todas las actividades crticas (tal vez con la ayuda). No trate de detener los comportamientos
que impiden el xito, buscar otros lugares para estas unidades (aficiones, voluntariado, deportes, etc. ).
Delegar todo lo dems.
6. Ley (el resto de su vida)
Vaya que esto ocurra, y volver a tu destino como sea necesario.

14

QT34: Categoras de requisitos de la solucin
No hay ninguna lista cannica de todos los tipos de requisitos de la solucin, pero algunas categoras se
utilizan en muchas organizaciones. Esta es una gua, NO UNA LISTA DE COMPROBACIN.
Derechos de acceso, niveles de autoridad: Las personas o sistemas con acceso a cualquier parte de la
solucin y la naturaleza de ese acceso.
Accesibilidad, facilidad de uso, Idioma, Presentacin de la solucin y la interfaz de usuario: la
facilidad con la que personas de todas las capacidades pueden interactuar con la solucin; experiencias de
usuario cuantificables.
Archivado, Auditora, Conservacin: Informacin realiza un seguimiento de la gestin, normas, informes
forenses, etc. , y cmo acceder a ella.
Autenticacin, identificacin: La forma en la que los usuarios de la solucin reivindican una identidad y
cmo la solucin valida esa afirmacin.
Disponibilidad: Horas de servicio o funcionamiento, media y mximo de inactividad, los cortes programados,
el tiempo de reaccin a cortes imprevistos, tiempo medio de reparacin, etc.
Continuidad del negocio: las operaciones de la empresa durante y despus de un desastre.
El cumplimiento, las Directivas, legales, polticas, normativas, estndares: Instrucciones que definen o
limitan el negocio, a menudo en las reglas de negocio.
Capacidad, el crecimiento: el volumen relacionados con los niveles de servicio y los cambios previstos
para el rendimiento durante determinados perodos de tiempo.
Conversin, Aplicacin: necesidades relacionadas con el desplazamiento de la solucin anterior a la
nueva solucin.
Canal de Distribucin, plataforma, portabilidad: las cosas y entornos utilizados para entregar o operar la
solucin.
Recuperacin ante desastres: Cmo las soluciones son recuperados despus de un desastre.
Distancia (fsico, Virtual): Los sitios de inters, y su capacidad de interactuar.
Control de errores, la fiabilidad, las advertencias: Los procesos y las polticas de control de errores y las
interrupciones imprevistas, incluidas las repercusiones para los interesados, las medidas y mtodos para
resolver las interrupciones.
Impactos Hardware: dispositivos fsicos en el entorno operativo y de la solucin.
Informacin: Los datos a los que se accede o alterado por una solucin durante un proceso o por un
informe; datos que se reestructuraron o trasladados por un proyecto.
Las interfaces, enlaces, fuentes de origen: Las fuentes , los objetivos, las estructuras y los tipos de
informacin que fluyen dentro y fuera de la solucin.
Supervisin, mantenimiento, apoyo: el esfuerzo, el costo y la complejidad necesaria para mantener la
solucin.
Privacidad: Normas y medidas para proteger la informacin.
Procesos: medidas estandarizadas entre las partes interesadas(s) para cumplir con los objetivos. Los
procesos pueden ser automatizados, sino que debe ser una parte interesada. Los informes a menudo
desencadenan procesos.
15

Informes: Informacin seleccionada, organizada, y que se presenten para las personas a tomar decisiones
informadas para gestionar el negocio. Generacin de informes es un proceso que puede ser automatizado,
pero no puede ser.
Tiempo de respuesta: la rapidez con que la solucin responde a un factor desencadenante.
Reusabilidad: los componentes de la solucin que se puede reutilizar o aplicar.
Formacin: Competencias los interesados necesitan interactuar con la solucin.

QT35: Construir un argumento de venta
Un argumento de venta es una cuidadosamente construida, mensaje corto, destinadas a provocar una accin de
uno de los interesados directos. Un argumento de venta:
Se pueden pronunciar en voz alta, lentamente, en 30 segundos o menos,
Es de 50 palabras o menos,
Tiene informacin esencial para motivar a uno de los interesados directos,
Contiene nada ms.
Un argumento de venta Plan de respuestas a estas preguntas:
1. INTERESADOS: Con quin necesita actuar?
2. RESULTADOS ESPERADOS:
A) Qu accin desea que la parte interesada debe tomar?
B) Qu medidas tiene el que los interesados deben tener en cuenta (lo sepan o no)?
3. FINALIDAD: Qu motivar a los participantes a actuar? (Dos o tres puntos crticos.)
En muchos casos, el resultado deseado es programar una conversacin para entrar ms en profundidad.
Construir su elevator pitch usando esta informacin y un editor. El editor tiene la perspectiva de las partes
interesadas al leer o escuchar. Si usted piensa que mejor mientras se habla, grabe su explicacin y la siguiente
conversacin con el editor. Si usted piensa mejor durante la escritura, no censurar o editar su proyecto inicial; las
palabras.
Con su editor, centrar el mensaje accin para motivar a los interesados. No se preocupe por nmero de palabras.
Preocuparse por el contenido. Quite todo lo que nos aleja de el mensaje.
Cuando se tiene el mensaje correcto, condensar el texto de 50 palabras o menos.
A) Eliminar colorido adjetivos (p. ej., muy, super, brillante).
B) Eliminar o condensar grasa frases (p. ej. "A fin de" "a" "de hecho" ).
C) Borrar cada tercera palabra. Use un marcador. Volver a montar los restos a la coherencia.
Confirmar que el tono se animar a las partes interesadas para cumplir con el resultado deseado.
Por ltimo, la prctica. Memorizar si tiene, pero sus lneas deben sentir espontneo de las partes. Poesas no
motivar.

16

QT36: La Magdalena Acertijo
La QT es una hoja de clculo. Si bien es ms de lo usual, no debe tomar ms de 10 minutos para completar. Usted
tiene dos opciones para realizar este experimento:
Tomar la online survey o,
download it, Imprimirlo y rellenarlo con un bolgrafo.
Pensamiento experimentos sencillos para revelar las interacciones e informar. Acertijo en la Magdalena, se explora
un sesgo cognitivo que afecta a los humanos y algunos otros primates. Es importante registrar la respuesta despus
de cada paso. Memoria es maleable, y tendr un registro escrito para demostrar que todo puede cambiar sus
creencias.
No hay preguntas trampa. Algunas respuestas son fciles. Algunos son duros. Respuesta sobre la base de la
informacin dada, no hacen nada "fantasa" como cortar las magdalenas, o hacer suposiciones acerca de las
personas. Cada escenario se basa en el anterior, con informacin aadida. Slo sabemos lo que se te dice en cada
escenario, y debe tomar una decisin basada en la informacin. No read ahead.
Imprimir el PDF
Tome la online survey

17

QT37: Principios fundamentales -la ignorancia es la fuerza
Esta sugerencia se describe uno de los tres principios bsicos de anlisis de negocio: la ignorancia es la
fuerza. Los prximos dos cuartos de galn explorar Obtencin est en todas partes, y la impotencia es la
alimentacin.
La ignorancia es la fuerza
En 1984 , George Orwell esto como una advertencia sobre los peligros de una profunda ilusin llamada
doublethink. Los analistas de negocio, es cierto para dos razones aparentemente contradictorias: que existen
para curar la ignorancia y a cultivar. (Nota: ignorante no es tonto : la ignorancia puede ser curada con el
aprendizaje.)
Curar La ignorancia con el conocimiento
Si las necesidades son conocidos; una vez que los problemas son resueltos; cuando las operaciones son
ptimos de cul es el valor del anlisis de negocio? Las organizaciones necesitan anlisis empresarial para
llenar los espacios vacos de informacin til y, en ltima instancia, para realizar cambios significativos. Curar
la ignorancia nos hace ms fuertes porque la ignorancia est en todas partes y es inevitable. Esto significa
que podremos ir a cualquier organizacin a cualquier nivel y ofrecer valor.
El curado con la ignorancia
Nos pasamos aos aumentar nuestros conocimientos, habilidades y experiencia en anlisis de negocio, pero
muchas de las ms fuertes bas tienen una profunda falta de conocimiento: son ignorantes en los dominios
que analizar. Pueden hacer preguntas a las que un experto en la materia (SME) despidi, porque la
ignorancia se desarma retribucin. Las preguntas que una PYME no se imaginan, porque la ignorancia revela
supuestos que las PYME no puede ver. Incluso utilizan tcnicas tiles para crear la ignorancia y el enfoque
(vase ms adelante).
Flexiona Tu ignorancia
Hay muchas formas prcticas de utilizar su conocimiento de la ignorancia para generar valor. Por ejemplo, se
puede exponer la ignorancia de los interesados con su propio. Todos sabemos que Bas: "Yo s lo que
necesito" muy pocas veces es verdadera. Ser un curioso estudiante: "me ayudan a entender... ?" es una
forma eficaz de ayudar a las partes interesadas descubrir sus propios prejuicios y la ignorancia.
Muchas malas decisiones con confianza. Experiencia, esperanza, emocin, y el instinto son poco fiables
fuentes de conocimiento, pero se sienten dignos de confianza. Gua BABOK muchas tcnicas para ayudar a
ee.uu. actuar como si furamos ignorantes de estos aspectos de la naturaleza humana, incluyendo: 9.8
Anlisis para toma de decisiones, anlisis de riesgos, 9,24 9,25 Anlisis de causa raz, y 9,32 Anlisis SWOT.
Cada uno de ellos se basan en hechos y observaciones y la razn, y nos ayudan a tomar decisiones
racionales.


18

QT38: Principios Bsicos - Obtencin est en todas partes
Esta sugerencia se describe uno de los tres principios bsicos de anlisis de negocio: Obtencin est en
todas partes. QT37 examinaron la ignorancia es la fuerza; QT39 explora la impotencia es la alimentacin.
Obtencin se encuentra en todas partes
Este principio es muy simple, omnipresente y disco duro: aplicar conocimientos de anlisis su negocio a su
vida, no slo a los proyectos se te asigna en el trabajo. Obtencin no se limita a las salas de reunin; su
anlisis de la empresa conocimientos se pueden aplicar en muchas situaciones. Una manera de hacer esto
es pensar en su carrera como una empresa para la que trabaja, llamada "CareerCo".
Como el principal analista de Negocios (CBA) para definir el efecto CareerCo tendr en el mundo. Establecer
una misin para describir cmo CareerCo har que esta visin real. Crear objetivos a largo plazo - objetivos
generales que sirven como orientacin.
La Empresa como Analista de negocios (EBA) para definir las iniciativas que ayuden a CareerCo lograr sus
objetivos. Desarrollar casos de negocios y comparar (vase ). The Rapid Business Case, QT25 2011-01-
13Selecciona las iniciativas basadas en el valor que debe ofrecer el servicio y la inversin necesaria para
hacerlas reales.
Como el proyecto Analista de negocios, usted da vuelta CareerCo casos de negocios en los requisitos.
Diseo de la gua, y la aplicacin. Medir la solucin para ver que se cumplen objetivos CareerCo.
En cada una de las funciones que utiliza la mayora de las tareas en el BABOK familiar Gua para responder
las preguntas:
- Cul es su enfoque de anlisis de negocio actividades?
- Cul es su plan de accin y medir el progreso?
- Quines son los interesados?
- Cmo se puede obtener sus necesidades?
- Cmo pueden CareerCo satisfacer esas necesidades?
Un ejemplo: KBCo CareerCo
Es 2003. Usted trabaja para un banco canadiense y descubrir un mal entendido con un gran potencial. Usted
forma KBCo para transformar ese papel en una profesin esencial para empresas de todo el mundo. KBCo
busca a personas con ideas afines a colaborar con, y las organizaciones para patrocinar una asociacin
profesional. Trabajan para KBCo, desarrollar requisitos KBCo contra objetivos, tal como la formacin de
redes entre pares profesionales, y que los empleadores. Cada una de las reuniones, formales o informales,
improviso - es una oportunidad para obtener necesidades de las partes interesadas, a fin de compartir los
KBCo visin y para invitar a la gente a que participe en la creacin de la solucin.
Puede haber adivinado que "KBCo" no existe en un sentido, con un empleado: Kathleen Barret. Ahora es
director general de una empresa multinacional con rapidez creciente pasado 25.000 miembros, en menos de
10 aos.
Cul ser tu CareerCo? Ser su propio analista de negocios y encontrar.

19

QT39: Principios Bsicos - La impotencia es poder
Esta sugerencia se describe uno de los tres principios bsicos de anlisis de negocio: impotencia es la
alimentacin. Los dos ltimos cuartos de galn explor la ignorancia es la fuerza y obtencin est en todas
partes.
La impotencia es poder
La mayora de los analistas no tienen poder: ni personal, ni los presupuestos, ni la autoridad. Esta impotencia
tiene ventajas y desventajas.
Imagnese a usted mismo por cuenta ajena en una gran empresa, la ejecucin de una obtencin sesiones
con un jefe y su personal. Cuando el personal describir lo que hacen el jefe dice, "No, no", y lo que
"realmente" sucede. Comprender que los seres humanos poder contradecir es a menudo una mala, por lo
que el registro muestra la jefe de opinin, en lugar de lo que hacen en realidad.
Sugerencia: considerar cuidadosamente antes de los gerentes y obtener informes directos.
Ahora imagine que usted es un consultor contratado por BA un ejecutivo; que tienen ms poder que el jefe.
Ahora tratan de decirle qu es lo que creo que quieres escuchar, en lugar de lo que hacen en realidad.
Sugerencia: La falta de poder brindar ayuda a las partes interesadas las descripciones realistas de lo que
realmente sucede en la organizacin.
Estos casos ilustran la necesidad de Bas a ser respetado como si, al mismo tiempo, evitar poder real. Ganar
este respeto por ayudar a las personas interesadas a comprender cmo su BA actividades proporcionan valor
organizacional y apoyar a las personas en el poder.
Sugerencia: Alinear su BA actividades (consulte la tarea 2.3 ) por separado de la solucin (ver tareas 7.1 ,
7.5 ).
Alineacin a la Alimentacin: una persona en el poder de su trabajo. Esto puede ser tan sencillo como que el
patrocinador enviar una solicitud de reunin para usted. Este enfoque depende de la participacin de la
persona en el poder, lo cual puede significar que necesita ver a un beneficio personal directo de su trabajo.
Sugerencia: Personas que se encuentran en el poder es ms probable que le apoyo cuando se compruebe
que hay que apoyar. Revise su enfoque (tarea 2.1 ) con actores (patrocinador, PM, administradores, etc. ).
Alineacin de valor: demostrar que su trabajo aporta valor a la organizacin. Esto puede ser tan sencillo
como describir la forma en que una BA actividad reduce el riesgo de fracaso del proyecto. Esta alineacin
depende de la percepcin de los actores se sienten acerca de la salud de la organizacin.
Sugerencia: Hacer un anlisis de causa raz (tcnica 9,25 ) sobre los problemas en el pasado los esfuerzos
de cambio. Su enfoque (2.1 ) debe abordar directamente los puede controlar, y ayudar a otros miembros de
la direccin del equipo el resto.
Para el analista de negocios, la impotencia es el poder - cuando usted sabe cmo usarlo.


20

QT 40: Cmo Detectar las necesidades y los supuestos ocultos de las objeciones
Supuestos y requisitos son a menudo oscurecidas por los interesados las objeciones: "no va a funcionar, Yah
pero, no satisfacer nuestras necesidades, y va a ser demasiado difcil"
Las objeciones que Bas atados para justificar el cambio organizacional y se aleja de obtener la informacin
necesaria para definir los requisitos. Lo que si nos fijamos en las objeciones como un instrumento de
comunicacin positiva en lugar de algo que nos impide obtener requisitos!
Personal de ventas cuantificar las necesidades de los clientes, atendiendo a sus objeciones. Bas que puede
hacer lo mismo y descubrir las hiptesis, los interesados comprender los retos y las objeciones en
informacin valiosa. Con frecuencia, requerimientos sesiones puede desviarse por distintos tipos de
objeciones:
Escepticismo - dudas que el cambio no tiene ningn beneficio
Malentendido: slo tiene la informacin incorrecta (a menudo a travs del rumor)
Los inconvenientes, las limitaciones que no cumplen con la las necesidades de las partes
interesadas
Denuncia - con frecuencia se basa en evidencia histrica - "hemos tratado de hacer esto hace cinco
aos y no trabajo"
Red Herring - utilizado para desviar
A veces es fcil de reconocer estas objeciones. Los escpticos suelen dar un toque los agujeros en los
beneficios de una propuesta de cambio: "nunca va a funcionar." Cuando alguien se comunica inconvenientes,
que suenan como los escpticos pero generalmente son ms especfico: "no trabajar porque necesitamos X,
o hemos Y". Las quejas suelen tener un elemento histrico o consultar al estado actual, como consecuencias
de los cambios "no tenemos tiempo para esto." Malentendido tiende a ser el ms fcil de detectar porque
ellos tienen informacin incorrecta acerca del cambio o el impacto que tendr para ellos. Por ltimo, las ms
difciles de identificar con el red herring. Ms informacin sobre la misma, caminando en los pasos que le
ayudarn a abordar las objeciones y descubrir necesidades.
Nuestra reaccin inicial puede ser para evitar objeciones y conversaciones difciles puesto que los
comentarios son percibidas como algo negativo. Echemos un vistazo a estas conversaciones como una
manera de comprender mejor las necesidades y para detectar los riesgos.
"Buscar primero entender y despus ser entendido." -Steven R. Covey
1. Establecer una buena comunicacin, decirles que "obtener"
2. Haga preguntas inquisitivas, "tell me more... qu se por qu ser"
3. Parafraseando a garantizar la claridad
4. A continuacin, responder. Este es un ejemplo:
Interesados: "no trabajo"
BA: entiendo que este es un enfoque muy diferente. Me dicen que "no" va a tener un impacto su
grupo
Interesados: "el problema es ."
BA: "De modo que lo que estn diciendo es que si el grupo no tiene X, a continuacin, ser necesario
Y, por lo tanto, si el proceso que permite X y Y, a continuacin, iba a cumplir sus necesidades? ".
Interesados: S!
Parece fcil de entender, sondeo, y la colaboracin de lo que acerca de la red herring? Cambio en las
organizaciones provoca resistencia, la gente debe preocuparse si an ser capaz de hacer su trabajo.
Resistencia al cambio genera descontento y objeciones. Esto puede ser el resultado de la disolucin del
debate entre las partes interesadas en una denuncia.
Qu puedo hacer? Tomar nota si usted se encuentra pasando por pasos y continuar el ciclo a travs de
ellos los interesados porque el dice las cosas como "ya pero" o tirar ms objeciones sin resolver la primera
de, a continuacin, usted tiene una red herring. Realmente no queremos una solucin a la cuestin que slo
quieren poner lmites. Si usted cree que no lo deje ir demasiado. Informar de que la cuestin se pondr en un
estacionamiento. No direccin hasta que el socio puede hacer una aportacin que le permite identificar un
requisito, una hiptesis o un riesgo.
21

Buena suerte convirtiendo las objeciones en conversaciones ricas y mejor.

22

41 QT: Escuchar - Los olvidados aptitudes de comunicacin
"Me gusta escuchar. He aprendido mucho de escuchar atentamente. La mayora de la gente nunca
escucha."
--Ernest Hemingway
En la misma medida en que es un analista de negocios debe hacer preguntas para probar, es igualmente
importante escuchar. Escuchar lo que alguien dijo no es suficiente; se debe procesar la informacin y
confirmar que entiende el mensaje del hablante. Saber escuchar es una habilidad comunicativa fundacional y
una habilidad que necesitamos para la prctica de nuestra competencia en este mbito.
Escucha activa es la mejor tcnica para un analista de negocio y es utilizado por muchos profesionales como
los trabajadores de la salud y periodistas. "Escucha activa consiste en la observacin del orador escucha el
comportamiento y lenguaje corporal. Tener la capacidad de interpretar un lenguaje corporal la persona
permite que el oyente desarrollar una comprensin ms precisa del mensaje del hablante." Atwater,
Eastwood (1981). le oigo. Prentice-Hall . pg. 83.
Escucha activa puede ser utilizado por el BA para obtener las necesidades con eficacia, sino tambin para
administrar el grupo obtencin sesiones tutoriales y estructurado. De acuerdo con paloma blanca libros "El
uso adecuado de la escucha activa los resultados a la gente a abrir, para evitar malentendidos, resolver los
conflictos, y la creacin de confianza." ( )http://www.whitedovebooks.co.uk/books/Active-
Listening/page_1.html
Tenga en cuenta lo siguiente cuando comunicarse con las partes interesadas, los amigos y la familia:
Preste atencin en los ojos de la persona y ver lenguaje corporal. Si en el telfono, escuchar su tono
de voz.
Parafraseando lo que la otra persona ha dicho que esto demuestra el deseo de entender el punto que
l o ella est expresando.
Ser consciente de sus propios prejuicios y tratar de comprender la persona su posicin.
No lo interrumpa.
Pensar en el mensaje que se transmite, no lo que quiere decir en la respuesta.
Para averiguar cmo escuchar ir a Psychology Today por un auto-test.

23

QT42 desarrollo gil Scrum: Cmo priorizar Productos Historias

El Scrum master facilita la elaboracin, el equipo se desarrolla, y el propietario del producto? Cul es el
papel del propietario del producto adems de no interferir con los esfuerzos de desarrollo y mantenimiento de
todos los molestos clientes de llamar al equipo durante el sprint? En realidad, poco gil Scrum desarrollo
describe el papel del propietario del producto, pero si el equipo desarrolla el mal conjunto de requisitos, el
propietario del producto tiene la culpa.
El propietario del producto es responsable de los productos. El producto cartera especifica la prioridad lista de
funciones (AKA las historias) con una breve descripcin de toda la funcionalidad deseada en el producto. En
otras palabras, el propietario del producto es nuestro analista de negocios que es responsable para la gestin
de las necesidades.
OK, esto tiene sentido, el analista de negocios o propietario del producto gestiona los requisitoslo siento,
Historias de usuario; el director de proyecto... lo siento, el Scrum master facilita el trabajo y el equipo
desarrolla la funcionalidad. Poco se dice sobre las prioridades pendientes. Cmo puede priorizar el atraso?
Concretamente, cules son las herramientas y tcnicas por las cuales un inteligente propietario del producto
construye y gestiona los retrasos.
La clave es entender que el retraso es el requisito y matriz trazabilidad es principalmente una herramienta
comunicacin y acuerdo entre el Scrum team y las diferentes partes interesadas.
Los requisitos del propietario del producto (historias de usuario) se muestran en una hoja de clculo (o en una
ms sofisticada aplicacin de gestin requisitos).
En la parte superior de la trazabilidad matrix aadimos tres a cinco dimensiones o campos para clasificar a
los atributos de requisito como:
Requisito propietario ranking
Nivel de complejidad
Nivel de dificultad
Empresa fecha de vencimiento
Nivel de riesgo
Otros elementos que se utilizan para establecer prioridades
En el enfoque sencillo que utilizar un 1-3 -5-7-9 escala, uno es el ms bajo, nueve es el mximo a la hora de
clasificar los requisitos. Asignar pesos a cada uno de los requisitos y pesos mltiples de la fila, a un rango
ponderado; sumando todas las dimensiones tenemos nuestro promedio ponderado que sirve como base para
la prioridad atraso.
En un enfoque ms sofisticado que utilizamos de Saaty Analytic Hierarchy Process (
),http://colorado.edu/geography/leyk/geog_5113/readings/saaty_2008.pdfpares de herramienta de
comparacin la prioridad para recibir pedidos.
Publicamos y comunicar a nuestros diversas partes interesadas, el resultado del anlisis. Este retraso es
nuestra prioridad contrato base con nuestros grupos de inters y establece el vnculo vital entre el equipo de
desarrollo y el "mundo exterior".
Michael Nir ha sido proporcionar operativa, organizativa y la formacin en materia de gestin y consultora
para ms de 13 aos. Es un certificado profesional de gestin de proyectos y la Gestalt, facilitador del
proceso de formacin, consultora y desarrollo de soluciones en gestin de proyectos y productos, el
mejoramiento de los procesos, el liderazgo, construccin de equipos y programas. Posee dos licenciaturas en
ingeniera en el Technion Israel Institute of Technology: una licenciatura en Ingeniera Civil y una Maestra en
Ingeniera Industrial.

24

QT 43: Requisitos de la forma escrita, la Declaracin del problema
Un problema de la empresa es algo que mantiene la empresa de alcanzar sus objetivos. Podra ser una
oportunidad o un problema. El objetivo de escribir una declaracin del problema es documentar y clasificar el
problema de la empresa, no para resolver el problema. Proporciona una breve descripcin del problema e
identifica lo que el xito. Tambin sirve como un lmite al evaluar soluciones y definir mbito de la solucin.
Estos pasos son los siguientes:
1. Definir el problema (ver IIBA o una gua al anlisis del negocio conjunto de conocimientos
(BABOK Guide) en los que se sugiere tcnicas para definir los problemas y hacer un anlisis de causa raz).
2. Antes de empezar a escribir la declaracin pregntese si usted tiene las respuestas a las siguientes
preguntas:
Que se encuentra afectado por el problema?
Cmo se ven afectados por el problema?
Cuando ellos se ven afectados por el problema?
Cules son los impactos presentados por el problema?
Dnde est el problema manifiesta? (Lugares, procesos, etc. )?
Por qu debera ser el problema solucionado?
Qu suceder si no se soluciona el problema?
3. Una vez que tenga las respuestas a esas preguntas, formular el problema mediante la siguiente estructura:
El problema de Describir el problema.
Afecta a
Los interesados afectados por el problema.
El impacto de lo que es
Cul es el impacto del problema, en cada uno de los grupos de
inters.
Una solucin satisfactoria,
Lista algunas de las principales ventajas de una solucin
satisfactoria.
4. Una vez que haya escrito el planteamiento del problema, conseguir el acuerdo de los principales
interesados que la declaracin se describen con precisin el problema.
5. Comunicar el problema a los interesados directos pertinentes.
No:
Utilice una falta de solucin, como no tenemos un sistema de gestin del cliente.
Dar una solucin absoluta, por ejemplo, compra empresa ABC sistemas de gestin.
El planteamiento del problema debe ser utilizado en cualquier resultado o un estudio de viabilidad. Debe
incluirse en una carta del proyecto y los requerimientos de negocios documentos. Al iniciar las actividades de
anlisis empresarial (aparte de definir el problema y planteamiento del problema), si su primera orden de
negocios consiste en definir el problema, oportunidad o necesidad y no tiene una exposicin del problema,
vaya a travs de los cinco pasos enumerados anteriormente.
Referencia: http://www.ceptara.com/blog/how-to-write-problem-statement
IIBA, una gua para el anlisis de la empresa Cuerpo de Conocimiento ( BABOK Guide), pg. 94


25

QT 44: Requisitos de la forma escrita

Hay muchas maneras de comunicar las necesidades de la empresa y, a continuacin, convertirlos en
suficiente detalle para que el grupo que recibe los requisitos puede hacer algo con ellos. En mi opinin no son
fciles de escribir. Las siguientes sugerencias de la empresa campo de anlisis debe dar un marco.
De Ian F. Alexander y Richard Stevens (escribir mejor Requisitos - Addison-Wesley )
Una forma de comenzar a organizar en escenarios requisitos:
1. Comience con un objetivo.
P. ej. El objetivo es compartir informacin con un equipo internacional.
2. Definir los pasos clave para llegar a la meta.
P. ej. Proporcionar informacin, formular observaciones sobre la informacin, editar la informacin y
dar acceso a los miembros del grupo.
3. Descomponer cada paso en pequeos pasos.
P. ej. Proporcionar informacin: introduzca la informacin en diversos formatos (Word, Excel, PDF),
asignar una fecha, asignar un nmero de versin...
En la pgina 97, el Sr. Alexander y el Sr. Stevens sugieren que este enfoque para escribir un usuario:
Tipo de usuario: miembro del equipo
Tipo de resultado (verbo): deber ser capaz de post
Objeto: informacin
Calificador (frase verbal): en un repositorio central.
Otras sugerencias incluyen:
Utilizar frases cortas, mayor ser el nmero de palabras ms el lector tiene que interpretar.
Utilizar el lenguaje de la lectora, lenguaje sencillo y evite la jerga.
Cada requisito debe nombrar a un solo resultado deseado. "El miembro del equipo deber ser capaz
de introducir uno o ms comentarios en un documento ".
Asegrese de que el requisito se puede probar, por ejemplo, "Cada uno de los documentos 1
comentario aceptar a 200 caracteres".
Incluir diagramas para proporcionar mayor claridad.
Cada nio debera ser un caso de test separado.
Lo que no se debe hacer:
No incluir ms de una exigencia en una frase. Estos se pueden detectar cuando se utilizan las
conjunciones (y, o, con, tambin).
No utilice expresiones vagas como "tal vez", "en general" "debe ser capaz de".
Karl E. Wieger libro de Requisitos de software (2 edicin, Microsoft), tiene una gran lista de trminos
ambiguos para evitar en las pginas 182-183.
Recuerde: Usted siempre debe preguntar a alguien que revise los requisitos - no podemos pensar en todo y
un segundo o tercer conjunto de ojos en un documento lo ayudar a identificar ambigedad y requisitos
faltantes.


26

QT 45: Casos de prueba - Lista de verificacin para verificar requisitos

Proporcionar comentarios y observaciones sobre la QT ( http://IIBA.info/QT4BBA45 Inicie sesin en antes de
hacer clic en el enlace)
Aprender a compartir su propio QT a http://community.IIBA.org/QT4BBA
Los requisitos funcionales estn documentados para explicar el comportamiento del software. Este
documento, a menudo se denomina una especificacin de requisitos software (SRS), se utiliza en el
desarrollo de software, pruebas de software, y gestin de proyectos. Los requisitos que se describen
funcionalmente se remonta a un de alto nivel funcin solicitada por una de las partes interesadas (p. ej., el
cliente puede ponerse en contacto con asistencia del producto en nuestra empresa).
El alto nivel de exigencia se hace de la funcionalidad, como buscar producto informacin de contacto de
soporte, comunicar el problema, clasificar el problema, va problema hasta su resolucin. Requisitos
describen lo que el sistema va a hacer; por lo tanto, tambin tiene que incluir todas las condiciones en que la
solucin se comportar. Es necesario tener en cuenta las reglas de negocio, qu es lo que desencadena el
comportamiento, y qu medidas del sistema tienen que tomar.
El aseguramiento de la calidad del software debe escribir un caso de prueba de los requerimientos.
Requisitos por escrito regla: el requisito debe ser comprobable. Veamos, pues, lo que pasa en un caso de
prueba como esta se dar una perspectiva de cmo hacer sus necesidades testeables.
La definicin de un caso de prueba es "un caso de prueba tiene componentes que describen una entrada,
accin o evento y una respuesta esperada, para determinar si una funcin de una aplicacin funciona
correctamente. "1
Es necesario describir cmo el software responder a una posible condicin de error, no vlido para entradas
o acciones. Comience con el requisito de nivel superior, la descomponen en detalles suficientes para evitar la
ambigedad: qu es el resultado que se espera.
Sugerencia: eliminar toda ambigedad de su mundo.2
Karl Wiegers tiene una lista de trminos ambiguos, en su libro Requisitos de software 2 Edicin. Trminos
ambiguos no pueden ser probados. La siguiente es una muestra de su libro, que ha sido modificado por m
para incluir como ejemplo aqu.
Trmino Maneras de Mejorar
Al menos, como
mnimo
"Especifique el mnimo y el mximo valores aceptables."
Por ejemplo, el pedido del cliente debe ser de un mnimo de $10.00
El pedido del cliente no debe exceder $1.000,00
Opcionalmente
"Definir si se trata de una eleccin de sistema, a eleccin del usuario o desarrollador
eleccin."

P. ej. Eleccin del Usuario: El cliente elige un tema de la siguiente lista de opciones:
1. Mal servicio al cliente
2. Demora en la entrega
3. Declaracin incorrecta
Sugerencia: Utilice una tabla de decisin para comunicar los hechos, las entradas y salidas de todas
las condiciones posibles de un requisito.
Las condiciones se pueden describir mediante una tabla de decisin. Una tabla de decisin se describen los
resultados de una decisin, las alternativas y las reglas de negocio que rigen la accin. Una tabla de decisin
es lgica. Hay una condicin - el cliente est registrado. Si esta afirmacin es verdadera entonces sus
necesidades debe responder a la pregunta: qu debe suceder? (Accin). Si la afirmacin es falsa, a
continuacin, sus necesidades deben responder a la pregunta: qu debe suceder? Considerando las
condiciones y utilizando una tabla de decisin sus necesidades se pueden probar.
27

Para obtener ms informacin sobre tablas de decisin vaya a http://www.cems.uwe.ac.uk/jharney/table.html
Una sugerencia ms: incluir siempre un responsable de calidad en la revisin de requisitos tutoriales. l o ella
ser capaz de identificar ambigedad y donde los requisitos, las reglas de negocio y los datos pueden estar
ausentes. Estas personas son un recurso valioso.
1. Recurso: Softwaretestinghelp.com
2. Requisitos de software, 2nd Edition de Karl Wiegers, Microsoft Press

28

QT 46: Facilitacin - El arte de guiar a otros hacia el logro de los resultados

La definicin de la facilitacin es "cualquier actividad que facilita la realizacin de tareas de los dems, o
tareas que son asistidos." (Fuente: Wikipedia). Esta es una de las tcnicas ms importantes un analista de
negocios puede desarrollar. Las habilidades de facilitacin se puede utilizar para presidir las sesiones,
ejecutar un taller de requisitos o realizar una entrevista. Los analistas de negocio, el objetivo final es
comprender las necesidades de las partes implicadas. Para los interesados, el objetivo final es para ser
escuchado, comprendido y considerado. Recuerde su tiempo es valioso.
Los elementos de una buena facilitacin sesiones incluyen la forma correcta de enfocar las cosas, un
objetivo, un conjunto de los resultados deseados, el derecho, el derecho y las actividades de los
participantes.
A la hora de decidir sobre el enfoque correcto (entrevista, taller, etc. ) pregntate: " Qu quiero lograr, cul
es el objetivo de la reunin?" Por ejemplo, si usted necesita para validar que tiene el correcto proceso actual
e identificar los problemas en el proceso, un taller es probablemente su mejor criterio. Si se quiere
comprender la visin de un jefe de departamento, la entrevista inicial es probablemente el mejor enfoque.
El objetivo debe definir por qu todo el mundo est ah. Es til para llamar el objetivo global de esta iniciativa,
y de qu manera los requisitos sesiones se inscribe en el objetivo general de la empresa. El objetivo debe ser
especfico, medible, alcanzable, relevante y limitado en el tiempo. Por ejemplo, hoy nos reunimos para definir
el tiempo y residuos de materiales cuestiones relacionadas con el proceso de admisin actual a fin de cumplir
con los costos de la organizacin objetivos de ahorro para 20xx
Ahora que ha definido el objetivo, slo se debe invitar a las partes interesadas que estn ntimamente
consciente de los costos del proceso, que tengan los conocimientos y que tienen la autoridad para ofrecer
sugerencias. Autoridad no siempre significa invitar al manager, l o ella debe delegar esa autoridad a un
miembro del personal de confianza que es ntimo con el asunto de que se trate. Como se suele decir "el
diablo est en los detalles".
Piense en lo que desea abandonar la sesin con: una lista de temas, un nuevo mapa de proceso, y una lista
de las ideas? Puede y debe orientar las actividades que realizan y cmo se ejecuta el perodo. Tambin se
proporcionan a los participantes la posibilidad de la reunin y lo que se espera de ellos.
Sea creativo, gente que realmente no quiere sentarse y discutir mientras frenticamente escriben sus ideas
sobre un fondo blanco. Utilice ideas; que dibujar una imagen o guin grfico del estado deseado. Romper las
personas en grupos y que pueda seguir en el equipo y para el debate. Resumen despus de cada actividad y
definitivamente cerca del final del perodo de sesiones. Llamar a lo que se ha realizado, confirme exactitud de
la informacin, y asignar tareas. Siempre les doy las gracias por tomar el tiempo para asistir y asesorar a
ellos de lo que se va a hacer con la informacin.
Como un facilitador, estar a la hora, de estar preparados, no defensiva, mantenerse neutral, y siempre dar a
todos la oportunidad de hablar, utilice un programa, y permanecer en la tarea de "estacionamiento". Una
zona de aparcamiento es una lista de elementos que no encajan en el mbito de la reunin, pero tendr que
ser debatida, si el tiempo lo permite o si son las dependencias para seguir adelante con la sesin. Los
elementos de un lote de estacionamiento puede ser utilizado para formular el siguiente conjunto de
reuniones.
Ponerse en el lugar del participante, a fin de garantizar la sesin vale la pena. Cuando la invitacin
pregntese qu papel desempean en persona X el perodo de sesiones (experto en la materia, observador,
toma de decisiones)? En la medida de lo posible, y si la persona no es necesario en toda la sesin, los
participantes durante un perodo de tiempo especificado durante el perodo de sesiones.
Por ltimo, ser valiente. Si el valor predeterminado para las sesiones de requisitos es una entrevista, intente
un taller o usar diferentes tcnicas de la entrevista. Si usted est nervioso por conseguir delante de gente,
mantener al mnimo; deja que los participantes hagan todo el trabajo. Como un colega mo dijo, "usted no
sabe un buen facilitador es hasta que es necesario".
Si usted es un IIBA, usted puede acceder a los siguientes libros a travs de nuestro Online Library.
29

El experto facilitador: un recurso completo para los consultores, facilitadores, gestores, formadores y los
entrenadores, nueva y revisada edicin
Por Roger Schwarz
El arte y el poder de la facilitacin: Ejecucin potente Reuniones
Por Javier Zavala y Kathleen B. Hass
Facilitar con facilidad!: Habilidades Bsicas para facilitadores, lderes de equipo y de los miembros, directivos,
consultores y formadores: nuevas y revisadas
Por Ingrid Bens

30

Sugerencia 47: doble obligacin: Usando " Given-When -entonces", para
descubrir y validar los requisitos
Definicin
Given-When -entonces (GWT) es un formato estructurado para expresar situaciones hipotticas con datos de
ejemplo, incluyendo pre y post-condiciones.
Utilidad
GWT ayuda a los interesados en el proyecto (empresas, clientes y socios de tecnologa) comunicarse con
dominio del negocio. Puede utilizar GWT para explorar las opciones de producto y confirmar las opciones
seleccionadas.
Todo lo que necesita saber
Para cualquier historia, escenario y reglas de negocio, responder a estas preguntas:
Dado: Cul es el contexto del sistema? Qu condicin debe ser cierto antes de la accin es prueba?
Cules son los datos en el sistema?
Cuando: lo que ser probado? Qu datos de entrada ser puesto a prueba a travs de la regla de negocio
cuando se desarrolla la accin?

Entonces: En respuesta a la accin, cul es el resultado observable? Cules son los resultados
esperados? Cul es el post-estado (el estado) o salida de datos observables por el usuario?
Ejemplo
Historia Como cliente, debe cancelar una ventana trabajo de limpieza.
Escenario
El cliente se pone en contacto Sper Kleen dos das hbiles antes de la fecha programada del
trabajo.
Regla de Negocio
Un trabajo canceladas con menos de un da hbil antes de la fecha programada del trabajo
debe ser cargado un honorario de la cancelacin.
Dado

Pre-condicin(s) Estado del trabajo: programado
Datos fijos
Nmero de trabajo: 1255
Trabajo fecha programada: 24 2012 Octubre
Cuando

Accin Solicitar la cancelacin de un trabajo
Datos de entrada Fecha de solicitud: 22 2012 Octubre
A continuacin,

Datos de salida El trabajo se ha cancelado. Le gustara programar para una fecha futura?
Post-condicin Estado del trabajo: cancelada.
Descubrimiento Colaboracin
Los interesados deben ser eficaces, formas precisas para confirmar los requisitos. Given-When -le guiar
para definir ejemplos. Tambin puede utilizar GWT para explorar las opciones del producto teniendo un
enfoque concreto.
31

Oportuna Validacin
Lo mejor es probar la validez de sus requisitos antes de la entrega. GWT le ayuda a evitar sorpresas
desagradables, como la entrega la solucin equivocada.
GWT en pocas palabras
Given-When -luego le ayuda a ahorrar tiempo, evitar retrabajo, reducir errores de requisitos, y promover la
responsabilidad conjunta de requisitos detallados.
Tcnica Alternativa
Utilice ejemplos de datos en una tabla para definir las entradas y salidas para una hiptesis (vase
Gottesdiener y Gorman, 2012).
Sugerencia rpida Fuente
Gottesdiener, Ellen, y Mary Gorman. Descubrir y entregar: gil Planificacin de productos y anlisis. EBG
Consulting. 2012.
Notas:
1. GWT comenz como un Behavior-Driven Development (BDD), de Dan al Norte. Otros nombres:
Aceptacin Desarrollo controlado por pruebas (ATDD) y especificacin por ejemplo (SBE).

2. Para obtener ms informacin, vea el gil Extensin del BABOK Gua, "Get Real Utilizando ejemplos."

3. Las herramientas que generan pruebas de aceptacin con GWT: Pepino, Easyb, RSpec, Jbehave y mucho
ms.
Para obtener ms informacin
, Gojko Adzic, especificacin por ejemplo: cmo los equipos exitosos ofrecen el software adecuado.
Manning Publications, 2011.
Grout Matts" (Colchones, Chris, y Gojko Adzic. "Inyecciones: Tres Pasos para el xito." . Available here

Norte, Dan. "Introducing BDD." . Available here
Los miembros IIBA calificar para un descuento de Ellen y de Mara libro Descubrir para ofrecer: gil
Planificacin de productos y anlisis. Descubra cmo ofrecer productos de alto valor. A la orden con
el descuento, visite . IIBA Bookstore

32

48 QT: para obtener su interesados para pensar acerca de las opciones

Como analistas de negocios, a menudo lucha con la forma de obtener sus grupos de inters y describir sus
necesidades reales en lugar de la solucin a la que han mostrado en sus cabezas. Se habla de diversas
tcnicas de anlisis causa raz y nos dicen que pensar en las necesidades sin centrarse en el diseo de la
solucin. Todo esto parece lgico en la teora, pero cmo puedo hacer que mis partes interesadas que
quiere tener esa discusin conmigo?
Las partes interesadas no se trata de ser difcil cuando se hacen las peticiones en la forma de una solucin.
Por supuesto, queremos hacer nuestra parte por tratar de encontrar soluciones y a menudo puede articular
mejor algo a travs de una visin del producto final, en lugar de todas sus piezas. Desde el momento en el
que estn los jvenes se nos ensea a ser solucionadores de problemas. Por ello, lo primero que podemos
hacer es aceptar y comprender que el deseo de los dems para contribuir a la solucin. No slo diciendo las
palabras, sino que realmente se siente agradecido a los interesados.
Lo siguiente que tiene que hacer es abrir a la gente a pensar en otras opciones. Sin que, puede ser difcil que
alguien te d un paso atrs para pensar acerca de los fundamentos. Con frecuencia la gente se siente que
detenerse a pensar acerca de los requisitos se retrasan el progreso porque ya pensaba en esto cuando se
les ocurri la solucin. Y despus de todo, no saben mejor? Por lo tanto, cmo se les motiva a
querer frenar las cosas? Un truco es hacer preguntas como: "Si nuestro equipo podra llegar a una solucin
mejor que la que en la misma cantidad de tiempo o menos, que?" es muy raro que alguien le dice que no,
que no quieren algo an mejor que lo que haba pedido. Una vez de acuerdo a la premisa subyacente, que
ha motivado el inters de pensar los requisitos subyacentes por apelando a lo que les importa... hacer algo
mejor.
La combinacin de estas dos cosas, el reconocimiento de la solucin propuesta y motivar a otros a querer
ms, usted tiene una herramienta muy poderosa para los interesados que pensar fuera de la caja inicialmente
definido. La siguiente conversacin se ilustra cmo el BA puede promover la colaboracin con
reconocimiento:
Analista de negocios: "Me gusta que pensar tanto en la manera en que podra abordar esta brecha en lo que
nuestro producto. Tenemos unos muy talentosos desarrolladores de nuestro personal, por lo que me
pregunto... si se pudiera tomar su idea y trabajar en colaboracin con usted para construir sobre ella que
venga con algo an mejor, sera conveniente que lo OK? Les he visto algunas cosas interesantes que nunca
se me habra ocurrido antes".
Interesados: "Seguro. Por supuesto. Mientras todava podemos entregar a finales de ao."
Analista de negocios: "Si usted y yo podemos trabajar juntos para describir algunas de las cosas que le
estaban tratando de mejorar con su idea, podemos trabajar con los desarrolladores para ver algunas
opciones y decidir como un equipo que trabajar mejor para nosotros. Podramos utilizar su experiencia y sus
ideas, si desea ser socio con nosotros sobre esto."


33


49 QT: estimar las necesidades esfuerzo

Estimacin es realmente una estimacin, es de esperar que una mera conjetura, pero una estimacin del
mismo. Al calcular el nivel de requisitos de esfuerzo, determinar y documentar las hiptesis en las que el clculo
se basa (por ejemplo, todos los interesados a asistir a los perodos). Determinar la complejidad de la tarea en
base a los siguientes factores:
Las Personas
Disponibilidad de buenos expertos en la materia
La resistencia de las organizaciones al cambio
Algunos de los interesados, las ubicaciones
Geografa co-ubicado (o dispersos) y las diferencias culturales
Nivel de compromiso de los patrocinadores
Nivel de conocimientos y experiencia de los interesados
Nivel de conocimiento/experiencia del analista de negocios
Procesos
Nmero de procesos afectados
Interdependencia Proceso
Tecnologa
Nmero de sistemas afectados
Complejidad de la integracin
Complejidad del sistema
Los datos
Tipo de cambio
Nuevo desarrollo de la empresa
Mejorar los sistemas existentes
De la Mano de software
Cambios en el proceso y la optimizacin
Calcular complejidad
Para determinar complejidad, considere los factores anteriormente mencionados, por ejemplo, un sistema se ha
actualizado, hay algunos procesos y reas de negocio afectados. El analista de negocio es inexperto pero ha
administrado el sistema en el pasado. Asignar un nivel de complejidad para cada rea y calcular el promedio.
La complejidad resultante factor ser utilizado como un multiplicador de la estimacin.
34


Lista de tareas
La siguiente lista le dar una idea de las tareas y actividades que deben considerarse cuando se estima el nivel
de anlisis de negocio.
Planificacin: determinar cunto tiempo le llevar a crear un plan requisitos incluyendo el derecho a llevar a
cabo anlisis de las partes interesadas, la planificacin de las actividades, comunicaciones, planificacin y
definicin de los requisitos y procedimiento que se ha de seguir.
Obtencin: El nivel de esfuerzo debe incluir la planificacin del evento, realizando el evento, en el que se
documentan los resultados del evento, y validar los resultados del evento.
Anlisis: La cantidad de tiempo que se tarda en realizar esta actividad no debe ser subestimado, que a
menudo se tarda ms tiempo de lo que inicialmente parece. Las actividades incluyen anlisis de los resultados
de las actividades la obtencin - priorizacin, organizacin y requisitos para la construccin de modelos.
Por escrito Requisitos: Las actividades incluyen la escritura los requisitos, editando y creando esquemas.
Verificacin y validacin Requisitos: Esto incluye organizar la revisin de requisitos, el tutorial y, a
continuacin, incluye todas las modificaciones (tendr que volver a realizar un anlisis para asegurarse de que
no hay otros requisitos son afectados).
Administracin de requisitos: Esta tarea se produce durante la etapa de diseo y desarrollo incluye
actividades tales como los cambios requerimientos, trazabilidad, identificar los requisitos para la transicin,
validando la solucin y quizs modificar los documentos de requisitos (no subestimar este esfuerzo). Puede
usar un porcentaje de los cambios previstos en funcin del tipo de participacin de los actores que usted espera
y la disponibilidad del equipo de desarrollo.
Ahora que sabemos qu es lo que vamos a hacer, y de la complejidad del cambio, podemos utilizar una
combinacin de estimacin paramtrica (parmetros multiplicado por el nmero de horas) que incluye el juicio
de expertos y la informacin histrica
El siguiente es un ejemplo de un enfoque que se puede utilizar (nota no en analizar los nmeros, ellos estn all
slo por motivos de ilustracin). Slo con el ms alto BA y otros recursos puede estimar el nmero de horas.
35


Yo recomendara usar estimar rangos (ej. 30 A 35 das) y ola. Ola estimacin entraa el perfeccionamiento de
las estimaciones de ms informacin se trata de iteracin, por ejemplo, una vez que el modelo de negocio se ha
escrito, y despus de la requisitos empresariales de alto nivel se definen, a continuacin, despus de la
especificacin de requisitos detallados o est definida.
El nmero de das total de das, y no el tiempo transcurrido durante el que se le llevar a completar sus
necesidades las actividades; por ejemplo, puede que te lleve dos semanas para planificar, preparar, organizar y
dirigir sus actores conflictos de programacin.
La clave para mejorar las estimaciones es medir el valor real de horas contra las horas estimadas, analizando
los factores y por qu el real es diferente. Esta informacin le ser muy til para su prximo proyecto.


36

50 QT: competir con las caractersticas - Requisitos Prioridades

Requisitos prioridades debe ocurrir muy pronto y a menudo para administrar las expectativas de las partes
interesadas, el presupuesto y la programacin del proyecto. Si el proyecto es con cascada, iterativo, o
enfoques giles para entregar la solucin a la empresa, los requisitos prioridades tcnicas deben utilizarse
para satisfacer los plazos y ofrecer valor a los clientes.
Hay diversas tcnicas, tales como debe tener, debe tener, podra tener y no tener (Mosc), TimeBoxing y el
presupuesto que utilizan "all in" -iniciar con todos ellos, a continuacin, mover a otros, "todo" lo que es a la
inversa, o "selectiva" que se centra en agregar o quitar las necesidades sobre la base de la hora o
presupuesto lmite ( Gua BABOK, pgs. 99-103)
No importa el enfoque, al priorizar los requisitos que debe tener en cuenta lo siguiente:
1. El valor del requisito aporta al usuario y/o cliente
2. El riesgo de que el requisito es que no hay
3. La relacin con otros requisitos - dependencias
Uno podra argumentar que el costo y el tiempo son importantes, y son, pero si la solucin no agrega ningn
valor, no es el deseable y no satisfacer las necesidades, metas y objetivos de la organizacin y, a
continuacin, lo que se puede muy bien ser un desperdicio de tiempo y dinero.
El requisito de valor
El valor de la obligacin debe estar asociado con lo que el cliente y el usuario necesita. Por ejemplo, si el
cliente (externo) le d una gran importancia a una ventana de envo de dos das, qu necesita el usuario
para poder realizar esto?
De valor, se le puede preguntar cmo los requisitos cumplir los objetivos de negocio. En el caso de los
tiempos de entrega que desea averiguar si es asociado con un objetivo de la empresa, como aumentar la
satisfaccin del cliente en un 10 %. Al formular la pregunta, el interesado podr aconsejar que tiempos de
entrega se han identificado como una forma de mejorar esa mtrica. En otras palabras, el cliente se identifica
valor como recibir el producto tan pronto como sea posible. Que van a comprar su producto por encima de la
otra porque de tiempo de entrega y ser un cliente satisfecho como resultado.
Las siguientes preguntas ayudarn a determinar la exigencia de valor:
1. Este requisito a los objetivos de negocio (aumento de la satisfaccin del cliente)?
2. Cmo funciona este requisito cumplir el objetivo de la empresa y el objetivo?
3. Cmo funciona este requisito aumentar el cliente o nivel de satisfaccin del usuario?
4. Por qu el cliente y el usuario de este requisito?
5. El requisito satisfacer una amplia base de usuarios y clientes?
6. No satisfacer el requisito partes interesadas importantes (por ejemplo, clientes que invierten
$1 M anuales - que pueden ser pequeos en nmero, pero su impacto es importante para la
organizacin). Esto podra decirse de exigencias que satisfacen "C" y otros ejecutivos.
El requisito Riesgo
Riesgo es definido por IIBA como " un acontecimiento incierto o condicin que, si se produce, afectar a las
metas y objetivos de la propuesta de un cambio". Gua BABOK ( p. 232). Las siguientes preguntas le
ayudar a las partes interesadas y el BA, a fin de priorizar mejor los requisitos.
1. Si el producto no se entrega en dos das, cul es el impacto para la organizacin?
2. Si ofrecemos una entrega de dos das nuestros pedidos y opcin aumentar hasta el punto en que no
podemos cumplir con la obligacin, lo que se debe poner en marcha para hacer frente al aumento?
La necesidad de Relacin con otros requisitos
La entrega de dos das requisito podra depender de la organizacin de inventario en tiempo real de los
niveles disponibles para los usuarios internos para que puedan responder a la baja los niveles de inventario
que impedira la entrega de dos das. Por otro lado, un requisito que el cliente seleccione el lugar de destino
37

de un mapa interactivo en la web podra ser considerado una prioridad baja porque no ayudan a satisfacer las
necesidades de dos das. El primer paso para la BA es determinar las necesidades de las dependencias, a
todos ellos, y, a continuacin, pedir las mismas preguntas acerca del valor y el riesgo de cada uno de ellos
para determinar su verdadera prioridad.
No he mencionado el coste y el tiempo factores como parte del establecimiento de prioridades, ya que esos
son manejables, el presupuesto puede ser revisada, horarios pueden ser cambiados si -y subrayo si. los
requisitos son considerados de alto valor y riesgo manejable. Si el riesgo indica que ms de los requisitos son
necesarios para gestionar el riesgo y lograr los objetivos de la organizacin, identificacin temprana es
esencial para el PM puede gestionar el presupuesto y el calendario. En esencia, las prioridades las preguntas
deben ser requisitos durante el primer descubrimiento para que sus necesidades sean lo ms completas
posibles y el interior de las partes interesadas se gestionen las expectativas.
Otros recursos:
IIBA una Gua para el anlisis de la empresa Cuerpo de Conocimiento
(
Gua BABOK ), Captulo 6, Anlisis
de requisitos
IIBA Archived Webinars:
Proveedor IIBA escaparate, definir y gestionar mbito de la solucin
Tracecloud
Plan
10 Enero, 2013
ABC IIBA Serie: Siete pasos para dominar Anlisis Empresarial de
Barbara Carkenord
Barbara Carkenord,
RMC Project
Management
10 Julio, 2012
Requisitos de seguimiento (un componente de BABOK tarea 4.2 ).
Plan
TechnoSolutions
Serena
16 Febrero, 2012
IIBA Biblioteca en lnea:
Customer-Centered Productos: crear productos de xito a travs de Smart Administracin de requisitos por
Ivy F. ganchos y Kristin A. Farry http://iiba.books24x7.com/toc.aspx?bookid=3829
Getting It Right: Anlisis de requisitos empresariales Herramientas y Tcnicas por Kathleen B. Hass, Don J.
Wessels y Kevin Brennan http://iiba.books24x7.com/toc.aspx?bookid=24864
Fuente: Historias de Usuario aplicada para el desarrollo de software gil de Mike Cohn

38

Sugerencia 51: Organizar los requisitos

Qu Batman, el Joker y Bob Dylan tiene que ver con anlisis de negocio? En 2007 su pelcula biogrfica, I'm
Not There , el escritor/director Todd Haynes captura el espritu de la leyenda de la msica de los aos 60,
Bob Dylan. Dejando de lado la literal vientre de tomb biografa estructura narrativa, la pelcula cuenta con seis
diferentes actores, cada uno tocando un carcter diferente que representa un aspecto distinto de Dylan la
personalidad. Dylan se presenta como un andrgino selccionado (Cate Blanchett), un nio de 11 aos afro-
americanos ; Woody Guthrie (Marcus Carl Franklin), un joven poeta (Ben Whishaw); envejecimiento prohibir
Billy the Kid (Richard Gere), un ingenioso personaje cantante de folk (Christian Bale Batman fama); y una
sensible y un hombre de familia actor (Heath Ledger, mejor conocido por su Oscar. como El Joker). Adems
de ser un brillante trabajo de cine, la pelcula es la metfora perfecta para la tarea de una gua para el anlisis
de la empresa Cuerpo de Conocimiento ( Gua BABOK), para la Organizacin.
El propsito de organizar las necesidades es la de crear un conjunto de puntos de vista de los requisitos para
obtener una nueva solucin de negocios que sean integrales, completos, coherentes y entendido desde todas
las perspectivas de los grupos. Como se indica en la Gua BABOK, los objetivos de esta tarea son para
comprender que los modelos son adecuados para el dominio del negocio y mbito de la solucin y modelo
para identificar las relaciones y dependencias.
Porque los modelos simplifican la realidad, pasando por alto algunos detalles a fin de mejorar la comprensin
de los dems, ningn modelo nico puede proporcionar una vista completa del dominio. El analista de
negocios del reto, por lo tanto, es la eleccin de un conjunto de modelos complementarios que cada transmitir
un aspecto diferente de la verdad, como los seis personajes distintos en I'm Not There . Slo la combinacin
no presentan un panorama completo de la realidad. Por ejemplo, mientras que casos de uso puede ser una
tcnica muy eficaz para modelado requerimientos, casos de uso no solo ms representan toda la verdad de
una solucin de una pubertad personifica negras Bob Dylan.
La Gua BABOK identifica cinco conceptos de modelado que son relevantes para anlisis de negocio.
1. Clases de usuario, perfiles o Roles
2. Conceptos y relaciones
3. Eventos
4. Proceso
5. Reglas
Casos de Uso captar muchos de estos conceptos, los actores encarnan las clases de usuario; los factores
desencadenantes son eventos ; principal y suplente corrientes representan los procesos; y pre- y post-
condiciones representan los estados. casos de uso estn vinculadas a diagramas de estado, puesto que
describen el resultado que los procesos invisibles en las transiciones de un estado a otro. Estas transiciones
estn etiquetados en diagramas de estado en funcin de los eventos que desencadenan. Ya que ellos
representan el ciclo de vida de un concepto, diagramas de estado estn vinculados a los modelos de datos,
que se asignan los conceptos y sus relaciones . Hemos cerrado el crculo con la conciencia de que algunos
de los conceptos representados en los modelos de datos son en realidad actores cuyos objetivos se
concretan en casos de uso.
Debido a estas relaciones, modelos complementarios no slo proporcionan una verdadera y vista ms
holstica de la solucin, se puede usar cada modelo para verificar la integridad y otras caractersticas de
calidad de los otros. Y que, en la respuesta a la pregunta de uno de Bob Dylan ms conocido de las
canciones, se siente bastante bien!