De nombreuses autres grandes sociétés informatiques ont démarré avec une startup, et Badoo ne fait pas exception. Ces dernières années, l'entreprise est passée de plusieurs dizaines d'ingénieurs à plusieurs centaines. Nikolai Krapivny a été à l'avant-garde sur la plupart de ce chemin et a pris des décisions: ce qu'il y a de mieux à faire et à ne pas faire, comment faire face aux problèmes. Son rapport sur TeamLead Conf était consacré à cette expérience et à l'image du monde qui en a résulté.

Bien sûr, chaque entreprise a sa propre voie , mais les problèmes de communication humaine sont à peu près les mêmes pour tous. L'expérience de quelqu'un d'autre vous aidera à réfléchir à l'avance aux problèmes que devra affronter la croissance de l'entreprise. Même si ces valeurs ne s'appliquent pas directement, cela vous indiquera la manière de penser.

L'histoire se compose de trois parties. Le premier concerne les communications , leur évolution avec la croissance de l'entreprise. La deuxième partie concerne comment, avec l'augmentation du nombre d'ingénieurs dans l'équipe, essayer de maintenir la vitesse de développement . Et la troisième partie est pourquoi Badoo vit dans deux bureaux et comment faire face au problème de la communication.

Commençons!

À propos du conférencier: Nikolay Krapivny (@ cyberklin ) travaille chez Badoo depuis huit ans, cinq d'entre eux sont impliqués dans la gestion d'équipe et les processus de développement des bâtiments.

Avant de plonger dans la première partie, je veux dire que c'est une histoire sur notre chemin et ne prétend pas être une vérité absolue. Chaque entreprise a son propre chemin, mais je suis sûr que notre expérience, les valeurs que nous nous sommes forgées, certaines connaissances vous aideront dans votre croissance, vous aideront à construire le bon processus. Malgré le fait que vous ayez une spécificité différente, tout est un peu différent, j'espère que cela vous sera utile.

Les communications

Pour commencer, parlons un peu théoriquement de ce qui arrive aux communications lorsqu'une entreprise se développe.

La communication concerne la façon dont les départements interagissent entre eux, comment les gens interagissent entre eux, comment la communication se déroule pour que quelque chose se fasse dans l'entreprise.

Prenons un exemple un peu galvaudé, mais néanmoins vital: une équipe de démarrage abstraite. Plusieurs personnes se sont rassemblées, une personne plus proche de l'entreprise et une personne plus technique. Mais dans l'ensemble, il s'agit d'une petite équipe qui fait quelque chose qui deviendra peut-être un jour le deuxième Facebook. Et dans cette équipe, tout le travail repose sur les communications. L'équipe est petite et il n'y a aucun intérêt à introduire des processus. Tout fonctionne comme ça : quelqu'un a parlé avec quelqu'un, ils ont accepté de faire quelque chose rapidement, ils le font.

Malgré le fait que dans le processus, qui a été construit uniquement sur les communications, dans les conversations: «Faisons-le», «Faisons-le plus vite», «Faisons-le comme ça», il y a certains problèmes, une telle équipe a sans aucun doute ses avantages.

Le travail est rapide . Le temps entre une idée et la façon dont cette idée devient disponible pour l'utilisateur est très court. L'idée est venue, nous avons discuté avec quelqu'un de la façon de le faire plus rapidement, c'est déjà fait, c'est prêt.
C'est flexible . Dans cette petite équipe, il n'y a rien de tel que quelqu'un ne soit engagé que dans quelque chose de spécifique et ne peut pas, si nécessaire, se connecter à une tâche qui est importante. En principe, tout le monde fait tout, et si quelque chose est important pour nous, alors tout le monde fait un effort pour le faire.
En général, du fait que de tels processus n'ont pas encore été construits, ce travail est assez efficace . Nous ne consacrons pas trop de temps aux frais généraux, à certains processus, à certains régimes formels élaborés.

Ce ne sont que les valeurs que chaque entreprise veut voir: l'équation la plus flexible des ressources, le délai de mise sur le marché minimum et les faibles coûts d'exploitation.

L'entreprise se développe - les communications sont «déchirées».

Lorsqu'une entreprise se développe, les avantages d'une petite équipe, quand tout fonctionne rapidement, sur l'interaction, sur les conversations, deviennent un problème. La charge sur les communications de la quantité d'informations transmises commence à augmenter, et nous arrivons au fait que les communications sont «déchirées» . Nous commençons à perdre plus sur les communications que nous n'en gagnons. Nous devons parler avec trop de gens, quelque part il y a un malentendu lors de la transmission d'informations de personne à personne, quelque part où nous venons de perdre quelque chose, quelque part que nous avons oublié. Et tout ce qui a ensuite été construit, qui a donné de la vitesse, nous commençons lentement à perdre.

