Ir al contenido principal

Getting things done: 4 steps

Creo firmemente que los resultados se obtienen de las buenas ideas bien implementadas. Para eso es bueno tener un método para la toma de decisiones y la ejecución de las mismas.

Mucho se ha escrito al respecto, como es gratis y capaz le aporta a alguien va mi granito de arena sobre el método que yo trato de usar. No es nada innovador ni revolucionario, creo que es un refrito de AdizesSimon Sinek y otros que saben mucho más que yo del tema, sazonado con algo de experiencia en mi rubro. Capaz es un proceso muy orientado al "P" de Adizes pero, al menos en ese escenario, de pronto aporta.

Obviamente cada paso tiene mil puntas a considerar, esto es simplemente un "overview" para no perdernos en los detalles.




Los 4 pasos:

Paso 1: Acumulación
Conseguir toda la información posible sobre el tema a analiza/decidir. Especialmente visiones diferentes o hasta contrapuestas del asunto. La diversidad es clave aquí para evitar la miopía del experto. Si la información no es suficiente, procurar más.

Las trampas acá son:
a. quedar atrapados en esta etapa de acumulación. Una vez leía algo que decía "nos falta acumular mucha información para darnos cuenta que no estamos yendo a ninguna parte".
Tanto por escasez o abundancia extrema de información, lo más delicado en esta etapa es ¿cuánto es suficiente?
No conozco fórmulas al respecto.

b. asumir que determinadas cosas son de determinada manera sin ratificar esa asunción. Es el "contexto del experto" o el "pae de santo". Estas se identifican fácilmente cuando alguien comienza diciendo "yo creo....". En la etapa de acumulación no vale el "creo", la acumulación parte del pasado, algo "es" o "no es" o "no lo sé" pero, como dice un amigo: "a creer se va a la Iglesia".

Paso 2: Evaluación
A la luz de la información acumulada ¿cuáles son nuestras opciones?
Todas.
Las más conservadoras, las más razonables, hasta las más alocadas. Aplicar alguna técnica de "brainstorming".
En cualquier caso la idea es una lista clara para todos de las opciones, sus pros y sus contras.
Eventualmente esta etapa implica volver al Paso 1 (Acumulación) porque alguna opción requiere más información. Que así sea.

Las trampas acá son:
a. Quedar en loop entre la evaluación y la acumulación. Esos procesos que están como en una permanente discusión. Para esto lo mejor suelen ser las restricciones: tiempo, dinero, etc, suelen fomentar la creatividad.
Un tip para evitarlo: si piensa que le falta algún dato haga el ejercicio de inventar escenarios, si esos escenarios modifican la evaluación entonces vale la pena ajustar el dato. Si no es relevante el valor, no importa el dato.

b. Confundir esta etapa con la siguiente. A veces sucede que una opción parece claramente la mejor, sobre todo desde el punto de vista de alguien en particular y queda como "tomada" y se saltea el paso de la toma de decisión y vamos


Paso 3: Toma de decisión
¿Cuál opción tomaremos?
Eventualmente surge una opción como la mejor, la que tiene más apoyo o la que el sabio de la tribu define. Esa es la que se debe tomar.

¿No hay ninguna que guste? ¿se puede tomar la menos peor?
Si no se llega a una opción/decisión entonces de pronto hay que volver al paso 2 (Evaluación) o 1 (Acumulación) o de nuevo. Suele conocerse como: consultarlo con la almohada o directamente cajonear el tema.

Trampas aquí:
a. No zanjar el tema por no haber una opción claramente mejor (a veces temor a equivocarse). Las decisiones las tomamos o se toman solas. El tiempo, la competencia, el mercado, la tecnología, la naturaleza, todo puede terminar tomando la decisión por nosotros. Recordar que el no tomar una decisión es tomar la decisión de no hacerlo.

b. Exceso de democracia/comité. Del mismo modo que en la acumulación y en la evaluación la diversidad es importante, la decisión suele ser "en solitario", hay una opción que claramente se despega como la mejor y/o hay un "jefe" que define. En definitiva el jefe siempre es el que termina decidiendo porque es quien toma la responsabilidad de la decisión.

c. No abandonar opciones que se descartaron. A veces sucede que una opción que se plantea pero no se decide por ella sigue viviendo de algún modo. Hay que matarla, esa opción NO es la que se decidió adecuada, no invertiremos en ella. Caso contrario puede generar una guerrilla que conspire contra la opción que sí se ha tomado.

Paso 4: Ejecución
Una vez tomada la decisión hay que planificar y ejecutar las acciones. Nuevamente aquí puede suceder que tengamos que volver atrás a la toma de decisiones. A pesar de la acumulación y evaluación que hayamos hecho, el mapa es una cosa y el terreno es otra.

