Muchas otras grandes empresas de TI comenzaron con una startup, y Badoo no es una excepción. En los últimos años, la compañía ha pasado de varias docenas de ingenieros a varios cientos. Nikolai Krapivny estuvo a la vanguardia en la mayor parte de este camino y tomó decisiones: qué es lo mejor y qué no hacer, cómo hacer frente a los problemas. Su informe sobre TeamLead Conf se dedicó a esta experiencia y a la imagen del mundo que resultó en ella.

Por supuesto, cada compañía tiene su propio camino , pero los problemas de las comunicaciones humanas son aproximadamente los mismos para todos. La experiencia de otra persona lo ayudará a pensar de antemano sobre los problemas que tendrá que enfrentar el crecimiento de la empresa. Incluso si estos valores no se aplican directamente, le dirá qué forma de pensar.



La historia consta de tres partes. El primero es sobre las comunicaciones , sobre cómo cambian con el crecimiento de la empresa. La segunda parte trata sobre cómo, con el aumento en el número de ingenieros en el equipo, tratar de mantener la velocidad de desarrollo . Y la tercera parte es por qué Badoo vive en dos oficinas y cómo lidiar con el problema de la comunicación.

¡Empecemos!



Sobre el orador: Nikolay Krapivny (@ cyberklin ) ha trabajado en Badoo durante los últimos ocho años, cinco de ellos están involucrados en la gestión de equipos y en los procesos de desarrollo de edificios.


Antes de sumergirme en la primera parte, quiero decir que esta es una historia sobre nuestro camino y no pretende ser una verdad absoluta. Cada compañía tiene su propio camino, pero estoy seguro de que nuestra experiencia, los valores que hemos formado para nosotros mismos, algunos conocimientos lo ayudarán en su crecimiento, lo ayudarán a construir el proceso correcto. A pesar de que tienes una especificidad diferente, todo es un poco diferente, espero que esto te sea útil.

Comunicaciones

Para empezar, hablemos un poco teóricamente sobre lo que sucede con las comunicaciones cuando una empresa crece.

La comunicación se trata de cómo los departamentos interactúan entre sí, cómo las personas interactúan entre sí, cómo se lleva a cabo la comunicación para que se haga algo en la empresa.

Considere un ejemplo bastante trillado, pero sin embargo vital: un equipo de inicio abstracto. Varias personas se reunieron, alguien más cercano al negocio y alguien más técnico. Pero en general, este es un equipo pequeño que hace algo que quizás algún día se convierta en el segundo Facebook. Y en este equipo, todo el trabajo se basa en las comunicaciones. El equipo es pequeño y no tiene sentido introducir ningún proceso. Todo funciona así : alguien habló con alguien, acordaron hacer algo rápidamente, lo están haciendo.

A pesar del hecho de que en el proceso, que se basó únicamente en las comunicaciones, en las conversaciones: "Hagámoslo", "Hagámoslo más rápido", "Hagámoslo así", hay ciertos problemas, un equipo sin duda tiene sus ventajas.

1. El trabajo es rapido . El tiempo desde una idea hasta cómo esta idea está disponible para el usuario es muy pequeño. La idea surgió, hablamos con alguien sobre cómo hacerlo más rápido, ya está hecho, está listo.
2. Es flexible . En este pequeño equipo no existe tal cosa que alguien solo esté involucrado en algo específico y no pueda, cuando sea necesario, conectarse a una tarea que sea importante. En principio, todo el mundo hace todo, y si algo es importante para nosotros, todos hacen un esfuerzo para hacerlo.
3. En general, debido al hecho de que tales procesos aún no se han construido, dicho trabajo es bastante efectivo . No gastamos demasiado tiempo en costos generales, en algunos procesos, en algunos esquemas formales acumulados.

Estos son solo los valores que toda empresa quiere ver: la ecuación de recursos más flexible, el tiempo mínimo de comercialización y los bajos costos operativos.

La empresa está creciendo: las comunicaciones están "desgarradas".

Cuando una empresa crece, las ventajas de un equipo pequeño, cuando todo funciona rápidamente, en la interacción, en las conversaciones, se convierten en un problema. La carga en las comunicaciones de la cantidad de información transmitida comienza a crecer, y llegamos al hecho de que las comunicaciones están "desgarradas" . Estamos comenzando a perder más en comunicaciones que lo que estamos ganando. Necesitamos hablar con demasiadas personas, en algún lugar hay un malentendido al transmitir información de persona a persona, en algún lugar simplemente perdimos algo, en algún lugar que olvidamos. Y todo lo que se construyó, lo que dio velocidad, lentamente comenzamos a perder.



