Viele andere große IT-Unternehmen haben mit einem Startup begonnen, und Badoo ist keine Ausnahme. In den letzten Jahren ist das Unternehmen von mehreren Dutzend Ingenieuren auf mehrere Hundert angewachsen. Nikolai Krapivny war auf dem größten Teil dieses Weges an vorderster Front und traf Entscheidungen: Was ist am besten zu tun und was nicht, wie man mit Problemen umgeht . Sein Bericht über TeamLead Conf widmete sich dieser Erfahrung und dem Bild der Welt, das dazu führte.

Natürlich hat jedes Unternehmen seinen eigenen Weg , aber die Probleme der menschlichen Kommunikation sind für alle ungefähr gleich. Die Erfahrung eines anderen hilft Ihnen, im Voraus über die Probleme nachzudenken, die mit dem Wachstum des Unternehmens verbunden sein werden. Auch wenn diese Werte nicht direkt zutreffen, erfahren Sie, wie Sie denken müssen.



Die Geschichte besteht aus drei Teilen. Das erste betrifft die Kommunikation , wie sie sich mit dem Wachstum des Unternehmens verändert. Im zweiten Teil geht es darum, wie mit der Zunahme der Anzahl der Ingenieure im Team versucht werden kann, die Entwicklungsgeschwindigkeit aufrechtzuerhalten. Und der dritte Teil ist, warum Badoo in zwei Büros lebt und wie man mit dem Problem der Kommunikation umgeht.

Fangen wir an!



Über den Redner: Nikolay Krapivny (@ cyberklin ) arbeitet seit acht Jahren bei Badoo, fünf von ihnen sind in das Teammanagement und den Aufbau von Entwicklungsprozessen involviert.


Bevor ich in den ersten Teil eintauche, möchte ich sagen, dass dies eine Geschichte über unseren Weg ist und nicht behauptet, absolute Wahrheit zu sein. Jedes Unternehmen hat seinen eigenen Weg, aber ich bin sicher, dass unsere Erfahrung, die Werte, die wir für uns selbst geschaffen haben, einige Kenntnisse Ihnen bei Ihrem Wachstum helfen und Ihnen helfen, den richtigen Prozess aufzubauen. Trotz der Tatsache, dass Sie eine andere Spezifität haben, ist alles ein bisschen anders, ich hoffe, dass dies für Sie nützlich sein wird.

Kommunikation

Lassen Sie uns zunächst ein wenig theoretisch darüber sprechen, was mit der Kommunikation passiert, wenn ein Unternehmen wächst.

Bei der Kommunikation geht es darum, wie Abteilungen miteinander interagieren, wie Menschen miteinander interagieren, wie Kommunikation stattfindet, damit im Unternehmen etwas getan wird.

Stellen Sie sich ein ziemlich abgedroschenes, aber dennoch wichtiges Beispiel vor: ein abstraktes Startup-Team. Es versammelten sich mehrere Personen, jemand, der näher am Geschäft war, und jemand, der eher technisch versiert war. Aber insgesamt ist dies ein kleines Team, das etwas unternimmt, das vielleicht eines Tages das zweite Facebook wird. Und in diesem Team basiert die gesamte Arbeit auf Kommunikation. Das Team ist klein und es macht keinen Sinn, Prozesse einzuführen. Alles funktioniert einfach so : Jemand hat mit jemandem gesprochen, er hat zugestimmt, schnell etwas zu tun, er tut es.

Trotz der Tatsache, dass in dem Prozess, der ausschließlich auf Kommunikation und Gesprächen basiert: „Lass es uns machen“, „Lass es uns schneller machen“, „Lass es uns so machen“, gibt es bestimmte Probleme, ein solches Team hat zweifellos seine Vorteile.

1. Die Arbeit ist schnell . Die Zeit von einer Idee bis zur Verfügbarkeit dieser Idee für den Benutzer ist sehr gering. Die Idee kam, wir haben mit jemandem darüber gesprochen, wie man es schneller macht, es ist bereits fertig, es ist fertig.
2. Es ist flexibel . In diesem kleinen Team gibt es nicht die Möglichkeit, dass sich jemand nur mit etwas Bestimmtem beschäftigt und sich bei Bedarf nicht mit einer wichtigen Aufgabe verbinden kann. Im Prinzip tut jeder alles, und wenn uns etwas wichtig ist, bemüht sich jeder, dies zu tun.
3. Im Allgemeinen ist eine solche Arbeit aufgrund der Tatsache, dass solche Prozesse noch nicht erstellt wurden, sehr effektiv . Wir verbringen nicht zu viel Zeit mit Gemeinkosten, für einige Prozesse und für einige aufgebaute formale Systeme.

