The Inversion of Control Pattern (IoC)

Hi there! It’s me, remember me?

It’s been a while, a lot of things have happened; good things, no worry about that… I just forgot about this blog and recently I read some good stuff about something that I could use to make a good article… so here we are!

Today I’ll talk about a pattern I’ve been using for more than one year and a half and it’s a proven usefulness: The inversion of control pattern (IoC).


When a class (say ClassA) depends on other class (say ClassB) and it needs some instance of it in order to do its job, we say that ClassA is coupled with ClassB. If ClassA needs to know a lot of details of ClassB then we say it’s tightly coupled.

public class ClassB
    public void SomethingCool() { ... }

public class ClassA
    private ClassB svc;
    public ClassA()
        svc = new ClassB();

    public void DoSomethingInteresting()

Coupling is a problem for two reasons, mainly:

  • Changes in ClassB have the risk of breaking ClassA.
  • Designs are not flexible and it’s difficult to modify ClassA so that it uses the services provided by ClassB differently.

Normally, the best way to reduce coupling consists of introducing some abstraction layer between both, implemented by some abstract class or interface, so that ClassA depends on ClassB in those abstraction terms.

public interface ICoolService
    void SomethingCool();

public class ClassB : ICoolService
    public void SomethingCool() { ... }

public class ClassA
    private ICoolService svc;

    public ClassA()
        svc = new ClassB();

    public void DoSomethingInteresting()

This solves almost everything, because ClassA still needs to determine what implementation of the abstraction will it use.

Moving out of the dependant class (ClassA) the creation of the dependency (ClassB) is what the IoC (Inversion of Control) Pattern tries to solve. The name reflects what it does: invert the control bewteen the “dependee” and the so called “depender” (ClassA -> ClassB).

IoC is an abstract pattern that doesn’t explain how to achieve our purpose. Two common ways to implement it are:

  • Service Locator
  • Dependency Injection

The Service Locator Pattern (SL)

The aim of this pattern is to achieve IoC making the software components get their dependencies from an external component called Service Locator (SL).

There are two kinds of SL:

Strongly typed

public interface IServiceLocator
    ICoolService GetServiceB();

and then:

public class ClassA
    private ICoolService svc;

    public ClassA(IServiceLocator sl)
        svc = sl.GetServiceB();

    public void DoSomethingInteresting()

The code who instantiates ClassA needs to provide an instance of a service that implements IServiceLocator. This interface returns elements of services interfaces: IService1, IService2,… to that all client classes (such as ClassA) are loosely coupled to the services. As you can see, we delegated the problem of instancing some precise ClassB on the SL.

The problem of this approach is that the IServiceLocator is not flexible regarding the services it provides. Adding new services after it was defined may require to modify some existing classes in order to use those services.

Weakly typed

public interface IServiceLocator
    TService GetServiceB<TService();


public class ClassA
    private ICoolService svc;

    public ClassA(IServiceLocator sl)
        svc = sl.GetServiceB<ICoolService>();

    public void DoSomethingInteresting()

Thus, the SL can provide new services without knowing about them ahead of time, reducing maintenance.

On the other hand, the weakly-typed SL can do little custom configuration for each service provided, since it is so generic.

The Dependency Injection Pattern (DI)

Instead of having an intermediary object that handles all the dependencies, these are directly received during instanciation as constructor parameters. This kind of DI is called Constructor Injection.

public class ClassA
    private ICoolService svc;

    public ClassA(ICoolService someSvc)
       svc = someSvc;

This way dependencies are explicit int he constructor and, by reading the it, we can figure out what dependencies have the whole ClassA.

Contrariwise, when using the SL we need to read the whole ClassA looking for the SL uses to get a picture of the dependencies ClassA has.

An alternative to the Constructor Injection is the Property Injection, which consists of defining in the client class (ClassA) a property of the interface implemented by the service it depends on and rely on someone filling it.

public class ClassA
    private ICoolService svc;

    public ICoolService CoolService
        get { return svc; }
        set { svc = value; }

The constructor is cleaner -or even redundant- since it doesn’t require all the services stuff.

