Muchas veces, al leer un conjunto de requerimientos (ya sea de negocio, sistemas, o cualquier otro nivel que se nos pueda ocurrir), recuerdo aquellos juegos que venían en las revistas de crucigramas, en donde se enunciaban características de un conjunto de individuos, de manera tal que indirectamente, se pudiera descubrir a quién se refería el enunciado. Por ejemplo: El acertijo de Einstein.
Tenemos 5 casas de cinco colores diferentes y en cada una de ellas vive una persona de una nacionalidad diferente.
Cada uno de los dueños bebe una bebida diferente, fuma una marca de cigarrillos diferente y tiene una mascota diferente.
Tenemos las siguientes claves:
Y por ultimo la pregunta:
¿Quién es el dueño del pececito?
Cuando esto ocurre, no puedo evitar pensar que algo no está funcionando. Ante todo, una premisa: “No importa cuán hábiles seamos diseñando sistemas, ni cuán metódicos podamos ser. Si no se cuenta con requerimientos claros, hasta un diseño apropiado, es incorrecto, ya que no se basa en fundamentos lógicos. Es decir que su característica de apropiado, resulta una mera casualidad”.
Pero, ¿A qué se debe un conjunto de requerimientos pobremente o directamente MAL definidos?
Las causas pueden ser diversas, o una combinación de causas. A continuación, algunas que se me ocurren, tan solo por haberlas visto:
Y, ¿Qué se puede hacer ante tal situación?
Claramente, nuestra primer intención como profesionales de sistemas (buenos profesionales de sistemas), es intentar evidenciar el problema: Si el problema es desconocido, es un doble problema. Y si bien, suele ser la actitud correcta, también suele corresponder a la de los profesionales menos maduros (favor de no mal interpretar. No es ningún insulto ser inmaduro profesionalmente. Es solo la característica de quienes tienen poca experiencia en ciertas situaciones. Es decir, que podría haber desarrolladores seniors que sean inmaduros en cuanto a lo profesional). Esto lo digo, porque muchas veces la madurez profesional lleva a convivir con el desorden y acostumbrarse rápidamente a una situación desfavorable. Claramente, esto tampoco es del todo deseable. Existe infinidad de puntos medios entre estos 2 extremos, y la cercanía a uno o el otro, no necesariamente es directamente proporcional a la madurez profesional, sino que depende más bien de los tipos de personalidades, o características profesionales (como la mayoría de las acciones que desarrollamos). Entre estas características, se encuentra la creatividad, y es un concepto sobre el cual me detengo y me detendré muchas veces en el futuro por diferentes motivos. En este caso puntual, pero fácilmente generalizable, la creatividad no solo suele aportarnos una solución, sino que además suele aportarnos una solución alternativa, y esto es muy valioso, ya que la definición de requerimientos es un trabajo de interacción con el humano, y siendo todos los humanos diferentes, no podemos pretender poder encontrar solución a los problemas que con ellos tengan relación, siempre de la misma manera.
Un ejemplo algo trillado, seguramente eficaz para comprender la idea, pero inservible para comprender un requerimiento puntual:
Llegan requerimientos; Nos damos cuenta que son crípticos; La vía tradicional nos indicaría preguntar puntualmente, y para cada requerimiento, “¿qué intenta expresar?”; Una vía alternativa, podría plantear un juego, en el cual el desafío es encontrar la clave para desencriptar los requerimientos.
La creatividad puede dispararse de diversas maneras. En el ejemplo, la analogía entre algo confuso y algo encriptado, pide jugar a desencriptar.
Esta obviedad, ha llevado en el pasado, a diversas formas de reconocer necesidades, o de desencriptar las vagamente planteadas. Por ejemplo: Prototipos de interfases. Una pantalla con la funcionalidad final emulada (de manera que se comprenda el circuito futuro, sin tener que desarrollarlo al 100%). Esta técnica, hoy comúnmente aceptada y practicada, surgió alguna vez como una ídea creativa, y es importante no perder eso de vista, para entender, que las nuevas maneras de identificar requerimientos, pueden surgir en una reunión en la que cualquiera de nosotros participemos.
Tenemos 5 casas de cinco colores diferentes y en cada una de ellas vive una persona de una nacionalidad diferente.
Cada uno de los dueños bebe una bebida diferente, fuma una marca de cigarrillos diferente y tiene una mascota diferente.
Tenemos las siguientes claves:
- El británico vive en la casa roja.
- El sueco tiene un perro.
- El danés toma té.
- La casa verde esta a la izquierda de la blanca.
- El dueño de la casa verde toma café.
- La persona que fuma Pall Mall tiene un pájaro.
- El dueño de la casa amarilla fuma Dunhill.
- El que vive en la casa del centro toma leche.
- El noruego vive en la primera casa.
- La persona que fuma Brends vive junto a la que tiene un gato.
- La persona que tiene un caballo vive junto a la que fuma Dunhill.
- El que fuma Bluemasters bebe cerveza.
- El alemán fuma prince.
- El noruego vive junto a la casa azul.
- El que fuma Brends tiene un vecino que toma agua.
Y por ultimo la pregunta:
¿Quién es el dueño del pececito?
Cuando esto ocurre, no puedo evitar pensar que algo no está funcionando. Ante todo, una premisa: “No importa cuán hábiles seamos diseñando sistemas, ni cuán metódicos podamos ser. Si no se cuenta con requerimientos claros, hasta un diseño apropiado, es incorrecto, ya que no se basa en fundamentos lógicos. Es decir que su característica de apropiado, resulta una mera casualidad”.
Pero, ¿A qué se debe un conjunto de requerimientos pobremente o directamente MAL definidos?
Las causas pueden ser diversas, o una combinación de causas. A continuación, algunas que se me ocurren, tan solo por haberlas visto:
- Un equipo de analistas de requerimientos con conocimiento o experiencia limitada.
- Un liderazgo incorrecto del equipo funcional.
- Mala definición de los entregables que un equipo funcional debe comprometer.
- El misconcepto que reza “cualquiera puede interpretar una necesidad y escribir un requerimeinto”
- El análisis integral de requerimientos, como proceso previo o separado del de desarrollo representa una “pérdida de tiempo”.
- El misconcepto de pensar que un diseño debe ser lo suficientemente flexible para cubrir la falta de definición de requerimientos.
Y, ¿Qué se puede hacer ante tal situación?
Claramente, nuestra primer intención como profesionales de sistemas (buenos profesionales de sistemas), es intentar evidenciar el problema: Si el problema es desconocido, es un doble problema. Y si bien, suele ser la actitud correcta, también suele corresponder a la de los profesionales menos maduros (favor de no mal interpretar. No es ningún insulto ser inmaduro profesionalmente. Es solo la característica de quienes tienen poca experiencia en ciertas situaciones. Es decir, que podría haber desarrolladores seniors que sean inmaduros en cuanto a lo profesional). Esto lo digo, porque muchas veces la madurez profesional lleva a convivir con el desorden y acostumbrarse rápidamente a una situación desfavorable. Claramente, esto tampoco es del todo deseable. Existe infinidad de puntos medios entre estos 2 extremos, y la cercanía a uno o el otro, no necesariamente es directamente proporcional a la madurez profesional, sino que depende más bien de los tipos de personalidades, o características profesionales (como la mayoría de las acciones que desarrollamos). Entre estas características, se encuentra la creatividad, y es un concepto sobre el cual me detengo y me detendré muchas veces en el futuro por diferentes motivos. En este caso puntual, pero fácilmente generalizable, la creatividad no solo suele aportarnos una solución, sino que además suele aportarnos una solución alternativa, y esto es muy valioso, ya que la definición de requerimientos es un trabajo de interacción con el humano, y siendo todos los humanos diferentes, no podemos pretender poder encontrar solución a los problemas que con ellos tengan relación, siempre de la misma manera.
Un ejemplo algo trillado, seguramente eficaz para comprender la idea, pero inservible para comprender un requerimiento puntual:
Llegan requerimientos; Nos damos cuenta que son crípticos; La vía tradicional nos indicaría preguntar puntualmente, y para cada requerimiento, “¿qué intenta expresar?”; Una vía alternativa, podría plantear un juego, en el cual el desafío es encontrar la clave para desencriptar los requerimientos.
La creatividad puede dispararse de diversas maneras. En el ejemplo, la analogía entre algo confuso y algo encriptado, pide jugar a desencriptar.
Esta obviedad, ha llevado en el pasado, a diversas formas de reconocer necesidades, o de desencriptar las vagamente planteadas. Por ejemplo: Prototipos de interfases. Una pantalla con la funcionalidad final emulada (de manera que se comprenda el circuito futuro, sin tener que desarrollarlo al 100%). Esta técnica, hoy comúnmente aceptada y practicada, surgió alguna vez como una ídea creativa, y es importante no perder eso de vista, para entender, que las nuevas maneras de identificar requerimientos, pueden surgir en una reunión en la que cualquiera de nosotros participemos.