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

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.

Esta entrada fue publicada el Miércoles, 15 de julio de 2009 a las 20:06 por danielcabrera y está clasificada bajo: Consejos prácticos, Tendencias. Puede hacer un seguimiento de los comentarios de esta entrada gracias al feed RSS 2.0. Puede dejar un comentario, o enviar un trackback desde su sitio.