The problem with this implementation is that we trust that someone will provide the property instanciated, otherwise a null exception will be raised… unless we protect every single access to the service checking for null, which could hide bugs in the code.

That’s why Constructor Injection is strongly recommended.

Dependency Injection Containers

There’s some unanswered question still:

how we provide the implementations of the dependencies in the first place?

So far we’ve moved the dependencies out of the business code but that’s just… moving the problem to a different place instead of solving it. If the whole system bases on DI then someone will provide implementations for… everyone else.

Here’s where Dependency Injection Containers come in place. DI Containers are libraries that implement what we need. They provide an API to define who implements what, so that when someone needs the what, some who is provided by the container. It’s like a SL extracted in an external library.


Testing gets huge benefits of using IoC, since we can mock dependencies and inject them in the code by just setting up a little bit the DI Container to tell it that, when testing, the implementations are provided by the mocks and not the actual implementations. Therefore, with no fluff in code we can easily test it.

Stack Browser app

Hi, there, it’s been a very long time since the last post… I promise to write something else more often and keep this good ol’ blog updated more frequently…

Today I’m glad to announce that I’ve just published my first Android app: Stack Browser!


Main Stack Browser screen

What stackoverflow is

Stack Browser is intended for software engineers that regularly use stackoverflow. For you to know, this website is probably the most well-known Q&A website regarding computing. It was created several years ago by Joel Spolsky (FogBugZ, among others) and Jeff Attwood (Coding Horror). Since it was started back in 2008, stackoverflow has become the most popular Q&A website and almost anything you google related to programming you probably will be targeted to this site. Due to its success, lots of sibling websites have appeared since then, all related to the idea of someone asks something and the community answer, and both questions and answers are promoted by users, so users get high rankings and their geek-ego becomes increased (I’m just kidding). Nowadays, all those sites are grouped by the StackExchange concept (yeah, let’s say conecpt or idea).


Bookmarks management.

 What Stack Browser is

So, this non-official app lets users browse (actually, browse) stackoverflow questions and answers. This is my first release of my first app, so the set of features is rather small yet:

  • Browse different categories of latest questions: active, most viewed / answered, featured, new, unanswered, most popular in the week / month
  • Filter by some term the results listed.
  • Search on the website by title, tags and answers.
  • Read the detail of the questions and answers.
  • Bookmark your favourite questions to read them later.

Detail of a question and its answers.

My first aim in this release was to make easy for users browsing questions related to some specific term or issue, read answers and keep them in a handy place to seek them later. I’m not that interested currently in: show who wrote what, posting or voting. I was interested in the contents, going to the point.

There are other apps in Google Play available, most of them are not very useful or are just web browser embeeded in Android applications; a couple of them are very nice but they don’t make the searching or reading a topic as easy as I’d like to see in a stackoverflow app.

My concern was to provide an app that makes reading a topic easy in a reduced-size screen.



Question expanded.

Tablets are one of my future targets, but first things first, I wanted an app in my smartphone to read stackoverflow questions in an easy way.

During the development of this app, I had to figure some possible solutions out to provide an acceptable way of reading questions and answers: one of those features was to let users expand the question to use all the available space, to show an answer in a different activity when it’s touched and to provide different layouts for portrait and landscape orientations.

That said, I’d like to develop more features that I have planned for the future, if users rate this app and like it. In the meantime I’ll be developing new Android applications, but if I get some acceptance by the community, these are the features I’d like to develop in the near future:


Landscape layout for a specific question.

  • Tablet specific layouts to fully use all the space available.
  • Translate the app into spanish, german…
  • Log in and voting features (cool!)
  • List users and their profiles.
  • List tags and information about them.
  • Support for other Stack Exchange sites (cool!)

So, I hope you like this app, download it, rate it and send  us feeback via Facebook,Twitter, Google+ or rate it in Google Play, or leave a comment just below!

La Ley de Servicios Profesionales y la Informática

La polémica ley de la que actualmente existe un borrador pero que en próximas fechas debería confirmarse, ha suscitado muchas polémicas. En este artículo trataré de aclarar y de informar, en la medida de lo que conozco, de cómo la LSP (Ley de Servicios Profesionales) nos afecta a la Ingeniería en Informática.