Si extrapola y observa el modelo de desarrollo de la compañía durante un intervalo de tiempo prolongado, entonces parece un ciclo. El número de personas aumenta, la carga en el proceso aumenta, las comunicaciones comienzan a interrumpirse. Lo que anteriormente funcionó deja de funcionar. Por lo tanto, nos vemos obligados a reparar algo en estos lugares. A menudo esto sucede en las fronteras de los departamentos. Para solucionarlo, debe formalizar el proceso de comunicación. Y este ciclo se repite muchas veces : el número de personas aumenta, algo comienza a funcionar de manera ineficiente, introducimos nuevos procesos, de alguna manera los formalizamos, obtenemos un nuevo suministro para el crecimiento hasta que se rompe en otro lugar y así sucesivamente. Es como escalar un sistema, como un rendimiento: si aumenta la carga en el sistema, el elemento más débil, la parte más lenta no lo soportará. Reparamos, de alguna manera mejoramos, aparece una ventana en la que puede aumentar la carga en el sistema. Entonces con la escala de la empresa.

Fue una pequeña parte teórica introductoria.

Ahora echemos un vistazo a los ciclos que atravesamos, los problemas que encontramos y cómo los resolvimos.

Términos de referencia

Como primer ejemplo, considere la tarea de formalizar la relación entre una empresa y un equipo de ingeniería. Los términos de referencia, o, como lo llamamos PRD, es una solicitud de lo que debe cambiarse en términos de funcionalidad de diseño. Esta es una formalización bastante obvia por la que pasan todas las empresas. Creo que la mayoría de ustedes trabajan en empresas donde hay algún tipo de proceso formal de transferencia de una tarea de desarrollo. De un equipo de producto, de una empresa o de un cliente externo, no importa.



Pasamos por varias partes de la complicación de este proceso. Al principio solo escribimos. Cuando el equipo se hizo más grande que el que le permite hacer negocios simplemente hablando entre nosotros, comenzamos a escribir todo esto en tareas. Los objetivos se formularon como "lo que hay que hacer". Además, la complejidad del producto creció, el número de personas en la empresa creció y llegamos a la conclusión de que es útil mantener la versión actual del sistema de trabajo actual en un solo lugar. Pasamos todo esto a Wikis, y una discusión de los cambios en los comentarios de la wiki para que todo esté en un solo lugar. El siguiente paso fue formalizar lo que debería estar en el proceso de revisión de PRD + PRD. Ahora tenemos una plantilla que corrige qué información debe estar en el PRD, qué se debe describir y qué datos se deben recopilar antes de comenzar a trabajar. Por ejemplo, ahora la plantilla PRD contiene los siguientes bloques:

• El objetivo, ¿por qué estamos haciendo esta funcionalidad?
• ¿Qué plataformas, productos, países planeamos lanzar?
• Descripción del formato funcional de casos de uso: casos principales + una lista predefinida de "casos complicados" de los que todos se olvidan.
• Fichas (procesadas por separado por el redactor).
• Comunicaciones: si habrá notificaciones por correo electrónico / push para esta funcionalidad y, de ser así, cuáles.
• Plan de lanzamiento, dependiendo del marketing / otros proyectos en la empresa.
  
• Análisis: cómo evaluaremos los resultados, qué métricas comerciales debemos agregar para evaluar el éxito del cambio.

Por lo tanto, en la forma actual, la interacción entre el producto y el equipo técnico se formaliza con bastante fuerza y ​​nos ayuda a no perder algunos puntos importantes en el proceso de transferir una tarea al trabajo.

Cliente del servidor

Crecimos aún más, apareció el desarrollo móvil y se convirtió en una de las áreas clave. Surgió el siguiente punto en el que la comunicación "se interrumpió". Este es el punto en la unión entre el cliente y el servidor . Se trata de cómo el cliente debe interactuar con el servidor a nivel de protocolo, a nivel de relación. Esto fue decidido por las conversaciones entre los clientes y los servidores. Pero el número de equipos creció, el número de personas en estos equipos creció. Y el hecho de que la información sobre la interacción del cliente y el servidor se almacenara solo en la cabeza de los desarrolladores comenzó a generar problemas.

La documentación

Los problemas que encontramos fueron bastante simples y obvios. La relación cliente-servidor no es solo un protocolo, sino también un esquema de comunicación de acuerdo con este protocolo. Qué comandos enviar y cuándo, cómo el cliente debe solicitar algo, cómo se inicia la aplicación; todo debe seguir el protocolo.