Dies sind nur die Werte, die jedes Unternehmen sehen möchte: die flexibelste Ressourcengleichung, die minimale Markteinführungszeit und niedrige Betriebskosten.

Das Unternehmen wächst - die Kommunikation ist „zerrissen“.

Wenn ein Unternehmen wächst, werden die Vorteile eines kleinen Teams, wenn alles schnell funktioniert, bei der Interaktion, bei Gesprächen zum Problem. Die Belastung der Kommunikation durch die Menge der übertragenen Informationen nimmt zu, und wir kommen zu der Tatsache, dass die Kommunikation „zerrissen“ ist . Wir verlieren mehr an Kommunikation als wir gewinnen. Wir müssen mit zu vielen Menschen sprechen, irgendwo gibt es ein Missverständnis bei der Übertragung von Informationen von Person zu Person, irgendwo haben wir einfach etwas verloren, irgendwo haben wir vergessen. Und alles, was damals gebaut wurde, was Geschwindigkeit gab, beginnen wir langsam zu verlieren.



Wenn Sie das Entwicklungsmodell des Unternehmens über einen langen Zeitraum extrapolieren und betrachten, sieht es wie ein Zyklus aus. Die Anzahl der Personen steigt, die Belastung des Prozesses steigt, die Kommunikation beginnt zu unterbrechen. Was zuvor funktioniert hat, funktioniert nicht mehr. Deshalb sind wir gezwungen, an diesen Stellen etwas zu reparieren. Oft geschieht dies an den Grenzen von Abteilungen. Um dies zu beheben, müssen Sie den Kommunikationsprozess formalisieren. Und dieser Zyklus wiederholt sich viele Male : Die Anzahl der Menschen nimmt zu, etwas beginnt ineffizient zu funktionieren, wir führen neue Prozesse ein, formalisieren sie irgendwie, wir erhalten ein neues Angebot für Wachstum, bis es an einem anderen Ort bricht und so weiter und so fort. Es ist wie das Skalieren eines Systems, wie eine Leistung: Wenn Sie die Belastung des Systems erhöhen - das schwächste Element, wird der langsamste Teil es nicht aushalten. Wir reparieren, irgendwie verbessern, erscheint ein Fenster, in dem Sie die Belastung des Systems erhöhen können. Also mit der Skalierung des Unternehmens.

Es war ein kleiner theoretischer Einführungsteil.

Schauen wir uns nun an, welche Zyklen wir durchlaufen haben, auf welche Probleme wir gestoßen sind und wie wir sie gelöst haben.

Technische Aufgabe

Betrachten Sie als erstes Beispiel die Aufgabe, die Beziehung zwischen einem Unternehmen und einem Engineering-Team zu formalisieren. Die Leistungsbeschreibung oder, wie wir sie PRD nennen, ist eine Anforderung, was in Bezug auf die Designfunktionalität geändert werden muss. Dies ist eine ziemlich offensichtliche Formalisierung, die alle Unternehmen durchlaufen. Ich denke, dass die meisten von Ihnen in Unternehmen arbeiten, in denen es einen formalen Prozess zur Übertragung einer Entwicklungsaufgabe gibt. Von einem Produktteam, von einem Unternehmen oder von einem externen Kunden - das spielt keine Rolle.



Wir haben einige Teile der Komplikation dieses Prozesses durchlaufen. Zuerst haben wir gerade geschrieben. Als das Team größer wurde als das, mit dem Sie einfach durch Gespräche miteinander Geschäfte machen können, haben wir begonnen, all dies in Aufgaben zu schreiben. Die Ziele wurden als „was getan werden muss“ formuliert. Darüber hinaus wuchs die Komplexität des Produkts, die Anzahl der Mitarbeiter im Unternehmen und wir kamen zu dem Schluss, dass es nützlich ist, die aktuelle Version des aktuellen Arbeitssystems an einem Ort zu halten. Wir haben all dies auf Wikis verschoben und die Änderungen an den Wiki-Kommentaren besprochen, damit sich alles an einem Ort befindet. Der nächste Schritt bestand darin, zu formalisieren, was im PRD + PRD-Überprüfungsprozess enthalten sein sollte. Jetzt haben wir eine Vorlage, die festlegt, welche Informationen in der PRD enthalten sein müssen, was beschrieben werden sollte und welche Daten vor Beginn der Arbeit gesammelt werden sollten. Beispielsweise enthält die PRD-Vorlage jetzt die folgenden Blöcke:

