Lo que todo Gerente de Proyecto debe saber (parte II) – deGerencia.com

Lo que todo Gerente de Proyecto debe saber (parte II)

Este grupo de artículos contiene una serie de tips útiles en el Ciclo de Vida de todo Proyecto.

La Calidad y Claridad de los Requerimientos juegan un rol decisivo para el éxito del Proyecto

En este punto se cumple el refrán “Cuentas claras conservan amistades”. Se debe evitar a como dé lugar los supuestos, “yo pensaba”, “yo creía”, “yo juraba que…”.

Con el acento en los proyectos de desarrollo de software, este punto es de una importancia capital, importancia que ha trascendido hasta el punto que hoy disponemos de toda una Ingeniería de Requerimientos, acompañada de un señor proceso de administración de Requerimientos.

La importancia de la Calidad y Claridad de los requerimientos se basa en el hecho que éstos marcan el punto de partida para actividades como la Planificación, especialmente en lo que se refiere a las estimaciones de tiempos y costos, así como la definición de recursos necesarios y la elaboración de cronogramas que será uno de los principales mecanismos de seguimiento y control con los que se contará durante la etapa de desarrollo.

Mi estimado gerente de Proyecto, necesariamente debes manejar dos tipos de requerimientos:

Funcionales

A través de éstos se define el ¿qué?, y se describen con claridad las diferentes funcionalidades que tendrá el producto final a lograr.

No Funcionales

O atributos de calidad, a través de éstos se definen las características del producto final, como un todo, por ejemplo: operación y mantenimiento, seguridad, etc. (por lo general representan aquellos “detalles” que agregan valor).

Al hablar de “funcionales” nos estamos refiriendo a las funciones (funcionalidad) que el producto final debe tener.

El profesor del Departamento de Ciencias Naturales de la Sede de Occidente de la Universidad de Costa Rica, Michael Arias Chaves en su artículo \»La ingeniería de requerimientos y su importancia en el desarrollo de proyectos de software\», publicado en la Revista InterSedes ©, Volumen VI, Número 10, 2005, nos dice:

Es importante no perder de vista que un requerimiento debe ser:

  • Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
  • Posible de probar o verificar: Si un requerimiento no se puede comprobar, entonces ¿cómo se sabe si se cumplió con él o no?
  • Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
  • Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
  • Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
  • No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.

Y nos sigue diciendo:

Durante la etapa de especificación de requerimientos se pueden presentar muchos inconvenientes los cuales son importantes de identificar y prevenir:

  • Los requerimientos no son obvios y vienen de muchas fuentes.
  • Son difíciles de expresar en palabras (el lenguaje es ambiguo).
  • La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
  • Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
  • El usuario no puede explicar lo que hace
  • Tiende a recordar lo excepcional y olvidar lo rutinario
  • Hablan de lo que no funciona
  • Los usuarios tienen distinto vocabulario que los desarrolladores.
  • Usan el mismo término con distinto significado

Ahora bien, el objetivo, más bien el único objetivo, la razón de ser de todo proyecto (indiferentemente del tipo) es indiscutiblemente satisfacer uno o varios requerimientos, en la medida que sean cubiertos en su totalidad será la satisfacción de quien los formuló y con dicha satisfacción vendrá el éxito del mismo.

Para que hacerlo sencillo si podemos hacerlo complejo

Por lo general, por nuestra inmadurez y ante nuestro complejo y algo de frustración, en este punto sale a flote nuestro querido amigo el Ego quien maquiavélicamente nos induce a demostrar que tenemos el dominio cognitivo por encima de lo normal.

Mi estimado Gerente de Proyecto, recuerda el dicho chino \»en la simpleza esta la perfección\».

El solo hecho que usted sea el Gerente del Proyecto es un indicativo que le demuestra la confianza y el reconocimiento de la organización hacia su persona, no tiene porque “liberar” el Ego a fin de demostrar lo que la organización ya sabe. Recuerde, el producto final de su proyecto pasará a manos del equipo de mantenimiento, por favor, no le haga la vida más difícil de la que ya tiene, mientras más sencillo, mejor será su mantenimiento incluso, facilitará su ampliación y mejorará su tiempo de vida útil.

Salvatore Tarantino

26 años en el área de Seguimiento y Control de Gestión (10 años en Ingeniería - 15 en telecomunicaciones).

Más sobre Salvatore Tarantino

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Este artículo es Copyright de su autor(a). El autor(a) es responsable por el contenido y las opiniones expresadas, así como de la legitimidad de su autoría.

El contenido puede ser incluido en publicaciones o webs con fines informativos y educativos (pero no comerciales), si se respetan las siguientes condiciones:

  1. se publique tal como está, sin alteraciones
  2. se haga referencia al autor (Salvatore Tarantino)
  3. se haga referencia a la fuente (degerencia.com)
  4. se provea un enlace al artículo original (https://degerencia.com/articulo/lo-que-todo-gerente-de-proyecto-debe-saber-parte-2/)
  5. se provea un enlace a los datos del autor (https://www.degerencia.com/autor/staran)