Los primeros ocho errores constituyen toda una lista de "pecados capitales" a evitar por todo emprendedor digital:
1.- Malgastar recursos en construir un producto que desde el inicio escale a grandes cantidades de usuarios y volúmenes de uso, en vez de asegurarse de tener una arquitectura técnica que permita pasar fácilmente a dicha escalabilidad cuando (¡ojalá!) sea necesario.
2.- Dejarse llevar por el impulso de ir construyendo el producto en base a sucesivos parches que nos permiten llegar a diferentes hitos puntuales de presentación a clientes, demostraciones, etc., convirtiendo el resultado en algo tremendamente difícil de mantener y mejorar sostenidamente (efecto al que Jon Evans se refiere como "technical debt", lo que obliga en el futuro a tener que "tirar" y rehacer grandes bloques de código.
3.- Preocuparse en exceso por el secretismo sobre su idea a la hora de implementarla sobre servicios de los gigantes del sector (Google, Amazon, etc.) y por la posibilidad de que puedan acabar apropiándose del resultado.
4.- Guiar en exceso el desarrollo del producto por una potencial evolución y crecimiento hasta ser una "plataforma", centrando la decisión sobre las funcionalidades a implementar desde un principio según lo que debiera tener esa futura plataforma, en vez de pensar incrementalmente y comenzar por un producto más simple que debe madurar antes de evolucionar.
5.- Fiar la capacidad viral de tu producto a un excesivo incremento de la cantidad y visibilidad de funcionalidades para su compartición en multitud de redes sociales, y no tanto en la propia calidad del producto como estímulo para compartirlo.
6.- Suponer que, una vez lanzado el producto en su versión final, todas las previsiones acerca de su incremento viral se harán realidad tal cual, y no estar preparado para la (más que habitual) cruda realidad de un crecimiento discreto o quizá un estancamiento en la base de clientes.
7.- Caer en la tentación de construir toda una batería de métricas y datos de los que hacer seguimiento acerca del uso del producto, sin pensar realmente en las razones para analizarlos ni en el objetivo que persigues con ello.
8.- Acostumbrarse tanto a gestionar situaciones de crisis y de carreras contra reloj para llegar a la siguiente demo, que haces de ello la manera habitual de gestionar todo el trabajo de la startup.
La recopilación se completa con un punto específico resumido en el "Half-Arsed Agile Manifesto" (una sátira del manifiesto original), dirigido a las grandes empresas que deciden lanzar proyectos ágiles pero sólo quedándose con las "jerga bonita" y no tanto con la verdadera manera de trabajar, y otro punto final orientado a evitar la habitual forma poco descriptiva de informar de errores en los productos software.
1.- Malgastar recursos en construir un producto que desde el inicio escale a grandes cantidades de usuarios y volúmenes de uso, en vez de asegurarse de tener una arquitectura técnica que permita pasar fácilmente a dicha escalabilidad cuando (¡ojalá!) sea necesario.
2.- Dejarse llevar por el impulso de ir construyendo el producto en base a sucesivos parches que nos permiten llegar a diferentes hitos puntuales de presentación a clientes, demostraciones, etc., convirtiendo el resultado en algo tremendamente difícil de mantener y mejorar sostenidamente (efecto al que Jon Evans se refiere como "technical debt", lo que obliga en el futuro a tener que "tirar" y rehacer grandes bloques de código.
3.- Preocuparse en exceso por el secretismo sobre su idea a la hora de implementarla sobre servicios de los gigantes del sector (Google, Amazon, etc.) y por la posibilidad de que puedan acabar apropiándose del resultado.
4.- Guiar en exceso el desarrollo del producto por una potencial evolución y crecimiento hasta ser una "plataforma", centrando la decisión sobre las funcionalidades a implementar desde un principio según lo que debiera tener esa futura plataforma, en vez de pensar incrementalmente y comenzar por un producto más simple que debe madurar antes de evolucionar.
5.- Fiar la capacidad viral de tu producto a un excesivo incremento de la cantidad y visibilidad de funcionalidades para su compartición en multitud de redes sociales, y no tanto en la propia calidad del producto como estímulo para compartirlo.
6.- Suponer que, una vez lanzado el producto en su versión final, todas las previsiones acerca de su incremento viral se harán realidad tal cual, y no estar preparado para la (más que habitual) cruda realidad de un crecimiento discreto o quizá un estancamiento en la base de clientes.
7.- Caer en la tentación de construir toda una batería de métricas y datos de los que hacer seguimiento acerca del uso del producto, sin pensar realmente en las razones para analizarlos ni en el objetivo que persigues con ello.
8.- Acostumbrarse tanto a gestionar situaciones de crisis y de carreras contra reloj para llegar a la siguiente demo, que haces de ello la manera habitual de gestionar todo el trabajo de la startup.
La recopilación se completa con un punto específico resumido en el "Half-Arsed Agile Manifesto" (una sátira del manifiesto original), dirigido a las grandes empresas que deciden lanzar proyectos ágiles pero sólo quedándose con las "jerga bonita" y no tanto con la verdadera manera de trabajar, y otro punto final orientado a evitar la habitual forma poco descriptiva de informar de errores en los productos software.
No hay comentarios:
Publicar un comentario