Hace un par de días estuve hablando con Pablo Martínez (fundador de TodoStartups) y le comentaba que iba a tener la suerte de pasar 2 semanas trabajando con floqq.com en las oficinas de 500 Startups en Mountain View, entonces me animó a escribir un artículo y aquí está ^_^.
Ya es la segunda vez que puedo venir aquí a la cuna de la tecnología, y la primera vez me quedé con ganas de compartir muchas cosas de las que aprendí y que me di cuenta que podían ser muy útiles para otras personas así que esta vez me he animado a crear una serie de vídeos donde cada día he decido a compartir lo que vaya aprendiendo sobre: inversión, diferencias culturales, startups, etc. Para los que estéis interesados en ver todos los vídeos os dejo el siguiente enlace:
Suscríbete gratuitamente a todos los vídeos
Vista de Mountain View desde 500 Startups
Aquí os dejo el primer vídeo que grabé con @okmakey antes de salir de viaje por si os interesa lo que hay que tener preparado para irse allí:
Bueno, hoy os voy a dejar algunos consejos/insights que nos ha dado Zal Bilimoria (Senior Product Manager en Linkedin pero que también ha trabajado para Google o Netflix) a la hora de gestionar el desarrollo de un producto como el nuestro donde tenemos el equipo divido geográficamente (EEUU y España) y por tanto trabajamos en franjas horarias diferentes, además de tener la necesidad de ir muy rápido y lanzar nuevas versiones cada semana:
Cualquier herramienta de gestión de tareas tipo Teambox, Pivotal Tracker, Asana, Trello, etc. es muy útil para poder llevar un control de las tareas pendientes, realizadas y en progreso (Kanban whiteboard).
Además de usar Scrum, una buena práctica es revisar las estimaciones diariamente para ver si algo se está alargando demasiado, y si alguien de equipo puede ayudar a resolver posibles bloqueos.
Planificando el sprint de la semana
Es muy útil que cada 1 ó 2 semanas el equipo haga una Demo delante del equipo de calidad que supervise las historias realizadas. Además es saludable que cada miembro presente lo que ha hecho y pueda responder a cualquier tipo de preguntas. Esta demo es recomentable tenerla lista para el jueves tarde o viernes a primerísima hora (por posibles retrasos)
Además de planificar a corto plazo (sprints) es una buena práctica hacer una reunión de un par de horas en la que definir las historias de los próximos 4 sprints (para tener una visión global).
También nos ha resaltado la importancia de la documentación del código, en el caso de una startup es especialmente importante ya que sirve tanto para evitar bloqueos a la hora de programar como para introducir a nuevos miembros en el equipo.
Antes de hacer los sprints hace falta que el Product Manager recopile toda la información posible, a pesar de ellos siempre habrá un 10% de información que no sabremos que es necesaria hasta que estemos trabajando.
Bugfixing vs New features: en una startup que crece rápido y tiene un equipo reducido es muy complejo gestionar la resolución de bugs a la vez que desarrollar nuevas funcionalidades; por eso nos ha recomendado usar la regla del 80/20, 80% para desarrollar y 20% para arreglar bugs. Sólo en caso de bugs de prioridad cero (que afecten al beneficio (€) de la empresa) deben introducirse en el flujo de trabajo inmediatamente.
Y por último nos ha echo incapié en no tener un sólo "apaga fuegos", que si necesitamos hacer releases continuamente sería mejor crear un rol que cada semana vaya rotando, compartiendo así la responsabilidad de este cargo entre todos.
Bueno, que ya me he extendido mucho y no me quiero alargar más. Espero que esto os pueda ayudar de alguna forma, de todos modos ya sabéis, cada día subiré un nuevo vídeo y podéis preguntarme lo que queráis.
¡Un abrazo!
