La matriz de Eisenhower en el desarrollo de software
Dwight D. Eisenhower fue uno de los presidentes más importantes de los Estados Unidos.
Eisenhower dijo:
Hay dos tipos de problemas lo urgente y lo importante. Lo urgente no siempre es importante y lo importante generalmente no es urgente.
Hay una gran cantidad de verdad en este sistema.
Las cosas que son urgentes no siempre son de gran importancia, y las cosas que son importantes rara vez son de gran urgencia.
El peligro es caer en una de las falacias más peligrosas, una que te hará concentrarte siempre de forma continua en lo irrelevante.
El error es pensar que lo importante y lo urgente son sinónimos, pasando por alto la gran diferencia que hay entre ambos términos.
La capacidad de distinguir entre ambos es un paso clave para desarrollar de forma más eficiente.
Urgente
Lo urgente no exigen otra cosa que velocidad e inmediatez y generalmente nos lo asigna un tercero, como el cliente.
Pueden tener relación con una tarea importante, pero también puede que exijan tu atención inmediata aun sin merecerla.
Suelen ser más breves y sencillas de completar, así que solemos concentrarnos en ellas por motivos de procrastinación. Es decir, retrasamos tareas importantes que deben atenderse, sustituyéndolas por otras situaciones más irrelevantes o agradables con la escusa de ser urgentes.
Posiblemente en la actualidad el mejor ejemplo de algo que requiere inmediatez urgente es cuando te suena una notificación del móvil, requiere tu atención de forma inmediata, pero no tiene por qué ser algo importante.
Importante
Contribuyen con nuestros objetivos a corto o largo plazo.
Son necesarias para nuestro trabajo y no pueden ser omitidas.
Puede que no necesiten realizarse de inmediato y esto las hace parecer menos importantes.
Omitir este tipo de tareas tiene consecuencias negativas en el futuro.
Para el caso de lo importante, un buen ejemplo que comer saludable o hacer deporte. No es particularmente urgente, pero sí importante, de modo que de no hacerlo, a largo plazo, tu futuro no tiene buena pinta a nivel de salud.
Lo urgente y lo importante en el código
En el anterior artículo vimos los dos valores del desarrollo de software.
El primer valor, el del comportamiento, es urgente pero no siempre particularmente importante.
El segundo valor de la arquitectura de software es importante pero nunca particularmente urgente.
Por supuesto, algunas cosas son tanto urgentes como importantes. Otras cosas no son urgentes ni importantes.
Según la matriz de Eisenhower, podemos organizar estos cuatro pareados en prioridades:
- Urgente e importante
- No urgente e importante
- Urgente y no importante
- Ni urgente ni importante
La arquitectura del código es importante y se encuentra en las dos primeras posiciones de esta lista.
El comportamiento del código ocupa la primera y la tercera posición, dependiendo de la prioridad del comportamiento.
Existen comportamientos que nos transmite el cliente como urgentes, pero que realmente no son importantes en un momento dado y, por lo tanto, deberían estar en el nivel 3 de prioridad.
El error que se suele cometer es elevar cualquier comportamiento requerido por el cliente de los elementos de la posición 3 a la posición 1.
En otras palabras, no lograr separar las tareas que son urgentes, pero no importantes de las que realmente son urgentes e importantes.
Habitualmente, debido a esto, damos menos prioridad a la arquitectura importante del sistema a favor de las características no importantes del sistema para un momento dado.
Para los clientes todo es urgente, pero porque no saben diferenciar la importancia de la arquitectura. La clave es que los clientes no están normalmente capacitados para evaluar la importancia de la arquitectura. Y es muchos casos no son conscientes de ella.
Para eso nos contratan a nosotros, los desarrolladores de software.
Por lo tanto, es responsabilidad del equipo de desarrollo de software afirmar la importancia de la arquitectura sobre la urgencia del comportamiento.
Al igual que un médico, no te receta por diversos motivos una medicina, aunque sea la que quieras como cliente. O un cirujano no se salta la desinfección del quirófano porque tú tengas mucha prisa en operarte.
Lucha por la arquitectura
Cumplir con esta responsabilidad significa en ocasiones meterse en una disputa por priorizar.
El equipo de desarrollo tiene que defender lo que cree que es mejor para el desarrollo del producto, al igual que el equipo de gestión, el equipo de marketing, el equipo de ventas y el equipo de operaciones.
Siempre es una disputa.
Y es una gran parte de por qué nos contrataron.
Solo recuerda: si la arquitectura es lo último, entonces en el futuro el sistema será cada vez más difícil de desarrollar, mantener y, finalmente, el cambio será prácticamente imposible para una parte o la totalidad del sistema.
Si quieres aprender sobre lo siempre importante aunque no particularmente urgente:
Curso Clean Architecture en abierto - Lista de Espera
¿Te ha gustado esta newsletter?
Un pequeño click para ti, un gran descubrimiento para tus followers 👇
Te animo a que me des tu opinión, o me transmitas dudas en los comentarios de esta newsletter desde la web o respondiendo a este correo.
A veces tardo, pero siempre acabo contestando.