Retos escalando el desarrollo de producto

Probablemente no necesitas un CTO, necesitas orden.

Uno de las preguntas que escucho mas seguido de emprendedores, sobre todo de empresas que han logrado una tracción inicial, es: “Como contrato a un CTO?” o como “ayudar” a la persona que esta encargada de producto o tecnología a “convertirse en un CTO”.

Cada empresa se construye de manera diferente y existen ejemplos de empresas que han levantado capital para rápidamente contratar equipos grandes. Esas empresas definitivamente necesitan contratar a un CTO experimentado para reclutar, organizar, y ser el líder de multiples equipos de desarrollo en poco tiempo.

Las empresas a las que me refiero son las que por el contrario, crecen paso a paso, levantando capital en etapas, conforme llegan a ciertos objetivos. Esta situación ocasiona que no pueden contratar a un CTO experimentado en el momento en el que quisieran — sin embargo — tampoco lo necesitan.

En la mayoría de los casos, debemos de replantear la pregunta hacia “Como aceleramos el desarrollo de producto y creamos un equipo técnico que pueda crecer?”.

El rol del primero.

Cuando estamos contratando a un contador para las necesidades iniciales de una empresa, no estamos buscando alguien que pudiera ser el CFO de una empresa publica. Cuando estamos buscando a nuestro primer vendedor, no estamos buscando que sea un Director de Ventas que sepa entrenar equipos de vendedores. En ambos casos estamos buscando personas que sean extremadamente capaces en las metas de corto y mediano plazo, que sean jugadores de primer nivel que atraiga a mas personas como ellos. Lo mismo pasa con los desarrolladores, diseñadores y cualquier perfil involucrado con desarrollo de producto.

Una de los temas mas complicados con un programador es entender como desea avanzar en su carrera. Si su pasión fuera manejar equipos de trabajo, no hubiera pasado todas esas horas aprendiendo como crear productos, muchas veces de manera solitaria, sin depender de muchas otras personas. Entre mas eficiente y genial sea un programador, menor son las probabilidades de que su sueño para los próximos 5 años sea pasar el día en reuniones pidiendole amablemente a personas que hagan su trabajo, es mas probable que quiera dictarle, claramente, a compiladores como hacer las cosas.

Es por eso que debemos de abandonar la idea de que la primera persona responsable del lado técnico de una empresa, debería de crecer a ser el director de esa area. Si sucede, es increíble, pero anormal. Lo que si debemos de hacer es de diseñar un proceso en el cual podemos aumentar la velocidad y el talento del equipo de desarrollo hasta que un día, podamos atraer a personas que verdaderamente busquen ese rol, o alguien del equipo desee crecer en este aspecto.

Divide y perderas

Cuando tenemos a una persona hacia desarrollo, todo es ordenado y claro, al menos para una persona. Sin embargo, cuando agregamos a mas personas al proceso, comienzan a existir fricciones, en todos los terrenos. Uno de las soluciones mas sencillas, es designar “dueños” de diferentes partes del producto. Este es un buen síntoma de que estamos en una situación complicada y tenemos que darle mucha atención a diseñar como va a trabajar el equipo de desarrollo de producto.

Tener personas responsables por diferentes partes del código, es la peor forma de escalar porque genera dependencias, hace complicado opinar de la arquitectura completa del producto y en general hace que todo el proceso sea lento y difícil para todos los involucrados.

Predictibilidad, la bala de plata

La mejor manera de que los responsables del negocio, el equipo de desarrollo y todos los involucrados estén felices con la cultura de la empresa, es que existan expectativas reales y se cumplan.

Para lograr eso necesitamos una gran cantidad de cosas que son importantes y nunca sucede por casualidad. El primer paso es poder priorizar las necesidades del negocio, el segundo paso es entender el proceso en el que se pueden construir y el tercero, y ultimo paso, es tener un proceso que entienda lo que sucede en el día a día y pueda rectificar en el proceso. Para poder lograr estos tres pasos, requerimos construir una cultura de tolerancia, comunicación y esfuerzo.

Paso 1: Priorizar las necesidades del negocio

Si un equipo de desarrollo es rápido, eficiente y entrega lo que se le parece mas interesante programar, nunca resolvemos los problemas reales de nuestros clientes. Por otro lado si en lo único en lo que se trabaja son en las partes aburridas que se le prometieron a un cliente para ayer, nadie se siente dueño del producto — ni se puede diseñar una arquitectura para el futuro.

Balancear las ideas, necesidades y compromisos de toda la empresa hacia las decisiones de como priorizar un producto es complicado, muy complicado. El primer paso es agendar reuniones cada tres o cuatro meses donde todos los involucrados puedan, en un espacio creativo y divertido, participar en el proceso de prioritizar el desarrollo, en un muy alto nivel, para los próximos meses. [1]

La meta no es terminar con un plan detallado y realista del cada día de trabajo, sino tener un consenso general del orden en el que se van a realizar ciertos proyectos, funcionalidades o productos. Es importante involucrar al equipo técnico y a las personas que están interactuando con clientes para poder balancear las expectativas y tener ideas posibles de lo que se puede construir en cierto tiempo.

A este boceto del trabajo que describe las 2-6 metas, ordenadas que se desean realizar muchas veces se le llama “el estacionamiento” — no tengo idea porque.

