Hace unos meses escribí uno de tantos artículos en esta lista de correo sobre la importancia de la distribución: la gente no vendrá. En él describía como, en realidad, no importa mucho cuántas funcionalidades añadas a tu producto si no consigues captar a usuarios:

El argumento me sirve para ilustrar uno de los mayores peligros al que se enfrentan emprendedores y empresas de todos los tamaños en su día a día: la creencia de que si construyes algo bueno es suficiente para que la gente venga.

Películas de Hollywood aparte, la realidad es que la gente no vendrá.

Puedes crear el mejor producto del universo, pero si no has pensado cómo llevarlo hasta tu público, si no has pensado en su distribución, si no has pensado en cómo venderlo, la realidad es que habrás construido un campo de béisbol en un maizal en la mitad de Iowa.

Una derivada importante que no relacioné en ese momento, aunque sí en otros artículos como en Sobreingeniería: el arte de resolver problemas que aún no existen, es la cantidad de tiempo que perdemos en la industria preparándonos para algo que probablemente no vaya a pasar, como puede ser escalar.

Es curioso como la mente ingenieril juega en nuestra contra en estos casos. El poder anticipar todo lo que puede pasar al construir un producto, puede acabar haciendo que no lo construyas nunca porque te quedas paralizado analizando todas las posibilidades.

Mientras tanto, los que no saben lo que no saben, generalmente gente sin experiencia o background de ingeniería, son capaces conquistar un mercado con un producto que te hace querer arrancarte los ojos. Simplemente porque llegaron primero a resolver el problema de sus clientes e iteraron desde esa posición de ventaja.

Esta es la gran virtud que tienen las startups y los equipos pequeños. La falta de recursos te impone preocuparte sólo de lo importante e ignorar todo lo demás. ¿De qué sirve preocuparse por escalar si lo mismo no llego a pagar las nóminas a final de mes?

Y me ha dado por pensar, ¿habría alguna forma de prevenir caer en la parálisis por análisis en organizaciones más establecidas? ¿Cómo podríamos volver a recuperar la agilidad de los primeros días?

Diseñado para fallar

¿Y si en vez de diseñar soluciones pensando que van a funcionar las diseñáramos con el objetivo de que fallaran? ¿Tendría sentido pasarnos días diseñando la estructura de datos? ¿Tendría sentido cubrirla de tests de integración antes siquiera de lanzarla?

En mi equipo en Voicemod lanzamos varios experimentos por semana. Muchos de estos experimentos fallan y su código nunca llega a desplegarse a todos los usuarios, pero de cada uno de ellos aprendemos valiosos puntos de información que nos ayudan a diseñar mejores soluciones en el futuro.

No tendría sentido invertir días en protegernos de situaciones que quizás no se den nunca, así que tenemos un acuerdo tácito entre producto e ingeniería de forma que si un test funciona y valida una funcionalidad, le reservamos tiempo a posteriori para cubrir todos los aspectos que la harán más robusta en producción.

En cierto modo, y aunque nunca lo he expresado así, podría decirse que diseñamos con la idea de fallar. O de aprender fallando. Soy un firme creyente de que el aprendizaje real sólo surge de poner el producto en manos de los clientes y usuarios. Y para hacerlo eficiente, el flujo de desarrollo y la velocidad de iteración son críticos

Decidir lo más tarde posible

Iba a cerrar el artículo, cuando releyéndolo me he dado cuenta de que no he contado nada que los mejores y más experimentados equipos de ingeniería no conozcan ya.

Decidir lo más tarde posible, es uno de los principios que Mary y Tom Poppendieck adaptaron del afamado sistema de producción de Toyota al desarrollo de software en su libro seminal, Lean software development : an agile toolkit.

Citando el resumen de la Wikipedia:

El desarrollo de software está siempre asociado con cierto grado de incertidumbre, los mejores resultados se alcanzan con un enfoque basado en opciones por lo que se pueden retrasar las decisiones tanto como sea posible hasta que éstas se basen en hechos y no en suposiciones y pronósticos inciertos. Cuanto más complejo es un proyecto, más capacidad para el cambio debe incluirse en éste, así que debe permitirse el retraso de los compromisos importantes y cruciales. El enfoque iterativo promueve este principio: la capacidad de adaptarse a los cambios y corregir los errores, ya que un error podría ser muy costoso si se descubre después de la liberación del sistema.

Un enfoque de desarrollo de software ágil puede llevarles opciones rápidamente a los clientes, lo que implica, retrasar algunas decisiones cruciales hasta que los clientes hayan reconocido mejor sus necesidades. Esto también permite la adaptación tardía a los cambios y previene las costosas decisiones delimitadas por la tecnología. Esto no significa que no haya planificación involucrada en el proceso, por el contrario, las actividades de planificación deben centrarse en las diferentes opciones y se les adapta a la situación actual; así como, se deben clarificar las situaciones confusas estableciendo las pautas para una acción rápida. Evaluar las diferentes opciones es eficaz tan pronto como queda claro que ellos no son libres, pero proporcionando la flexibilidad necesaria para una tardía toma de decisiones.

Una versión menos teórica y también más basada en la experiencia sobre este principio la encontramos en el siempre recomendable blog de Eduardo Ferro, Lean Software development: The art of postponing decisions:

One of the seven principles of Lean Software Development is Defer Commitment. This principle tries to maintain options open (options have value) and avoid waste by only solving the current problem (avoiding speculative design). Following this principle allows us to generate easy to change, minimal systems with low accidental complexity and minimal features (as we have a low lock-in).

Keep in mind that software is only a means to an end, and that we are trying to generate impact, not software.

Over the years, I have found that postponing decisions and working in small, safe steps have been the key to creating sustainable solutions.

My experience tells me this is an excellent way to work, at least for product development.

Conclusiones

No sabía muy bien sobre qué iba a escribir cuando hoy comencé esta entrada. Pero tenía la certeza de que si me ponía delante del ordenador e iba hilando temas que me rondaban la cabeza sería capaz de construir algo lo razonablemente aceptable para enviarlo.

En cierto modo, he puesto en práctica lo que he contado. Generalmente, es mejor lanzarse a la acción que paralizarse esperando tener la solución perfecta. La alternativa hubiera sido no enviar este artículo y perder la oportunidad de aprender de vuestras reacciones al mismo. ¿Tendrá más lecturas o menos que otros artículos? ¿Interesará el tema? ¿Generará interacciones? Todos estos datos sólo se pueden conocer lanzando, y en ocasiones, lanzando cosas que nos dan vergüenza.

La agilidad, especialmente en startups, no viene de tener todas las respuestas desde el principio, sino de la capacidad de adaptarse rápidamente a lo que realmente sucede al lanzar un producto al mercado. Priorizar el aprendizaje continuo por encima de una planificación perfecta es clave para generar impacto.

El mayor riesgo no es equivocarse rápido. Es quedarse paralizado analizando escenarios que nunca llegarán.