Es necesario negociar los requerimientos de un proyecto TI
Supone la clave en la consecución del éxito
Después de algunos años, puede llegarse a la conclusión de que una de las ideas más destructivas que circulan en los grupos técnicos es la de la “recopilación” de los requerimientos o necesidades para un proyecto de Tecnologías de la Información.
Durante décadas, casi todo el mundo en el sector ha aceptado que la primera fase de todo proyecto TI debe ser la de recopilar los requerimientos planteados por los usuarios. Al menos en teoría, ese debería ser el punto de partida para todas las actividades. Por lo tanto, ahora que el porcentaje de éxitos para proyectos TI ha aumentado a la todavía decepcionante cifra del 25%, quizás sería conveniente cuestionarse una parte de esta antigua idea.
Cuando se trabaja en tareas de consultoría y celebrando conferencias, con frecuencia se plantea la pregunta: Cuáles son las causas principales de los fracasos en los proyectos? Y casi, invariablemente, una de las primeras respuestas es: Porque no se recogen unos requerimientos adecuados.
Y cuando uno se pregunta por qué se recogen requerimientos inadecuados para los proyectos, las respuestas son: los usuarios no nos dicen lo que desean, o, no hacemos buenas preguntas, o lo que nos dijeron que querían no era lo que querían realmente. Sin embargo, el problema es más sutil que ninguna de estas respuestas.
El problema de recopilar los requerimientos está precisamente ahí, en el término “recopilar”. ¿Qué imagen trae a la mente esta palabra? Para algunos, puede ser la imagen de una cosecha, de un grupo de personas ante filas interminables de vides, recogiendo uvas maduras y colocándolas cuidadosamente en un cesto. Para otros, podría ser la imagen de un niño recogiendo conchas marinas en la playa o un grupo de personas agrupadas en una reunión del ayuntamiento. Lo que es común a todas estas imágenes de recogida es que hay algo que recoger, como cosechas, conchas marinas o personas, y que estas cosas están disponibles ya enteras y completas.
Por lo tanto, si estamos recogiendo requerimientos TI, asumimos que deben existir, dispuestos para ser agrupados como un paquete de monedas. El problema está en encontrar y elegir los adecuados. Por lo tanto, si los usuarios de la tecnología no nos dicen lo que realmente desean, debemos extraer de ellos hasta el último requerimiento que tengan. La única conclusión es que si no obtenemos requerimientos adecuados, no nos habremos esforzado bastante en extraérselos.
Naturalmente, esto resulta algo ridículo. Los requerimientos no son algo que flota en el éter, totalmente disponibles y completos. Los clientes y los usuarios que trabajan en la empresa no están desarrollando un costoso juego de ocultación con los responsables de los proyectos TI. Generalmente, los bolsillos de los clientes internos están bastante vacíos, y en la mayoría de los casos no saben exactamente qué es lo que requieren o necesitan. E incluso si lo saben, es en forma de ideas incompletas o inconsistentes, que sólo pueden ser expresadas de manera parcial. Los proyectos rara vez comienzan con unos objetivos o requerimientos claros; comienzan en la confusión y en la ambigüedad.
El otro problema de recopilar los requerimientos es que sugiere cierta sumisión o pasividad desinteresada por parte del departamento TI. Da la impresión de que el trabajo de un equipo técnico es recibir órdenes como un camarero al que no le importase lo que uno come y que después sirviera la comida cocinada. Los equipos técnicos que mantienen esta actitud rara vez ofrecen un servicio de calidad.
Entonces, ¿cuál es la alternativa? Obviamente, en los proyectos se necesita conocer unos requerimientos sólidos sobre los cuales construir la tecnología.
Un conjunto de requerimientos deberá ser considerado como un tratado multilateral entre un grupo de naciones. Los representantes de las naciones negocian tratados buscando puntos de acuerdo, reconociendo limitaciones y estableciendo compromisos y compensaciones. La forja de un tratado es un proceso de creación activo y difícil. Nadie sugeriría “recoger párrafos” para redactar un tratado.
Por lo tanto, hay que negociar requerimientos entre las múltiples partes interesadas, cuyas posiciones e intereses deben ser reconocidos. Naturalmente, están los intereses de negocio de los ejecutivos que financian proyectos. Y están los requerimientos de los usuarios que trabajan con los sistemas todos los días. Y también están las necesidades técnicas de quienes crean, despliegan y soportan esos sistemas. Y la lista podría seguir.
Los proyectos de éxito no comienzan con una cosecha, sino con una serie difícil de discusiones sobre lo que hay que hacer. Si se deja de intentar recopilar requerimientos y se inicia un proceso de negociación de esos requrimientos, los proyectos producirán cosechas más ricas.
La tecnología SÍ importa en la empresa del siglo XXI
------------------------------------------------------------------------
La X Conferencia Internacional ComputerWorld sobre Tecnologías de la Información y las Comunicaciones se celebrará del 17 al 19 del próximo mes de mayo en Sancti Petri (Cádiz), bajo el lema “La tecnología Sí importa en la empresa del siglo XXI”. La Conferencia, que cuenta con el patrocinio de EMC, Informática El Corte Inglés, Microsoft, Nortel Networks y Unisys, se constituye en un foro de encuentro e intercambio de información para los principales directivos de Tecnologías de la Información y las Comunicaciones de las mayores empresas y organismos públicos españoles y centra sus contenidos en los aspectos ligados a la gestión de las TIC.
La X Conferencia Internacional ComputerWorld sobre Tecnologías de la Información y las Comunicaciones se celebrará entre el 17 y el 19 del próximo mes de mayo en Sancti Petri (Cádiz) bajo el patrocinio de EMC, Informática El Corte Inglés, Microsoft, Nortel Networks y Unisys. Si desea conocer más detalles sobre la Conferencia, puede solicitar más información a través del e-mail conferenciacw@idg.es. en el teléfono 91 349 66 00 o en www.idg.es/computerworld/conferencia
Durante décadas, casi todo el mundo en el sector ha aceptado que la primera fase de todo proyecto TI debe ser la de recopilar los requerimientos planteados por los usuarios. Al menos en teoría, ese debería ser el punto de partida para todas las actividades. Por lo tanto, ahora que el porcentaje de éxitos para proyectos TI ha aumentado a la todavía decepcionante cifra del 25%, quizás sería conveniente cuestionarse una parte de esta antigua idea.
Cuando se trabaja en tareas de consultoría y celebrando conferencias, con frecuencia se plantea la pregunta: Cuáles son las causas principales de los fracasos en los proyectos? Y casi, invariablemente, una de las primeras respuestas es: Porque no se recogen unos requerimientos adecuados.
Y cuando uno se pregunta por qué se recogen requerimientos inadecuados para los proyectos, las respuestas son: los usuarios no nos dicen lo que desean, o, no hacemos buenas preguntas, o lo que nos dijeron que querían no era lo que querían realmente. Sin embargo, el problema es más sutil que ninguna de estas respuestas.
El problema de recopilar los requerimientos está precisamente ahí, en el término “recopilar”. ¿Qué imagen trae a la mente esta palabra? Para algunos, puede ser la imagen de una cosecha, de un grupo de personas ante filas interminables de vides, recogiendo uvas maduras y colocándolas cuidadosamente en un cesto. Para otros, podría ser la imagen de un niño recogiendo conchas marinas en la playa o un grupo de personas agrupadas en una reunión del ayuntamiento. Lo que es común a todas estas imágenes de recogida es que hay algo que recoger, como cosechas, conchas marinas o personas, y que estas cosas están disponibles ya enteras y completas.
Por lo tanto, si estamos recogiendo requerimientos TI, asumimos que deben existir, dispuestos para ser agrupados como un paquete de monedas. El problema está en encontrar y elegir los adecuados. Por lo tanto, si los usuarios de la tecnología no nos dicen lo que realmente desean, debemos extraer de ellos hasta el último requerimiento que tengan. La única conclusión es que si no obtenemos requerimientos adecuados, no nos habremos esforzado bastante en extraérselos.
Naturalmente, esto resulta algo ridículo. Los requerimientos no son algo que flota en el éter, totalmente disponibles y completos. Los clientes y los usuarios que trabajan en la empresa no están desarrollando un costoso juego de ocultación con los responsables de los proyectos TI. Generalmente, los bolsillos de los clientes internos están bastante vacíos, y en la mayoría de los casos no saben exactamente qué es lo que requieren o necesitan. E incluso si lo saben, es en forma de ideas incompletas o inconsistentes, que sólo pueden ser expresadas de manera parcial. Los proyectos rara vez comienzan con unos objetivos o requerimientos claros; comienzan en la confusión y en la ambigüedad.
El otro problema de recopilar los requerimientos es que sugiere cierta sumisión o pasividad desinteresada por parte del departamento TI. Da la impresión de que el trabajo de un equipo técnico es recibir órdenes como un camarero al que no le importase lo que uno come y que después sirviera la comida cocinada. Los equipos técnicos que mantienen esta actitud rara vez ofrecen un servicio de calidad.
Entonces, ¿cuál es la alternativa? Obviamente, en los proyectos se necesita conocer unos requerimientos sólidos sobre los cuales construir la tecnología.
Un conjunto de requerimientos deberá ser considerado como un tratado multilateral entre un grupo de naciones. Los representantes de las naciones negocian tratados buscando puntos de acuerdo, reconociendo limitaciones y estableciendo compromisos y compensaciones. La forja de un tratado es un proceso de creación activo y difícil. Nadie sugeriría “recoger párrafos” para redactar un tratado.
Por lo tanto, hay que negociar requerimientos entre las múltiples partes interesadas, cuyas posiciones e intereses deben ser reconocidos. Naturalmente, están los intereses de negocio de los ejecutivos que financian proyectos. Y están los requerimientos de los usuarios que trabajan con los sistemas todos los días. Y también están las necesidades técnicas de quienes crean, despliegan y soportan esos sistemas. Y la lista podría seguir.
Los proyectos de éxito no comienzan con una cosecha, sino con una serie difícil de discusiones sobre lo que hay que hacer. Si se deja de intentar recopilar requerimientos y se inicia un proceso de negociación de esos requrimientos, los proyectos producirán cosechas más ricas.
La tecnología SÍ importa en la empresa del siglo XXI
------------------------------------------------------------------------
La X Conferencia Internacional ComputerWorld sobre Tecnologías de la Información y las Comunicaciones se celebrará del 17 al 19 del próximo mes de mayo en Sancti Petri (Cádiz), bajo el lema “La tecnología Sí importa en la empresa del siglo XXI”. La Conferencia, que cuenta con el patrocinio de EMC, Informática El Corte Inglés, Microsoft, Nortel Networks y Unisys, se constituye en un foro de encuentro e intercambio de información para los principales directivos de Tecnologías de la Información y las Comunicaciones de las mayores empresas y organismos públicos españoles y centra sus contenidos en los aspectos ligados a la gestión de las TIC.
La X Conferencia Internacional ComputerWorld sobre Tecnologías de la Información y las Comunicaciones se celebrará entre el 17 y el 19 del próximo mes de mayo en Sancti Petri (Cádiz) bajo el patrocinio de EMC, Informática El Corte Inglés, Microsoft, Nortel Networks y Unisys. Si desea conocer más detalles sobre la Conferencia, puede solicitar más información a través del e-mail conferenciacw@idg.es. en el teléfono 91 349 66 00 o en www.idg.es/computerworld/conferencia