Lo que dice la ley

En esencia la ley dice que se elimina la mayoría de atribuciones profesionales. Esto significa que no hará falta que un ingeniero industrial preste su firma para un proyecto de construir una nave, la de un arquitecto para la construcción de una casa o la de un ingeniero de puentes para construir un puente. Se conservan algunas atribuciones muy específicas pero las más generales se suprimen, entendiéndose que no es necesario ser ingeniero en A para firmar un proyecto A, sino que es suficiente conocer los entresijos de dicho proyecto y tener cierta experiencia.

Esto, que en principio puede sonar muy bárbaro (¡¿ingenieros de montes firmando proyectos de construcción de puentes?!) quizá no lo sea tanto porque se conservan ciertas atribuciones específicas y se eliminan las demás (desconozco qué se conserva y qué se elimina), y la idea es, quizá, noble: reducir la carga burocrática y abaratar costes a la hora de realizar trámites para llevar a cabo obras. De ser así, ojalá no afectara sólo a ingenierías y arquitecturas, sino también a la abogacía y la notaría, ¿verdad?

Cómo nos afecta a los Ingenieros en Informática

En dicho escrito se establece que los profesionales de la informática podemos seguir con la nomenclatura de “Ingenieros”, si bien no se nos incluye en el reglamento que se establece para las demás ingenierías. Y aquí está la enjundia del asunto, amigos, en que no estamos con las ingenierías mayores, con casta y solera. Y de lo malo podemos darnos con un canto en los dientes: otras ingenierías nuevas han perdido hasta el trato de ingenierías…

¿De dónde viene todo esto?

De la “Ley Guerra” de 1986, llamada así por ser establecida por el entonces ministro Alfonso Guerra. Dicha ley regulaba las competencias de las distintas ingenierías; la Ingeniería Informática no existía aún en España, los pocos profesionales del sector no estaban aún organizados y por tanto no levantaron la mano para hacerse oír.

Por aquél entonces se estableció la regularización, mientras que ahora se trata de hacer lo contrario: des-regularización de atribuciones.

¿Cuál es el verdadero problema?

El problema real está en el hecho de que no se nos trate como a las demás ingenierías, en el hecho de que seamos tratados como una ingeniería “menor”. Actualmente este es el problema, dado que la desregularización de las atribuciones en principio no nos afecta en absoluto. Sin embargo, esta situación actual abre las puertas a muchos problemas futuros:

  • Si en el futuro vuelven las tornas y se decide re-regularizar las atribuciones (ya se hizo y probablemente se vuelva a hacer), nosotros que no estamos en el saco nos quedaremos fuera, y posibles atribuciones como por ejemplo Seguridad Informática, Criptografía o Gestión de Proyectos quedarán fuera de nuestras manos y pasarán a estar controladas por ingenieros industriales o de telecomunicación (sigh). Dado que nosotros no nos metemos a construir puentes pues pueden imaginarse lo que significa dejar en manos de personal no cualificado tareas de tamaña relevancia.
  • El hecho de estar menospreciados de una u otra manera afectará a que muchos futuros profesionales se decidan por otros estudios más prestigiosos, tendremos una fuga de cerebros en nuestro sector y dado que el área de las tecnologías es posiblemente el área con mayor futuro en España y en el mundo sería una pérdida irreparable para el país y para el avance de nuestra sociedad global.
  • Trato, respeto, igualdad… esas cosas básicas que se presuponen a todo individuo y a las que a veces hay que apelar para que te escuchen…

¿Quién es el malo de la película?

Esta ley empezó a barruntarse en el anterior gobierno socialista, y tiene su continuidad en el actual gobierno popular. Como he señalado antes, la ley no es ni buena ni mala, eso el tiempo lo dirá y el caso es más complejo de lo que parece. El asunto está en que nosotros nos quedamos fuera, y España no puede dar la espalda a más de 150.000 profesionales punteros en hacer avanzar al país. Para que se hagan una idea, los ingenieros de minas, que sí están en el grupo de los Elegidos, no pasan de 5.000.

De hecho hay políticos socialistas, de UPyD y populares que nos apoyan, comprenden la situación e incluso comprenden el escarnio que el actual escrito nos supone.

