Diseño para cubrir necesidades, no lo que uno quiere

A menudo diseñamos aplicaciones con sobre-ingeniería, como resultado, en gran medida, de intentar complacer a ciegas, a los clientes. Estamos tan distraídos por los detalles de las soluciones que ofrecemos, que a veces cometemos fallos, solventando en primer lugar los problemas incorrectos.

Así que aquí va un pequeño consejo: No convierta simplemente los requisitos del cliente en código, ponga esfuerzo en ser un buen intérprete. Es decir: Diseñe en base a sus necesidades, no simplemente en lo que uno quiere ofrecer.

Usted debe cuestionarse la definición de los requisitos, tomando como base que muchos clientes, definen mal sus necesidades reales que tienen.

Frecuentemente ellos dicen que necesitan una antena más grande, cuando de realmente, quieren decir que necesitan una mejor recepción de la señal. Entonces, usted debe plantear preguntas sencillas del tipo “Por quieres esta función?” y “Que beneficio esperas de esta?” y necesita investigar hasta recibir una respuesta adecuada. Una vez identificadas las necesidades subyacentes, se tiene la visión de poder ofrecer soluciones alternativas. No se detenga en la primera buena idea y no confié ciegamente en sus primeros instintos. Como el filósofo francés Alain (Émile Chartier) una vez dijo: “Nada es más peligroso que una idea cuando es la única que usted tiene”. Hágase preguntas deliberadamente del tipo “esta es la forma de hacer que?” y “de que otra forma puede lograrse?”.

De paso, esta es la mejor forma de reducir complejidad en sus aplicaciones: directamente de la fuente, que es donde más interesa. Soluciones simples y elegantes con frecuencia son difíciles de encontrar, y no suelen serlo en absoluto. Pero no hay que renunciar a ellas demasiado rápido, ya que se pueden perder grandes oportunidades.

Autor Claudio Perrone.

Versión original: Design for needs, not wants

---

Diseñe en base a sus necesidades, no simplemente en lo que uno quiere ofrecer.Ya que la solución propuesta puede ser muy potente, pero poco aplicable a su contexto final, lo cual puede forzar, a veces a realizar adaptaciones realmente dolorosas.

Mi profesor de programación en C siempre decía, una cosa es los que el usuario ve, y otra como la aplicación se comporta por dentro; extrapolando esta frase siempre digo, una cosa es lo que el usuario “dice que quiere” y otra lo que “realmente necesita” (los problemas de la comunicación).


Emmerson

---

- FIN -