Yammer: La estructura tradicional de las empresas de desarrollo está muerta

Kris Gale, Vicepresidente de Ingeniería en Yammer, afirma que los equipos pequeños son la clave para el desarrollo rápido de productos en empresas más grandes. Explora los matices de la construcción de organizaciones en el desarrollo de productos y explica cómo tomar decisiones conscientes durante una fase de crecimiento puede asegurar que las cosas que hacen único y especial a una startup no se pierdan. Al final, es tarea de un director técnico pensar en cómo se puede organizar y optimizar el desarrollo de software.

Los equipos más pequeños entregan más rápido

Inicialmente, el equipo de Yammer siguió un enfoque bastante simple. Se concentraron principalmente en el producto en sí y no pensaron mucho en el personal durante la expansión de la organización. Sin embargo, a medida que la empresa siguió creciendo, notaron que el aumento marginal de productividad con cada nuevo desarrollador se volvía cada vez menor debido a un mayor esfuerzo.

Al mismo tiempo, el resto del mundo se dio cuenta de que Yammer estaba creando algo grande. Por todas partes, las startups intentaban copiar el producto, e incluso las grandes empresas lanzaban productos de la competencia. En Yammer se dieron cuenta de que solo podía haber una empresa dominante en el mercado y que sería otra si no eran lo suficientemente ágiles. Las aplicaciones web modernas deben ser ágiles y adaptables.

Para poder entregar algo más rápido, Yammer adoptó el enfoque de trabajar con equipos pequeños. Pero eso significa más que solo dividir una empresa en equipos pequeños. Si estos equipos están de alguna manera restringidos en la implementación del código, son inútiles. Deben tener la libertad de poder hacer las cosas también fuera de la organización.

Especialización en equipos pequeños

Al principio, las nuevas características en Yammer se dividían entre los tres desarrolladores según la especialización. No era particularmente estricto. Si había mucho trabajo con Rails, Gale podía ayudar un poco, aunque Rails no fuera su fortaleza. El objetivo debería ser crear grupos similares que sean pequeños y especializados, pero que no representen silos puros, porque diferentes problemas requieren diferentes competencias (y diferentes experiencias).

Procesos seriales y grandes empresas tecnológicas

Este enfoque funcionó muy bien con tres desarrolladores. Pero cuando el equipo de Yammer se hizo más grande, se movieron a un modelo más tradicional para organizaciones en el desarrollo de software, en el que había una división por habilidades funcionales. Así que había un equipo de back-end, un equipo de front-end, un equipo móvil, etc. A finales de 2010, ya no solo tres desarrolladores trabajaban en las características, sino aproximadamente 30. ¿Pero eran diez veces más rápidos? No.

Según la ley de Amdahl sobre la ejecución paralela de programas, el aumento de velocidad de un programa al usar múltiples procesadores está limitado principalmente por la parte secuencial del problema [ya que su tiempo de ejecución no se puede reducir mediante paralelización]. Ejemplo: Si tienes un programa del que solo puedes paralelizar la mitad, podrías duplicar la velocidad incluso con 100 procesadores. Incluso con otros 100 procesadores, no cambiaría mucho. El tiempo para la parte serial del esfuerzo total siempre permanece igual.

La gente asume erróneamente que en el desarrollo de software el código se escribe según especificaciones, pero eso no es cierto. Las decisiones técnicas también son muy importantes, y nadie puede construir una empresa de desarrollo si cree eso.

En una organización típica de desarrollo de software de tamaño mediano a grande, tal vez tengas un equipo de front-end, un equipo de back-end y posiblemente un equipo de middleware. Estos equipos tienen su propia base de código y su propio gerente que reporta a un supervisor. Se trata de que la organización y la arquitectura del código deberían coincidir.

Antes de que los líderes puedan dividir y delegar el trabajo, primero deben decidir qué exactamente se debe construir. Entonces surgen preguntas como: "¿En qué trabajará el equipo de back-end?" y "¿Cómo se conecta esto con el equipo de front-end?"

Sin embargo, si el trabajo se divide y delega como se acaba de describir desde los niveles superiores de liderazgo, está mal. Piensa en ello. Si la persona que debe implementar el código encuentra un problema con las especificaciones, debe enviar una sugerencia de mejora hasta el nivel de gestión superior, que luego debe enviarse de vuelta hacia abajo. Este proceso frena un producto y finalmente lo detiene. Además, los desarrolladores en otras partes de la organización ven esto como una interrupción, ya que no trabajan estrechamente con el desarrollador que propuso el cambio. Simplemente no entienden la razón del cambio.

Eso no es lo que querían en Yammer.

La gestión no debería tomar decisiones de desarrollo

Siempre debes contratar personas que sean mejores y más inteligentes que tú. Si sigues este consejo, ¿no deberías confiar en estas personas para tomar decisiones que de otra manera tendrías que tomar tú mismo? Al final, es tarea del líder técnico construir y fomentar una organización. Probablemente tendrás que concentrarte en algo más que escribir código más rápido de lo que pensabas, y enfocarte en la organización en sí.

No creo que debas construir un producto. Creo que debes construir una organización que construya un producto.

Ten mucho cuidado con confiar en los gerentes para las decisiones de desarrollo. De hecho, deberías pasar todas estas decisiones hacia abajo a las personas que también deben implementarlas. Es una señal de advertencia clara si los gerentes son los únicos que toman decisiones para más de 30-40 personas.

¿Cómo se deberían construir las características?

Cuando se construye una característica en Yammer, siempre se debe mejorar una de las tres métricas principales:

• Viralidad
• Compromiso
• Monetización

