Me pareció un interesante recorte a partir de que ahora voy a estar ligado a proyectos de gran magnitud y estos puntos que analiza son muy prácticos y cotidianos.
En los proyectos donde vamos a
utilizar Sharepoint , como en otros proyecto sin Sharepoint, es
fundamental la tarea del analista de negocios.
Muchas
veces es necesario que conozca del negocio que se está relevando , pero
esto no es siempre así en todos los casos. Por eso acá van algunos
consejos para esos casos.
Vos, analista de negocio has sido asignado a
un proyecto nuevo o en ejecución . Empezaste a trabajar en su kick off
inicial preparándote, leyendo el alcance, revisando el documento de
schedule y convocando tus primeras reuniones con los diferentes
stakeholders del proyecto. En el medio de la reunión mientras estás
escuchando atentamente como es el proceso detallado para la
transferencia de una política de un organismo a otro, te encontras
tomando notas y más notas. De pronto te das cuenta que las notas
empiezan a perder relación y el interlocutor continúa hablando y
hablando!.
Aunque tus notas son palabra por palabra lo que están
diciendo, por temor a parecer tonto o que el equipo no pierda
credibilidad en tu tarea,lo mejor es seguir escribiendo, mientras
intentas desesperadamente entender lo que se está diciendo.
Cuando este es tu primer proyecto, esto es lo que le suele suceder a un analista de negocios.
En muchas reuniones donde participe vi esto muchas veces.
Para estos casos, existen este tipo consejos para manejar esas situaciones
No
importa que tan experimentado sea un analista de negocios, una
situación como esta va a volver a suceder. Es muy raro que un analista
de negocio -sin importar su experiencia - pueda empezar cada proyecto
con todo el conocimiento y tener respuestas para todos los escenarios.
Cuando estas perdido en la reunión:
1) Trata de no mirar a los ojos de otros miembros de tu equipo del proyecto como buscando complicidad en lo que no se entiende.
2) Intentar encontrarle sentido a lo que se dice
3) Sé capaz de tomar la información relevada - aunque no tenga sentido - y producir requerimientos relevantes a lo escuchado.
Hay cuatro sencillos trucos para poder salir del aprieto de no saber el tema y aún así obtener algo de la reunión.
· 1) Saber que "No estoy familiarizado con los detalles".
Bajo mis roles, trabajo con muchos clientes. Y la mayoría de las veces,
sé muy poco sobre sus procesos internos, normas, procedimientos,
políticas, etc., y mucho menos como lo plasmaron en sus sistemas y/o
aplicaciones. Pero eso no me impide rápidamente empezar a conocerlos.
Podes pedir acceso al sitio de Normas y procedimientos por ejemplo, y
empezar a conocer más de lo que se habla en la reunión. Cuando estoy con
un cliente o un proyecto nuevo, aunque tenga muchas habilidades, a
veces son inútiles a menos que se sepa cómo utilizarlas en un proyecto.
Cuando me encuentro en un nuevo proyecto que conozco muy poco, tengo que
preguntar ¿Podría explicar esto con más detalle? ¿Le importaría
explicarlo de una manera más fácil de entender? La razón de esto es para
que se pueda entender el tema en un nivel superior con menos detalle
antes de empezar a ver temas como el workflow del proceso en particular o
la funcionalidad de la interfaz de usuario o lo que sea que se esté
tratando de entender. En otras palabras, estamos admitiendo abiertamente
que no estamos familiarizados con los detalles. Ser abierto y honesto
al preguntar para que se entienda, fortalecerá aún más la relación de
confianza con el equipo del proyecto y los stakeholders del negocio.
Manejarse de esta manera es poner en claro que todavía no sé de lo que
se esta hablando pero pronto voy a estar al tanto de todos los detalles.
· 2) Buscar los puntos de acción
- aunque no seas un Analista de negocios - y hacete carne de ellos, si
es que te corresponde. Otro tip interesante es hacer seguimiento de los
puntos de acción que salen de una reunión, incluso si no te involucran
directamente. Aprovecha la oportunidad en algún nuevo proyecto para
aprender tanto como puedas. No importa de donde venga el conocimiento o
contenido, simplemente sumergite en el tema del proyecto. No hace falta
decir que primero debes atender tus responsabilidades, pero si tenés la
oportunidad de asistir a una reunión ; mejor , por ejemplo a revisar un
documento de diseño o sentarse con los stakeholders , o incluso convocar
reuniones informales para apuntalar tu conocimiento. A pesar de que
algunos de los puntos de acción que no están enteramente relacionados
con tu trabajo en el proyecto, te van ayudar a construir tu conocimiento
de fondo que será muy útil más adelante en el proyecto.
3) Creá una asociación con el Stakeholder del negocio
(o donde esté el conocimiento). Aunque es importante para el analista
tener una sociedad sana con el Manager del Proyecto, es igual de
importante tener una sociedad sana y abierta con los stakeholders del
negocio. Después de todo ellos van a ser a quienes debemos satisfacer
con el proyecto. Muchas veces esta relación se pasa por alto, o se
pierde valor. Esto conduce a limitar la comunicación o a romperla en el
peor de los casos . Si queres tener éxito como analista , tenes que
valorar la asociación con los stakeholders. Te va a ser más fácil
obtener información vital con rapidez cuando tengas una alianza
saludable, fuerte y abierta.
Probablemente el truco más difícil, es
ser humilde y pedir. Este truco es simple de entender , pero también el
más difícil de llevar a cabo. Es bueno que al principio de un nuevo
proyecto, seas cauteloso de exponer tu punto débil al resto del equipo ,
para que tus colegas no sepan que tienen una vulnerabilidad en torno a
la plena comprensión del tema. Sin embargo, si no hablas ahora será
demasiado tarde. Debido a que el papel de un analista es tan vital para
el éxito global de un proyecto, nunca se debe dejar pasar la oportunidad
al principio para pedir a los stakeholders para aclarar sus comentarios
si no los entendes. Podría ser comentarios sobre el alcance, , los
fuera de alcance , las necesidades de negocio, requisitos,
especificaciones funcionales, diagramas, o cualquier cosa relacionada
con el proyecto. El punto es, no importa cual sea la consulta, si no son
muy comprensibles, les pedimos que aclaren la cuestión. Muchas veces la
fase de requisitos de un proyecto se trata de ejecutar rápidamente, por
lo que es importante para establecer las expectativas de nivel de
comprensión de la materia al principio y con el fin de evitar ser
olvidado. Y te preocupa la pérdida de credibilidad en el inicio de un
proyecto por no saber el tema en detalle, imagínate la cantidad de
credibilidad que se pierde cuando no entendes nada después de tres
semanas de sesiones de análisis o diseño. Te aseguro que participe en
proyectos donde recibió documentación de los analistas que me sirvió muy
poco para entender cómo construir la aplicación.
Muchas veces, he
visto como buenos analistas pierden la credibilidad con un equipo de
proyecto, ya que no están dispuestos a admitir que no sabe algo. Ante el
temor de ser ridiculizados, el analista seguirá adelante, con lo que
saben del tema, pero cuando se llega a la hora de la verdad en un
proyecto y no son tan bien versados, entonces es cuando los requisitos
están en riesgo de ser incompletos o incorrectos. La próxima vez que
estés en una reunión del proyecto o reuniendo requisitos no sabes la
respuesta a una pregunta o no sabes cómo funciona un proceso de negocio,
proba utilizar uno de estos consejos para ayudarte a obtener una mejor
comprensión del tema. Tenes que ser lo suficientemente audaz para dejar
el miedo de perder credibilidad y hacer lo necesario para tener una
comprensión clara y concisa del tema en cuestión. Al hacer esto, te
colocaras en la posición para producir requisitos sólidos, reales, y
precisos.
Llegar a obtener estos resultados es muy importante para la siguientes etapas del proyecto.
Recorda que mucha gente se va a basar en esos requerimientos y que el éxito del proyecto depende mucho de vos.
Fuente:
http://blogsfest.blogspot.com.ar/2012/09/no-saber-la-respuesta-esta-bien.html