Por ejemplo, los desarrolladores de la parte del cliente resuelven el problema y creen que la API tiene un comando adecuado al que se puede llamar y todo estará bien. Este cliente se libera y crea un problema en el servidor, porque el equipo era demasiado pesado y requiere demasiados recursos. Además, iOS y Android entienden la API de manera un poco diferente, y la implementan de diferentes maneras, debido a esto no podemos hacer cambios rápidamente en la API. Por lo tanto, hemos llegado a la conclusión de que el protocolo debe documentarse.

Liberar no volver

La peculiaridad de las plataformas móviles también es que el lanzamiento no puede ser devuelto. Si la aplicación se presenta en la tienda y el usuario la ha instalado, lo más probable es que le lleve mucho tiempo vivir con esta versión del cliente. Error en la etapa de diseño del protocolo, en la etapa de determinar la interacción entre el cliente y el servidor, querido. En Badoo por otro año o dos, tendremos que admitir cualquier aplicación que se publique hasta que el número de usuarios baje a un cierto límite.



Para resolver este problema, decidimos asignar un equipo MAPI separado, que documentará el protocolo y será el punto de intercambio de conocimiento entre el cliente y el servidor . Este equipo incluye empleados del desarrollo de clientes y servidores. Este equipo combinado está transformando los requisitos del producto para modificar el protocolo y su documentación. Dado que el error en la etapa de implementación del protocolo es bastante costoso para nosotros, los procesos en este equipo son un poco más complicados y difíciles que en todos los demás. Utilizan una revisión de código doble, tratando de eliminar la posibilidad de error tanto como sea posible.

Este equipo se convirtió rápidamente en un centro de intercambio de conocimientos. A menudo hay situaciones en que los desarrolladores de clientes y servidores no pueden ponerse de acuerdo sobre cómo deberían interactuar. Por ejemplo, iOS puede ser la única forma, pero para Android no es adecuado. El nuevo equipo resuelve estos problemas controvertidos y, si es necesario, reúne a las personas adecuadas para tomar la decisión correcta.



Si observa el diagrama de nuestro proceso, el equipo de Mobile API es un enlace intermedio entre cuando los requisitos están listos y cuándo comienza el desarrollo. Eso es:

• del equipo de producto recibe la tarea de desarrollar TK (PRD);
• el equipo de diseño del protocolo elabora la documentación;
• comienza el desarrollo de las partes del cliente y el servidor de acuerdo con la documentación.

Con dicho proceso, el desarrollo del servidor y el cliente puede ir de forma independiente, y a menudo lo usamos.

Problema estadístico

La compañía continuó creciendo y desarrollándose, había más personas y proyectos. Poco a poco, llegamos al punto de que ha surgido un equipo separado que se ocupa de datos, estadísticas y ayuda al equipo del producto a analizar cómo los usuarios responden a los cambios. Como dije, los problemas aparecen en la unión de los equipos . Tenemos un nuevo equipo, y después de un tiempo, esta articulación también comenzó a funcionar de manera ineficiente.

El hecho es que los analistas necesitan buenos datos para identificar patrones y responder preguntas difíciles sobre productos. Los buenos datos significan que todas las estadísticas deben estar subordinadas a un solo idioma. Cuando hablamos de estadísticas y de nuestro producto, necesitamos hablar un idioma.

Antes de esto, en cada tarea técnica, el gerente de producto describió los principios de recopilación de estadísticas con palabras: para este botón, debe medir la tasa de clics, para esta pantalla, la conversión. Pero luego el propio desarrollador decidió qué eventos rastrear, cómo medir (desde el cliente o servidor), qué gráficos dibujar y, por ejemplo, qué secciones agregar a estos eventos. El desarrollador puede hacer gráficos cortados por tipo de dispositivo, agregar género, recopilar estadísticas por país. Estos datos dispares llegan al departamento analítico, pero sobre la base de esto es imposible evaluar con precisión la calidad de la solución en el producto. Como resultado de esto, surge el eje inverso de las tareas: realizamos cambios, estos cambios se implementan, el gerente de producto solicita análisis, el equipo de estadísticas solicita datos adicionales, la tarea se revisa, las estadísticas se están finalizando, esperamos nuevamente ... Esto alarga el ciclo del producto y este fue el problema para nosotros.

El proceso de recopilación y análisis de estadísticas debe formalizarse.