• Das Ziel, warum machen wir diese Funktionalität.
• Welche Plattformen, Produkte und Länder planen wir zu starten.
• Beschreibung des funktionalen Anwendungsfallformats: Hauptfälle + eine vordefinierte Liste von „komplizierten Fällen“, die jeder vergisst.
• Token (vom Texter separat verarbeitet).
• Kommunikation: ob und welche E-Mail- / Push-Benachrichtigungen für diese Funktionalität vorhanden sind.
• Release-Plan, abhängig vom Marketing / anderen Projekten im Unternehmen.
  
• Analytics: Wie wir die Ergebnisse bewerten, welche Geschäftsmetriken wir hinzufügen müssen, um den Erfolg der Änderung zu bewerten.

In der aktuellen Form ist die Interaktion zwischen Produkt und technischem Team daher recht stark formalisiert und hilft uns, einige wichtige Punkte bei der Übertragung einer Aufgabe auf die Arbeit nicht zu verlieren.

Server-Client

Wir sind weiter gewachsen, die mobile Entwicklung erschien und wurde zu einem der Schlüsselbereiche. Der folgende Punkt trat auf, an dem die Kommunikation „abgebrochen“ wurde. Dies ist der Punkt an der Verbindung zwischen Client und Server . Es geht darum, wie der Client auf Protokollebene und auf Beziehungsebene mit dem Server interagieren soll. Dies wurde durch Gespräche zwischen den Kunden und den Servern entschieden. Aber die Anzahl der Teams wuchs, die Anzahl der Leute in diesen Teams wuchs. Und die Tatsache, dass Informationen über die Interaktion zwischen Client und Server nur in den Köpfen der Entwickler gespeichert wurden, führte zu Problemen.

Die Dokumentation

Die Probleme, auf die wir stießen, waren ziemlich einfach und offensichtlich. Die Client-Server-Beziehung ist nicht nur ein Protokoll, sondern auch ein Kommunikationsschema gemäß diesem Protokoll. Welche Befehle wann gesendet werden sollen, wie der Client etwas anfordern soll, wie die Anwendung startet - alles muss dem Protokoll folgen.

Zum Beispiel lösen die Entwickler des Client-Teils das Problem und glauben, dass die API einen geeigneten Befehl hat, der aufgerufen werden kann und alles in Ordnung ist. Dieser Client wird freigegeben und verursacht ein Problem auf dem Server, da das Team zu stark dafür war und zu viele Ressourcen benötigt. Darüber hinaus verstehen iOS und Android die API etwas anders und implementieren sie auf unterschiedliche Weise. Aus diesem Grund können wir die API nicht schnell ändern. Wir sind daher zu dem Schluss gekommen, dass das Protokoll dokumentiert werden muss.

Nicht zurücklassen

Die Besonderheit mobiler Plattformen besteht auch darin, dass die Version nicht zurückgegeben werden kann. Wenn die Anwendung im Store angelegt ist und der Benutzer sie installiert hat, wird es höchstwahrscheinlich sehr lange dauern, bis diese Version des Clients verfügbar ist. Fehler in der Phase des Entwurfs des Protokolls, in der Phase der Bestimmung der Interaktion zwischen Client und Server, Liebes. In Badoo müssen wir für ein oder zwei Jahre jede Anwendung unterstützen, die veröffentlicht wird, bis die Anzahl der Benutzer auf ein bestimmtes Limit gesunken ist.



Um dieses Problem zu lösen, haben wir beschlossen, ein separates MAPI-Team zuzuweisen, das das Protokoll dokumentiert und der Punkt des Wissensaustauschs zwischen Client und Server ist . Dieses Team besteht aus Mitarbeitern der Client- und Serverentwicklung. Dieses gemischte Team wandelt die Produktanforderungen in Änderungen des Protokolls und seiner Dokumentation um. Da der Fehler in der Protokollimplementierungsphase für uns ziemlich teuer ist, sind die Prozesse in diesem Team etwas komplizierter und schwieriger als in allen anderen. Sie verwenden eine doppelte Codeüberprüfung, um die Möglichkeit von Fehlern so weit wie möglich auszuschließen.

