Especificando con ambigüedad

En múltiples ocasiones he escuchado el término 'ambigüedad', que hay que evitarla, que no debemos incurrir en ella, que los requerimientos son ambiguos etc. etc. ¿Alguien se ha planteado qué significa este enemigo de la humanidad (y de los proyectos) llamado ambigüedad? Pues simplemente significa que 'algo' se puede interpretar de 'distintas' maneras. Y eso ¿en qué nos afecta? Supongamos que un conjunto de requerimientos es documentado por el equipo de análisis, la forma en que ellos hayan descrito al requerimiento dará lugar a una buena implementación de dicha especificación en el producto. La lista de requerimientos pasará por varias manos, y si existen requerimientos ambiguos, cada quien los entenderá a su manera, cada quien le dará un significado diferente al requerimiento (con eso de que cada cabeza es un mundo) y al final tendremos que diferentes miembros del equipo entendieron el mismo requerimiento de diferentes formas.

Si un requerimiento no se encuentra debidamente detallado (empezamos con imprecisiones), entonces producirá ambigüedad. Pero los requerimientos pueden ser ambiguos incluso por la forma en que están redactados, entonces tenemos que cuidar hasta el lenguaje con el que describimos los requerimientos. El decir 'el sistema debe ser flexible' realmente carece de significado, más bien deberíamos indicar las formas en que el sistema podría cambiar para responder a los cambios del entorno o del negocio. O en ocasiones he leído requerimientos que dicen: 'el sistema no debe' (negatividad y ambigüedad pura), no no y no (hablando de negatividad) los requerimientos deben de ser positivos y enunciar aquellas acciones que el sistema debe realizar. Otro ejemplo de un requerimiento ambiguo es 'el sistema debe acelerar la velocidad del proceso de negocio x', pensemos... como diantres vamos a saber cuales son los valores mínimos aceptables de velocidad para el 'proceso de negocio x' si no lo tenemos especificado. Estás lagunas de ambigüedad forzaran en la mayoría de los casos a que el desarrollador interprete e implemente a su juicio un requerimiento, algo así como 'rellenar los espacios en blanco'.

Pero claro, se nos está olvidando un rol que rara vez existe en un proyecto y nos podría auxiliar en el combate de la ambigüedad... si adivinaron, el arquitecto de software. Esta persona tiene la dura tarea de enfrentarse a las ambigüedades de los requerimientos y rellenar aquellos vacíos. Esta persona bien nos podría ahorrar el hecho de que cada desarrollador interprete a su manera un mismo requerimiento (pausa... el mismo requerimiento podría estar implementado mas de una sola vez de distintas maneras en un mismo proyecto). Y bien, esta persona podría ahorrarnos bastante tiempo en el proyecto, ya que un requerimiento ambiguo se podría convertir en tiempo desperdiciado de desarrollo, ya que podríamos haber implementado una solución acertada para un problema equivocado. Y si nos vamos mas allá del desarrollo... pongamos un ejemplo de un tester, leyendo e interpretando un requerimiento ambiguo a su manera, el tester realizará una suposición de lo que 'debe hacer' dicho requerimiento, la cual es muy probable que sea una interpretación distinta a la del desarrollador que lo implementó, y al final hasta podrían llegar a un interminable debate sobre de 'quien tiene la razón'.

Lo anterior no significa que debamos leer los requerimientos como desquiciados en busca de ambigüedades, mas bien significa que debemos de estar conscientes del problema que estos representan, tratar de llevar un buen control de cambios de los requerimientos, diseñar nuestros casos de pruebas (regresando al ejemplo de 'el sistema debe acelerar la velocidad del proceso de negocio x', no hay manera de probar si el sistema cumple con este requerimiento, por lo tanto al intentar diseñar un caso de prueba para este requerimiento se descubrirá la ambigüedad), y sobre todo mantener informados a todo el equipo acerca de cuales son los requerimientos.

Corregir una ambigüedad en una etapa tardía del proyecto será costoso. Pero pues para nuestro objetivo del blog que es desadministrar proyectos, las ambigüedades son aceptables siempre y cuando no se excedan del rango permitido de manera razonable y suficiente (nunca había visto tanta ambigüedad en una sola frase), total... que más puede pasar si una simple línea que detalla un requerimiento se puede interpretar de distintas maneras (sarcasmo puro).

¡Complica lo complicado!

Imaginemos el siguiente escenario: Un arquitecto de software presentando su flamante y enmarañado diseño ante el jefe de una empresa, el cual se queda impactado al ver tantos símbolos en tan poco espacio, definitivamente nunca había visto un diseño tan 'completo', 'novedoso' y 'admirable'. Es más, desea que dicho modelo se presente ante el cliente en la reunión de avance del proyecto de esta semana y exclama exaltado: 'Definitivamente los clientes quedarán muy impresionados al ver este diseño, y así entenderán lo complicado de nuestro trabajo. Felicidades Arquitecto'.

¿Ya se lo imaginaron? pues ahora analicemos como este comportamiento nos ayuda a lograr nuestro objetivo del blog. Ciertamente en muchas ocasiones nos complicamos demasiado la vida, somos adictos a la complejidad, lo complejo nos atrae, ver algo complejo nos seduce y nos hace pensar 'eso debe ser muy bueno, porque se ve bastante complejo'.