Decidimos que los requisitos de estadísticas se registrarán en los Términos de Referencia, y los propietarios de los conocimientos sobre los requisitos serán analistas. El analista, en la etapa de transferir el trabajo en TK al desarrollo, dice qué estadísticas se necesitan, qué eventos rastrear, por qué sectores para romper los datos. Si el analista solicita expandir las estadísticas existentes o agregar nuevas, entonces agregamos nuevas funciones o modificamos las existentes. Para hacer esto, formalizamos el trabajo con datos en código. Creamos una única API, que simplemente no permite enviar datos insuficientes o datos no válidos.

Paralelamente, desde el punto de vista de las herramientas, tenemos una herramienta rápida de Microstrategy para la visualización de datos y nuestra propia herramienta para pruebas A / B. Los propietarios de todos los conocimientos sobre cómo utilizar estas herramientas correctamente son analistas.



Se agrega otra etapa al diagrama del proceso. PRD pasa por la etapa de coordinación en el departamento de análisis, y solo después de eso se transfiere al MAPI y al desarrollo. Entonces funciona ahora.

Compartir la carga

El siguiente problema está asociado con una mayor carga e interacción dentro de un departamento. Lidero el equipo de desarrollo de back-end para nuestros productos, y en su ejemplo ilustraré qué problemas surgen con el aumento en el número de empleados dentro de un equipo.



En un equipo de hasta 15 personas, todo es bastante simple. Creíamos que todo el mundo hacía todo y distribuía tareas principalmente sobre la base de quién es libre ahora, eso es lo que hace. ¿Por qué hasta 15?

Se cree que uno o el líder del equipo o líder técnico debe dirigir un equipo de hasta 7–9 personas. Este es un número empíricamente establecido de un número adecuado de subordinados.

Teníamos un líder de equipo y su adjunto, así que juntos controlamos a 14-15 personas. Con un mayor crecimiento, se hizo necesaria una división adicional. El flujo de tareas de desarrollo necesita ser equilibrado. Hemos identificado el requisito principal para este proceso: estamos formando especialización . Cada parte del código tendrá expertos, 1-2, y preferiblemente 3, que conocen mejor este código y que lo admiten. Pero al mismo tiempo, hay un requisito ortogonal: mantener la flexibilidad . Por ejemplo, si cinco personas apoyan al mensajero y han llegado demasiadas tareas urgentes, entonces no deberían estar inactivas. Si el equipo tiene recursos gratuitos, deberían incluirse en el desempeño de las tareas de otras personas. Estos requisitos se contradicen entre sí, pero aún queremos tratar de lograrlo.



Dividimos un gran equipo en grupos de desarrollo de 4 a 9 personas. A la cabeza de cada grupo está el líder técnico y él es el líder directo del equipo. Introducimos tal concepto como un componente. Un componente es un fragmento de código completado en términos de funcionalidad del producto. Cada componente se asigna a un grupo específico. Cada componente dentro del grupo tiene 1-2-3 personas que son expertas en esta pieza y se dedican a su desarrollo y apoyo.

• En términos de carga compartida, cada tarea tiene un componente.
• Las tareas de la deuda técnica y el soporte se distribuyen en el grupo "nativo", al que se asigna este componente.
• Estamos tratando de distribuir nuevas funcionalidades en el grupo "nativo". Pero solo si tenemos esa oportunidad.
• Para mantener la flexibilidad, no excluimos una situación en la que un grupo ayuda a otro y hace algo que no está conectado con sus componentes.
• En este caso, se lleva a cabo una revisión de tareas técnicas o una revisión de código, esto lo hace el grupo "nativo".

En esta opción, estamos trabajando ahora. El equipo tiene 30 personas, 5 grupos y 22 componentes que compartimos entre ellos. Si bien no vemos el límite para un mayor crecimiento en este formato, nos adheriremos a cierta escala.



Un efecto secundario interesante: lo que sucede en un equipo cuando la cantidad de proyectos, la cantidad de personas, la cantidad de cambios crece con bastante fuerza. Nos enfrentamos al hecho de que hay tantos en total que es difícil entender las razones específicas de un cambio.

Daré un ejemplo del crecimiento en el registro de nuevos usuarios en Brasil. La razón puede ser: un bot de spam que registra nuevas cuentas y arruina nuestras vidas; problemas con las sesiones; solo una campaña promocional; lanzamiento de una nueva ola de marketing en Brasil. El cambio es visible en el gráfico, y queremos entender con un mínimo esfuerzo lo que sucedió.



Nos hicimos una herramienta llamada WTF. Esta es una herramienta que recopila en sí misma de todo tipo de subsistemas y partes de producción algo que de alguna manera puede afectar las métricas. , . , (, ), ( ).



