Agile

Conferencia Agile Spain

Este año voy a asistir a la CAS 2017 en Sevilla como voluntaria.

Me apatece un montón porque aunque he ido a muchos eventos nunca he participado con ese rol, y ahora que dispongo de tiempo me parece una forma genial de aprender y conocer a gente.

CAS 2017

Para los que no lo sepan la Conferencia Agile Spain (@confagilespain) es un evento que se celebra cada año en una ciudad diferente, generado por personas que viven el desarrollo de software de una manera diferente.

Profesionales del sector comparten conocimientos y experiencias en torno a las metodologías ágiles y como personalmente creo en ellas para desarrollar productos y servicios, es una oportunidad única de compartir conocimientos con empresas y personas de España que piensan igual.

¡Nos vemos allí el 7!

Y el sábado a primera hora a coger el AVE directa a Zaragoza a la Women TechMakers! Moriré de cansancio???? Nooo, I can!!!

Funciones del Scrum Master

Seguimos con los post sobre Scrum (ver anterior post sobre los Roles de Scrum) en este caso explicando las funciones del Scrum Master, dentro de su dualidad sirviente-líder que ocupa para el Scrum Team y para la organización.

Scrum Master

Imagen obtenida www.scrumalliance.org

Cuando una organización cambia su modo de trabajo a Scrum todos deben aprender como integrarlo, que nuevas funciones tienen y cual va a ser la forma de desarrollar los productos.

El Scrum Master es la persona encargada de servir de apoyo a todos los integrantes en ese nuevo cambio.

Y es que por muchas ganas que tenga todos los integrantes de cambiar la forma de trabajar (no hablemos si alguien es reticente) la misión no es sencilla, por lo que el Scrum Master igual el que Product Owner deben ser personas empáticas, colaboradoras, pacientes, y con el coraje de defender los roles y funciones de Scrum.

Funciones del Scrum Master para el Product Owner

La persona que adquiere el rol de Scrum Master sirve al Product Owner de varias maneras, que incluyen:

  • Encontrar técnicas para una gestión eficaz del Product Backlog.
  • Ayudar al Scrum Team a entender la necesidad de elementos claros, concisos y bien definidos en el Product Backlog.
  • Comprender la planificación del desarrollo de productos en un entorno empírico.
  • Asegurar que el Product Owner sepa cómo organizar el Product Backlog para maximizar el valor.
  • Comprender y practicar la agilidad.
  • Facilitar eventos de Scrum según se solicite o necesite.

Funciones del Scrum Master para el Development Team

El Scrum Master sirve al Equipo de Desarrollo de varias maneras,  siendo para mi la más importante la de ayudarle a eliminar impedimentos. Y es que muchas veces el trabajo no sale porque las personas no saben como proseguir o si pueden hacer algo o no.

Seguir leyendo «Funciones del Scrum Master»

Roles en Scrum

A continuación voy a hablar de los roles que existen dentro del Scrum Team y que funciones y deberes tiene cada uno.

Scrum no tiene un rol llamado «Project Manager».

Scrum Team

Scrum Team

El Scrum Team se compone de 3 perfiles:

  1. Product Owner (1 persona)
  2. Development Team (Varias personas)
  3. Scrum Master (1 persona)

El Scrum Team debe ser auto-organizado y multifuncional. Lo primero para saber elegir cual es la mejor manera de hacer el trabajo, mejor que siendo dirigidos por otros externos. Multifuncionales porque el equipo debe tener las comptencias necesarias para realizar el trabajo sin depender de otras personas que no formen parte del equipo.

El equipo perfecto en Scrum está diseñado para optimizar flexibilidad, creatividad y productividad.

Es decir, debe ser capaz de poder entregar y publicar (si ha sido pasada a Done) esa nueva release lanzada.

No puede depender de otros equipos para subir a producción algo definido como «Done».

El equipo entrega productos cíclica e incrementalmenre, maximizando las oportunidades para obtener feedback. Entregas incrementales de productos con la etiqueta «Done» (Hecho) aseguran potenciales versiones usables del producto están siempre en activo.

Product Owner

El Product Owner , PO es el responsable de maximizar el valor del producto y el trabajo del Development Team (Equipo de desarrollo). Como se realiza esto, puede variar dependiendo de la empresa, los Scrum Teams y los inddividuos.

El Product Owner es la única persona responsable para gestionar el Product Backlog.

Entre las tareas que se realizan en esa gestión se encuentran:

  • Nombrar claramente los ítems del Product Backlog.
  • Ordenar los items en el Product Backlog priorizándolos para lograr los mejores objetivos y resultados.
  • Optimizar el valor del trabajo que realiza el Development Team.
  • Asegurarse de que el  Product Backlog sea visible, transparente y claro para todos, y que muestra en que va a trabajar el Scrum Team.
  • Asegurarse de que el Development Team comprende perfectamente los elementos del Product Backlog.

El PO puede hacer el trabajo anterior o hacer que lo haga el equipo de desarrollo, pero en ambos casos será el Product Owner responsable.

Seguir leyendo «Roles en Scrum»

Aprendiendo Scrum

Scrum es un framework (marco de trabajo) dentro del cual las personas pueden abordar problemas complejos, a la vez que ofrecen productos de manera eficiente y creativa del más alto valor posible.

Scrum

Web de scrum.org

Scrum proviene del trabajo de Ikujiro Nonaka e Hirotaka Takeuchi cuando publicaron «The New New Product Development Game» en Harvard Business Review (HBR) en 1986.

Su forma final proviene de “Scrum Development Process” presentado por Ken Schwaber en OOPSLA 95. Tanto Ken Schwaber como Jeff Sutherland son considerados sus creadores oficiales.

Aunque para Takeuchi y Nonaka, Scrum está relacionado indirectamente con el software. Tiene que tiene más que ver con el liderazgo y el funcionamiento de las principales compañías del mundo, tal y como aparece su artículo en HBR llamado «The Big Idea: The Wise Leader».

En sí mismo, no es un proceso o una técnica, sino que como marco de trabajo, para desarrollar complejos productos de software, pudiendose emplear varias procesos y técnicas. Presenta varios componentes, roles, eventos, artefactos y reglas, que tienen un propósito muy claro y son esenciales para el éxito de Scrum.

Sirve especialmente para ver de forma clara la eficacia relativa de las prácticas de desarrollo y gestión de producto para que se pueda mejorar.

Si de verdad se quiere lograr un cambio en la forma de trabajar, éste debe contar con el apoyo de «los de arriba».

Los stakeholders deben respaldar al Product Owner con conocimientos e información de los productos o servicios a desarrollar y apoyar al Scrum Master para provocar un cambio organizacional que fomente el empirismo, la autoorganización, la inteligencia y el poder decidir de forma inteligente cuando el producto está listo para ser lanzado.

Los 3 pilares de Scrum

Dentro de los principios Agile, vivimos en un mundo de constante cambio e incertidumbre por lo que es imposible predecir a futuro cual va a ser la siguiente innovación.

Scrum se basa en la teoría empírica de control de procesos. El empirismo afirma que el conocimiento proviene de la experiencia y toma decisiones basadas en lo que se conoce.

Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad del mundo en el que vivimos y controlar el riesgo.

Tres pilares sostienen la implementación del control del proceso empírico:

Seguir leyendo «Aprendiendo Scrum»

Mejorando la experiencia de usuario gracias a Soporte (II)

Seguimos con el resumen de la genial charla de Inés Luna (@cuquiesp) en la Tarugoconf 2016 sobre lo aprendido al montar un equipo de soporte desde cero en una startup. (Leer antes la primera parte)

2º Fase: Escala o muere

Vas creciendo y tienes un volumen de clientes más grandes, es un caos contestarles por email, has tenido problemas con los equipos porque no sabes que hacer cuando alguien reporta un bug, los bugs no se arreglan…

Luna comenta que cuando el equipo crece busca personas que no necesariamnete tengan experiencia en soporte, sino que sean grandes comunicadores y que tengan una gran capacidad empática con los clientes, pero que tengan «huevos grandes» para tomar decisiones porque muchas veces hay que decirles que no a los clientes, pelerse con ventas que han mentido a los clientes, con producto…

Inés nos cuenta que la clave es formar un equipo fuerte y solidario. No solamente personas alineadas con la cultura de la organización sino q esten alineadas con el resto del equipo para crear un equipo muy unido ya que atención al cliente puede ser muy ingrato. ¿Cómo?:

  • Hacerles participe en el proceso de nuevas incorporaciones
  • Que el equipo cree documentos de onboarding para ayudar a los nuevos miembros
  • Poner un mentor a la persona nueva para ayudarle y que aprendan entre ellos

Segmentar a los usuarios

Cuando creces y tienes muchos clientes, seguramente ya has cabredo a más de uno (y parece que se acabe el mundo! Pero no). Si, como en su caso, eres un producto freemium, tienes que empezar a tomar decisiones,y segmentar a tus usuarios, ya que no es el mismo soporte el que le das a una persona que no paga, a una que paga poquito o a una que paga mucho.

Tienes que empezar a segmentar a los usuarios y empezar a entender:

  • Cómo de rápido puedes contestar a la gente
  • Qué tipo de incidencias equieren atención urgente
  • Cual es el canal más adecuado para cada segmento, no es lo mismo una gran corporación que tiene el pooducto instalado a medida, que una persona que lo usa gratis una vez al mes…

Zendesk

Es el momento de empezar a pensar a usar una herramienta de Customer Service profesional como ZenDesk y empezar a trabajar en los procesos, como las automatizaciones, el workflow de los tickets… ya que vas a ser mucho más eficiente en lo que haces.

Gestión de indidencias

Tambien en esta etapa debes empezar a coordinarte mucho más con el resto de los equipos, como en el caso de las incidencias técnicas o bugs, trabajando con QA, desarrollo, producto… para definir que algo es una incidencia versus que el cliente no entiende cómo usar el producto, como reproducir esa incidencia, acordar entre todos cual es el criterio para poner una prioridad, quien es el responsable de asignar esa prioridad, si esa prioridad puede variar en función del número de tickets que dispongas…

Sino hay un acuerdo entre todos, el proceso puede ser muy doloroso.

Medición y analítica

Implementas procesos con ventas, con facturción…. y ya usas una herramienta específica para atención al cliente y tienes q empezar a medir lo que estás haciendo. Y con herramientas como Zendesk puedes hacer reporting de cualquier cosa. Inés nos recomienda que nos centremos en cosas básicas en su caso por ejemplo, en el tiempo que tardaban en atender a un cliente.

Se dieron cuenta de que atendían antes a los usuarios que no pagaban, ya que preguntaban cosas más sencillas, haciendo esperar más tiempo a los que pagaban por la herramienta.

Darse cuenta de eso hizo que tuvieran que reorganizar el workflow para poner la prioridad en los clientes que más aportan.

El tiempo de resolución de un ticket es otra historia, porque si tienes incidencias que tienes que escalar a otro equipo ya no depende de tu trabajo, y ver cual es el proceso para escalar, cuanto tardan en resolverlas, cada cuanto haces una release, cada cuanto se arreglan los bugs, la proporción de tiempo entre trabajar en roadmap y hacer la plataforma más estable y arreglar bugs… Esas métricas ya no depende sólo de ti.

Satisfacción de tus usuarios

Para conocer si los usuarios estaban contentos, Inés comenta que ella implementó 2 tipos de métricas, una más transaccional que es en base a las interacciones con el equipo de soporte y la otra para conocer la satisfacción general, el NPS.

En la primera mandaba un email después de resolverles la incidencia con una encuesta, donde les preguntaba si están satisfechos o no. Descubrieron que vivían estresados con los tickets pero los usuarios estaban en un 95% sastisfechos con el servicio que tenían en soporte.

Lo segundo que implementaron fue el NPS (Net Promote Score) que no es una métrica de soporte sino que es mucha más amplia, usada en marketing, producto… que consiste en hacerles la pregunta de ¿Cómo de problable es que recomiendes este producto a un compañero de trabajo o un amigo?

Descubrieron que si bien en soporte estaban contentos, había un descontento generalizado de los clientes que no tenía que ver con soporte sino que tenía que ver con funcionalidades que habían quitado en el producto, sobre el proceso de ventas y facturación que era muy engorroso y muy lento para muchos clientes pagar, con el reposicionamiento del producto, de gestiñon de proyectos en comunicación en tiempo real que la gente no entendía porque habíaan hecho ese cambio.

Son métricas muy diferentes que te dan 2 visiones para ver como de contentos están tus usuarios.

Etapa: Todo explota

En 2014 hacen un rebranding y lanzan una visión nueva del producto. Era simplemente un lavado de cara visual, pero a los usuarios no les gustan los cambios. Y eso hace que el equipo de soporte reciba miles de llamadas contestando siempre lo mismo.

¿Qué haces cuando tus clientes no están contentos de ese cambio?

Seguir leyendo «Mejorando la experiencia de usuario gracias a Soporte (II)»

Principios Lean UX para guiar el proceso

Una vez que hemos hablado qué cultura y organización debe existir en la empresa y los equipos, vamos a ver cómo deben trabajar.

Trabaja en bloques pequeños para reducir el riesgo

Otro principio fundamental heredado de Lean Manufacturing es la práctica de dividir el trabajo en pequeñas unidades, en su caso con el objetivo de reducir el inventario y obtener la máxima calidad.

Trasladado a Lean UX significa que sólo la cantidad de trabajo necesario se realizará para poder avanzar hacia delante, validando la hipótesis y continuando el desarrollo en base a lo aprendido. Con ello contribuimos a otro de los principios, el de reducir el desperdicio.

Descubrimiento continuo

Para realizar este proceso debemos involucrar al usuario o cliente en el proceso durante la fase de diseño y desarrollo de las ideas.

Muchas veces (en el caso de que se haga) este contacto, en vez de hacerse de forma regular se realiza al final, con el trabajo ya desarrollado. Por ello se deben definir encuentros seguidos mediante métodos cuantitativos o cualitativos que permitan obtener el feedback para la validación.

Descubrimiento continuo

El objetivo es claro: entender que hacen los usuarios con tus productos y por qué lo están haciendo.

Por ello la investigación debe hacerse de forma regular y con todo el equipo implicado.

Este segundo punto (con todo el equipo implicado) es muy importante ya que normalmente sólo los UX Research hacen esta parte teniendo posteriormente que explicar los resultados al resto del equipo.

Al introducir a todo el equipo en la investigación consigues 3 cosas:

  1. Que desarrollen una mayor empatía por el usuario y sus problemas
  2. Entendimiento compartido de lo que ocurre y por que luego se van a tomar ciertas decisiones.
  3. Reducción de la necesidad de generar documentación que explique los descubrimientos de la investigación

GOOB (Getting out of the building)

Con esta expresión que significa literalmente “salir fuera del edificio”, Steve Blank, profesor de Stanford, quiere conseguir que los equipos salgan fuera de las salas de reuniones con sus interminables divagaciones y suposiciones, y que den a los potenciales usuarios la oportunidad de proveer feedback real tan pronto como sea posible.

Gracias a esta dosis de realidad verás que ideas no funcionan antes de malgastar más recursos en ellas.

Exponer el trabajo

Con este principio, se quiere que las ideas salgan de la cabeza o de las pantallas de las personas y se pongan a la vista de todo el equipo. Esto permite ver el estado del trabajo, creando un flujo de información compartida, de nuevas ideas y sugerencias que surgen en base a lo visto…

Seguir leyendo «Principios Lean UX para guiar el proceso»

Principios Lean UX para guiar la cultura de la empresa

Seguimos con los principios Lean UX ya que al adoptar este proceso, la cultura de la empresa debe ser la correcta para que se produzca el entorno perfecto para la innovación y la creación conjunta.

De la duda a la seguridad

El desarrollo de un producto digital es a menudo complejo e impredecible ya como hemos comentado el mercado está en constante cambio. Por ello Lean UX se basa en la idea de que todo es una hipótesis hasta que se valide.

Esta validación puede ser muy rápida o hacerse demasiado tarde. Por ello hay que eliminar el riesgo de malgasto de recursos en algo basado en una mala suposición, todo hay que validarlo. Continuamente el equipo se mueve de una posición de incertidumbre a una de conocimiento.

Resultados, no productos

Características y servicios son productos. Los objetivos que ellos quieren satisfacer son los resultados.

En Lean UX los equipos quieren crear un cambio medible y significante en el comportamiento del usuario. Es el equipo el que debe decidir como provocar ese cambio, qué aplicaciones, servicios… debe crear para ello.

Shared Understanding

Normalmente, hoy en día, sucede lo contrario. El equipo recibe un documento que le explica lo que tiene que realizar: x páginas, un filtro, un buscador… en vez de recibir el objetivo que se cree que es el deseado por el usuario.

Al partir de que todo es una hipótesis hasta que no se valide, es más fácil cambiar una característica por otra si probamos que no cumple el camino hacia el objetivo a conseguir.

Eliminar el desperdicio

Uno de los principios básicos de Lean Manufacturing es eliminar todo aquello que no lleva hacia el objetivo final. En Lean UX el objetivo final es el impacto en el comportamiento que se espera obtener, por lo que cualquier cosa que no contribuya a ello es desperdicio y debe ser eliminado.

Esto se hace porque dos motivos. Por un lado, los recursos suelen ser limitados. Cuanto más pueda ser eliminado, más rápido se moverá el proyecto hacia el resultado final.

Y el segundo motivo es que a nadie le gusta ver que si trabajo no se usa (a no ser que sea porque se ha validado y se ha visto que no es el camino correcto en cuyo caso si que ha tenido un uso).

Los equipos quieren trabajar en los retos correctos.

Queremos sentirnos efectivos. Ver que aportamos algo. Por ello si la empresa no valida cada poco tiempo, y el trabajo de varios meses o año acaba siendo no válido porque no cumple el objetivo, y debe ser realizado de nuevo, la moral del equipo desciende.

Entendimiento compartido

Esto sucede cuando todo el equipo conoce la misma información porque están trabajando de forma conjunta. Cuanto más entienda un equipo por qué están realizando algo, menos necesidad existe de debatir por qué se toma esa decisión y cómo resolver nuevos retos.

Seguir leyendo «Principios Lean UX para guiar la cultura de la empresa»

Principios Lean UX para guíar la organización de equipos

Los principios en los que se basa Lean UX se agrupan en 3 bloques. Cada uno sirve para guiar:

  1. La organización de equipos
  2. El proceso
  3. La cultura

Gracias ellos iremos viendo las ventajas que conlleva implementar Lean UX en tu organización y como esta se modificará conviertiendose en un lugar abierto, transparente, que aprovecha el conocimiento y la entrega de todos para conseguir los mejores resultados.

En ellos se basarán las herramientas y técnicas para lograr mejorar la colaboración, lograr entregar mejores productos y servicios de forma más rápida y con el menor gasto de recursos usando los conocimientos de todos los implicados y basando las decisiones en pruebas reales.

Y es que como dice Jeff Gothelf en su libro Lean Startup: «Get out of the deliverables business», en castellano: olvidémonos de centrar el negocio en las entregas y centrémonos en los que de verdad importa, hacer disfrutar a nuestros clientes con una experiencia memorable.

Principios Lean UX para guíar la organización de equipos

Equipos multifuncionales

Con esta palebreja lo que se refiere es que los equipos deben estar formados por aquellas personas con conocimientos necesarios en ese momento del proceso: desarrolladores, product management, testers, diseñadores visuales y de interacción, gestores de contenidos, marketing…

Para crear un gran producto es necesaria la suma de todos los conocimientos y la colaboración entre todas las disciplinas.

El todo es mayor que la suma de sus partes

Cuando un equipo está formado por personas de diferentes perfiles, se obtienen mejores soluciones ya que cada problema es visto desde un punto de vista diferente, aportando una gran diversidad.

Los miembros del equipo además están en contínuo contacto, por lo que poseen todo el conocimiento de lo que está sucediendo y lo que va a haserse al contrario que en organizaciones donde todo esta compartimentado. Gracias ello conseguimos una gran colaboración desde el inicio del proyecto logrando una mayor eficiencia de equipo, y trabajadores mucho más implicados en el proyecto.

Equipos pequeños, dedicados y juntos

Lo ideal: no más de 10 personas, focalizadas en el mismo problema y a ser posible en la misma ubicación. ¿Por qué?

Los equipos muy grandes tienen problemas para organizarse y compartir la misma información.

Los equipos pequeños generan un mayor sentimiento de camadería lo que genera mayor implicación en el proyecto y en las personas que lo están creando juntas.

Building a team

Imagen obtenida de aquí

Trabajando además en el mismo y único proyecto se consigue que estén centrados al máximo en las mismas prioridades y elimina las odiosas dependencias sobre otros equipos.

Autosuficientes y con poder para decidir

Si queremos obtener de forma rápida algo con lo que poder testear una suposición necesitamos que el equipo tenga todas las capacidades necesarias para trabajar sin dependencias externas.

Seguir leyendo «Principios Lean UX para guíar la organización de equipos»

Cambiando la metodología de trabajo (o al menos intentarlo)

He trabajado en varias empresas que querían modificar su proceso de desarrollo de producto. Algunas (2013) querían implantar una nueva metodología (Agile en este caso) y otras ya la tenían, pero necesitaban un pequeño reajuste para adecuarla a su cultura de empresa.

Y es que desde mi punto de vista, cualquier metodología o proceso de trabajo tiene sus herramientas e indicaciones, pero no siempre sirven al 100%, sino que debe adaptarse a lo que la empresa necesita en ese momento.

Son una base sobre la que trabajar para encontrar el proceso que realmente funcione para cada grupo de trabajo.

En ambos casos las empresas contrataron los servicios de una persona que facilitase y guiase el cambio. En una el proceso duraba X meses, para luego la empresa continuar por su cuenta con lo aprendido, mientras que en la otra la fase de implantación duraba X meses, pero prosiguiendo después el trabajo con el facilitador.

Es decir, (o por lo menos lo que yo creo que es lo ideal) esa metodología por la que se estaba apostando no era algo cerrado, inmutable para siempre, sino que seguiría evolucionado en el tiempo.

En ambas empresas, como muchos imaginaréis, el proceso no fue sencillo.

Para mi existen 2 puntos claves en el proceso:

  1. ¿El cambio viene impuesto desde arriba o es algo en lo que todo el equipo cree y apuesta?
  2. Como en cualquier materia, la constancia y repetición son claves para hacer algo bien.

Si el cambio viene impuesto desde la dirección, va a ser muy difícil que suceda si los principales implicados no lo aprueban. El facilitador se va a encontrar con un muro muy difícil de romper, no digo que imposible, pero muy complicado.

Lo ideal es partir de una base en la que la mayor parte cree que es necesario el cambio porque lo existente no funciona. O funciona pero podría ir mejor.  Pero aun siendo algo querido por todos, cambiar unas costumbres suele ser muy complicado.

No olvidemos que estamos trabajando con personas.

Personas que pueden llevar 5, 10, 15, 20 años trabajando de una misma forma. Personas que han luchado por sacar adelante un proyecto. Personas que no se han sentido escuchadas. Personas que van agobiadas porque tienen unos plazos de entrega. Personas con un baggage emocional hacia la empresa y otros compañeros.

Seguir leyendo «Cambiando la metodología de trabajo (o al menos intentarlo)»

Getting Things Done® (GTD®)

Getting Things Done® (GTD®) es una metodología para ser más productivo sin estrés. Escrita por David Allen y publicada en un libro en 2001, en un principio estaba dirigida a  altos directivos, pero su uso puede ser aplicado a cada aspecto de tu vida.

Your mind is for having ideas, not holding them®

(David Allen)

Se basa en la idea de que nuestra mente es para generar ideas, no para mantenerlas, con lo que sino almacenamos de forma correcta las ideas, pensamientos… que vamos teniendo, el espacio que ocupan no permitiendo entrar a otras o el miedo a olvidarnos de ellas, nos genera un entimiento de estrés constante.

Más que un conjunto de consejos para la gestión del tiempo y la organización, GTD® es un sistema de gestión total. Allen crea un modelo coherente para almacenar elementos clave, los cuales aun pueden ser necesarios para nosotros, tanto para su uso futuro como presente.

El GTD es para no hacer, o más bien hacer sólo lo que vale la pena hacer.

Se trata de reducir la presión entrante de tareas por hacer aparcándolas en un sistema de almacenamiento auxiliar para centrarse en hacer sólo algunas.

En este mundo de información, constantemente nos están llegando nuevos datos, proyectos, ideas… que procesar que se suman a los que ya teníamos. El propósito de su proceso de gestión de flujo de trabajo es facilitarnos el hacer buenas elecciones sobre lo que estamos haciendo en ese momento.

GTD Diagram

 

Regla de los 2 minutos

A mi modo de ver, lo que cuenta Allen es de sentido común, y seguramente muchas de las cosas ya las haceis en vuestro día a día. Un ejemplo muy sencillo es la regla de los 2 minutos descrita en el diagrama superior.

La idea es muy sencilla. Cuando algo te llega, lo primero que te preguntas es si puedes hcer algo con eso. Si la respuesta es si, piensas en cual es la siguiente acción que quieres hacer con eso. Y si esa acción te cuesta menos de 2 minutos, la haces en ese momento, sino la delegas o la pospones apuntándola en un calendario si es para hacer en una fecha específica o en tu sistema de siguientes acciones.

GTD® en 5 pasos

La metodología se basa en 5 pasos que son los que naturalmente suceden en nuestra mente con las acciones más simples, solo que muchas veces lo hacemos de forma automática (Natural Planning Model) y no le ponemos nombres.

Seguir leyendo «Getting Things Done® (GTD®)»

Scroll hacia arriba