El manejar un automóvil es algo muy sencillo, la abstracción es muy adecuada a la naturaleza humana, no nos preocupamos de como funciona, simplemente lo utilizamos (por ello ruego que nunca me falle el carro ya que no sabría que hacer, a duras penas sé como llenar el tanque de gasolina y ni siquiera sé calibrar una llanta). En un software el nivel de abstracción debe ser de la misma manera, el cliente debería operar la interfaz de usuario de una manera natural, sin preocuparse de como fue construida, pero regresando al tema, el hecho de tener un diseño exageradamente complejo, aparte de apantallar al cliente (y a uno que otro jefe) va a provocar muchos problemas en el desarrollo del software y verdaderos dolores de cabeza a lo largo del proyecto.

Un diseño demasiado complejo nos va a retrasar en la mayoría de nuestras actividades, inclusive en aquellas de planeación y control, ya que nos va a orillar a las prisas y posiblemente dejemos de realizar ciertas actividades (pruebas, SQA por mencionar algunas) para poder cumplir con la fecha de entrega y conforme al diseño. Por naturaleza todas las decisiones de diseño son ya de por si complejas, existen demasiadas cosas que debemos considerar y debemos de tener en cuenta que estas decisiones afectaran a todo el proyecto (y al costo del mismo). La misma arquitectura puede incluso disminuir o incrementar los riesgos de un proyecto, es por ello que la elección de buenas decisiones es vital. Un diseño demasiado complejo se verá reflejado en un esfuerzo mayor de desarrollo, y por lo tanto todo lo que conlleva: pruebas, integración, mantenimiento, etc. El costo ni se diga, veremos como se eleva rápidamente hacia las fases finales del proyecto (al igual que el riesgo).

El tener buenas decisiones de diseño nos traerán beneficios, y las malas decisiones consecuencias. Entonces es un hecho que tenemos que administrar la complejidad, y sobre todo, definir nuestras abstracciones adecuadamente, ya que en una aplicación a gran escala la complejidad se eleva exponencialmente y se convierte en un factor crítico para el éxito de nuestro proyecto.

Lo anterior me hace pensar en la verdadera importancia y responsabilidad de un arquitecto de software y la importancia de las decisiones de diseño que va tomando a lo largo del proyecto, ya que deberá estar administrando la complejidad durante todo el ciclo de vida. Y también me hace pensar en la responsabilidad que tiene el administrador del proyecto de conocer y estar consciente de la complejidad del diseño, ya que esta influirá directamente sobre los recursos que se necesitaran durante el proyecto, tales como personas, tiempo y presupuesto.

Cabe recalcar la importancia de la abstracción, ya que esta nos llevará a tener interfaces más simples, y la falta de la misma nos llevará a una complejidad excesiva del sistema y muy posiblemente al fracaso de nuestro proyecto, por lo tanto... ¡Vamos a complicar lo complicado!

¿Desde cuando los patos le tiran a las escopetas?

Hola, el día de hoy les traigo un buen consejo para ser un buen desadministrador. Si deseas que tu proyecto sea todo un fracaso te será de gran ayuda el sentirte el 'Jefe de jefes' y 'llevar el puesto en alto' a donde vayas. Deberás creer que tu opinión es la única que vale, y que nadie más de tu equipo de trabajo merece ser escuchado, es más, ni siquiera mirarte a los ojos.

Cuantos de nosotros hemos visto o tenido este raro comportamiento, en el cual nuestro punto de vista es sagrado e intocable, totalmente exento de críticas en pocas palabras, la ley, sin contradicciones. ¿Y que pasa con nuestro equipo de trabajo? ¿No pueden opinar? ¡Claro que pueden! cuantas veces hemos descartado ideas brillantes sin siquiera haberlas escuchado, o peor aún, cuantas veces las hemos escuchado y pensado que son buenas ideas, pero simplemente el 'orgullo' nos hace rechazarlas al momento.

Sin duda uno de los puntos más importantes en un proyecto son las relaciones interpersonales y la comunicación efectiva a lo largo de toda la organización. El tener un equipo de trabajo al cual le inspires confianza, y se sientan con la libertad de expresar sus opiniones por muy diferentes que estas sean de las tuyas ayudará a impulsar el éxito de un proyecto. No debemos frenar la creatividad del equipo, esto sin embargo no significa que siempre sea un buen momento para incorporar dichas ideas al proyecto, pero las podríamos incorporar más adelante y el equipo quedará con un buen sabor de boca por haber aportado un granito de arena extra al proyecto.

He conocido líderes de proyectos con una gran habilidad de manejo de personal, ¡vaya forma de tratar al equipo de trabajo! todos lo respetan por sus habilidades, por su conocimiento, y confían plenamente en los planes y objetivos que establece conforme avanza el proyecto. Eso me hace reflexionar que el respeto se gana, no se impone.

Pero creo que me estoy desviando del tema central de este blog, si lo que buscamos es desadministrar el proyecto, la próxima vez que alguien del equipo nos contradiga basta con decirle: "¿Desde cuando los patos le tiran a las escopetas?"