Paso 2: El proceso.

Una vez que tenemos una lista de proyectos y un sentimiento de que se posible acabar en cierto tiempo, es momento de hacer la parte complicada, romper una meta de alto nivel en casos de uso, tareas y hacer que todos den la mayor productividad.

La meta es poder hacer lo que queremos hacer, bien, y a tiempo.

Tener una persona encargada de manejo de proyectos es importante, sin embargo cualquiera de los fundadores de la empresa, incluso sin ser muy técnico, puede realizar estas tarea de organización. La clave es saber pedir información a las personas correctas, en el momento correcto.

Mi recomendación es pasar de una meta de alto nivel como podría ser “Liberar una app” a un serie de historias de uso que engloban todo lo que esperamos del producto, una podría ser “El usuario puede utilizar la app para adquirir nuestro servicio, pagando con tarjeta de crédito”. En lo general son mas completas y descriptivas.

Una vez que tenemos esto, el siguiente paso es hacer una lista de tareas por cada una de estos casos, la meta es que todas las tareas sean menores de 3 horas. Podemos utilizar a los expertos en realizar esas tareas para validar si son lo suficientemente granulares para poderse hacer en menos de 3 horas. El proceso es muy sencillo, es ir con las diferentes personas involucradas y preguntar “Que haríamos para que el usuario pueda hacer esto?” y escuchar como podrían construirlo, proponer una seria de tareas y observar las reacciones. Usualmente sabemos que el trabajo esta listo cuando todo mundo dice “Claro, podemos hacer eso en ese tiempo, va a estar padre”.

Paso 2: El proceso, del proceso.

Una vez que tenemos una lista de tareas, podemos empezar a verdaderamente juntar las expectativas realistas con la cantidad de recursos que tenemos para realizarlas. Una manera de comenzar es hacer “sprints” de una semana.

Antes del Lunes, la persona manejando el proyecto debe de tomar las historias de uso, y sus tareas, que entren en el número de horas que el equipo puede realizar, una buena regla es numero de personas tiempo completo multiplicado por treinta. Conforme repetimos semana a semana podemos descubrir si estimamos para arriba o para abajo y si debemos de cambiar este numero.

El Lunes de 9 am a 11 am, el equipo tiene un desayuno divertido y tranquilo donde revisa todas las tareas de la semana, quien esta asignado a ella y revisan el orden, las tareas se trabajan de arriba para abajo.

De Martes a Viernes, a una hora establecida que funcione para todos y de preferencia en persona, se hace una junta de 15 minutos(El “Stand Up”) cada una responde a tres preguntas — “Que hiciste ayer?”, “Que vas a hacer hoy?” y “Estas bloqueado por alguien o por algo?”.

Viernes a las 5:00 pm, se entregan todas las tareas del “Sprint”. El equipo técnico se reúne e invita a personas de otras areas para demostrar lo que se logro durante la semana. Se realizan demostraciones y se actualiza el código en producción de manera que todos están involucrados con el proceso.

Paso 2: La cultura.

Para que todo esto funcione con la calidad y el tiempo adecuado, se requiere crear una cultura donde la gente ayuda constantemente a estimar tareas, donde la persona que lleva el proyecto sabe preguntar y medir si se va a tiempo y cuando las cosas salen diferente a lo esperado, puede tomar decisiones adecuadas generar un nuevo plan y comunicarlo de la manera adecuada.

Una de las cosas mas importantes de la cultura es como comunicar que no se esta logrando el plan, mi recomendación es poner una regla donde si has trabajado el doble de tiempo del que estaba estimado en una tarea, tienes la obligación de detener al equipo, plantear la situación y generar un nuevo plan.

Muchas veces una tarea que tarda mucho mas de lo que estaba planeado es un síntoma de un problema mas grande, quizá la arquitectura no es la correcta o bien, el equipo esta tratando de hacer algo que no puede o no sabe como hacer.

Otro dato importante es encontrar maneras de que todos estén motivados con el proceso, se sientan libres de cambiarlo y mejorarlo sin que eso signifique dejar de hacer las partes importantes — y difíciles — de planear y organizar el proyecto.

Paso 3: Repetir, cada vez mejor.

El paso 3 es sencillo: paciencia y mejora continua. Las primeras semanas las cosas no van a salir como esperado, el proceso va a requerir *mucho* mas esfuerzo del que hubiéramos imaginado, sin embargo, dedicando varias semanas a pulir el proceso, vamos a encontrar que tener el manejo correcto de un proyecto, nos permite agregar a mas personas sin generar mas fricciones, que el mismo equipo es ordenes de magnitud mas eficiente en entregar funcionalidades que importan y que en general, todos los involucrados están mas felices.

No reinventar el hilo negro, si motivar a que exista mas!
Existen muchos recursos de manejo de proyectos, y es urgente que comencemos a tener mas discusiones de mejores practicas, personas especialistas en este tema y estoy seguro que así veremos a equipos de desarrollo mas felices, empresas mas eficientes y mas casos de éxito!

[1] Empresas que sientan que tener un panorama de tres o cuatro meses de visibilidad en el desarrollo de producto, están en una etapa mas temprana de la que me refiero y probablemente deberían de tratar de tener un proceso mas acelerado de validación, pivotes, etc.