Yo pensaba, yo creía….

Que no te engañen, nunca nada bueno salió de una idea esbozada sobre una servilleta de papel, quizás solo el fichaje de Zidane se salva de esta afirmación tan contundente, pero el resto de las iniciativas de este estilo terminaran sin duda alguna en un “yo pensaba, yo creía”

Y con esto quiero referirme al difuso tema de los requisitos necesarios para la realización / gestión de proyectos. La especificación de requerimientos de un proyecto determinado es una tarea de mucha importancia, a la que lamentablemente, y por distintas razones, no le dedicamos el tiempo y los recursos suficientes, por lo que en muchas ocasiones quedan incompletos. Como consecuencia, pues ya sabes, dificultades y conflictos en la implementación de este, incumplimiento de fechas y lo peor de todo, sobrecostes.

Para ilustrar mejor el tema me apoyaré en este sencillo ejemplo. Nuestro cliente solicita la construcción de un columpio en un árbol de su jardín. Y este podría ser el resultado ante unos requerimientos poco claros.

Seguro que alguno pensará que la imagen anterior es una exageración, y dirán eso de que la especificación no vale para nada, que el código fuente es la especificación más importante, que ya te mando un email de lo que necesito y tú ya te especificas lo que quieras, (mi preferida) que no tengo tiempo para esas tonterías, que seguro que para la fabricación del Mjolnir no se hicieron especificaciones… y un millón de excusas de este estilo.

Además, en contextos corporativos, el escenario se vuelve más complejo, ya que hay un torbellino de intereses de los distintos participantes / departamentos que interactúan sobre un proyecto ejerciendo diferentes tipos de fuerza y en ocasiones en sentido contrario y en donde el peor escenario posible es en muchos casos, proyectos cancelados, o que fracasan por no atender completamente las necesidades de los clientes o bien exceder el plazo o el presupuesto estimado.

Yo que estoy en mi empresa desde antes de que la Wikipedia existiera, he trabajado en muchos proyectos y basándome en mi experiencia… creo que una buena especificación de requerimientos es pieza fundamental en la elaboración de un proyecto, ya que marca el punto de partida para las actividades a realizar, así como la planificación y todo lo que se refiere a estimaciones de tiempos, recursos y costes, o la definición de hitos que será uno de los principales mecanismos de control con los que se contará durante la etapa de desarrollo. Además, la especificación de requerimientos será la base que permitirá verificar si se alcanzaron o no los objetivos establecidos en el proyecto ya que estos son un reflejo detallado de las necesidades del cliente final o los usuarios del programa, contra los que se verificará el cumplimiento de las metas trazadas. Además, seguro que una falta de planificación de uno de los participantes del proyecto se convertirá en una emergencia para otro de los integrantes del equipo, así que mejor si está todo controlado y por escrito… que a nadie le gusta que le pongan la cara roja como a J. Balbin.

Desafortunadamente no puedo dar una solución mágica sobre este asunto, aunque si algunas directrices básicas que vosotros mismos podéis contrastar en las características de una buena especificación de requerimientos definidas por el estándar IEEE 830-1998.

Resumo algunas características que deberías cumplir:

  • Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
  • Un requerimiento debe ser básico, conciso y fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
  • Un requerimiento debe ser consistente y no admitir ningún tipo de duda.
  • 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.
  • Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo se sabe si se cumplió con él o no?
  • Modificable. Aunque todo documento es modificable, se refiere a que debe ser fácilmente modificable.
  • 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.

Así que ya sabes, ya seas usuario o integrador de soluciones, siempre exige una buena especificación, para que nadie te pueda decir yo pensaba que necesitabas otra cosa o yo creía que no era tan importante

Dedicado al más grande… del que aprendí la importancia que tiene una buena especificación para la creación de grandes soluciones.

Idioma