Dieses Team wurde schnell zu einer Drehscheibe für den Wissensaustausch. Oft gibt es Situationen, in denen sich Client- und Serverentwickler nicht darauf einigen können, wie sie interagieren sollen. Zum Beispiel kann iOS der einzige Weg sein, aber für Android ist es nicht geeignet. Das neue Team löst diese kontroversen Probleme und versammelt bei Bedarf die richtigen Leute, um die richtige Entscheidung zu treffen.



Wenn Sie sich das Diagramm unseres Prozesses ansehen, ist das Mobile API-Team eine Zwischenverbindung zwischen dem Zeitpunkt, zu dem die Anforderungen bereit sind, und dem Beginn der Entwicklung. Also:

• vom Produktteam erhält die Aufgabe, TK (PRD) zu entwickeln;
• Das Protokolldesign-Team erstellt die Dokumentation.
• Die Entwicklung der Client- und Serverteile gemäß Dokumentation beginnt.

Mit einem solchen Prozess kann die Server- und Client-Entwicklung unabhängig voneinander erfolgen, und wir verwenden sie häufig.

Statistikproblem

Das Unternehmen wuchs und entwickelte sich weiter, es gab mehr Menschen und Projekte. Langsam kamen wir zu dem Punkt, dass ein separates Team entstanden ist, das sich mit Daten und Statistiken befasst und dem Produktteam hilft, zu analysieren, wie Benutzer auf Änderungen reagieren. Wie gesagt, Probleme treten an der Kreuzung der Teams auf . Wir haben ein neues Team, und nach einer Weile begann auch dieses Joint ineffizient zu arbeiten.

Tatsache ist, dass Analysten gute Daten benötigen, um Muster zu identifizieren und knifflige Produktfragen zu beantworten. Gute Daten bedeuten, dass alle Statistiken einer einzigen Sprache untergeordnet sein sollten. Wenn wir über Statistiken und unser Produkt sprechen, müssen wir eine Sprache sprechen.

Zuvor beschrieb der Produktmanager in jeder technischen Aufgabe die Prinzipien der Statistikerfassung mit Worten: Für diese Schaltfläche müssen Sie die Klickrate für diesen Bildschirm messen - die Conversion. Dann entschied der Entwickler selbst, welche Ereignisse verfolgt werden sollten, wie gemessen werden sollte (vom Client oder Server), welche Diagramme gezeichnet werden sollten und welche Abschnitte beispielsweise zu diesen Ereignissen hinzugefügt werden sollten. Der Entwickler kann Diagramme nach Gerätetyp schneiden, Geschlecht hinzufügen und Statistiken nach Land sammeln. Diese unterschiedlichen Daten kommen in die analytische Abteilung, aber auf ihrer Grundlage ist es unmöglich, die Qualität der Lösung im Produkt genau zu bewerten. Infolgedessen entsteht die umgekehrte Welle von Aufgaben: Wir nehmen Änderungen vor, diese Änderungen werden implementiert, der Produktmanager fordert eine Analyse an, das Statistikteam fordert zusätzliche Daten an, die Aufgabe wird überarbeitet, Statistiken werden finalisiert, wir warten erneut ... Dies verlängert den Produktzyklus und dies war das Problem für uns.

Der Prozess der Erfassung und Analyse von Statistiken muss formalisiert werden.



Wir haben beschlossen, dass die Anforderungen für Statistiken im ToR erfasst werden und die Eigentümer des Wissens über die Anforderungen Analysten sind. Der Analyst sagt in der Phase der Übertragung der Arbeit an TK auf die Entwicklung, welche Statistiken benötigt werden, welche Ereignisse verfolgt werden müssen, anhand welcher Segmente Daten gebrochen werden sollen. Wenn der Analyst vorhandene Statistiken erweitern oder neue hinzufügen möchte, fügen wir neue Funktionen hinzu oder ändern vorhandene. Zu diesem Zweck haben wir die Arbeit mit Daten im Code formalisiert. Wir haben eine einzige API erstellt, die es einfach nicht erlaubt, unzureichende oder ungültige Daten zu senden.

Parallel dazu haben wir aus Sicht der Tools ein schnelles Microstrategy-Tool für die Datenvisualisierung und ein eigenes Tool für A / B-Tests. Die Eigentümer aller Kenntnisse über den richtigen Umgang mit diesen Tools sind Analysten.



Dem Prozessdiagramm wird eine weitere Stufe hinzugefügt. PRD durchläuft die Koordinierungsphase in der Analyseabteilung und wird erst danach an das MAPI und die Entwicklung übertragen. So funktioniert es jetzt.