Si vous extrapolez et regardez le modèle de développement de l'entreprise sur une longue période, cela ressemble à un cycle. Le nombre de personnes augmente, la charge sur le processus augmente, les communications commencent à se rompre. Ce qui fonctionnait auparavant cesse de fonctionner. Par conséquent, nous sommes obligés de réparer quelque chose à ces endroits. Cela se produit souvent aux frontières des départements. Pour corriger, vous devez formaliser le processus de communication. Et ce cycle se répète plusieurs fois : le nombre de personnes augmente, quelque chose commence à fonctionner de manière inefficace, nous introduisons de nouveaux processus, les formalisons d'une manière ou d'une autre, nous obtenons un nouvel approvisionnement pour la croissance jusqu'à ce qu'il se brise dans un autre endroit et ainsi de suite. C'est comme faire évoluer un système, comme une performance: si vous augmentez la charge sur le système - l'élément le plus faible, la partie la plus lente ne le supportera pas. Nous réparons, améliorons en quelque sorte, une fenêtre apparaît dans laquelle vous pouvez augmenter la charge sur le système. Donc, avec la mise à l'échelle de l'entreprise.

C'était une petite partie théorique d'introduction.

Voyons maintenant quels cycles nous avons traversés, quels problèmes nous avons rencontrés et comment nous les avons résolus.

Mandat

Comme premier exemple, considérons la tâche de formaliser la relation entre une entreprise et une équipe d'ingénieurs. Le mandat, ou, comme nous l'appelons PRD, est une demande de ce qui doit être changé en termes de fonctionnalité de conception. Il s'agit d'une formalisation assez évidente que toutes les entreprises traversent. Je pense que la plupart d'entre vous travaillent dans des entreprises où il existe une sorte de processus formel de transfert d'une tâche de développement. De la part d'une équipe produit, d'une entreprise ou d'un client externe - cela n'a pas d'importance.

Nous sommes passés par plusieurs parties de la complication de ce processus. Au début, nous venons d'écrire. Lorsque l'équipe est devenue plus grande que celle qui vous permet de faire des affaires simplement en discutant entre nous, nous avons commencé à écrire tout cela en tâches. Les objectifs ont été formulés comme «ce qui doit être fait». De plus, la complexité du produit a augmenté, le nombre de personnes dans l'entreprise a augmenté et nous sommes arrivés à la conclusion qu'il est utile de maintenir la version actuelle du système de travail actuel en un seul endroit. Nous avons déplacé tout cela vers les wikis et une discussion sur les modifications apportées aux commentaires du wiki afin que tout soit au même endroit. L'étape suivante consistait à formaliser ce qui devrait être inclus dans le processus d'examen PRD + PRD. Nous avons maintenant un modèle qui fixe quelles informations doivent être dans le PRD, ce qui doit être décrit et quelles données doivent être collectées avant de commencer le travail. Par exemple, maintenant le modèle PRD contient les blocs suivants:

Le but, pourquoi faisons-nous cette fonctionnalité.
Quelles plateformes, produits, pays prévoyons-nous lancer?
Description du format fonctionnel des cas d'utilisation: cas principaux + une liste prédéfinie de «cas compliqués» que tout le monde oublie.
Jetons (traités séparément par le rédacteur).
Communications: s'il y aura des notifications par e-mail / push pour cette fonctionnalité, et si oui, lesquelles.
Plan de libération, en fonction des projets marketing / autres dans l'entreprise.
Analytics: comment nous évaluerons les résultats, quelles mesures commerciales nous devons ajouter pour évaluer le succès du changement.

Ainsi, dans la forme actuelle, l'interaction entre le produit et l'équipe technique est formalisée assez fortement et nous aide à ne pas perdre certains points importants dans le processus de transfert d'une tâche au travail.

Client serveur

Nous avons poursuivi notre croissance, le développement mobile est apparu et est devenu l'un des domaines clés. Le point suivant est survenu au cours duquel la communication a «rompu». C'est le point à la jonction entre le client et le serveur . Il s'agit de la façon dont le client doit interagir avec le serveur au niveau du protocole, au niveau de la relation. Cela a été décidé par des conversations entre les gars du client et les gars du serveur. Mais le nombre d'équipes a augmenté, le nombre de personnes dans ces équipes a augmenté. Et le fait que les informations sur l'interaction du client et du serveur n'étaient stockées que dans la tête des développeurs a commencé à poser des problèmes.

