Wenn ein Produkt groß ist, gehen Entwickler bis zum Äußersten:
- Code ist zu schön - langsame Veröffentlichungen,
- zu viel Aufmerksamkeit für Prozesse - wenig Aufmerksamkeit für Entwicklung,
- schnelles Senden neuer Funktionen in der Produktion - zu schlechter Code,
- zu viel Aufmerksamkeit für Autotests - es ist schwierig, Änderungen vorzunehmen,
- Bedenken hinsichtlich der Geschwindigkeit der Benutzeroberfläche - Vermeidung neuer Funktionen,
- Verbesserung der Benutzeroberfläche - wenig Aufmerksamkeit für die Codearchitektur.
In dem Bericht habe ich darüber gesprochen, wie man diese Extreme vermeidet und erfolgreiche Teamarbeit erreicht.
- Ich möchte darüber sprechen, wie man in großen Teams lebt. Ein großes Team ist, wenn noch mehr Leute da sind als in diesem Raum.
Und ich möchte, dass sie so reibungslos funktionieren wie diese Leute im GIF:
Ich habe kein sehr großes Team, aber ich habe nur ein wenig ausspioniert, was mit den großen Teams im gesamten Unternehmen passiert, und ich möchte dies nur mit Ihnen teilen.
Um sich die Skala vorzustellen, muss man ganz offensichtliche Dinge erzählen. Das Yandex ist etwas mehr als eine Suchseite. Es gibt viele von uns, mehr als 10 Tausend
Und unter diesen „vielen“ sind die meisten Entwickler. Wir stellen viele verschiedene Produkte her, nicht nur für das Web. Es geht um Waren, um Autos, um Essen, um alle Arten von Eisenstücken, um künstliche Intelligenz. Und die Entwickler sind daran beteiligt. Auch wenn es sich anscheinend um Autos oder um Essen handelt.
Wir haben viele Dienstleistungen. Sie passen nicht auf die Folie. Ich hoffe, ich habe Sie überzeugt, dass Yandex sehr groß ist. Große Dinge sind schwer zu handhaben.
Ein wichtiger Punkt. Was ich weiterhin sagen werde, ist erstens eine sehr starke Vereinfachung; Zweitens habe ich Gedächtnislücken, also werde ich etwas interpretieren. drittens, einige Dinge, mit denen ich absichtlich ein wenig herumfummle, um die Kohärenz der Geschichte usw. zu gewährleisten. Allgemeine Ideen werden in der Zwischenzeit wahr sein.
Ich werde von sehr alten Zeiten beginnen. Ich bin dann gerade zu Yandex gekommen. Damals war es ganz anders arrangiert als heute. Die Aufteilung erfolgte nach Spezialisierung - cool für Entwickler. Es sah ungefähr so aus. Das Unternehmen war strukturell in Manager aufgeteilt, sie haben etwas untereinander getan. Es gab andere Spezialisierungen. Tatsächlich gab es zu dieser Zeit keine Designer, aber es vermittelt die Bedeutung. Und natürlich gab es Entwickler. Innerhalb dieser Struktur wurde es dann in noch kleinere Fragmente geschnitten.
Die Entwickler waren mit Sägen oder mit einer Zange. Es gab Typen in Mützen mit Smoothies, Typen in Helmen waren härter, Designer, die damals nicht da waren, und Manager, die es für alle bekamen. Sie gingen deshalb vorbereitet.
Wenn Sie sich mit dieser Geschichte befassen, dann war innerhalb der Hierarchie so etwas. Da war ein Typ im härtesten Helm, der alle Beulen bekam. Er hatte subtile Manager unter seinem Kommando, dann weniger strenge. Ich übertreibe, aber die Idee ist klar. Und für jede Spezialisierung funktionierte dieselbe Hierarchie.
Jungs mit Smoothies in Kappen haben genauso funktioniert und es macht Spaß. Sie sind Entwickler, Sie gehorchen einem anderen Entwickler, er versteht, was Sie tun, er lobt Sie für etwas, das er selbst mag. Großartig.
Angenommen, es kommt eine Idee zu einem Produkt. Und er hat nur andere untergeordnete Manager - wenn er Glück hat und zumindest jemanden, der untergeordnet ist. Der Rest gehorcht ihm überhaupt nicht, aber irgendwie muss die Idee verwirklicht werden.
Und er sagt: „Genosse Chefdesigner, ich habe eine coole Idee. Ich brauche einen Designer. “ Er wird antworten: „Erstens ist Ihre Idee seltsam, und zweitens sind alle Designer mit mir beschäftigt. Komm zu Q5. “
Wenn der Manager ihm in diesem Moment glaubt, wird er nichts haben. Wenn er hartnäckig, talentiert und bereit ist, alle Schwierigkeiten zu überwinden, wird er diesen Chefdesigner vielleicht überzeugen. Er wird sagen - okay, in zwei Monaten wirst du diesen Kerl nehmen, er muss frei sein. Alter, natürlich wird die Frist voll sein und in vier Monaten veröffentlicht, aber zumindest wird es eine Chance für die Entwicklung des Prozesses geben.
Dann geht dieser Manager zum Hauptentwickler und sagt: „Ich habe ein cooles Design, eine großartige Idee. Ich brauche ein Backend. “ Und das alles wird weitergehen: "Der Backender ist beschäftigt, Sie haben eine Idee, das Design ist schlecht."
Am Ende kann er sich ein Entwicklungsteam zulegen und etwas unternehmen. Einerseits bleibt auf diese Weise nur die coolste Idee erhalten, andererseits ist es wirklich schwierig, etwas zu tun.
Aber für den Entwickler ist das cool. Entwickler werden von anderen Entwicklern bewertet. Entwickler lieben natürlich alles Technische. Und über das Lebensmittelgeschäft lassen Sie den Manager zunächst überzeugen, dass dies eine coole Idee ist. Und aufgrund der Tatsache, dass alle Entwickler in derselben Struktur miteinander kommunizieren, jeder gemeinsame Parteien hat, ist der Austausch von technischem Fachwissen sehr gut etabliert. Mit Produktkompetenz sind die Dinge nicht sehr cool, aber wen interessiert das? Und viel Forschung, weil es für den Fan ist. Wird von anderen Entwicklern bewertet, die ebenfalls ein Fan sind. Sie können High-Tech-Sachen erfinden.
Offensichtlich hat dieser Ansatz ein Problem. Entwickler sind nicht sehr besorgt darüber, was mit dem Produkt zu tun hat, da sie den Managern nicht gehorchen. Helmmanager werden verspottet, wenn etwas schief geht, aber sie haben keinen besonderen Einfluss auf Entwickler. Und das Produkt wiederum ist ziemlich schwer zu ändern. Sie können in der Tat nur überzeugen, überzeugen und irgendwie tanzen, um zu beweisen, dass ihre Idee cool ist. Dann wird der Entwickler daran glauben und natürlich alles verletzen.
Es stellt sich jedoch heraus, dass man aus dieser großen Reihe von Entwicklern versehentlich jemanden schnappen muss, jeder etwas Interessantes tut, aber es ist problematisch, eine große und komplexe, ständig interagierende Sache zusammenzustellen.
In der Zwischenzeit passiert und wächst das Unternehmen zweimal im Jahr. Und du musst etwas tun. Wie Arkady Volozh sagte, ist die Führung eines Unternehmens wie das Braten eines Fleischbällchens. Es muss ständig umgedreht werden.
Die Struktur des Unternehmens ändert sich. Anstatt alle nach Spezialisierung zu teilen, nach Produkten zu teilen. Und der Manager wird ein viel wichtigerer Typ.
Es stellt sich ungefähr ein solches Schema heraus, wenn es stark vereinfacht und stark übertrieben ist. Wir haben ein großes Stück des Produkts, das in kleinere Teile zerfällt, und für jedes Teil sticht ein voll ausgestattetes Team hervor. Es gibt Designer, Entwickler, Manager, die alle dieses Produkt herstellen.
Es scheint, dass das Problem behandelt wurde, aber es gibt ein neues Problem. Teams können recht klein sein, und es wird natürlich ein Front-End, ein Back-End, einen Designer, einen halben Analysten und jemand anderen geben. Sie sind kitschig und niemand kann über ihr Fachgebiet sprechen, und es scheint, dass dies nicht erforderlich ist. Sie sägen ihr Projekt, aber all die Erfindungen, die sie dabei erhalten, haben sie niemanden zu vermitteln, sie haben niemanden zu fragen, wie sie es besser machen können. Sie wissen nicht, was sie hinter der angrenzenden Wand tun, und vielleicht tun sie dasselbe. Darüber hinaus machen sie das natürlich auch direkt.
Der Manager scheint mehr Macht zu haben, aber er versteht nicht alle Feinheiten der Entwicklung so gut. Ein talentierter Entwickler kann ihm auf Wunsch sagen, dass ohne eine vollständige Neufassung des Projekts nirgendwo etwas zu finden ist. Und was ist die nächste Wahl des Managers? Entweder wird er ihm glauben oder er wird es ihm verbieten, jeder wird unzufrieden sein. Im Allgemeinen gibt es ein Problem.
Ich möchte irgendwie alles in Bezug auf das Produkt ausbalancieren. Zum Beispiel hat ein Produkt ein Team und glaubt zum Beispiel, dass schöner Code wichtig ist. Und während sie diesen Code auf das Ideal verfeinern, ist es klar, dass Veröffentlichungen verschoben werden. Nicht cool. Oder das Team denkt: "Okay, wenn es nur coole Prozesse gäbe und der Code irgendwie passieren würde." In der Tat, nein, es passiert nicht. Es ist auch notwendig, dass dies von jemandem beobachtet wird.
Oder das Team sagt: „Wir müssen sehr schnell vorankommen, es ist wichtig für uns, dass wir jeden Tag Features rollen“, aber in diesem Moment gerät die Qualität des Codes aus dem Fokus. Oder das Team sagt: „Okay, als wir das letzte Mal um den Rechen herumgingen, haben wir erkannt, dass Qualität wichtig ist. Lassen Sie uns alles mit Autotests abdecken. “ Autotests werden für jede Funktion geschrieben, aber jetzt müssen diese Tests für jede Poolanforderung ausgeführt werden. Die Fertigstellung dauert lange und alles wird langsam.
Oder: „Wir wissen, dass unsere Benutzer, wenn die Benutzeroberfläche langsam ist, gehen. Lassen Sie uns die Schnittstellen schnell machen. “ Dann stellt sich jedoch heraus, dass jede neue Funktion ein zusätzlicher Code ist, der über das Netzwerk übertragen und ausgeführt werden muss, und die Schnittstelle verlangsamt. "Dann machen wir keine neuen Funktionen - alles wird schneller funktionieren." Oder: „Der Benutzer liebt es, wenn er schön ist. Lass es uns schön machen. “ Aber es spielt keine Rolle, was sich darin befindet.
Auf der Suche nach diesem Gleichgewicht stellt sich heraus, dass etwas erneut geändert werden muss. Inzwischen wächst das Team wieder dramatisch.
Wie wird das normalerweise gelöst? Nimm ein Schlagwort. Wir haben es auch genommen. Wir haben ein ziemlich häufiges Gedränge, aber mit unseren eigenen Erfindungen. Was sagt es? Es heißt, dass wir die Teams der Mitarbeiter kühlen sollen, damit jeder für das Endergebnis verantwortlich ist. Es gibt alle notwendigen Fachkenntnisse. Lassen Sie dieses Team auswählen, welche Aufgaben zuerst ausgeführt werden sollen und welche Prozesse darin enthalten sein sollen. Im Allgemeinen ist ein Produkt wichtiger als Prozesse. Das ist alles Klingt nach gut. Es scheint sogar einen Teil der Probleme zu lösen.
Trotzdem gibt es ein Problem. Beispielsweise wird davon ausgegangen, dass sich solche Scrum-Teams ständig an das anpassen, was um sie herum geschieht, sich ständig ändern (ihre Zusammensetzung ändert sich, sie können sich ständig bilden, auflösen), und im Prinzip gibt es keinen gemeinsamen Ort, an dem die Entwicklungshistorie des Mitarbeiters aggregiert wird.
Das heißt, es gibt eine Art Entwickler und er hat einige Stärken, er brennt irgendwo. Und so geht er in ein neues Scrum-Team, und sie kennen diese Stärken nicht und setzen sie nicht genau dort ein. Und im Gegenteil, vielleicht hält er in etwas nicht durch, es gibt niemanden, der davon weiß, dafür sorgt, dass er darin gepumpt wird, und dafür sorgt, dass das Projekt nicht unter der Tatsache leidet, dass er dort kein Fachwissen hat.
Und es gibt Lösungen, die wir jetzt versuchen, in einem separaten Teil des Unternehmens anzuwenden und zu sehen, was passiert. Die Idee ist wie folgt. Es gibt eine ziemlich stabile Struktur, in der es Verbindungen zwischen dem Entwickler und seinem Leiter, auch dem Entwickler, gibt. Alles ist wie am Anfang, wenn der Leiter versteht, was Sie tun, Interessen mit Ihnen teilt, Ihnen Ratschläge geben kann, wie Sie effizienter arbeiten und Ihnen irgendwo helfen können. Diese Links werden seit mehreren Jahren lange gepflegt.
Um den Anforderungen des Produkts gerecht zu werden, werden zusammen mit einer solch konstanten stabilen Struktur immer noch schnelle virtuelle Scrum-Teams für jedes Produkt und sogar für jeden einzelnen Aspekt des Produkts gebildet. Jetzt erzähle ich Ihnen mehr darüber.
Die Teams sind vorübergehend, schnell und können sich auf einige der wichtigsten Dinge konzentrieren.
Es sieht ungefähr so aus. Hier haben wir ein kleines Stück, zum Beispiel das Web. Und drinnen, wenn Sie schauen, eine ganze Reihe von Leuten, die dieses Netz sägen.
So kommt es zum Ausgleich der ganzen Geschichte. Es gibt grüne Typen, die dafür verantwortlich sind, dass die Schnittstellen schnell sind. Und alles, was sie interessiert, ist, dass nach Geschwindigkeitsmetriken alles so cool wie möglich sein sollte. Lass alles andere so sein, wie du willst. Aber es gibt auch andere Typen, denen die Geschwindigkeit im Prinzip nicht so wichtig ist, aber es ist wichtig, dass wir für einige Zeit eine Reihe neuer cooler Funktionen für den Benutzer in der Produktion eingeführt haben. Und jetzt ist es unmöglich, dass die Jungs sagen: „Geschwindigkeit ist am wichtigsten. Lass nichts laufen. “ Denn für dieses Team ist dies grundsätzlich inakzeptabel.
Im Gegenteil, das Team, das für die Funktionen verantwortlich ist, kann nicht mehr eine Menge neuen Codes werfen und sagen: „Also mussten wir die Funktionen starten, alles wurde langsamer, aber wir haben die Funktionen gestartet.“ Sie werden sich einig sein, sich irgendwie gegenseitig helfen und am Ende wird alles gut. Blaue Jungs schreiben hektisch und ständig Tests. Und sie haben alles mit Tests abgedeckt, und jetzt gibt es viele Tests, und alle arbeiten langsam. Und die Jungs kümmern sich nicht darum, weil sie nur für die Berichterstattung verantwortlich sind.
Aber es ist großartig, dass es andere gibt, die sagen: "Aber es ist wichtig für uns, dass der Entwicklungsprozess insgesamt schnell ist. Von dem Moment an, in dem wir die Aufgabe festlegen, bis zu dem Moment, in dem unsere Benutzer sie verwenden, sollte dieser Zeitraum verkürzt werden. “ Und sie werden zustimmen, und alles wird gut. Sie helfen Leuten, die Tests schreiben, diese Tests schneller laufen zu lassen.
Jemand ist nur dafür verantwortlich, dass alles architektonisch cool ist. Darüber hinaus müssen sie möglicherweise nicht einmal darüber nachdenken, was gerade im Code passiert. Sie können denken in Bezug auf: "Und wohin sollte alles in anderthalb Jahren gehen?" - und jetzt auf diese Zukunft konzentrieren. Gleichzeitig wird es jemanden geben, der die runden Ecken strafft, die Schatten korrigiert und über die Animation nachdenkt, damit der Benutzer morgen glücklicher ist. Und wenn es eine solche Verteilung der Verantwortung gibt und sich jedes Team gegenseitig ergänzt, wird ein Gleichgewicht erzielt.
Das alles hat mehrere Rollen. Ich habe bereits etwas dazu gesagt, aber das ist trotzdem eine wichtige Sache. Jeder hat seinen direkten Vorgesetzten, der alles über ihn weiß und dafür sorgt, dass eine Person professionell wächst, persönlich wächst und glücklich ist. Gleichzeitig gibt es einen Leiter eines solchen Teams, der sagt, dass die Testabdeckung zunehmen sollte und alles andere weniger wichtig ist. Und wenn solche zwei Rollen gleichzeitig auftreten, wird es mehr oder weniger gut.
Und es gibt noch verschiedene verschiedene Dinge. In einer solchen Situation stellt sich heraus, dass für Entwickler, die an demselben Produkt beteiligt sind und aus verschiedenen Strukturen zu einem solchen virtuellen Team zusammengesetzt sind, viel mehr Aufmerksamkeit von verschiedenen Managern erhalten wird. Insgesamt ermöglicht diese Erfahrung, das Produkt besser zu machen ...
... und dann auf andere Produkte übertragen, die Strukturmanager betrachten, einige Erfindungen, die während der Arbeit dieses großen Teams entstanden sind. Oder umgekehrt, das heißt, diese Pfeile können in die entgegengesetzte Richtung gedreht werden, und dies gilt auch. Es wird zu Überlauf und Fachwissen, und der Weg ist irgendwie bequem, Teams wieder zu dem Produkt zusammenzusetzen, wo es jetzt wichtiger ist. Dadurch steigt die Aufmerksamkeit für verschiedene Produkte der erfahrensten Kameraden des Unternehmens.
OK, irgendwie vereinbart, wie alles funktionieren soll. Aber wenn wir einen strukturellen Chef und einen Chef über ein Produkt haben, wie kann man dann bewerten, ob alles gut gelaufen ist? Sergey Berezhnoy hat im Jahr vor dem vergangenen Samstag ausführlich darüber gesprochen. Ich werde die allgemeine Idee kurz wiederholen.
Die Entscheidung, ob eine bestimmte Person gut gearbeitet hat, wird zum einen im Vergleich zu anderen Teilnehmern des Prozesses und zum anderen von allen Beteiligten gemeinsam getroffen. Das heißt, sowohl sein struktureller Leiter, der überwacht, wie er sich über das langfristige Segment entwickelt, als auch die Person, die für kurzfristige Produktaufgaben verantwortlich ist und schätzt, nicht in Bezug auf die Tatsache, dass die Person sich bemüht hat und nachts nicht geschlafen hat, sondern in Bezug auf wie er seine Ziele wirklich erreicht hat. Und das ist so, dass es uns im Moment am fairsten erscheint. Wenn Sie auffallen, auch ohne besonders anstrengend - gutaussehend, loben wir Sie. Ein solches Gleichgewicht scheint uns gut zu funktionieren.
Zusätzliche Vorteile. Als wir uns einig waren, dass wir schnell einzelne Teams zusammenstellen und die Mitarbeiter für jeden spezifischen Bedarf neu gruppieren können, wird es wichtig, dass dieser Übergang so einfach wie möglich ist. Und das ist nur möglich, wenn alles gut beschrieben und dokumentiert ist. Eine solche Konstruktion selbst erzwingt die Notwendigkeit einer Dokumentation. Und beim Schreiben von Dokumentationen werden Produkte insgesamt automatisch besser. Dies ist der Vorteil in zwei Richtungen.
Neben dem Austausch von Fachwissen machen die Übergänge der Menschen verschiedene Produkte einander ähnlicher - sowohl hinsichtlich ihres Aussehens als auch hinsichtlich ihrer Anordnung im Inneren. Davon können Sie auch profitieren - Benutzer verstehen die Verwendung der Systeme, da sie in einem anderen Projekt nur eine ähnliche Funktion verwendet haben. Und natürlich können Sie die Best Practices endlich wiederverwenden.
Solche Teams konzentrieren sich auf jeden Aspekt einzeln: Entweder schreiben sie Tests oder sie sind für die Geschwindigkeit oder die Schönheit verantwortlich - aber sie können immer noch nicht punkten, was mit den Nachbarn passiert. Tatsache ist, dass ihr Leiter für Entwickler in anderen Teams verantwortlich ist und sie möglicherweise bald selbst in ein anderes Team wechseln. Es ist ihnen klar, dass es sie bedingt morgen betreffen wird. Bei der Fokussierung geht daher nicht die Verantwortung für alles als Ganzes verloren. Dadurch ist der Wechsel zwischen Projekten einfach genug.
Gleichzeitig haben die Menschen viele Wachstumschancen. Denn in einer Struktur, in der alles aus Granit geformt ist und sich nicht vermischt, kommen die Menschen irgendwann zu der Situation, dass sie bereits alles verstehen. Sie haben alles an diesem Projekt versucht und sind einfach mit dem Fluss gegangen. Sie müssen sich nicht jedes Mal plötzlich anstrengen. Und wenn sie ständig das Team wechseln müssen, ständig den Winkel der Fortsetzung ihrer Talente ändern müssen, wächst ihr Fachwissen automatisch, all dies stärkt das Gesamtsystem. Und es ist sowieso nicht langweilig. Es ist unwahrscheinlich, dass Sie damit nicht einverstanden sind.
, : « , , ?». , . , , . , - , , .
, . , , . ? , , , , .
,
. , - , , . , . , , — , , , : «, , . ».
, — . , , , , , ? . . , , , . , , . . , — , , , . -, , .
: — , , , , . — . .