Básicamente, en Yammer quieren construir características que atraigan clientes, los retengan y sean compradas por ellos. Incluso si tus métricas clave se ven diferentes, definitivamente también deberías comenzar a comunicar algunos objetivos principales en toda la organización. De lo contrario, no puedes capacitar a todos los empleados de tu empresa para tomar buenas decisiones.

En las organizaciones tradicionales, los gerentes de proyecto escriben las especificaciones según sus ideas. En Yammer es diferente. En lugar de escribir una especificación rígida sobre qué se debe construir, una especificación se ve como un punto de partida para un equipo multifuncional, que luego puede elaborar la especificación. Si la especificación ya es demasiado larga o prescribe demasiado, debes tener cuidado. Los desarrolladores afectados deben poder entender las decisiones para una característica para que puedan implementar el código de la manera más eficiente y efectiva.

La regla de "Dos y Diez"

La regla de oro más importante en Yammer es: de dos a diez personas, de dos a diez semanas. Así que básicamente no hay proyectos que sean más grandes o complicados. Hay una relación no lineal entre la complejidad de un proyecto y la fase de integración final al final. Con todo lo que dura más de diez semanas, la duración de la fase final se vuelve desproporcionada.

Si te adhieres a esta regla, también te obliga a lanzar con más frecuencia, probar suposiciones y no lidiar demasiado con errores. Es similar a Lean Startup y si quieres probarlo, debes codificarlo en tu empresa.

Debes desarrollar un sentido de urgencia. Los proyectos muy largos a menudo son culpables de que los desarrolladores pierdan de vista el objetivo real. Es como hacer senderismo. Cuando comienzas, todavía estás lleno de energía, te emocionas con la caminata y avanzas bastante rápido. Con el tiempo, tu cuerpo se cansa y ya no puedes ver dónde comenzaste o hacia dónde vas. Cuando llegas a este punto, necesitas una fuerte voluntad para motivarte a seguir adelante. Desafortunadamente, muchas organizaciones han puesto a sus desarrolladores en esta fase media para la mayoría de sus tareas.

Sin embargo, hacia el final de la caminata puedes ver nuevamente tu objetivo y la motivación regresa. Con cada paso, el objetivo se acerca un poco. Es importante que tus desarrolladores estén en esta fase, donde pueden medir y visualizar su progreso. Solo así se puede mantener la urgencia y la moral de trabajo.

Propiedad del código

Ten cuidado con la propiedad del código: si las personas tienen su propia base de código, eso puede crear muchos incentivos incorrectos que deberías evitar. En Yammer, la organización está dividida en áreas funcionales. Los desarrolladores son realmente inteligentes y motivados, y si pueden orientarse hacia el objetivo de la empresa, pueden lograr cosas sorprendentes (e incluso completamente independientes).

Definir cómo se ve un equipo que funciona

Antes de crear un equipo de producto para una característica, se examina la especificación cuidadosamente. Más específicamente, se intenta estimar el esfuerzo para la característica.

Tomemos el Producto X. Es una característica imaginaria que aumenta la viralidad al permitirte invitar amigos durante el proceso de registro. En este ejemplo, el enfoque está en el front-end, lo que significa que tal vez necesites dos personas para la interfaz de usuario. Y como probablemente también necesites cambiar algo en el proceso de registro, definitivamente también necesitas a alguien del equipo de Rails para escribir el código.

Una vez que el equipo de producto se ha puesto de acuerdo sobre una prioridad para el proyecto, solo tienes que esperar a que los desarrolladores estén disponibles (en este caso dos para el front-end y uno para Rails). En Yammer hay una gran pizarra con cuadrícula llamada "Big Board". En un lado se enumeran los proyectos, en el otro todos los desarrolladores que trabajan en características. Por supuesto, un desarrollador solo puede trabajar en un proyecto a la vez. El Big Board también crea una buena transparencia de las prioridades. Todo lo que se hace durante el desarrollo se menciona allí, y así el director ejecutivo puede echar un vistazo en cualquier momento y determinar: "Entonces, esto es en lo que están trabajando los desarrolladores ahora".

Si logras asegurar el enfoque para un solo proyecto, tu empresa ya será significativamente más rápida. Es sorprendente que nadie haga esto una condición en su organización, cuando básicamente todos saben cuán costoso es un cambio de contexto. Con un enfoque absoluto, construyes una cosa, la entregas y luego puedes dedicarte a algo más.

Pero ¿quién se ocupa de los bugs entonces?

Si todos trabajan en características, ¿quién se ocupa de los bugs? En Yammer simplemente hay varios equipos multifuncionales. Tomas algunas personas del equipo de Rails, del equipo de front-end y del equipo móvil, etc., y les dices: "Tu trabajo es arreglar los bugs y trabajar en nuestra lista". Esto es solo un asunto temporal (como todos los grupos orientados a proyectos) y las personas se turnan. Esta estructura organizacional hace posible cuidar el soporte sin afectar el desarrollo de características.

Además, no se crea una segunda clase de desarrolladores. Aquí no solo se asignan algunos desarrolladores junior para arreglar bugs; los desarrolladores senior también están involucrados. Y eso es intencional, porque si se van a arreglar bugs, no quieres cubrirlos, sino arreglar la causa. A las personas más experimentadas se les debe permitir refactorizar el código si es necesario. Este sistema también conduce a un bucle de retroalimentación entre aquellos que construyen las características y aquellos que arreglan los bugs. Si conoces la frecuencia y el tipo de bugs, esa es información importante para las decisiones que pueden impulsar el desarrollo del producto.

Este texto proviene del Blog de First Round y fue traducido por nosotros al español.