Lastverteilung

Das nächste Problem ist mit einer erhöhten Belastung und Interaktion innerhalb einer Abteilung verbunden. Ich leite das Backend-Entwicklungsteam für unsere Produkte und werde anhand seines Beispiels veranschaulichen, welche Probleme bei der Erhöhung der Anzahl der Mitarbeiter innerhalb eines Teams auftreten.



In einem Team von bis zu 15 Personen ist alles ganz einfach. Wir haben geglaubt, dass jeder alles macht und Aufgaben verteilt, hauptsächlich auf der Grundlage dessen, wer jetzt frei ist - das ist, was er tut. Warum bis zu 15?

Es wird angenommen, dass ein Teamleiter oder technischer Leiter ein Team von bis zu 7 bis 9 Personen führen sollte. Dies ist eine empirisch ermittelte Anzahl einer angemessenen Anzahl von Untergebenen.

Wir hatten einen Teamleiter und seinen Stellvertreter, also kontrollierten wir zusammen 14-15 Leute. Mit dem weiteren Wachstum wurde eine zusätzliche Aufteilung notwendig. Der Fluss der Entwicklungsaufgaben muss ausgeglichen sein. Wir haben die Hauptanforderung für diesen Prozess identifiziert: Wir bilden eine Spezialisierung . Jeder Code hat Experten, 1-2 und vorzugsweise 3, die diesen Code am besten kennen und diesen Code unterstützen. Gleichzeitig gibt es jedoch eine orthogonale Anforderung: Flexibilität aufrechtzuerhalten . Wenn beispielsweise fünf Personen den Boten unterstützen und zu viele dringende Aufgaben eingegangen sind, sollten sie nicht untätig sein. Wenn das Team über freie Ressourcen verfügt, sollten diese in die Ausführung der Aufgaben anderer Personen einbezogen werden. Diese Anforderungen widersprechen sich, aber wir wollen immer noch versuchen, dies zu erreichen.



Wir haben ein großes Team in Entwicklungsgruppen von 4-9 Personen aufgeteilt. An der Spitze jeder Gruppe steht der technische Leiter und er ist der direkte Leiter des Teams. Wir führen ein solches Konzept als Komponente ein. Eine Komponente ist ein Code, der in Bezug auf die Produktfunktionalität vervollständigt wird. Jede Komponente ist einer bestimmten Gruppe zugeordnet. Jede Komponente innerhalb der Gruppe hat 1-2-3 Personen, die Experten für dieses Stück sind und sich mit seiner Entwicklung und Unterstützung befassen.

• In Bezug auf die Lastverteilung hat jede Aufgabe eine Komponente.
• Die Aufgaben der technischen Verschuldung und des Supports sind in der „nativen“ Gruppe verteilt, der diese Komponente zugeordnet ist.
• Wir versuchen, neue Funktionen in der "nativen" Gruppe zu verteilen. Aber nur, wenn wir eine solche Gelegenheit haben.
• Um die Flexibilität aufrechtzuerhalten, schließen wir eine Situation nicht aus, in der eine Gruppe einer anderen hilft und etwas tut, das nicht mit ihren Komponenten verbunden ist.
• In diesem Fall wird entweder eine technische Aufgabenüberprüfung oder eine Codeüberprüfung durchgeführt - dies wird von der "nativen" Gruppe durchgeführt.

In dieser Option arbeiten wir jetzt. Das Team besteht aus 30 Personen, 5 Gruppen und 22 Komponenten, die wir gemeinsam nutzen. Obwohl wir in diesem Format keine Grenze für weiteres Wachstum sehen, werden wir uns in einem bestimmten Maßstab daran halten.



Ein interessanter Nebeneffekt: Was passiert in einem Team, wenn die Anzahl der Projekte, die Anzahl der Personen, die Anzahl der Änderungen ziemlich stark zunimmt? Wir sind mit der Tatsache konfrontiert, dass es insgesamt so viele gibt, dass es schwierig ist, die spezifischen Gründe für eine Änderung zu verstehen.

Ich werde ein Beispiel für das Wachstum der Registrierung neuer Benutzer in Brasilien geben. Der Grund kann sein: ein Spam-Bot, der neue Konten registriert und unser Leben verdirbt; Probleme mit Sitzungen; nur eine Werbekampagne; Start einer neuen Marketingwelle in Brasilien. Die Änderung ist auf dem Diagramm sichtbar, und wir möchten mit minimalem Aufwand verstehen, was passiert ist.



