Cómo cumplimos las fechas de entrega en programación

Este post es el 4º de la serie de posts con los que te estoy presentado al equipo de SumaCRM. Los anteriores son:

1. Equipo Comercial: Cómo escalamos el equipo comercial con cazadores y granjeros.
2. Equipo Marketing: Todo nuestro marketing online al descubierto.
3. Equipo Soporte: Cómo damos soporte a más de 900 clientes con sólo 1 persona.

Mi mayor cagada en SumaCRM fue hace 7 meses, el 20 de septiembre de 2016, cuando anuncié por email el lanzamiento de SumaCRM 2.0 a bombo y platillo:

 

Mis socios y responsables de programación, Henry y Ale, me habían dicho que había quedado increíble de bien y que en 10 días lo lanzábamos.

Un par de días después pude testearlo antes de lanzarlo y, lamentablemente lo que habían hecho, después de 2 meses de desarrollo a full, no era lo que queríamos y no podíamos publicarlo. Pero ya lo había anunciado… gestionando fatal las expectativas de nuestros clientes.

Y lo que es peor, 2 meses después seguía sin estar. Empezamos a tener discusiones bastante incómodas entre programación y el resto de departamentos, así que decidimos pausarlo para salirnos del bosque, y analizar el fallo sin buscar culpables, sino soluciones.

Me puse a investigar por internet y a devorar todo lo que caía en mis manos sobre organización en departamentos de programación. La buena noticia es que a las pocas semanas creamos nuestro propio framework de trabajo de programación, con el que desde hace 5 meses no sólo hemos vuelto a cumplir con las fechas de entrega, sino que tenemos una comunicación buenísima, mil veces mejor que antes, que incluso ha hecho que desde la semana pasada volvamos a abordar el desarrollo de SumaCRM 2.0. 🙂

Así que por si te sirve, en este post te quiero dejar nuestro propio framework para afrontar nuevos desarrollos, que empieza por:

1) Las fechas de entrega son sagradas

Los deadline son súper necesarios ya que sirven para priorizar. A mí mismo me pasa con los posts, gracias a tener el martes como deadline, el lunes soy súper productivo. Estoy convencido que sin el deadline podría tirarme 1 semana más haciendo el post y que en cualquier caso no sería mejor.

En programación pasa lo mismo, pero la verdad es que programar es más difícil que hacer un post y pueden surgir imprevistos.

Uno de los descubrimientos que hicimos fue que para estos imprevistos, están las metodologías ágiles, que sirven para estar súper organizados, focus, con buena comunicación, y que en caso de un imprevisto no te tires demasiado tiempo hasta que te des cuenta que no vas en buen rumbo (por ejemplo nuestros 4 meses de SumaCRM 2.0) y puedas orientar el barco antes.

Dentro de las metodologías ágiles nosotros hacemos KANBAN (muy similar a SCRUM pero evolucionado)

Utilizamos Trello, dividido en varias columnas (estados) donde creamos cards (simulando a post-it).

Las columnas son:

1. Backlog: Aquí los product manager creamos todas las cards con las funcionalidades que queremos desarrollar en un plazo corto, que estimamos a ojo de buen cubero, de 1 a 2 meses. Dentro de cada card linkamos a un doc compartido en Google Drive donde explicamos en profundidad esa card.
2. Especificación: Ale, lee las cards de «backlog» y mueve a la columna «especificación» las que van a desarrollar en las siguientes 2 semanas. Y lo más importante hace dibujos a mano alzada y re-escribe el doc de Google Drive linkado en un lenguaje cercano al de programación, para que así estemos seguros de lo que se va a desarrollar es lo que queremos. En este momento, Ale nos da las fechas de entrega, que como máximo es de 2 semanas 🙂 Y si alguna card lleva más de 2 semanas, las divide en varias y las agrupa, para que cada 2 semanas al menos un grupo se pueda publicar (o nosotros testear).
3. En programación: Cuando un programador se queda libre coge una de las cards que hay en «especificación», la mueve a la columna «en programación«, y se pone a programarla.
4. Testeo: Cuando el programador termina mueve la card a la columna «testeo» para que los product manager la testemos. Lo buenísimo es que no espera a que lo testeemos, sino que directamente coge una card nueva de «especificación» y la mueve al estado «en programación» y sigue programando.  Si durante el testeo los product manager encontramos errores, devolvemos la card a «especificación», con nuestros comentarios en el doc, para que así el programador cuando se vuelva a quedar libre la retome. Como ves es todo asíncrono con lo cual es genial porque no tenemos que tener reuniones y todo el mundo está focus en lo suyo sin parar y súper comunicados.
5. Subir a producción: Si durante el testeo está todo ok, los product manager movemos la card al estado «subir a producción».
6. Subido a producción: Cuando Henry ve que hay una card en «subir a producción», y se puede subir a producción, lo hace, y mueve la card a «subido a producción».
7. Clientes avisados: El estado final; El product manager se encarga de avisar a los clientes de la nueva funcionalidad y mover la card a «clientes avisados», dando por terminado el nuevo desarrollo en plazos, o si no con tiempo para orientar el rumbo del barco 🙂