El verdadero problema está en los tecnócratas, los lobbys de poder que se encuentran apoltronados en los puestos relevantes de la Administración y no dan su brazo a torcer. Son éstos los que tienen la influencia para aconsejar y decidir el escrito final y que no quieren que nadie les quite su jugoso pastel. Estos lobbies están conformados por ingenieros industriales, de caminos, de telecomunicación… que dicen que estos chicos de los ordenadores no tienen nada que hacer, no son ingenieros y que cualquiera puede desempeñar su trabajo.

Dado que la labor desempeñada por la Ingeniería en Informática se encuentra fuertemente regida por procedimientos ingenieriles heredados y adaptados de otras ingenierías y no se trata de procedimientos científicos o artísticos, creemos firmemente (y así los planes de estudios lo estipulan) que somos tan ingenieros como otro cualquiera.

¿Qué es lo que queremos, entonces?

Que se nos trate como a las demás ingenierías. Ni más, ni tampoco menos. Queremos estar donde el resto de las ingenierías estén.

¿Qué podemos hacer?

Difundir el mensaje. Poner en conocimiento de todos los profesionales de la Ingeniería en Informática que esto es un problema que nos afecta a todos; que no nos va a quitar el plato de lentejas de cada día, pero que podemos perder una oportunidad CLAVE para futuras decisiones que atañen a nuestro sector y que nos competen, por simple y llana justicia.

Por encima de nosotros están los Colegios de Informática y distintas asociaciones y grupos de presión que tratan de hablar con políticos, difundir el mensaje y conseguir apoyos; la barrera principal no obstante radica en los lobbys que antes mencionaba.


En próximas fechas el escrito dejará de ser un borrador para convertirse en ley. El grupo socialista trató de confirmar el escrito la pasada legislatura, pero a última hora se echó atrás dado el bajo consenso y nuestras protestas en la calle. Así que lo dejó para el siguiente Gobierno y se quitó el marrón de encima. Ahora toca decidir, y ahora es cuando nos la jugamos.

Howto: Execute a command and use the output in Python

Let’s do something very simple to show a couple of things:

  • How to script Plastic SCM commands;
  • How to execute a program in Python and do something useful with the output.

Say that you want to check if there’s been some activity in a specific Plastic SCM server in a period of time. To do that, a good idea is to check if new changesets have been created. But let’s suppose that you have hundreds of repositories, so you really don’t want to check ‘em all one by one, do you?

Right, so let’s write some Python code to achieve this:

from subprocess import Popen, PIPE

proc = Popen(["cm", "lrep", "--format={1}"],
    stdout=PIPE, stderr=PIPE)

repositories = proc.stdout.readlines()

for repository in repositories:
    repository = repository.replace('\n','')
    print "Repository: %r" % repository
    proc = Popen(
         "changesets where date > '01/01/2013' on repository '"+
         repository + "@localhost:8084'"
        stdout=PIPE, stderr=PIPE)
    print "------------------------------"

First, we import the required library we need to execute subprocesses and redirect output and errors. This is a quite common library. Then we create a child process to execute the command “cm lrep”, to get the list of repositories in that server. The format string is just to cut the output in order to get just the names of the repositories.

See that we are redirecting the standard output and the standard errors to a PIPE. Then we get the output of the command. This is one of the beauties of Python: with just one single line you get and parse in an array the different lines of the output🙂.

Now we iterate in the list of repositories we’ve just got, remove the EOL character and execute the proper command to query if there have been new changesets in the last year (this could have been calculated with the current date, or could have been an argument to the script).

We execute the cm find changeset command and get the output, and just print it in the console.

Un relato corto

Año 2072. Como cada mañana, Fred se despertó a las 8 de la mañana. Había tenido una noche revuelta, probablemente debido a que estaban en primavera, el tiempo era bastante inestable y soñaba mucho. Se vistió rápidamente, tomó un café con un par de galletas, agarró su All-In-One y se fue a la calle, camino del trabajo.