La documentation

Les problèmes que nous avons rencontrés étaient assez simples et évidents. La relation client-serveur n'est pas seulement un protocole, mais aussi un schéma de communication selon ce protocole. Quelles commandes envoyer et quand, comment le client doit demander quelque chose, comment l'application démarre - tout doit suivre le protocole.

Par exemple, les développeurs de la partie client résolvent le problème et pensent que l'API a une commande appropriée qui peut être appelée et tout ira bien. Ce client est libéré et crée un problème sur le serveur, car l'équipe était trop lourde pour cela et nécessite trop de ressources. De plus, iOS et Android comprennent l'API un peu différemment et l'implémentent de différentes manières, de ce fait, nous ne pouvons pas apporter rapidement de modifications à l'API. Ainsi, nous sommes arrivés à la conclusion que le protocole doit être documenté.

Relâchez pas de retour

La particularité des plates-formes mobiles est également que la version ne peut pas être retournée. Si l'application est présentée dans le magasin et que l'utilisateur l'a installée, il faudra très probablement très longtemps pour vivre avec cette version du client. Erreur au stade de la conception du protocole, au stade de la détermination de l'interaction entre le client et le serveur, chère. À Badoo pendant encore un an ou deux, nous devrons prendre en charge toute application publiée jusqu'à ce que le nombre d'utilisateurs tombe à une certaine limite.

Pour résoudre ce problème, nous avons décidé d'affecter une équipe MAPI distincte, qui documentera le protocole et sera le point d'échange de connaissances entre le client et le serveur . Cette équipe comprend des employés du développement client et serveur. Cette équipe mixte transforme les exigences du produit en modifiant le protocole et sa documentation. Étant donné que l'erreur au stade de la mise en œuvre du protocole est assez coûteuse pour nous, les processus dans cette équipe sont un peu plus compliqués et plus difficiles que dans tous les autres. Ils utilisent une révision de code double, essayant d'éliminer autant que possible la possibilité d'erreur.

Cette équipe est rapidement devenue une plaque tournante du partage des connaissances. Il arrive souvent que les développeurs client et serveur ne parviennent pas à s'entendre sur la manière dont ils doivent interagir. Par exemple, iOS peut être le seul moyen, mais pour Android, il ne convient pas. La nouvelle équipe résout ces problèmes controversés et, si nécessaire, rassemble les bonnes personnes pour prendre la bonne décision.

Si vous regardez le diagramme de notre processus, l'équipe Mobile API est un lien intermédiaire entre le moment où les exigences sont prêtes et le début du développement. Soit:

de l'équipe produit reçoit la tâche de développer les savoirs traditionnels (PRD);
l'équipe de conception du protocole élabore la documentation;
le développement des parties client et serveur selon la documentation commence.

Avec un tel processus, le développement du serveur et du client peut se faire indépendamment, et nous l'utilisons souvent.

Problème de statistiques

L'entreprise a continué de croître et de se développer, il y avait plus de personnes et de projets. Lentement, nous sommes arrivés au point qu'une équipe distincte est apparue qui s'occupe des données, des statistiques et aide l'équipe produit à analyser la façon dont les utilisateurs réagissent aux changements. Comme je l'ai dit, des problèmes apparaissent à la jonction des équipes . Nous avons une nouvelle équipe, et après un certain temps, cette jointure a également commencé à fonctionner de manière inefficace.

Le fait est que les analystes ont besoin de bonnes données pour identifier les modèles et répondre aux questions délicates sur les produits. De bonnes données signifient que toutes les statistiques doivent être subordonnées à une seule langue. Lorsque nous parlons de statistiques et de notre produit, nous devons parler une seule langue.

Avant cela, dans chaque tâche technique, le chef de produit a décrit les principes de la collecte de statistiques avec des mots: pour ce bouton, vous devez mesurer le taux de clics, pour cet écran - la conversion. Mais ensuite, le développeur lui-même a décidé quels événements suivre, comment mesurer (à partir du client ou du serveur), quels graphiques dessiner et, par exemple, quelles sections ajouter à ces événements. Le développeur peut créer des graphiques coupés par type d'appareil, ajouter le sexe, collecter des statistiques par pays. Ces données disparates parviennent au service analytique, mais sur leur base, il est impossible d'évaluer avec précision la qualité de la solution dans le produit. En conséquence, l'arbre inverse des tâches se produit: nous apportons des modifications, ces modifications sont mises en œuvre, le chef de produit demande une analyse, l'équipe des statistiques demande des données supplémentaires, la tâche est révisée, les statistiques sont en cours de finalisation, nous attendons à nouveau ... Cela allonge le cycle du produit et c'était le problème pour nous.