Wir haben uns ein Tool namens WTF gemacht. Dies ist ein Tool, das in sich alle Arten von Subsystemen und Teilen der Produktion sammelt, was sich irgendwie auf die Metriken auswirken kann. , . , (, ), ( ).



: — , - . .

:

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

:

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

200 . , , . , :)

Geschwindigkeit

. , , .



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



, , « ». - , , - . :

• : — , ..
• Ein Mentor ist eine operative, kurzfristige Rolle, in der Tat: "Ich werde dir beibringen, jetzt zu kämpfen." Wie man sich verhält, um aktuelle Probleme zu lösen.

Die strategische Rolle kann durch einige regelmäßige Besuche und Gespräche aus der Ferne wahrgenommen werden, da sie strategisch ist und keine ständigen Eingriffe in die Arbeit erforderlich sind. Die Rolle des Mentors, das operative Management, ist aus der Ferne nur schwer zu erfüllen. Aus diesem Grund haben wir für uns selbst die Regel entwickelt, dass für alle jungen, neuen Mitarbeiter das technische Mentoring vor Ort stattfindet. Es gibt eine Person im Team, die die Verantwortung eines Leiters übernimmt, der die Person in neu auftretenden Problemen vor Ort betreut. In diesem Fall kann der Leiter weiterhin Arbeiten ausführen, die mit dem strategischen Wachstum einer Person zusammenhängen.



Niemand bricht die Tatsache ab, dass Sie sich nur öfter treffen müssen . Hier ist alles Standard:

• Wir machen Geschäftsreisen miteinander. Treffen Sie sich bei der Designarbeit.
• Einmal im Quartal findet eine Leistungsüberprüfung statt. Alle Manager, die Untergebene in einem anderen Büro haben, müssen kommen, um eins zu eins zu sprechen. Das Gespräch über Videokonferenzen ist jedoch keineswegs wie ein persönliches Gespräch mit einer Person.
• Neue Mitarbeiter müssen verschiedene Büros besuchen - um sich kennenzulernen, zu sehen, wie ein anderes Team arbeitet, einen Produktmanager für einen Ingenieur kennenzulernen oder umgekehrt.
• Wir machen Gruppentreffen. Die Abteilung ist in Gruppen unterteilt, und jede Gruppe kommt einmal im Quartal zusammen. Darüber hinaus in verschiedenen Städten wiederum. Zuerst versammelt sich eine Gruppe in Moskau, die Mitarbeiter machen etwas zusammen, interagieren irgendwie, durchlaufen eine Art Teambildung.
• Einmal im Jahr versuchen wir, eine allgemeine Versammlung der Abteilung in einem informellen Rahmen durchzuführen. Normalerweise ist dies ein Wochenende, an dem Sie etwas Nützliches tun, Probleme besprechen und gleichzeitig einfach „fürs Leben“ sprechen können. Es hilft zu spüren, dass wir eine gemeinsame Sache tun.

Wir haben auch eine Veranstaltung für das gesamte Unternehmen namens "All Hands". Einmal im Quartal versammeln sich alle Mitarbeiter des Unternehmens, und jemand spricht darüber, was wir in letzter Zeit erreicht haben. Um den Abstand zwischen den Büros zu verringern, findet dieses Treffen entweder in Moskau oder in London statt. In einem Viertel kommt jeder, der sprechen soll, nach Moskau, und in London findet eine Videokonferenz statt. Im nächsten Quartal gibt es dagegen eine Aufführung in London und in Moskau nur eine Videokonferenz.

So leben wir in Badoo.

Wir laden Sie ein, einen neuen Teil der organisatorischen Erfahrungen anderer bei Saint TeamLead Conf auszuspionieren . Das Programm beinhaltet Reden von sehr bekannten Unternehmen: Sberbank-Technologies, Avito, JetBrains, Spotify ... ja, sie sind alle cool!

Dieser Bericht ist einer von Dutzenden von Berichten. Wenn Sie nicht warten möchten, bis wir sie entschlüsseln und auf Habré veröffentlichen können, sehen Sie sich die Konferenz- Wiedergabeliste auf unserem YouTube-Kanal an .

Abonnieren Sie die spezielle Mailingliste, um nichts zu verpassen. Wir versuchen, Zeit zu sparen und nützliche Neuigkeiten zu veröffentlichen: Transkriptionsberichte, aktuelle Videos, ausgewählte Berichte über zukünftige Konferenzen.