Un All-In-One era un dispositivo que hacía las veces de teléfono móvil, radio, dispositivo de audio, cámara, calendario, gestor de eventos, sincronizador de redes sociales y otras mil cosas inútiles más. Más o menos como ahora, pero más pequeño y sin pantalla, ya que funcionaba a base de una especie de hologramas que uno controlaba con los dedos, describiendo ciertos movimientos en el aire.

Fred trabajaba como máximo responsable del departamento de IT en MeetLove, el Meetic de la época. Su creador, John Marrison había patentado hacía diez años una idea innovadora y rompedora: un sistema informático que, en base a parámetros sociológicos muy definidos y sesudos del cliente en cuestión, realizaba una búsqueda de la pareja perfecta, gracias a un algoritmo extremadamente complejo que se ejecutaba en un servidor de máxima capacidad, cuya responsabilidad era en estos momentos la ocupación de Fred.

En el año 2072 el ritmo de vida de las personas había provocado más divorcios y rupturas que nunca antes en la historia; la gente era más independiente, pero también más infeliz. Las personas no estaban dispuestas a aguantar en absoluto las manías o costumbres de otra persona, y a la menor discusión uno de los dos agarraba la puerta y se iba, y a empezar de nuevo. Muchos hombres y mujeres fallecían sólos en residencias privadas, pagadas con mucho dinero, y en muchos casos sin hijos. Precisamente la idea de John, que inteligentemente decidió patentar, cubrió una necesidad que muchos añoraban, o que soñaban cuando las oían contar a los más viejos: el amor, la fidelidad, el respeto, la complicidad de la pareja.

Desde entonces, y gracias al sistema de John, en los últimos diez años el número de divorcios se había reducido a tan sólo un 5% del total de nuevas parejas, o al menos eso decían ellos. “¿Para qué perder el tiempo con personas que no merecen la pena? ¡conoce a tu media naranja sin sufrir despechos y rupturas!”. Tal fue la campaña publicitaria que el mismo John personificó en los paneles publicitarios de los edificios que inundaban las ciudades.

Y la idea cuajó, vaya si cuajó. Los beneficios de John se contaban por millones y la gente era feliz. Pagabas, te sometías al procedimiento, y encontrabas a tu pareja perfecta. La gente acudía a su primera cita con la convicción del que se sabe ganador. Todo era más fácil. Nada podía fallar, el sistema era infalible. Muchos intentaron descifrar el algoritmo, sin éxito: el secretismo que lo protegía era absoluto, el servidor que ejecutaba la búsqueda estaba protegido por las máximas medidas de seguridad.

Aquella mañana, Fred había tenido una pesadilla. Algo no iba bien. Su antecesor en el cargo, el propio John Marrison en persona le había indicado que el sistema era tan estable que su trabajo sería coser y cantar, apenas le daría trabajo y casi nunca tendría que revisar el funcionamiento del sistema. En el sueño, el sistema se caía, el servidor dejaba de funcionar y todo era un auténtico caos, él era despedido fulminantemente y todo el mundo se reía de él.

Es por ello que aquella mañana se vistió rápido y fue casi corriendo a su trabajo, sin tomar el transporte urbano. Cuando llegó a su puesto, tuvo que revisar sus notas para consultar cómo se accedía al sistema central, el sistema más importante, el que ejecutaba el algoritmo de búsqueda. Se autenticó en los distintos niveles de protección del sistema hasta que llegó al núcleo. Entonces, se quedó pálido cuando descubrió que el núcleo estaba caído. Tras varios minutos de desesperada búsqueda, entendió que dicho algoritmo nunca existió, la máquina había operado en vacío los últimos diez años.

Fred comprendió la jugada de su jefe, y sonrió con una mueca de ironía. Miró la foto que colgaba de su despacho; en ella, John aparecía radiante, con los brazos cruzados, en una actitud de confianza y desafiante a la vez. “Qué cabrón”, pensó. Se levantó y se preparó un buen café.

Cómo conseguir realizar tus metas (IV y final)

El enfoque vertical

Como hace bastante que presentamos este enfoque y todavía no habíamos vuelto a ello, vamos a recordar brevemente en qué consistía el enfoque vertical: se trata de cómo enfocar un proyecto dado, desde su concepción a su culminación.

