17

Ago

Publicado por: Xavi Hidalgo | Agile | desarrollo | startup

Lecciones técnicas aprendidas trabajando con startups

Durante todo este tiempo que llevo desarrollando mi actividad en este sector, he tratado con gran número de empresa, la mayoría de ellas de Europa y calculo que aproximadamente el 70% de ellas eran startups o compañías que se encontraban en fase de desarrollo de su producto. De todos estos años he aprendido algunas cosas que hoy os voy a plasmar resumidas en tres lecciones técnicas básicas:

 

1. Las decisiones técnicas son críticas para el éxito

Algunas veces nos encontramos con una gran confusión con el concepto MVP (Producto Mínimo Viable). Esto lleva a traducirlo técnicamente como “Iniciarlo como puedas es justamente MVP”.

En la práctica, casi siempre… el MVP no lleva un mes sino más bien seis. Es esencial tener una arquitectura seria desde el comienzo hasta el final de esos seis meses para que el cliente no tenga que rehacer el proyecto.

Hacer un “pasteboard” en ocasiones puede ser muy “Lean” y debería ser evaluado un poco más, no se puede hacer siempre bien la primera vez.

La condición no desarrolla todas las especificaciones MVP pero, si cambio algo, no tengo que rehacer nada.

En muchos casos hemos encontrado que hacerlo bien no solo cuesta lo mismo sino que es siempre más barato.

Consejo: Trabajar desde el principio y lo más rápido posible con “working software”.

Más de la mitad de los proyectos ya han empezado sobre partes técnicas.

En todas las startups que he trabajado estos años, en más de la mitad -otra vez- teníamos componentes que no funcionaban o con complejidad accidental, no podíamos mantener un crecimiento funcional. Esto no solo representó un coste adicional e hizo esperar al cliente sino que también retrasó su producto.

Consejo: incluye en el contrato de subcontratación escalabilidad funcional porque pagas por un servicio y debe ser de calidad. Deja espacio para rehacer.

2. No existe “Lean Startup” sin cultura técnica Agile.

Lean Startup es un movimiento con el que concuerdo y respeto mucho. En estos años, hemos asistido en un gran número de bootcamps en Barcelona y hemos recibido consejo en Tetuan Valley. Hemos conocido grandes profesionales que se han convertido en amigos. Jimmy Flores en particular nos abrió los ojos y nos dió unas lecciones muy valiosas de forma totalmente altruista. ¡Muchas gracias Jimmy!

Este artículo te podría interesar: Lean Startup y Producto Mínimo Viable

Desde el principio, con nuestra experiencia en Agile, pudimos ver que el Lean tenía una base sólida. Aun así, hay algo que no está explicado completamente: Lean prescribe pequeñas iteraciones donde validar el producto con consistencia. Es en la implementación de este principio donde no podemos concebir “pases rápidos” sin una excelente base técnica.

Por ejemplo, si hablamos sobre una página web -que es un caso muy común-, ¿Cómo podemos hacer iteraciones cortas si le quitan tiempo para entrar en producción? ¿O cómo podemos hacer iteraciones cortas si durante mucho tiempo estamos solucionando bugs o integrando el trabajo de diseño, desarrollo y contenido?

Consejo: para la cultura y prácticas Lean Startup es efectivo asegurar que los “outsourcers” son agile: pruebas unitarias, integración constante,”deploys” automáticos, test funcional automático, SCRUM…

3. No trabajes con compañías “mono-framework”

No hay un framework mágico que lo soluciona todo, de hecho, es difícil es trabajar con uno son confiar en él, y eso se consigue diseñando una arquitectura con patrones de diseño bien definidos. Si tu compañía te dice que subcontrates expertos (como frameworks) quizás sea momento de buscar otra compañía, una que no esté atada a un framework y generas una dependencia desde el principio.

La solución es un buen diseño de la arquitectura, no una tecnología concreta.

Estos años, hemos trabajado con clientes los cuáles nos llamaban porque su aplicación era inmanejable. En casi todos los casos, era una instalación típica de Symphony, otras muchas veces era Ruby on Rails (RoR), además tenemos experiencias similares con Yii, unos frameworks java algo experimentales… No estoy diciendo que sean una mala elección en sí mismos, repito: la tecnología nunca es la razón del éxito o el fracaso. Pero sí debes ser cuidadoso con descontrolar o enganchar un Framework determinado

Consejo: escoge compañías de desarrollo, nunca especialistas en algo concreto. La especialización es para “renacuajos”.

Incluso si no eres “técnico”, puedes (y de hecho deberías) chequear el nivel tecnológico de tu producto.

Cada pieza en una Startup tiene una responsabilidad bien definida y en el caso del CTO consiste en dirigir la parte técnica. En ocasiones ocurre que en una Startup no tiene un CTO o, a veces, las funciones del CTO las llevan a cabo personas con mucha experiencia… es algo normal. En Startups que externalizan el desarrollo totalmente o en cualquier componente, es conveniente acceder a las cajas de control técnico para operar. Eso es, debemos romper la dependencia de la subcontratación. Una cosa es “rise to production” cuando pregunta, pero si quiero ir a producción o “rollback”… tengo un botón donde lo hago yo mismo.

Hoy en día hay muchas herramientas para controlar esto, en particular, Jenkins o TeamCity. Realmente… es muy sencillo.

Consejo: solicita un panel de control y un monitor de procesos técnicos de la aplicación. Un startup debe poder medir la velocidad de desarrollo o encontrar errores de un evento creado si no técnico. Prohibido estar cautivo de terceros.

Estas son algunas de las conclusiones que he obtenido trabajando con startups estos años.

Si te sientes identificado y quieres compartir tu opinión o quieres comentar alguna directriz técnica relacionada con dudas sobre startups, no dudes en contactar con nosotros. ¡Nos encanta compartir!

 

Barcelona
Passeig Gaiolà 13
+34 933 801 144
Lleida
Carrer Agustins 7
+34 973 988 222
Andorra
(Escaldes-Engordany)
Parc de la Mola 10, AD700
Bogota
Carrera 9A #99-07 Piso 9. Despacho 02
Torre la Equidad