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

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.

(más…)

¿Haces que tu trabajo sea simple o te complicas la vida? Es una pregunta que quizá deberías plantearte porque, cuanto más sencilla es tu forma de trabajar, más sencilla resulta tu relación con los clientes. Vamos a ver unos ejemplos:

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:

(más…)

Demasiado a menudo, empezamos a construir un sitio web de arriba abajo: pintamos unas cuantas cajas vacías (un área de trabajo y una columna lateral para el menú, por ejemplo) y después nos dedicamos a rellenarlas de contenido. El problema de este sistema es que acabamos con un montón de cosas en la página que son “de relleno, y que realmente no sirven para cumplir nuestros objetivos de diseño y de negocio.

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:

(más…)

¿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.

(más…)

El otro día hablábamos de los errores: siempre se ha dicho que constituyen uno de los mejores métodos para aprender y mejorar. Pues bien, hoy os proponemos una reflexión hecha desde un punto de vista muy diferente: ¿y si los fracasos no fuesen tan útiles para aprender como nos creemos? 

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.

A petición del público, aquí tienes la PRESENTACIÓN con 10 consejos ágiles que te ayudarán a mejorar tus proyectos y a gestionar más eficazmente tu negocio. Si lo prefieres, también puedes consultar el post original.

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.