El enfoque vertical consiste en cómo mantener un proyecto bajo control, identificar una solución o asegurar que se han determinado todos los pasos correctos. ¿Y cómo lograrlo? Pues como suele ocurrir… de la forma más natural, que curiosamente es la menos frecuente.

Nuestro cerebro funciona de la siguiente forma:

  1. Define propósito y principios: primero el qué y el porqué.
  2. Visualiza el resultado: ¿a dónde pretendes llegar?
  3. Brainstorming: Ahora piensa en qué cosas tienen que suceder para llegar a tu meta.
  4. Organiza: De lo que has pensado, ¿qué sirve y qué no?
  5. Identifica las siguientes acciones: de lo que sirve, ¿en qué orden?

Mejor que ponerte directamente a hacer, piensa primero qué hacer y cómo lo vas a hacer. ¿Cómo organizarías una fiesta? Si te gusta la cocina, ¿cómo prepararías tu receta favorita? La clave está en definir el objetivo, visualizar el resultado, verte a tí mismo realizando el proyecto, porque así es más sencillo decidir cuáles son los pasos que te llevarán al éxito y qué descartar.

Lo más importante es empezar bien desde el principio: definir el qué y el porqué: define en qué consiste el éxito del proyecto, clarifica el objetivo, crea criterios de decisión. Si estás trabajando en equipo entonces motiva, y expande opciones. Para esto último es muy útil el brainstorming.

Lo mejor para tener una buena idea es tener muchas ideas, y nada hay más peligroso que una idea cuando es la única que tenemos.

Cuando utilices brainstorming, ten en cuenta lo siguiente:

  • No juzgues, retes, evalúes o critiques.
  • Busca cantidad, no calidad.
  • Deja el análisis y la organización para otro momento.

La importancia de la carga cognitiva

Un detalle muy importante cuando estés trabajando en tus proyectos es utilizar carga cognitiva. Esto es: utiliza algo físico que te agarre a la idea y que no permita que te desconcentres. Cuando estás pensando en un proyecto, el cerebro tiende a desconcentrarse a los 60 segundos. Es por ello que jugamos con una pelota, paseamos por la habitación, pintamos en un papel… todos ellos son signos para indicar a nuestro cerebro que se mantenga trabajando en ello y no se desvíe. Intenta pensar en algo cruzado de brazos, sentado quieto y mirando al techo; verás que te costará bastante más concentrarte y no cambiar a otra cosa.

Un consejo: utiliza boli y papel para escribir todo lo que se te ocurra. No importa que sean palabra sueltas, esquemas, flechas, tachones, dibujos… lo importante es tener un ancla para tu cerebro que lo mantenga trabajando en la idea. Sugiero boli y papel, pero puede ser lápiz, puede ser el ordenador o puede ser dibujar con un palo en la arena. Lo importante es utilizar carga cognitiva, algo que nos mantenga agarrados a la idea.

Organiza tus ideas

Una vez tienes todas las ideas delante de tí, identifica relaciones naturales y de estructura:

  • ¿Qué cosas deben ocurrir para obtener el resultado final?
  • ¿En qué orden?
  • ¿Cuál es el elemento más importante para asegurar el éxito?

Una vez hecho esto, decide los siguientes pasos. Defínelos hasta el más mínimo detalle, escríbelos y asegúrate de que no olvidas nada. Una pregunta: ¿quién lo va a hacer? Si no eres tú, añade las acciones pertinentes a la lista de En Espera.

Si no tienes claras las siguientes acciones, vuelve atrás, reorganiza, nuevo brainstorming, hasta que veas claros los siguientes pasos. Éstos deberían acabar surgiendo de forma natural. Tómate tu tiempo.

Algunos consejos finales

Vamos a hablar un poco del entorno de trabajo.

Lo primero es que tu entorno de trabajo no debería ser compartido, porque lo que para tí está bien para otra persona no tiene por qué ser adecuado.

Ten todo lo que necesitas al alcance de la mano. Fíjate que si compartes tu entorno de trabajo esto se complica, porque las cosas que necesitas tú probablemente no son las que necesita otro. No compartas tus herramientas: que no te ocurra que cuando vas a necesitar algo no lo encuentres donde debería estar. Esto parece muy riguroso, pero si has leído hasta aquí atentamente entenderás por qué esto es importante.

