Requisitos y especificaciones

Existe una confusión generalizada entre requisitos y especificaciones de un producto. Si bien, éstas pueden considerarse como requisitos, la inversa no aplica en muchas ocasiones.

Esto se produce sobre todo en contextos donde tenemos que evolucionar un producto, del cual exisiten diversas especificaciones y nuevos 'requisitos' cada cierto tiempo, que implican ampliar, actualizar o incluso rebajar dichas especificaciones.

Confundir ambos conceptos es muy peligroso, no solo en términos de redundancia de información sino en terminos de planificación, gestión de trazas, gestión de cambios, etc.

Los requisitos son inestables, ambiguos, cambiantes, volátiles; lo bueno es que no hay nada de malo en ello, siempre y cuando estos requisitos sean derivados (mediante múltiples técnicas en las que no entraré ahora) y estabilizados en especificaciones sólidas y consistentes para el desarrollo posterior.

La estratosfera y los consultores galácticos

La estratosfera es coto privado de algunos pocos afortunados.

Existen grandes consultoras e integradoras, de sobra conocidas, que han hecho un arte de la ambigüedad, la falta de concrección y la abstracción ilimitada de las soluciones que ofrecen, hasta llevarlas a un punto cercano a la idiotez.

Presentaciones, documentos de consultoría, artículos, opiniones,... muchas de ellas están infectadas por ese virus. Podemos llamarle virus aunque pienso que es una estrategia bien orquestada para cubrir dos objetivos fundamentales:

- Reutilizar trabajos anteriores para trabajar menos. Mientras mas abstracta sea la solución, más se puede reutilizar.
- Evitar entrar en conflictos (véase el temor al conflicto). Cuanto mayor sea el nivel 'estratosférico', menor es la posibilidad de desacuerdo, por tanto, conflicto. Claro, no conviene enfangarse en discusiones para las que pueden quedar al descubierto las vergüenzas de los consultores y consultoras 'galácticos'.

Hay que reconocer que han sido capaces de 'estandarizar' ese nivel 'estratosférico' como adecuado para las soluciones que ofrecen. Así, tenemos un monton de 'expertos de whitepaper'. Aquellos que leyendo un whitepaper conocen todo lo necesario para permanecer cómodos y, hasta parecer expertos en ese nivel 'estratosférico'

He ahí el verdadero consultor galactico, aquel que es capaz de parecer experto en múltiples tecnologías, soluciones o métodos de trabajo. Un ser capaz de devorar panfletos escritos por sus semejantes, con los que se entiende y a los que admira. Aquel que habrá recomendado en las más importantes compañias cual debía ser la solución que 'otros' (pobres seres terrícolas) han tenido que implementar.

Repetibilidad

Supongamos que somos los responsables en una organización de que se lleven a cabo un conjunto de tareas. Lo más probable es que nos interese que se realicen bien. Existen dos métodos simples para que las cosas se hagan bien: el primero es hacerlas nosotros mismos y el segundo es encargárselas a personas de nuestra confianza. A posteriori, tenemos las mismas dos opciones para asegurarnos de que las cosas realmente se hicieron bien: revisarlas nosotros mismos o que lo haga alguien de nuestra confianza.

¿Pero qué pasa si no tenemos tiempo o conocimientos para revisar la ejecución de las tareas o el resultado de las mismas? ¿Y si tampoco conocemos a alguien de confianza para que lo haga por nosotros? Siempre está la posibilidad de contratar a alguien, pero pagar a alguien es un poco como pagar a una prostituta: nos va a dar lo que queremos, si gastamos mucho dinero podremos presumir de con quién hemos estado... pero lo más probable es que todo sea fingido. Siguiendo con el símil, existe la alternativa de la boda: ofrecer una posición permanente, seguridad y buenas condiciones. Pero como en los matrimonios, la rutina, la desgana y las recriminaciones están a la vuelta de la esquina.

Y eso es porque la revisión de la calidad del trabajo no es el la labor más excitante ni la más reconocido. Sobretodo porque es un montón de trabajo que requiere un montón de personas. Y cuando una tarea -que, seamos francos, proporciona un valor tan discutible a la organización por no hablar a corto plazo- requiere muchas personas altamente cualificadas lo que se suele hacer es contratar a unos pocos, menos preparados y con la finalidad de explotarlos.

Así, en el mejor de los casos, nos encontramos con un grupo de revisores de la calidad descontentos, mal pagados y con demasiado trabajo. En tales condiciones, lo único que se puede pedir es que al menos su trabajo sea sencillo. Idealmente la revisión de la calidad estaría totalmente automatizada pero no siendo así es imprescindible que las tareas manuales sean repetitivas: no sé le puede pedir a una persona que revise hoy el ensamblado del SEAT Panda y mañana la traducción al japonés de su manual de usuario.

Es decir, para que una persona que no esté especialmente preparada y motivada sea capaz de controlar la calidad es necesario que los productos y actividades sean siempre iguales. Una gran variedad en los procesos de desarrollos o las tecnologías de desarrollo que utilizamos nos condena a utilizar controles de calidad genéricos -incapaces de tratar gran parte de los problemas en su origen.

Así, la introducción de una nueva tecnología supone un cambio en el proceso de desarrollo y una merma de nuestra capacidad para controlarlo. El coste que de esto se deriva ha de ser tenido en cuenta antes de introducir nuevas herramientas (o utilizar nuevos proveedores).

Tendencias:

1) Metodologías OpenSource como instancias de los estándares de calidad. Basta de pagar a las grandes consultoras por procesos propietarios cuya calidad queda fuera de nuestro control.
2) Extensiones asfixiantemente específicas de 1) para soluciones tecnológicas concretas. Basta de pagar a nuestros empleados por el "tuning" de arquitecturas y metodologías, y
3) Automatización de 1) y 2).