Te dejo el vídeo con el que yo entendí Kanban por primera vez, es de Eric Brechner el CTO de Microsoft XBOX, y lo hace con palabras tan normales y en lenguaje tan coloquial que lo entiende un niño de 4 años 🙂

2) Decir NO a la solución y Sí al problema

Es clave escuchar a los clientes, pero sobre todo entender sus necesidades. Debemos saber cómo escucharlos.

Hay una frase que me encanta de Henry Ford:

Si cuando hablas con clientes, te dicen lo que quieren y te pones a hablar de esa solución, te puedes quedar en la superficie y no llegar a la raíz del problema donde está la solución de verdad.

La clave para poder hablar del problema y no de la solución (comprar más caballos jeje) está en preguntar ¿por qué? hasta el final.

Te lo cuento con un ejemplo muy visual:

Yo: Me he quedado sin gasolina en el coche.
Tu: ¿Por qué?
Yo: Porque no cogí la salida de la gasolinera.

>> Aquí la cagada sería no seguir preguntando y pensar que hay que poner una salida justo en el punto en el que la persona se quedó sin gasolina, pero fíjate si sigues preguntando…

Tu: ¿Por qué no cogiste la salida?
Yo: Porque no tenía dinero.

Tu: ¿Por qué no tenías dinero?
Yo: Porque ayer jugué al poker y estoy a cero.
Tu: Ah!! Ok !! Entonces tienes que dejar de jugar al poker.

>> Este es el problema real y por lo tanto la solución de verdad 🙂

3)  Mejor hacer el 80% pronto que el 100% tarde

Muchas veces para resolver el 100% de un problema se dedica proporcionalmente mucho más tiempo que resolver el 80%, pero ese 80% soluciona el problema al 100% a la inmensa mayoría.

Llegado el caso, tratamos de seguir 3 principios del bestseller «Getting Real: The smarter, faster, easier way to build a successful web application»

1. YAGNI (Siglas de You aint gonna need it = No lo vas a necesitar)
   No hay que invertir ni un segundo en cosas que no sabes si son necesarias o no, porque la gran mayoría no lo son. Es decir, no hacer lo de «Ya que estas con eso, ¿haces esto otro?» Cuando alguien hace eso tratamos de decir en voz alta «Eso es YAGNI«
2. BASIC FIRST:  Que lo básico esté MUY BIEN resuelto antes de poner cualquier adorno encima. Así sólo «pierdes» el tiempo en los adornos cuando de verdad va a ser final.
3. KILL YOUR BABIES: Hay que enamorarse del problema, pero no de tus soluciones. Si no lo es, hay que estar dispuesto a eliminarlo.

Por último, pero lo más importante: los magos

Con la Semana Santa no me ha dado tiempo a cuadrar agendas para hacer un vídeo con ellos, pero te los dejo en foto en su salsa:

Son respectivamente, Henry y Ale, que han hecho SumaCRM desde cero!! Y la nueva incorporación: Juli. Nota: Lamentablemente Edgar que entró hace meses, decidió bajarse del barco 🙁

Aprendimos un montón y estamos en búsqueda para subir al barco antes de verano a 2 programadores cracks, así que si te ape, aquí tienes nuestra oferta de trabajo de programador php.

¿Y qué más para el próximo martes?

El próximo martes debería continuar con la serie de posts en la que te estoy presentando al equipo de SumaCRM, pero tengo ganas de volver a la carga con posts relacionados con nuestros aprendizajes en ventas, así que te contaré cómo conseguimos recomendaciones B2B.

En cualquier caso, por supuesto me quedan pendiente 2 posts de esta serie: 1) mis cagadas y aciertos como CEO y 2) nuestro excel flujo de caja de caja actualizado a día de hoy.

Si quieres recibirlos, y no olvidarte de visitar la web, escribe tu email debajo y te avisaré de cada post de nuestro viaje a los 100.000€/mes.

Mientras tanto, el vídeo de este post

Por si lo quieres ver en el gym, cenando, en la cama, etc…

O  en podcast por si lo prefieres oír:

Y por último: Prueba SumaCRM gratis

No hace falta que seas cliente para unirte al viaje de este blog, pero ya va siendo hora que pruebes SumaCRM.