Antes de ponerte a la tarea, piensa en todas las cosas o recados que tengas pendientes y hazlos ya, antes de ponerte a trabajar. O bien planifica y calendariza claramente cuándo lo vas a hacer. Cinco minutos pueden salvarte una sesión en la que constantemente te distraes por hacer cosas pendientes más urgentes, o que aunque esas cosas no sean urgentes realmente te distraigan porque te ronden la mente en el momento menos oportuno.


Y esto es todo. Espero que hayáis encontrado interesante esta serie de artículos. Si os animáis a leer el libro ya sabéis dónde encontrarlo. He tratado de resaltar lo más importante, pero probablemente me haya dejado cosas y seguramente algunas cosas de las que he contado carecen de interés para otros, aunque para mí sí lo tengan. Al final lo importante es interpretar, reflexionar, juzgar y adaptar el conocimiento que recibimos a nuestras necesidades, para aplicarlos de la forma más cómoda para cada uno. Muchas gracias por los comentarios recibidos y si tenéis alguna duda más será un placer para mí atender vuestras dudas, espero saber resolverlas.

David Allen, Getting Things Done

Cómo conseguir realizar tus metas (III)

Terminamos con el enfoque horizontal:


Cada lista de las que hemos hablado tiene una frecuencia de revisión diferente. Las listas más urgentes son el Calendario y Siguientes Acciones. Lo recomendable es que revises tus lisas una vez a la semana. Un buen momento es hacia el final de la semana, los viernes por la tarde (un buen momento para revisar tus listas laborales) o los domingos por la tarde (coincidiendo con el cierre de la semana, es un buen momento para hacer una revisión de todo).

Lo más importante de todo es establecer un sistema del cual tu cerebro se fíe y delegue en él, de otra manera no lograrás deshacerte de ese estrés acumulado. Ello implica revisar tu sistema periódicamente para mantenerlo al día y que de este modo te puedas fiar de él.

Pero no sólo esto: el sistema debe ser tal que te ayude a ver todas tus posibles acciones a realizar cuando lo necesitas. Por ello tu sistema no debe basarse únicamente en algo como Evernote; imagina que tienes que recordar llevar mañana algo al trabajo; lo más natural es ponerlo junto a las llaves para que no se te olvide, ¿no? ¡Eso es un sistema fiable! Otro ejemplo: imagina que tienes que llamar al taller para preguntarles si tu coche está listo; ¡un buen método sería poner junto al teléfono la tarjeta del taller!

Un último ejemplo: cada vez que leo un libro siempre tengo al lado boli y un cuaderno para resumir las ideas más importantes. Fruto de ello son estos artículos, que además me sirven a mí para recordar los libros… pues bien: dada la gran acogida que están teniendo estos artículos me he querido esmerar en hacerlos bien, y he anotado cosas al margen de mis propias notas expresamente para los posts. ¿No es mejor esto que anotar en un sitio aparte lo que quiero decir en cada artículo?

Como ves, muchos de estos sofisticados sistemas no son más que sencillos consejos que muchas veces realizamos de forma casi intuitiva. Y es que, como suele ocurrir, lo más sencillo es lo mejor.


– ¿Cómo decidir entre la larga lista de cosas para hacer la siguiente?

Por intuición…

Parece que con esto no decimos nada, pero si has realizado correctamente las fases anteriores, sabrás tomar la decisión adecuada. No obstante vamos a ver algunos modelos que te ayudarán a decidir, por si con todo y con eso no lo tienes claro.

El modelo de los cuatro criterios para elegir acciones en el momento

