Los requisitos nunca se entienden y el usuario sabe lo que quiere cuando lo ve funcionando

Para mí es, aún hoy (me gustaría repetirlo, para mí, que llevo en esto ya tiempo, y aún hoy, casi 2020), sorprendente tener que seguir luchando contra el Lado Oscuro de la prescripción en la creación de productos basados en software (tan típica de la gestión clásica y los ciclos de vida en cascada) en defensa de la adaptación (tan típica en modelos Ágiles).

Prescripción, ya sabes, una de las múltiples maneras de llamar a intentar adivinar y acotar el futuro con bastante tiempo de antelación, adelantándose mucho, y especificando, típicamente en documentos, lo que posteriormente debe implementarse, lo que quiere crearse.

Y, curiosamente, frente a lo que se pueda pensar, a día de hoy, como te dije, casi en 2020, tenemos que andar concienciando de los históricos problemas de la prescripción…. a gente de veintitantos recién salida de la Universidad. En contra de lo que pueda parecer, este problema no es, no sólo es, de generaciones más antiguas.

Para los que os gusta Scrum, Scrum del bueno, no del oscuro, hay tres viejas Leyes que se han usado (por sus creadores) para justificar su aparición, generalizables a cualquier modelo de trabajo adaptativo / Ágil.

3 Leyes que nos recuerdan los problemas de la prescripción, de intentar adivinar el futuro, y tenerlo muy estudiado y documentado, antes de empezar a crear:

  • La Ley de Ziv, los requisitos nunca se entienden completamente
  • La Ley de Humphrey, los usuarios no saben realmente el software que quieren hasta que lo ven funcionando
  • El lema de Wegner, un sistema interactivo nunca puede ser ni especificado ni Testeado por completo 

La verdad es que sin nombres molones, como los anteriores, ya sabíamos todos, o casi todos, los que nos dedicamos al mundo de la gestión y el desarrollo software que las anteriores «Leyes» existían. Aun así, no está demás recordarlo.

1 comentario en “Los requisitos nunca se entienden y el usuario sabe lo que quiere cuando lo ve funcionando”

  1. Hay un tema subyacente a estas 3 leyes que comentas, que es el derivado de la especialización: todo el mundo conoce bien su campo de actuación específico pero pocos tienen una visión de conjunto que les permita ver las posibilidades de desarrollo (y, adicionalmente, pocos son los que tienen una visión sistémica de la realidad sobre la que se trabaja).
    Esto quiere decir que los desarrolladores conocen suficientemente las inquietudes y necesidades de los clientes, ni los clientes conocen suficientemente bien las posibilidades que les puede ofrecer un desarrollo de software.
    El abancio de conocimientos de hoy en día es tan amplio que es imposible renunciar a la especialización, pero esto obliga a tres cosas: la primera, que es imprescindible una estrecha colaboración entre clientes y desarrolladores. La segunda, que no teniendo a priori, ninguna de las dos partes, un conocimiento idóneo del puerto de llegada, no se puede realizar un diseño previo o un plan de acción previo que sea cerrado. La tercera viene dada de cajón: si no se establece una relación de confianza entre las partes basada en la búsqueda del entendimiento mutuo y la buena fe, es dificil que se logren resultados ambiciosos.
    En el mundo de los servicios, éstas son cuestiones básicas, como lo son también para los modelos Ágiles, además de otras exigencias que se deben cumplir, por supuesto, para no caer en el Lado Oscuro.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba