¿Podemos tener éxito centrándonos en el error y en las posibilidades de que parte de nuestro trabajo falle?

El tema es muy interesante. Hay profesionales que tienen a sus espaldas un largo historial de éxitos, sobre todo en grandes empresas tradicionales. Hasta ahora, el método les ha funcionado, y por eso siempre planifican pensando que van a volver a tener éxito en todo lo que hacen.

Pero las cosas han cambiado mucho. ¿Qué ocurre si ponemos a esta gente a trabajar en un entorno de cambio e incertidumbre, como el de cualquier startup? Es posible que sus recetas para el éxito no sirvan para nada.

Para demostrar esta tesis, Andrew Chen nos propone los ejemplos de 3 compañías líderes que han tenido éxito haciendo justo lo contrario: planificando y construyendo sobre el error/fracaso. Se trata nada menos que de Google, Ideo y 37 Signals. Vamos a verlo.

1. Google

- Google obtiene sus beneficios porque tiene un gran producto que siempre está disponible, en cualquier lugar y momento.

- Para prestar estos servicios, Google cuenta con 100.000 servidores.

- Hay realmente muchas posibilidades de que cualquiera de esos servidores falle en algún momento.

- Para crear un sistema “tolerante a los fallos”, la empresa cuenta con muchos servidores de sobra, y una respuesta muy sofisticada para cuando una de las máquinas se cae.

ENFOQUE: Puedes comparar este sistema, construido entorno al fallo, con el enfoque de otras compañías, que concentran su esfuerzo y sus inversiones en contar con un hardware especializado que nunca falle.

2. IDEO

- Las empresas contratan a IDEO para conseguir un diseño atractivo y basado en las necesidades del usuario final.

- Una parte del proyecto consiste en el proceso de brainstorming: generar nuevas ideas.

- Pero en IDEO saben que casi todas las ideas que surgen en un brainstorming son inservibles. Ni siquiera un 1% de las ideas suele tener éxito.

- Por eso combinan el brainstorming con un prototipado rápido y trabajo de campo (test y encuestas a usuarios). De esta forma se aseguran un buen producto final.

ENFOQUE: Puedes comparar esta metodología con el típico enfoque del diseñador que cree que no puede fallar porque “lo sabe todo”, y que de manera casi espontánea -basándose en su genial creatividad- es capaz de dar con la solución.

3. 37 signals

- Rails es un entorno de desarrollo en el que los desarrolladores pueden construir sitios web muy rápidamente.

- Cada proyecto web requiere un montón de líneas de código que es fácil que fallen

- Si asumes que los programadores suelen construir un código que tiene errores y falla, entonces querrás que el trabajo que realizas sea muy fácil de probar y de modificar. Éste es el corazón del desarrollo ágil: desarrollo rápido que no espera a tenerlo todo perfecto, sino que va creciendo con cada interacción, mejorando a medida que se detectan y corrigen los errores.

ENFOQUE: Puedes comparar este método con el enfoque tradicional (en cascada) que asume que los ingenieros son capaces de lograr una arquitectura y un diseño perfectos, y que para ello sólo necesitan seguir todos los procesos y protocolos establecidos (y un buen montón de tiempo, claro).

Características de los sistemas “tolerantes al fallo”

De estos ejemplos podemos extraer unas características generales que definen a los sistemas “tolerantes al fallo”

Aceptación del error. Tienes que aceptar que nosotros fallamos y las cosas que construimos también. El error es un lugar común, y hay que aceptarlo.

Recursos para cubrirnos las espaldas. Si las cosas fallan, es mejor que tengamos recursos de sobra para compensar los errores. Como hemos visto, en Google tienen servidores de sobra para cuando alguno falla. Todas las empresas deberían probar muchas ideas para desechar aquellas que no sirven, y para encontrar una idea genial.

Barato, fácil y rápido. Para que podamos tener muchos recursos, éstos deben ser baratos, rápidos y fáciles de generar. Si cada servidor de Google fuese muy caro, Google simplemente no existiría.

Proceso iterativo, productos probados en condiciones reales. Es fundamental que pongas a prueba tu trabajo a menudo, y que vayas mejorándolo a medida que detectas los errores y los vas corrigiendo. Recuerda: sólo valen las pruebas en condiciones y entornos reales, nunca en un laboratorio.

Puedes leer el artículo Built to Fail: How companies like Google, IDEO, and 37signals build failure-tolerant systems for anything!, publicado por Andrew Chen en su blog

Algo más sobre la filosofía ágil: 10 consejos que te ayudarán a gestionar mejor tus proyectos.

Algo más sobre el error: Aprender de los fracasos, un método sobrevalorado y Es más divertido cuando fallan los demás.

¿Haces que tu trabajo sea simple o te complicas la vida?

Presupuestos rápidos

¿Cuánto sueles tardar en darle un presupuesto a un cliente interesado? La rapidez con la que respondes puede ser la clave para cerrar el trato. Es un poco como en una venta tradicional: hay que aprovechar el momento, porque si el interés del comprador se enfría, es muy posible que ya no vuelva a nosotros.

Como freelance tienes la ventaja de que no cuentas con una estructura pesada y burocrática: no dependes del trabajo de otros compañeros, no necesitas un informe de otro departamento, ni tienes que esperar a la autorización de tu jefe. Tú marcas los tiempos, todo depende de ti. Y eso hace que todo esté en tus manos. Si eres ágil -capaz de reaccionar con rapidez ante los cambios y demandas- el proyecto puede ser tuyo enseguida.

Para explicar lo simple -y eficaz- que puede ser un negocio cuando realmente lo hacemos simple y no nos complicamos la vida, la gente de 37 signals nos propone el ejemplo de una empresa de jardinería:

Llevaba semanas pensando en desarrollar un “proyecto” en mi patio trasero. Pero así, sólo pensando y mirando, no se consigue nada… Hasta que se me ocurrió preguntar cuánto costaría que otras personas lo hiciesen por mí.

Les llamé. El tipo llegó en 10 minutos. Estaba por allí, con otro trabajo, pero se acercó enseguida. Le dije lo que quería. Él echó un vistazo alrededor, durante unos 20 segundos, y me dijo: “300 dólares”. Yo le respondí: “Trato hecho”.

Eso fue todo. Nada de propuestas. Nada de “Contactaré contigo en breve”. Nada de “Déjame comprobar cuánto cuestan los materiales y te mando una estimación por email la semana que viene”.

Simplemente:

-300 dólares.
-Trato hecho.
-¿Cuándo puedes empezar?
-El miércoles.
-¿Cuánto tardarás?
-Unas cuantas horas, un par de personas.

El profesional conocía bien su negocio. Yo [como cliente] conozco el valor de mi tiempo. Y ahí cerramos la transacción. Fue algo “refrescante”, por lo novedoso.

Ya sé que no todo se puede hacer así, de forma tan sencilla, pero muchas veces tengo la sensación de que hemos desarrollado muchas formalidades y trámites que en realidad no necesitamos: contratos complicados, papeleo, retrasos, intentos de estimar todo al detalle… Demasiado: “Déjame que lo piense y contacto contigo”. ¿Realmente es esencial? A veces sí, pero la mayor parte del tiempo, probablemente no.

Propuestas más simples

Quizá podemos llevar la simplicidad también a nuestras propuestas a los clientes. En 37 Signals recuerdan cuando preparaban ofertas de 20 páginas. Se pasaban toda la noche trabajando para presentar todo ese material a un posible cliente. Ahora consideran que esas propuestas gigantes son una auténtica pérdida de tiempo:

“Al final, empezamos a hacer propuestas de sólo una página, y no pareció importar absolutamente nada. En 6 años, nunca pude encontrar una relación entre la longitud y el detalle de la propuesta y el hecho de conseguir el proyecto”.

Menos es más

Conclusión: Muchas veces, menos es más. En ocasiones, las circunstancias nos impiden hacer las cosas de forma sencilla. Pero a veces ni siquiera lo intentamos. Deberíamos preguntarnos por qué.

En el primer caso, el problema puede ser el método. En el segundo, nuestra forma de abordar los problemas.

Puedes leer la historia completa en A reminder of how simple business can be when you don’t make it complicated, publicada en Signal Vs Noise, el blog de 37 Signals, pioneros en desarrollo y negocio ágil.

Afortunadamente, existen otros caminos. En el el blog de 37 signals nos proponen un método sencillo y efectivo para diseñar el interfaz de usuario de un sitio web. A ellos les ha ido siempre muy bien. Aquí va resumido:

1. Haz una lista con todas las cosas que esa pantalla debe hacer. Estas preguntas pueden ayudarte a descubrirlo: ¿Qué es lo que el usuario debe ser capaz de conseguir? ¿Cuánta información es necesario que se muestre? ¿Qué funcionalidades son necesarias para que los clientes completen un proceso? Una vez que hayas descubierto los requisitos, etiquétalos con números.

2. Define cuáles de estos elementos numerados tienen relación entre ellos, ya sea de manera espacial (uno va al lado del otro) o conceptual (tratan sobre el mismo tema). Asigna una letra a cada grupo de elementos relacionados.

3. Realiza un boceto (o varios) para cada una de las letras (que agrupan a los números).

4. Agrupa todos esos diseños en un diseño único, para hacer que todas las piezas formen una unidad.

El siguiente paso consistiría en elaborar un wireframe o maqueta.

Si todavía lo ves un poco abstracto, aquí tienes un pequeño ejemplo:

Haz una lista con los requisitos que necesitas:

1. Información de la compañía.
2. Información del usuario.
3. Enlace a búsqueda.
4. Fecha de creación.
5. El cambio de contraseña es una operación muy común.

Establece las relaciones entre cada requisito. Algunos estarán estrechamente ligados, y otros serán independientes. Se trata de ver qué impacto genera cada requisito en los demás:

A: 1, 2, 4
B: 3
C: 2, 5

Establece prioridades:

Lo más importante: A
Necesario: C
Estaría bien tenerlo: B

Dibuja cada “trozo o pieza” del interfaz: Desde el momento en que ya hemos agrupado los requisitos que están relacionados, podemos diseñar cada parte de manera individual sin preocuparnos por los posibles conflictos.

Une todas las piezas. Se trata de ponerlas todas juntas. Unos consejos:

- Piensa en las limitaciones que han surgido al efectuar los diseños individuales.

- Ten en mente la prioridad que has establecido.

- Busca un equilibrio.

- Y ponte a dibujar. Primero un boceto. Después obtendrás algo parecido a un wireframe.

Conviértelo en realidad: Puede que funcione bien en papel, pero que en pantalla genere algún problema. Así que llega el momento de hacer un diseño mucho más cercano al resultado final.

Más información sobre el método.

¿Cuántas horas hay que trabajar al día? ¿Y a la semana? Es una buena pregunta. Y sólo hay una respuesta posible: depende. Depende del proyecto concreto al que nos estemos enfrentando, y de la fase en la que se encuentra. Depende, también, del rendimiento y la capacidad de cada persona, y de su grado de compromiso. Y no podemos olvidar otro factor fundamental: las horas que trabajamos dependen de nuestra filosofía de trabajo y de vida.

¿Está el éxito directamente relacionado con el número de horas trabajadas? Otra muy buena pregunta. La gente de 37 Signals -pioneros del desarrollo ágil- tiene su propia teoría al respecto. A ellos no les ha ido nada mal. Vamos a conocerla:

Tiempo para la inspiración

En nuestra empresa cada persona decide sobre sus horarios, pero yo diría que, como media, cumplimos una jornada laboral típica: 8 horas al día y descanso los fines de semana (a no ser que realmente estemos absorbido por el proyecto y consideremos más efectivo no parar). Después del trabajo, nos tomamos el tiempo suficiente para descansar y para conseguir inspiración. Así que, normalmente, se trata de la típica semana laborable (40 horas).

Trabajar muchas horas no garantiza el éxito

Demasiada gente piensa que hay que trabajar entre 80 y 100 horas semanales. Piensan: “No importa cuánto trabajes, nunca será suficiente”. Y dedican incluso parte de la noche a sus proyectos. Puede que la gente de los bancos de inversión trabaje 18 horas al día… pero mira cómo está ahora mismo su negocio. Lo importante no es la cantidad de horas que trabajas, sino cómo aprovechas esas horas, y a qué las dedicas.

Cuando vas justo de tiempo, te concentras en lo esencial

No hace falta que dediques un número sobrehumano de horas al trabajo. Una semana laboral normal debe ser suficiente. Incluso un poco menos debería bastar. De hecho, trabajar con el tiempo justo es una cosa buena. Te obliga a concentrarte en lo esencial. Ya no puedes perder el tiempo en cosas sin importancia. Y es que la única manera de hacer algo grande es, precisamente, concentrarse en lo esencial.

Nuestro producto “estrella” Basecamp [una de las aplicaciones más conocida para la gestión de proyectos], fue creado mientras nos dedicábamos a otros proyectos. Con sólo 20 horas a la semana construimos un producto que realmente consiguió despegar. No teníamos tiempo para concentrarnos en otra cosa que no fuese lo esencial. La aplicación hacía unas pocas cosas, y las hacía realmente bien. No había distracciones. Y hacía lo que la gente necesitaba, nada más y nada menos. Sólo después de conseguir que el producto despegase decidimos dedicarle más tiempo.

Estás definiendo los hábitos del futuro

Además, hay que tener en cuenta que estás definiendo los hábitos que después seguirás. Si ahora trabajas una cantidad de horas descomunal, es muy posible que después no seas capaz de parar. Ya sabes: cuando el hámster comienza a dar vueltas en la rueda, le cuesta mucho bajarse. Así que preocúpate de la calidad de esas horas, no de la cantidad. Eso es lo que realmente importa.

Tú decides

Dicho lo cual, como tú eres el dueño -y el empleado- de tu negocio, a ti te corresponde definir las horas que vas a trabajar. Es lo justo, porque después, será a ti a quien te toque trabajarlas… Habrá épocas de mucha actividad y otras más relajadas, días mejores y peores. Pero es importante que intentes encontrar un equilibrio; que traces unos límites para no agotar toda tu energía y tu motivación antes de tiempo. Recuerda que esto no es un sprint, sino más bien una carrera de fondo.

Si estás compaginando un empleo como asalariado con otros trabajos por tu cuenta, encontrar ese equilibrio va a ser bastante más complicado, y es muy posible que te toque batir el récord de horas trabajadas… Para ese caso también tenemos algunos consejor prácticos que te ayudarán a salir vivo/a del trance.

Puedes leer el artículo How Many Hours Should I Work per Week, publicado en Signal Vs Noise, el blog de 37 Signals.

También te recomendamos que le eches un ojo a la filosofía ágil de Getting Real.

Esto es lo que piensa la gente de la gente de 37 Signals: 

“Seguro que lo has oído por activa y por pasiva: aprende de tus propios errores. Existen muchas frases hechas sobre el error. Casi todas finalizan con un giro inteligente que hace que suenen bien…

Pero no entiendo la fascinación cultural que existe con el fracaso como método para extraer grandes lecciones de aprendizaje. ¿Qué es lo que has conseguido aprender de tus fracasos? Aprendiste que aquello no funcionaba. Ya no volverás a cometer el mismo error dos veces, pero es perfectamente posible que la próxima vez cometas un error diferente. En otras palabras: puede que no sepas lo que no funciona, pero todavía no sabes qué es lo que funciona. Así que, sinceramente, no parece una gran lección para el futuro.

En vez de concentrarte en los errores, pon toda tu energía en estudiar tus éxitos. ¿Qué es lo que has hecho bien? ¿Qué es lo que realmente funciona? ¿Eres capaz de repetirlo o reproducirlo? En vez de hacer que lo malo sea un poco mejor, ¿por qué no hacer que lo bueno sea todavía un poco mejor? No gastes tanto tiempo mirando hacia abajo; mira hacia arriba.

Hay una diferencia fundamental entre “ahora sé lo que tengo que hacer” y “no hagas eso otra vez”. La primera opción es sin duda mucho mejor.

Es cierto: todo constituye una experiencia de aprendizaje. Se puede aprender de lo bueno y de lo malo. Pero no todos los aprendizajes son iguales. Si vas a dedicar tiempo a analizar el pasado, es mejor que te concentres en las ganancias y no en las pérdidas. Las lecciones aprendidas de lo que has hecho bien te conceden más probabilidades de continuar tus proyectos con el éxito”.

Y tú, ¿qué opinas? ¿Has conseguido aprender de los fracasos?

Los miembros de 37signals son los padres de la filosofía ágil de Getting Real.

Puedes ver el artículo original: Learning From Failure is Overrated.

RESUMEN: Lo importante no es REPRESENTAR la realidad mediante especificaciones, documentación, gráficos y tablas; lo verdaderamente esencial es CONSTRUIR ese proyecto que va a cambiar la realidad, y ponerlo en funcionamiento tan rápido como sea posible. La filosofía Getting Real tiene que ver con organizaciones ágiles y transparentes; pequeñas, rápidas y flexibles, abiertas al cambio y la innovación. El reto es ser ágil, y estos 10 consejos pueden ayudarte a conseguirlo.

Hace ya un par de años que el equipo de 37 Signals, pionero en el desarrollo software ágil, realizó un interesante análisis sobre el escenario actual:

• En la vida real -frente a lo que ocurre en las previsiones y planificaciones- los proyectos se hacen mucho mejor con equipos pequeños y flexibles, capaces de cambiar en cualquier momento.

• Para ser competitivo hay que centrarse en los verdaderamente esencial, el corazón del negocio del cliente, y rechazar los superfluo.

• Lo importante no es REPRESENTAR la realidad mediante especificaciones, documentación, gráficos y tablas; lo verdaderamente esencial es CONSTRUIR ese proyecto que va a cambiar la realidad, y ponerlo en funcionamiento tan rápido como sea posible.

Con ese espíritu nació la filosofía Getting Real, que tiene que ver con organizaciones ágiles y transparentes; pequeñas, rápidas y flexibles, abiertas al cambio y la innovación. El reto es ser ágil, y estos 10 consejos pueden ayudarte a conseguirlo.:

1. Prueba a hacer menos que la competencia

Hasta ahora, el planteamiento siempre ha sido: la competencia ha creado este producto, así que tenemos que superarlo con algo que haga lo mismo y mucho más. Como resultado de esta actitud, vivimos en un mundo cada vez más complejo. En el caso de las aplicaciones, demasiadas funcionalidades que nunca se usan y que aumentan el precio, el plazo de entrega y la dificultad de uso. Se ha convertido en una carrera sin sentido que, muchas veces, sólo sirve para justificar la venta de una nueva versión.

Así que prueba a hacer menos. A hacer lo esencial. Y que la competencia se quede con el resto de los problemas. ¿Conoces a alguien que sepa explotar al máximo toda la potencia de Excel? ¿Y de SAP?

2. Pon en marcha algo que funcione de verdad tan rápido como puedas

Los cambios se suceden a gran velocidad y la competencia es máxima. Por eso no podemos perder ni un minuto cuando desarrollamos un proyecto. Ya no tiene sentido realizar estimaciones a años vista. Para cuando lleguemos, nuestro producto, nuestro servicio o nuestra aplicación ya no tendrán ningún sentido. Habremos gastado tiempo y dinero en fabricar un cadáver. Necesitamos CONSTRUIR aquello que el cliente necesita muy rápidamente, descartando todo aquello que no es esencial para su negocio. Para conseguirlo, debemos estar dispuestos a incorporar los cambios en cualquier momento del proceso. En eso consiste ser “ágil”.

Poner algo en marcha es la mejor manera de tomar impulso. Es correcto construir menos cosas, saltarse la documentación y los detalles, y tomar atajos en el proceso siempre que esto nos permita poner el proyecto en funcionamiento más rápidamente. Llegar tarde es igual que no llegar, y habrá supuesto un derroche de tiempo y esfuerzo.

3. Trabaja con las “historias de usuario”

¿Qué es lo que realmente necesita tu cliente? Si no tienes claro cuál es su objetivo, es imposible que el proyecto llegue a buen puerto. Hay una dificultad añadida: puede que ni siquiera él sepa lo que está buscando. Muchas veces está tan inmerso en su propio negocio que le cuesta analizar las cosas desde otro punto de vista. En esas situaciones, conviene pensar siempre en las necesidades del usuario final del producto o servicio que vas a crear.

Una historia de usuario es una forma de recoger los requisitos de un proyecto en tan sólo un par de frases. Esas frases se anotan en una pequeña cartulina o tarjeta para garantizar que los requisitos no crecen hasta hacerse inabarcables, y se formulan en un lenguaje corriente, para que tanto el equipo como el cliente pueda entenderlas a la perfección.  Se trata de pasar de una petición genérica y algo abstracta -así son muchas veces las peticiones de los clientes- a un caso concreto que nos permita ponernos en la piel del usuario. Esto nos permitirá determinar:

• La importancia real ese requisito para el usuario: puede que no sea tan importante, y que no merezca la pena dedicarle esfuerzo; puede que el requisito imprescindible sea otro.
• La dificultad y los problemas que plantea.

Estos requisitos se transformarán después en las tareas que irás completando a lo largo del proyecto. Si ayudas al cliente a descubrirlas, te estarás ayudando a ti mismo.

Un caso práctico

Las historias de usuario se llaman así precisamente porque recogen el punto de vista del usuario. En su blog, Kelly Waters nos propone el siguiente sistema: Una historia de usuario debe centrarse en el QUIÉN, el QUÉ, y el POR QUÉ, no en el CÓMO. Por ejemplo, antes de construir un sitio web de empleo, dos de las historias de usuario serían:

1. Como persona en busca de trabajo, quiero buscar un empleo para progresar profesionalmente.
2. Como seleccionador de personal, quiero publicar una oferta de trabajo para encontrar a un nuevo miembro del equipo.

La estructura sería:
Como [rol de usuario], quiero [objetivo], de forma que pueda [motivación]

4. Mantén el plazo y el presupuesto; ajusta el alcance

En el desarrollo de un proyecto manejamos 3 variables fundamentales: el plazo, el presupuesto y el alcance. En un entorno altamente competitivo como el actual, no tiene sentido modificar el plazo y el presupuesto. La solución pasa por ajustar bien el alcance final del proyecto. Es decir, hay que establecer bien las prioridades para realizar la parte fundamental -el corazón- respetando el plazo y el presupuesto. Los proyectos a años vista no son más que una pura fantasía, una entelequia que nunca toma cuerpo tal y como se planeó.

5. Desarrolla medio producto o servicio

Empieza por el principio: el “corazón”. Cíñete a lo verdaderamente esencial. Las buenas ideas pueden acotarse; las ideas no tan buenas, en cambio, son difíciles de formular… Toma lo que piensas que debe ser el proyecto y pártelo por la mitad. Sigue recortando objetivos para quedarte con lo básico. Vuelve a partir el resultado por la mitad: ya tienes lo esencial. Es el “corazón” del proyecto.

6. Acorta el tiempo, trocea los problemas hasta que puedas digerirlos

Trocea el tiempo disponible para el proyecto. Sigue troceando los plazos hasta hacer pedazos más pequeños. En vez de un proyecto de 12 semanas, haz 12 proyectos de 1 semana: ganarás motivación y eficacia. Todos perdemos tensión e interés cuando el plazo de entrega de nuestro trabajo queda demasiado lejos en el horizonte.

Trocea también las tareas. Trabaja mediante iteraciones: pequeñas tareas que puedes manejar sin problemas, y que te permiten avanzar rápidamente e introducir cambios prácticamente en cualquier estadio del proyecto. Divide los problemas en trozos más y más pequeños hasta que seas capaz de digerirlos. Es la mejor forma de superar los bloqueos. Ver más sobre Scrum.

7. Equipos pequeños y ágiles

La Ley de Metcalfe tiene un corolario que explica bien la necesidad de contar con equipos pequeños: la eficiencia del equipo es inversamente proporcional al cuadrado del número de integrantes. Es decir, las probabilidades de que surjan problemas de comunicación aumentan de forma brutal cuando el número de miembros se dispara. Un equipo multidisciplinar de sólo 3 personas es el formato óptimo para desarrollar un proyecto en su fase inicial.

8. La comunicación es fundamental

No dividas la empresa ni el equipo en “departamentos” (marketing, ventas, desarrollo, etc.). Es fundamental que exista un diálogo fluido en todas las direcciones a lo largo de todo el proceso. Las organizaciones deben estar centradas alrededor de lo que queremos crear, y las fronteras deben ser líquidas entre las diferentes responsabilidades.

Prueba a reunirte todas las mañanas durante 10 minutos con el equipo; de pie, a una hora fija pero sin formalismos. Que cada uno explique brevemente qué es lo que está haciendo, y que problemas está encontrando. Así, todo el mundo estará informado de la situación real del proyecto, y entre todos podréis superar los obstáculos que bloquean el trabajo.

9. Evita las opciones innecesarias: toma decisiones

Decide los pequeños detalles para que tu cliente no tenga que elegir. ¿Rojo o negro?, si no es absolutamente vital para el proyecto, toma tú la decisión. Las “opciones” (puedes hacer A o B o C) son una manera de evitar la toma de decisiones de peso. Los clientes no deberían tener que decidir sobre cada pequeño detalle. No les traslades esos problemas: son responsabilidad tuya. Valora la importancia de avanzar y progresar. Entra en el ritmo y la dinámica de tomar decisiones.

Todas las decisiones son temporales. Volverás de nuevo sobre ellas. Así que no te pares: decide y sigue adelante. No te obsesiones con hacerlo todo perfecto a la primera: es imposible. Elimina la presión. Deja que el proyecto crezca y te hable, que tome forma y evolucione. Conforme avances en el proceso iterativo, conocerás mejor el proyecto y sus circunstancias, y contarás también con la aportación de tus colaboradores. Esto te permitirá tomar decisiones cada vez mejor informadas.

10. Testea en condiciones reales. Escucha y mejora

Recuerda siempre: estás desarrollando un proyecto de verdad, así que tienes que ponerlo a prueba en condiciones reales. No sirven las reflexiones en el limbo, ni las pruebas en laboratorio. Pon a prueba tu servicio o producto. Testea con usuarios de verdad en condiciones reales. No busques sustitutos: no existen. Trabaja con datos reales. Consigue un feedback auténtico y, lo más importante: haz las mejoras basándote en la información que has obtenido. Se lo debes a tus usuarios.

Algo más sobre la filosofía “Hazlo realidad”

Recuperar la pasión. Las organizaciones tradicionales, con su estructura lenta y pesada, su burocracia, sus reuniones interminables y sus reglas han acabado con la pasión y la creatividad de los empleados. Los procesos de gestión han dejado de ser racionales, y se han convertido en un auténtico obstáculo para el cambio y la innovación. Por eso hay que formular una alternativa real. Frente a las grandes estructuras y los departamentos especializados, pequeños equipos multidisciplinares. Frente al “ordeno y mando” de las jerarquías tradicionales, comunicación fluida en todas las direcciones, y profesionales creativos capaces de organizar su trabajo y de tomar decisiones. Personas motivadas, unidas en torno a un proyecto común.

Hazlo realidad. Evita los rodeos, simplemente HAZLO. Hay que evitar de forma consciente aquellos procesos que sólo REPRESENTAN la realidad (especificaciones, documentación, tablas, gráficos, etc.) para dedicarse a CONSTRUIR aquello que necesitamos.

Menos es más. En la vida real, a la hora de HACER las cosas, menos es más. Hay que concentrarse en lo esencial y rechazar lo superfluo: menos gente en los equipos, menos instrucciones, menos papeleo, menos jerarquías, menos reuniones, menos políticas de empresa. Hay que hacer sólo aquello que es verdaderamente central e importante para tu negocio. Y hacerlo bien.
Una estructura sencilla permite, además, que la gente nueva que se incorpore a la organización aprenda rápido, y pueda ser productiva en menos tiempo.

La teoría sin ejecución no sirve. La teoría tiene un objetivo: mejorar y acelerar la ejecución de la práctica. Cuando la teoría “flota” en el limbo, o sólo sirve para retrasar la ejecución real de los proyectos, deja de tener sentido para la organización. La ejecución diferencia a las organizaciones que son de alto rendimiento de las que no lo son.