Trampas aquí:
a. volver siempre a la acumulación. Mi recomendación es volver a la toma de decisiones, si no se decide por alguna previamente analizada, entonces volver a las evaluación y así eventualmente hasta la acumulación, pero solo en última instancia se vuelve a la acumulación, no como primer paso hacia atrás.

b. Continuar en la ejecución de algo cuando es evidente que no fue la decisión correcta. Hay una escena en la película Titanic donde, con el barco zozobrando, el Ingeniero explica que eso no es posible. Esa escena describe claramente el tema.


Resumiendo el proceso: Acumulación/Evaluación/Toma de Decisión/Ejecución.



Algunos temas transversales a todas esas etapas:

Start with Why?

Sobre esto no voy a profundizar mucho, recomiendo simplemente ver este video.
Lo resumo en: siempre tenga claro el por qué hace lo que hace.
Es especialmente crítico en el punto de acumulación. Es lo que da el marco general al resto.

Five Whys?

Toyoda formalizó en Toyota el proceso de los 5 Whys que también me parece medular, sobre todo pensando en que todo lo que se pregunte en etapas tempranas puede ayudar a la toma de decisión y acción.

What if?

El "what if" es otro tema transversal donde uno se pregunta: ¿qué pasaría si tomáramos tal decisión o si consiguiéramos tal dato o si tal cosa ocurriera?
De algún modo es validar la decisión o acción.

Velocidad 

A veces el camino más rápido parece ser ir directamente a la ejecución, sin nada de lo anterior. Suponiendo un escenario, datos e intuyendo una solución. Puede que lo sea en el corto plazo, a veces ni siquiera eso.
Lo que sí es claro que lo que se invierta en las etapas tempranas suele ahorrarnos en la ejecución. También es claro que en la ejecución hay que ser lo más veloces posibles.
Al igual que cuando se emprende un viaje: saber el destino, evaluar las rutas, decidir por una y recién ahí comenzar el viaje.

¿Siempre es bueno aplicar este proceso?

No sé si este u otro, pero un proceso acordado con los actores involucrados siempre es bueno. No es recomendable no tener un proceso o que cada uno tenga el suyo.
Incluso cuando se trabaja solo en algo tener un proceso aporta.




Comentarios

Publicar un comentario

Entradas más populares de este blog

Abrir links con aplicaciones nativas y no el browser (deeplinking)

El problema que tengo con algunas aplicaciones Android/iOS es que cuando recibo un link por algún medio (mail, tweet, etc) al abrirlo me lo abre con el browser, en lugar de abrirlo con una aplicación nativa asociada a ese “contenido”. Por ejemplo, si recibo un link a un tweet espero que lo abra con alguna aplicación de twitter que tenga instalada y no con el browser. De modo análogo si recibo un mail con una nota de prensa de un medio X y tengo la aplicación de ese medio X instalada, espero que el link lo abra con la aplicación nativa y no con el browser. Lo mismo quisiera con mi aplicación de "banking" o cualquiera que tenga instalada y sepa manejar ese "contenido" (link). Los motivos son bastante obvios pero los resumo en: la experiencia de usuario es mucho mejor en la aplicación nativa que en el navegador. Parte importante del tema es que el mismo link sea válido tanto para ver el contenido en el browser como para verlo en la aplicación, porque como prove

¡A la salud de mi KB!

Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud". En este sentido KBDoctor  es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB. También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices. A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server". En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".

Rocha:Constantes tipo fecha

En la Rocha se soportan constantes del tipo fecha o fecha-hora con formato ANSI/ISO (AAAA-MM-DD HH:MM:SS).  Tecnicamente (Sintáxis): <date>::=    [0-9]{1,4}"/"[0-9]{1,2}"/"[0-9]{1,2} | [0-9]{1,4}"."[0-9]{1,2}"."[0-9]{1,2} | [0-9]{1,4}"-"[0-9]{1,2}"-"[0-9]{1,2} <hms>::=    [0-9]{1,2}[ap] | [0-9]{1,2}":"[0-9]{1,2}[ap]? | [0-9]{1,2}":"[0-9]{1,2}":"[0-9]{1,2}[ap]? <constant> ::=   "#"<date>"#" | "#"<date> <hms>"#" | "#"<hms>"#" Funcionalmente Se pueden utilizar esas constantes en las reglas, eventos, propiedades, etc (todo lugar donde se utilice el parser): Algunos ejemplos básicos: &FechaInicial=#2007-01-01# &FechaHoraInicial=#07-1-1 11:15a# &HoraInicial=#11a# Me parece bueno no tener que escribir funciones (CTOD, TTOC) sobre constantes tipo char para lograr una fecha y mucho mejor aun en