Le processus de collecte et d'analyse des statistiques doit être officialisé.

Nous avons décidé que les exigences en matière de statistiques seront enregistrées dans les TdR, et les propriétaires des connaissances sur les exigences seront des analystes. L'analyste, au stade du transfert des travaux sur les savoirs traditionnels au développement, indique quelles statistiques sont nécessaires, quels événements suivre, par quelles tranches pour briser les données. Si l'analyste demande d'étendre les statistiques existantes ou d'en ajouter de nouvelles, nous ajoutons de nouvelles fonctionnalités ou modifions celles existantes. Pour ce faire, nous avons formalisé le travail avec les données dans le code. Nous avons créé une seule API, qui ne permet tout simplement pas d'envoyer des données insuffisantes ou invalides.

En parallèle, du point de vue des outils, nous avons un outil de microstratégie rapide pour la visualisation des données et notre propre outil pour les tests A / B. Les propriétaires de toutes les connaissances sur la façon d'utiliser correctement ces outils sont des analystes.

Une autre étape est ajoutée au diagramme de processus. PRD passe par la phase de coordination dans le département analytique, et seulement après cela, il est transféré au MAPI et au développement. Donc ça marche maintenant.

Partage de charge

Le problème suivant est associé à une charge et une interaction accrues au sein d'un même service. Je dirige l'équipe de développement backend pour nos produits, et sur son exemple je vais illustrer les problèmes qui surviennent avec l'augmentation du nombre d'employés au sein d'une équipe.

Dans une équipe de 15 personnes maximum, tout est assez simple. Nous pensions que tout le monde fait tout et répartit les tâches principalement en fonction de qui est libre maintenant - c'est ce qu'il fait. Pourquoi jusqu'à 15?

On pense qu'un ou un chef d'équipe ou un chef technique devrait diriger une équipe de 7 à 9 personnes. Il s'agit d'un nombre établi empiriquement d'un nombre adéquat de subordonnés.

Nous avions un chef d'équipe et son adjoint, alors ensemble nous avons contrôlé 14 à 15 personnes. Avec la poursuite de la croissance, une division supplémentaire est devenue nécessaire. Le flux des tâches de développement doit être équilibré. Nous avons identifié la principale exigence de ce processus: nous formons une spécialisation . Chaque morceau de code aura des experts, 1-2, et de préférence 3, qui connaissent le mieux ce code et qui le supportent. Mais en même temps, il y a une exigence orthogonale: maintenir la flexibilité . Par exemple, si cinq personnes soutiennent le messager et que trop de tâches urgentes sont arrivées, elles ne devraient pas être inactives. Si l'équipe dispose de ressources gratuites, elles doivent être incluses dans l'exécution des tâches des autres. Ces exigences se contredisent, mais nous voulons toujours essayer d'y parvenir.

Nous avons divisé une grande équipe en groupes de développement de 4 à 9 personnes. À la tête de chaque groupe se trouve le chef technique et il est le chef direct de l'équipe. Nous introduisons un tel concept en tant que composant. Un composant est un morceau de code complété en termes de fonctionnalité du produit. Chaque composant est affecté à un groupe spécifique. Chaque composante au sein du groupe a 1-2-3 personnes qui sont des experts de cette pièce, et sont engagées dans son développement et son soutien.

En termes de partage de charge, chaque tâche a un composant.
Les tâches de dette technique et de soutien sont réparties dans le groupe «natif» - celui auquel cette composante est affectée.
Nous essayons de distribuer de nouvelles fonctionnalités dans le groupe «natif». Mais seulement si nous en avons l'occasion.
Afin de maintenir la flexibilité, nous n'excluons pas la situation où un groupe aide un autre et fait quelque chose qui n'est pas lié à ses composants.
Dans ce cas, soit un examen de mission technique soit un examen de code est effectué - cela est fait par le groupe "natif".

Dans cette option, nous travaillons maintenant. L'équipe compte 30 personnes, 5 groupes et 22 composantes que nous partageons entre elles. Bien que nous ne voyions pas la limite d'une croissance future dans ce format, nous y adhérerons à une certaine échelle.