Este modelo te ayudará a decidir qué hacer en cada instante atendiendo a qué es más apropiado, qué tiene más probabilidad de éxito en el momento actual. Siguiendo este orden de prioridad:

  1. Contexto: ¿Tienes las herramientas adecuadas y estás en el lugar preciso para realizar la tarea?
  2. Tiempo disponible: ¿Cuándo tendrás que emprender la acción siguiente? (Fíjate en que la pregunta NO es: ¿Cuánto tiempo te llevará realizar la acción? ¡sino que pensamos en el momento en que la siguiente acción requerirá tu atención inmediata! De este modo no gestionamos TIEMPO, gestionamos ACCIONES, como hablábamos hace un par de posts)
  3. Energía disponible: ¿Tienes la frescura necesaria para hacerlo?
  4. Prioridad: ¿Qué es más importante? Aquí, amigo, usa tu intuición🙂.

Evalúa tu lista de siguientes acciones atendiendo a estos cuatro criterios, en el orden especificado. Fíjate que si no estás en el contexto adecuado no puedes plantearte siquiera lo demás. Finalmente, ten en cuenta que la prioridad “real” de la tarea queda en último término.

Este modelo es el que más me gusta de todos, porque realmente ayuda a decidir entre unas u otras tareas, y considero que tiene bastante sentido común.

El modelo tríptico para evaluar el trabajo diario

Este modelo trata de enfocar cómo realizar la lista de acciones diarias. Según tal modelo, hay tres opciones:

  • Hacer trabajo predefinido: Estás usando tu lista de Siguientes Acciones.
  • Hacer el trabajo según llega: Imprevistos que se cuelan en tu lista.
  • Definir tu trabajo: Trabajas en limpiar y actualizar tus listas.

En todo momento te encuentras en alguno de estos modos: bien estás trabajando, o bien atendiendo a imprevistos o bien estás planificando con qué vas a seguir, revisando, organizando y procesando.

Con los imprevistos puedes hacer lo mismo que con cualquier otra acción: hacer, posponer o delegar.

Modelo de los seis niveles para revisar tu propio trabajo

Este modelo se encarga realmente de valorar la prioridad de las tareas. Según él, existen 6 niveles de prioridad, pero para ello necesitas tener claro en qué consisten tus proyectos:

  1. Vitales
  2. Visión a 3-5 años
  3. Visión a 1-2 años
  4. Áreas de responsabilidad.
  5. Proyectos actuales.
  6. Acciones actuales.

Estos niveles deben entenderse como niveles de perspectiva, no de prioridad necesariamente. Me explico: el nivel 6 es el nivel más concreto, menos abstracto, más inmediato y más factible. Es un nivel que permite acciones concretas e inmediatas por un lado pero que por otro no reportan un gran beneficio.

Por el contrario, los niveles superiores son los menos urgentes, más abstractos y definidos a un nivel de detalle menor, pero que tienen un beneficio mayor a largo plazo.

Fíjate en que ninguno de estos niveles es necesariamente más importante que el resto; todo depende de la perspectiva: la altura a la que se encuentre el objetivo.

Es importante que sepas clasificar cada acción y cada proyecto en alguna de estas categorías, para tener perfectamente claro en qué visión estás, tener claro qué esperas conseguir con dicha tarea, y de ese modo encontrar su valor real. Esto permitirá dar la prioridad adecuada a tus proyectos, porque te hará reflexionar en su importancia real, y no en la urgencia ficticia que solemos imponernos para realizar o posponer dichas acciones.


El enfoque horizontal se basa en que, dada una bandeja de entrada de tareas que hemos recolectado previamente, procesar o clasificar qué hacer en menos de 2 minutos y realizarlo, en riguroso orden de entrada, y el resto organizarlo en siguientes acciones, proyectos futuros (el libro desglosa esto más en material de referencia), para algún día o bien delegar en otra persona y anotar en una lista de “En espera”. Como véis: hacer, posponer o delegar. Este sistema requiere una continua revisión de las listas para mantenerlas actualizadas y que nuestro cerebro se fíe de dicho sistema. Finalmente, en algún momento realizamos cada elemento de cada lista, eligiendo la acción más adecuada en el momento adecuado, teniendo en cuenta su perspectiva. Todo esto hace que siempre estemos trabajando, delegando o atendiendo los imprevistos que se cuelan en nuestra bandeja de entrada y que requieren (o no, es importante evaluar minuciosamente esto) atención inmediata.

En el siguiente y último artículo veremos enteramente el enfoque vertical, y algunos consejos finales.

David Allen, Getting Things Done