No saber la respuesta está bien - Especialmente para el analista de negocio
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
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
No hay comentarios:
Publicar un comentario