Un effet secondaire intéressant: ce qui se passe dans une équipe lorsque le nombre de projets, le nombre de personnes, le nombre de changements croît assez fortement. Nous sommes confrontés au fait qu'il y en a tellement au total qu'il est difficile de comprendre les raisons spécifiques d'un changement.

Je vais donner un exemple de la croissance de l'enregistrement de nouveaux utilisateurs au Brésil. La raison peut être: un robot de spam qui enregistre de nouveaux comptes et gâche nos vies; problèmes avec les sessions; juste une campagne promotionnelle; lancement d'une nouvelle vague de commercialisation au Brésil. Le changement est visible sur le graphique, et nous voulons comprendre avec un minimum d'effort ce qui s'est passé.

Nous nous sommes fait un outil appelé WTF. Il s'agit d'un outil qui recueille en lui-même à partir de toutes sortes de sous-systèmes et de parties de la production quelque chose qui peut en quelque sorte affecter les mesures. , . , (, ), ( ).

: — , - . .

:

. .
, .
, , — .
.

.
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 , , . , — , , - , -, , . , - , .

, , « ». - , , - . :

: — , ..
— , , , : « ». , .

Le rôle stratégique peut être effectué à distance par des visites et conversations régulières, car il est stratégique et il n'y a pas besoin d'une intervention constante dans le travail. Le rôle du mentor, la gestion opérationnelle, est assez difficile à réaliser à distance. Par conséquent, pour nous-mêmes, nous avons développé une règle selon laquelle pour tous les jeunes et nouveaux employés, le mentorat technique se déroule localement. Il y a une personne dans l'équipe qui assume les responsabilités d'un leader qui encadre la personne sur les problèmes émergents localement. Dans ce cas, le leader peut toujours effectuer des travaux liés à la croissance stratégique d'une personne.

Personne n'annule le fait que vous avez juste besoin de vous rencontrer plus souvent . Tout est standard ici:

Nous partons en voyage d'affaires. Rencontre sur le travail de conception.
Une fois par trimestre, il y a une évaluation des performances. Tous les managers qui ont des subordonnés dans un autre bureau doivent venir en parler un à un. Pourtant, parler par vidéoconférence n'est pas du tout comme parler en personne avec une personne.
Les nouveaux employés doivent visiter différents bureaux - pour se connaître, voir comment fonctionne une autre équipe, connaître un chef de produit pour un ingénieur, ou vice versa.
Nous organisons des réunions de groupe. Le département est divisé en groupes et chaque groupe se réunit une fois par trimestre. De plus, dans différentes villes à leur tour. Tout d'abord, un groupe se réunit à Moscou, les employés font quelque chose ensemble, interagissent d'une manière ou d'une autre, passent par une sorte de team building.
Une fois par an, nous essayons d'organiser une réunion générale du département dans un cadre informel. Habituellement, c'est un week-end pour lequel vous pouvez faire quelque chose d'utile, discuter de problèmes, mais en même temps parler simplement «pour la vie». Cela aide à sentir que nous faisons une chose commune.

Nous organisons également un événement pour toute l'entreprise, appelé «All Hands». Une fois par trimestre, tous les employés de l'entreprise se réunissent et quelqu'un parle de ce que nous avons réalisé récemment. Afin de réduire la distance entre les bureaux, cette réunion se tient soit à Moscou, soit à Londres. Dans un quartier, tous ceux qui sont censés parler viennent à Moscou et une vidéoconférence a lieu à Londres. Le trimestre suivant, au contraire, il y a une représentation à Londres, et à Moscou, seulement une vidéoconférence.

C'est ainsi que nous vivons à Badoo.

Nous vous invitons à espionner une nouvelle partie des expériences organisationnelles de quelqu'un d'autre à Saint TeamLead Conf . Le programme comprend des discours de sociétés très célèbres: Sberbank-Technologies, Avito, JetBrains, Spotify ... oui, ils sont tous cool!

Ce rapport est l'un des dizaines de rapports, si vous ne voulez pas attendre que nous ayons la main pour les décrypter et les publier sur Habré, alors regardez la playlist de la conférence sur notre chaîne YouTube .

Pour ne rien manquer, abonnez - vous à la liste de diffusion spéciale. Nous essayons de gagner du temps et de publier des nouvelles utiles: comptes rendus de transcriptions, vidéos récentes, rapports sélectionnés de futures conférences.

Extension du développement: du démarrage à des centaines d'ingénieurs