: — , - . .

:

• . .
• , .
• , , — .
• .

:

• .
• BI, ;
• MAPI .
• , — .

200 . , , . , :)

. , , .



Time-to-marker . .



. , , , - . , , .



: . , , . - . . : — . . , , . , .

-, , . - .

• . - . .
• . 10 , . : . . .
  
• - . bus- , . , , , .
  

, ( — ), . , OX . . OY .

, .



. - — . - , time-to-market , . - , , - , - , . , , . .



. - . , , . . , workflow. (, ) . - . , , .



, . , , , . , — . . — 2 , . , . , , . - - , - , .

. , , .



70–80 . , , . , . , - , .



.

— , - — .

, . , , - , , — - . , , — . .

—

, , . , . , .



. , . , , , . , - , , , server-side , . , , - , . , server-side, , . 14 , . - , server-side. , server-side 50/50. , , , . , , , - , , . , , .



.

— , . , , - , , .

. , , , , . « ».

. , — , , , . 50/50 10- .



, — . , . , 3 . - , 12 . 3 — , . , , , , , , , - , . — . . 11:00, — 9:00. , .

, — , 2 , , . , — , , - , -, , . , - , .



, , « ». - , , - . :

• : — , ..
• Un mentor es un rol operativo a corto plazo, de hecho, es: "Te enseñaré a pelear ahora". Cómo comportarse para resolver los problemas actuales.

El rol estratégico se puede realizar de forma remota mediante algunas visitas y conversaciones regulares, ya que es estratégico y no hay necesidad de una intervención constante en el trabajo. El papel del mentor, la gestión operativa, es bastante difícil de realizar de forma remota. Por lo tanto, para nosotros mismos, hemos desarrollado una regla que establece que para todos los empleados jóvenes y nuevos, la tutoría técnica se realiza localmente. Hay una persona en el equipo que asume las responsabilidades de un líder que asesora a la persona en asuntos emergentes localmente. En este caso, el líder aún puede realizar trabajos relacionados con el crecimiento estratégico de una persona.



Nadie cancela el hecho de que solo necesita reunirse con más frecuencia . Todo es estándar aquí:

• Hacemos viajes de negocios el uno al otro. Reunirse en el trabajo de diseño.
• Una vez al trimestre hay una evaluación del desempeño. Todos los gerentes que tienen subordinados en otra oficina deben venir a hablar uno a uno. Aún así, hablar por videoconferencia no es en absoluto como hablar en persona con una persona.
• Los nuevos empleados deben visitar diferentes oficinas: para conocerse, ver cómo funciona otro equipo, conocer a un gerente de producto para un ingeniero o viceversa.
• Hacemos reuniones grupales. El departamento se divide en grupos, y cada grupo se reúne una vez por trimestre. Por otra parte, en diferentes ciudades a su vez. Primero, un grupo se reúne en Moscú, los empleados hacen algo juntos, de alguna manera interactúan, pasan por una especie de trabajo en equipo.
• Una vez al año intentamos realizar una reunión general del departamento en un entorno informal. Por lo general, este es un fin de semana en el que puede hacer algo útil, discutir problemas, pero al mismo tiempo simplemente hablar "de por vida". Ayuda a sentir que estamos haciendo una cosa común.

También tenemos un evento para toda la empresa, llamado "All Hands". Una vez por trimestre, todos los empleados de la compañía se reúnen y alguien habla sobre lo que hemos logrado últimamente. Para reducir la distancia entre oficinas, esta reunión se celebra en Moscú o en Londres. En una cuarta parte, todos los que deben hablar vienen a Moscú, y se está llevando a cabo una videoconferencia en Londres. El próximo trimestre, por el contrario, hay una actuación en Londres, y en Moscú, solo una video conferencia.

Así vivimos en Badoo.

Te invitamos a espiar una nueva porción de las experiencias organizacionales de otra persona en Saint TeamLead Conf . El programa incluye discursos de compañías muy famosas: Sberbank-Technologies, Avito, JetBrains, Spotify ... ¡sí, todos son geniales!

Este informe es uno de docenas de informes, si no desea esperar hasta que podamos descifrarlos y publicarlos en Habré, mire la lista de reproducción de la conferencia en nuestro canal de YouTube .

Para no perderse nada, suscríbase a la lista de correo especial. Intentamos ahorrarle tiempo y publicar noticias útiles: revisiones de transcripciones, videos recientes, informes seleccionados de futuras conferencias.