Antipatrón: Requerimientos lanzados sobre la pared

Siguiendo con la discusión sobre requerimientos, recordé que alguna vez leí sobre el antipatrón llamado "Requiremens Tossed Over The Wall".

Básicamente el contexto es el siguiente:

Al equipo de desarrollo se le da una visión de muy alto nivel sobre el sistema y se le pide (como parte del "proceso", claro está) que desarrolle una propuesta completa y detallada. El experto del lado del negocio revisa la propuesta y hace varios comentarios sobre algunos errores obvios. Si los desarrolladores tienen alguna duda durante la fase de construcción, se concertará una cita para una reunión o, dado que las reuniones son asuntos relativamente caros, elaboran una lista de preguntas que son enviadas via e-mail. El experto eventualmente responderá a las dudas del equipo cuando tenga algo de tiempo disponible. Finalmente, el sistema es entregado y el cliente trata de utilizarlo, pero informa al equipo que hay varios "errores" que deben ser corregidos.

¿Suena conocido? Bueno, no es de extrañar, ya que de hecho es la forma en que se desarrollan la gran mayoría de los proyectos. Pero, ¿qué onda con el nombre raro? Bueno se debe a que mayormente, el desarrollo de requerimientos cesa en el momento en que la codificación comienza. Simplemente, los lanzo por encima de la pared y me olvido de ellos: "ya no es mi problema".

Cruelmente, la realidad suele ser bastante distinta. En realidad, esta forma de pensar asume que los requerimientos del sistema son de hecho estables, o que permanecerán estables el tiempo suficiente como para entregar el sistema terminado. A menos que trabajemos en un dominio en el que los requisitos dependan más del ambiente físico (el sistema de aviónica de un 747, por ejemplo) que del cambiante mundo de los negocios, generalmente las cosas no son así.

En cuanto al usuario, no quisiera adoptar una postura radical como la expresada en la primera edición de "Extreme Programming Explained: Embrace Change" de Kent Beck, en la que básicamente ベック先生 nos dice que todos los proyectos deben tener a un usuario del lado del negocio asignado al 100% durante la duración del mismo, y trabajando en el mismo lugar que el equipo. Si bien es cierto que eso sería lo deseable, en muchos casos no es posible, ya sea por una verdadera imposibilidad operativa o bien por cuestiones de idiosincrasia. Sea cual fuere la razón, incluso el mismo Beck ha flexibilizado su postura al respecto con el tiempo.

Lo que no ha cambiado en lo absoluto es el hecho de que una gran parte de responsabilidad sobre el éxito o fracaso del proyecto recae en que el usuario se involucre directamente en él. Muchos usuarios hoy en día siguen creyendo que el desarrollo de software es como mandar hacer un closet, para lo cual basta elegir un modelo del muestrario del carpintero, que éste último tome medidas y esperar un número de días acordado para recibir aquello por lo que pagué.

Seamos realistas. Si este fuera el modelo a seguir, todos los usuarios podrían irla llevando solamente usando software COTS. Sin embargo en el mundo real, las cosas no son así. La mayoría de los negocios tienen particularidades que los hacen únicos. Los gerentes y directivos aplican estrategias que los diferencian de su competencia. Sus políticas son diferentes. Sus procesos son diferentes. No importa cuantos sistemas de control de producción se hayan programado, jamas se hacen dos iguales. Si, hay una gran área común entre sistemas para diferentes empresas dentro de una misma industria (y es aquí donde la experiencia ganada en una ventaja), pero finalmente quien realmente sabe cómo llevar el negocio es... si, el usuario.

En México tenemos un proverbio muy folclórico, pero muy atinado:

A ojo del amo crece el caballo.

Si de este sistema depende el poder aprovechar una oportunidad de negocio o no, el poder atacar un problema recurrente en mi organización o dejarlo como está, el obtener información fidedigna hoy para poder tomar las decisiones correctas sobre el rumbo a tomar mañana, ¿no debería entonces yo por lo menos dedicar por lo menos una parte de mi tiempo o la de algún colaborador que conozca el negocio lo suficientemente bien, para asegurarme que las personas que van a desarrollar el proyecto hayan entendido correctamente mis necesidades? ¿que hayan entendido cual es el problema que se pretende atacar, el valor de negocio que se pretende obtener?

Esto no solo disminuye sensiblemente el riesgo de llegar 6 meses después a la fecha de entrega para darnos cuenta de que el sistema está mal, sino permite aprovechar la experiencia y el talento del equipo de desarrollo para obtener soluciones más creativas que las que inicialmente podríamos haber imaginado.

El valor real de los requerimientos bien levantados y desarrollados es que dan la oportunidad al equipo de desarrollo de expresar en el lenguaje del usuario cuales son sus necesidades y expectativas, y así asegurarse de que las ha comprendido correctamente. Los requerimientos escritos (especialmente los casos de uso o "especificaciones funcionales") son antes que nada una herramienta de comunicación:

• entre el usuario y el equipo de desarrollo
• entre miembros del equipo de desarrollo
• entre miembros actuales y futuros del equipo
• entre miembros actuales y futuros del negocio

Si, la comunicación directa y frente a frente es la más efectiva, pero los requerimientos pueden ser también altamente efectivos cuando se usan correctamente y se desarrollan por las razones correctas; esto es, cuando aportan valor al proyecto.

Y por el amor de Dios... no pidamos documentar 400 páginas de requerimientos que nadie piensa leer con la única justificación de que "el proceso lo exige".