10 Reglas para el Análisis de Negocios

En TDAN The Data Administration Newsletter dan un listado de 10 reglas para obtener de la mejor manera los requerimientos cuando se está realizando un análisis del negocio:

1. Cuenta una historia

Una historia, en que consiste la empresa, sus inicios, el problema a solucionar y como se va a llegar a solucionarlo, hay que transmitir emoción, para que el cliente la perciba y apoye de mejor manera el proyecto.

2. Toma la ambiguedad y conviertela en certeza

Cuando una idea empieza, es vaga, algo sin forma, ni pies ni cabeza podríamos decir, hay que darle forma, hacerla mas material, con límites y fronteras, para que el equipo técnico pueda plasmarla en algo real.

3. Haz lo invisible, visible.

Generalmente los encargados de tomar las decisiones, no están involucrados directamente, hay que hacerles sentir de alguna manera, que vean el proyecto y se sientan parte, para que se haga visible y pueda ser aprobado.

4. No confundas la historia con los detalles.

La idea llevada a la práctica puede ser bosquejada con esquemas y gráficos, pero cuando ya hay que construirla hay que detallarla y los detalles son los que importan a los técnicos.

5. Lo suficiente es suficiente.

Tu criterio establecerá cuando es suficiente al momento de detallar una característica del proyecto.

6. Analiza tu audiencia, una medicina no cura todas las enfermedades.

Según la audiencia que tengas, expresate, y expon la parte del proyecto que sabes les va a interesar.

7. Es el proyecto de tu cliente, pero el resultado depende de tí.

El cliente paga por el proyecto, y pide tal o cual cosa, y uno puede ofrecerle algo más, pero al final lo que importa es entregar la solución, si uno ofreció algo más también forma parte del trabajo, ya no es adicional.

8. Una metodología es una caja de herramientas, no un proceso en sí. Eligela cuidadosamente.

Para un determinado proyecto, una metodología es especifíca. No podemos utilizar la misma para todos.

9. Imitar lo que es bueno.

Siempre que veamos a algien hacer algo bueno, hay que preguntarse ¿Cómo lo hizo? y ¿Yo puedo hacerlo?, lo bueno se imita, y se amplía.

10. Un problema compartido, es un problema casi resuelto.

Compartir conocimiento ayuda a terminar un proyecto más rápido y de la mejor manera, consultar a otra persona no es malo, uno aprende de todos.

El artículo completo en inglés lo pueden leer haciendo clic aquí.

No te olvídes de seguir las actualizaciones de la página en tu Facebook.

0 comentarios:

Recientes

Ultimos 3 en Visual Basic & Sql Server

Ultimos 3 en Sistemico en Apuros