Wenn sie in Artikeln und Berichten über Fälle im Teammanagement sprechen, beschränken sie sich oft darauf, zu sagen, was falsch war und wie sie die Situation verändert haben. Aber diesmal haben wir die einmalige Gelegenheit herauszufinden, wie das Team weiter gelebt hat und wie alles endete - tatsächlich endete es nicht, sondern ging weiter.

Hier ist eine Fortsetzung einer Geschichte mit dem Titel " Wie man einen skalierbaren Sclim überlebt und die Codequalitätskontrolle aufrechterhält " über die agile Transformation in ivi. Bei TeamLead Conf erklärte der technische Direktor des Unternehmens, Jewgeni Rossinsky ( eross ), warum es möglicherweise erforderlich sein könnte, die gesamte Reorganisation des Teams zurückzusetzen, um nicht zu streiten und Entwicklern zu helfen, sondern auch um die Geschäftseffizienz aufrechtzuerhalten und zu steigern.

Unternehmenskontext

ivi - das größte legale Internetkino mit einem Publikum von 48 Millionen Nutzern, die zusammen monatlich 70 Millionen Stunden verbringen. Ivi verfügt über 62.000 Inhaltseinheiten, die von verschiedenen Geräten und immer in ausgezeichneter Qualität verfügbar sind.

So kam es, dass Eugene an dem Tag, an dem Eugene bei TeamLead Conf mit diesem Bericht sprach, Geburtstag hatte. Vor 9 Jahren fand die erste Veröffentlichung der Webversion des Projekts statt, und nach 2 Tagen brachte die Stärke von Channel One eine große Anzahl von Benutzern zu ivi. Das Unternehmen glaubte sogar, es sei DDoS, konnte aber würdevoll standhalten.

In diesem Artikel geht es um die Einführung eines neuen Produkts - einen vollständigen Neustart aller Anwendungen.

Sehen Sie sich das Video an, um die unzensierte Version zu hören, oder lesen Sie das Protokoll des Berichts in der ersten Person.



Lassen Sie uns zunächst über die Technologien und Kompetenzen sprechen, mit denen das Ausmaß des Schadens verstanden wird.

Kompetenzen:

• Backend (Python, Golang, Java);
• Web (JavaScript, Node.js);
• Android (Java)
• iOS (Objective-C, Swift);
• SmartTV (JavaScript);
• Windows / XBox (C #);
• Sony PS (JavaScript).

Für jede dieser Kompetenzen hatten wir 2016 unser eigenes Team, d.h. iOS-Team, Android-Team usw. Es gab auch ein Backend-Team und separat ein Team von Produktmanagern, die neue Funktionen entwickelten.

Das Hauptproblem, aufgrund dessen eine Transformation erforderlich war, bestand darin, dass alle Plattformen unterschiedlich sind, einschließlich unterschiedlicher Rückstände und Prioritäten. Und wir wollten wirklich einen einzigen Informationsraum innerhalb unserer Anwendungen schaffen.

Es kam häufig vor, dass 4 Monate nach der Konzeption auf allen Plattformen ein komplexes Feature auftrat. Gleichzeitig wurde es nach 3 Tagen auf einer Plattform angezeigt und dann, abhängig von der Priorisierung der Rückstände, auf verschiedenen Plattformen mit unterschiedlichen Geschwindigkeiten eingeführt. Es stellte sich aus folgenden Gründen als monströs heraus:

• Für 4 Monate könnte das Feature bereits eine völlig andere Bedeutung bekommen und die Notwendigkeit dafür könnte verschwinden.
• Aufgrund von Kommunikationsproblemen, die in diesem Fall offensichtlich sind, haben die Benutzer Funktionen auf unterschiedliche Weise implementiert.

Da das Produkt über drei Monetarisierungsmodelle verfügt, die auf verschiedenen Plattformen mit unterschiedlicher Effizienz arbeiten, war die Priorisierung des Rückstands auf jeder Plattform unterschiedlich. Einige Funktionen könnten im Prinzip niemals auf separaten Plattformen implementiert werden.

Eine kurze Nacherzählung der Transformation

2017 haben wir das Konzept von Value Stream eingeführt - dies sind funktionsübergreifende Teams, die für bestimmte Geschäftsaufgaben verantwortlich sind. Um zu verstehen, was für ein spezifisches Geschäft unser Geschäft ist, haben wir etwa 25 bis 30 Mitarbeiter aus dem gesamten Unternehmen zusammengebracht, Coaches eingeladen, die sich mit flexiblen Methoden beschäftigen, und in zwei Tagen formuliert, was unser Wert sein sollte - Entwicklungsrichtungen.

Erhielt 5-6 Wertströme. Sie pflanzten diese Leute zusammen und gaben jedem einen Product Owner, der für diese bestimmte Richtung ertrinken würde (mehr Details hier ).

Wir kannten Schmerz, Blut, Tränen und Freude und erreichten sehr gute Indikatoren:

• Synchrones Entladen identischer Funktionen auf verschiedenen Plattformen .
• Eine mehrfache Verkürzung der Markteinführungszeit . Die Veröffentlichung vieler Funktionen beruhte nur auf dem Release-Verwaltungszyklus auf jeder Plattform, da Apple beispielsweise nicht zulässt, dass jede Funktion einzeln entladen wird. Daher werden die Funktionen gruppiert und im Durchschnitt alle zwei Wochen veröffentlicht.
• Beseitigung von "Engpässen" , die sowohl Produktbesitzer als auch technische Manager und Teamleiter waren.
• Entwickler begannen zu verstehen, warum sie neue Funktionen "sägen".

Wir haben das Jahr sehr gut überstanden - 2017 hat sich der Umsatz fast verdoppelt .

Aber das war nicht genug und das Leben Ende 2017 - Anfang 2018 hat uns überrascht.

Warum brauchten Sie ein neues Produkt?

Das Geschäft hat neue Ziele gesetzt. Die Überraschung war, dass die Entwicklung einer Software für etwas existiert. Nur wenige schreiben aus altruistischen Gründen Code. Damit das Unternehmen seine Existenz rechtfertigen kann, setzen sich seine Eigentümer und Aktionäre bestimmte Ziele, die das Team erfüllen muss.

Unsere Aktionäre sagen nicht, wie es geht, sie sagen, was sie erreichen wollen. Wie - das Team muss entscheiden.

Das Team stand vor der Aufgabe, herauszufinden, wie man mehr verdienen kann . Wir führten ein Brainstorming durch, und die Lebensmittelabteilung kam zusammen mit der technischen zu dem Schluss, dass wir, um ehrgeizige Ziele zu erreichen (durch Konvention, um die Größe des zahlenden Publikums zu verdoppeln), im Prinzip den Schwerpunkt vom freien Ansehen des Films auf das bezahlte verschieben müssen.

Fast alle vorgebrachten Hypothesen passen sehr schlecht in das Konzept des alten Produkts. Genauer gesagt, es passte überhaupt nicht - jeder Motivationsfluss bei Benutzerübergängen beruhte auf der Tatsache, dass dies auf einigen Plattformen implementiert ist, auf einigen nicht, es gibt einige Einschränkungen, andere dort. Unser Team ist 9 Jahre alt und wir haben viele Dinge angesammelt, die uns auf den Grund gezogen haben. In guter Weise war es notwendig, alles neu zu schreiben.

Mehrere qualitative und quantitative Studien haben die Probleme des alten Produkts gezeigt . Es stellte sich heraus, dass wir 2-3 Jahre hinter dem zurückbleiben, woran die weise Menschheit gedacht hat. Wenn es zum Beispiel vor ungefähr 5 Jahren auf Mobilgeräten modisch und modern war, ein Burger-Menü in die obere linke Ecke zu stellen, dann hörten die Leute mit dem Aufkommen großer Bildschirme auf, dorthin zu gelangen. Bis 2018 hatten wir wirklich ein Burger-Menü, und die Leute haben es irgendwie geschafft.

Der arme Benutzer gewöhnt sich an alles, aber das bedeutet nicht, dass Sie alles so lassen müssen, wie es ist.

Viele Frameworks mussten überarbeitet werden. Wir haben logische Fehler gefunden und wie in jedem langlebigen Code hatten wir viel alten, nicht sehr guten Code. Den Entwicklern hat es wirklich nicht gefallen.

Zum Beispiel ist es sehr schwierig, Entwickler einzustellen, die in Objective-C schreiben möchten. Wir sind alle von Mode beeinflusst und sogar faul - wenn es ein Tool gibt, mit dem Sie das Gleiche tun können, aber schneller und effizienter, möchten wir es nutzen. Und die Situation auf dem Arbeitsmarkt ist so, dass Sie in einer Zusammenfassung schreiben können: "Ich möchte in Swift schreiben", und selbst wenn Sie nicht wissen, wie man in Swift schreibt, werden Sie definitiv irgendwohin gelangen.

Damit musste etwas getan werden, und dies ist eines der Probleme, die die Entwicklung behindern. Daher mussten wir veraltete Komponenten neu schreiben und moderne Frameworks implementieren.

Ziele

Wir wollten:

• Erstellen Sie ein neues Produkt mit einem einzigen Design.
• Machen Sie unser gutes Empfehlungssystem für die Ausgabe aller Blöcke in unserem Produkt verantwortlich.
• Korrigieren Sie logische Schnittstellenfehler.
• Bereinigen Sie den Code.
• Migrieren Sie zu einem neuen Statistiksystem.
• Implementieren Sie ein Design-System.

Alle Herausforderungen sind sehr ehrgeizig, insbesondere das Designsystem, da es nur sehr wenige Designsysteme gibt, die plattformübergreifend arbeiten und vom Programmcode getrennt sind. Sie produzieren hauptsächlich die JS-Engine, die auf verschiedenen Plattformen verwendet wird. Tatsächlich befindet sich der Mechanismus zum Übertragen von Informationen darüber, wie das Produkt aussehen soll, im Code.

Wir können dies nicht sehr gut machen, da wir mit Videos arbeiten und für die Arbeit mit Videos mehr oder weniger native Tools erforderlich sind. Wenn Sie keine nativen Tools verwenden, tritt bei Betriebssystemversionen immer ein Rückstand von 1 bis 2 Schritten auf. Alle universellen Frameworks wie Xamarin müssen nach der Veröffentlichung noch eingeholt werden. Und wir sind sehr gierig, bevor wir vorgestellt wurden - sowohl Google als auch Apple empfehlen uns, nur weil wir native Tools verwenden.

Native Tools helfen dabei, qualitativ hochwertige, gute und schnelle Anwendungen zu erstellen. Bei Videos ist dies einfach notwendig.

Suche nach Managementlösungen

Nachdem wir die Ziele festgelegt hatten, haben wir uns auf ihre schnelle Erreichung eingestellt. Ich möchte Sie daran erinnern, dass wir in Value Stream unterteilt waren, verschiedene Entwickler in verschiedenen Teams saßen und wir mit der harten Realität konfrontiert waren - was tun?

Es scheint, dass wir ein System hatten, an das wir uns schon seit einiger Zeit gewöhnt haben, und jetzt haben sich die Spielregeln geändert.

Natürlich haben wir zunächst versucht, wie zuvor mit Value Stream zu arbeiten und dabei die folgenden logischen Berechnungen zu akzeptieren: „Lassen Sie Value Stream, das sich in einer solchen Richtung des Geschäfts engagiert, alle mit diesen Bereichen verbundenen Komponenten umgestalten.“

Oh wie falsch wir waren! Ungefähr einen Monat später stellte sich heraus, dass Sie, um den Kern jeder Anwendung neu zu schreiben, in alle Bereiche der Geschäftsregeln einsteigen müssen.

Es war sehr schwierig, den Verantwortungsbereich von Value Stream zu unterscheiden, der welche Rolle spielt, wenn Menschen auf verschiedenen Etagen in verschiedenen Räumen sitzen.

Was am traurigsten ist, ist aufgrund der unterschiedlichen Sprachen und Funktionen von Entwicklungsplattformen der Effekt der Zusammenarbeit vollständig verschwunden.

Im Rahmen von Value Stream sehen iOS- und Android-Entwickler die gleiche Funktion, und sie haben etwas zu besprechen, sie diskutieren Geschäftslogik. Und wenn jeder von ihnen ein Low-Level-Framework sägt, das schwach mit dem korreliert, was später im Endprodukt sein wird, verschwindet die Synchronisation vollständig.

Es gab Leute, die sich im Prinzip von der Bedeutung des Geschehens losgesagt haben. Die Timlids waren die ersten, die entmutigt wurden, weil sie als verantwortungsbewusste Menschen über Mitarbeiter der Menschheit stolpern und nicht glauben mussten, um zum Schoß der wahren Kirche zurückzukehren, damit sie einen angemessenen Code in die richtige Richtung schreiben konnten. Es stellte sich sehr schlecht heraus.

Nach anderthalb Monaten stellte sich heraus, dass Value Streams für fertige Produkte hervorragend funktionieren, aber im Allgemeinen unwirksam sind, wenn ein Produkt von Grund auf neu geschrieben werden muss.

Wie alle einfachen Wahrheiten verstehen Sie sie erst, nachdem Sie barfuß durch den Rechen gegangen sind, und lassen sogar den Strom durch den Rechen fließen.

Alles Neue ist alt vergessen.

Wir werden alles so zurückgeben, wie es war

Nach der triumphalen agilen Transformation haben wir beschlossen, alles so zu machen, wie es 2016 war, weil das Recht auf Demokratie verdient werden muss.

Damit jeder das Wahlrecht hat und dieses Recht beansprucht und genutzt wird, müssen die Regeln und das Ökosystem, in dem es funktionieren wird, festgelegt werden.

Wenn es kein Ökosystem gibt, müssen einige Dinge autoritär getan werden, damit die Regeln irgendwie gebildet werden.

Hat folgendes getan:

• Sie brachten die Menschen wieder unter die Fittiche der Timlids und richteten sie von der merkmalsorientierten Programmierung auf die normale Programmierung um.
• Produktmanager wurden Flow-Benutzern zugewiesen. In unserem Fall ist dies Herunterladen, Autorisieren usw.
• Wir haben versucht, alle Anforderungen an ein neues Produkt zu formalisieren, auf die wir uns zu Beginn der Entwicklung geeinigt haben.

Alles scheint logisch zu sein, aber wie vor zwei Jahren hatten wir die gleichen Probleme.

Es wird nicht funktionieren, wieder Probleme in der Organisation

Die Hauptprobleme vor zwei Jahren waren: Zentralisierung und Entscheidungsfindung.

Autoritarismus führt zur Entstehung von "Engpässen" - Teamleitern, technischen Managern und Produktmanagern, die keine Zeit haben, Funktionen für die Entwicklung zu vermitteln. Ein Produkt, das vor 8 Jahren gesägt wurde, ist in wenigen Monaten schwer zu überdenken. Es ist nicht cool, wenn 80% des Konzepts fertig sind und 20% (genau dort, wo sich das Fruchtfleisch befindet) noch nicht da sind. Dies ärgerte und verärgerte das Team sehr.

Als die Entwickler offiziell zum Management der Teamleiter zurückkehrten, gab es viel weniger Live-Kommunikation mit Produktmanagern und es bestand die Notwendigkeit, TK zu formalisieren. Was durch verbale Kommunikation perfekt ersetzt wurde, verwandelte sich wieder in Formalismus - er kehrte zurück, niemand gab ihn zurück. Aber die Ingenieure sind so angeordnet, sie werden am Institut unterrichtet: Es gibt eine Problemstellung - sie muss gelöst werden, es gibt keine Problemstellung - die Welt stürzt ab, der Algorithmus funktioniert nicht.

Dabei wurden sowohl logische als auch architektonische Fehler und Fehlkalkulationen entdeckt. Stellen Sie sich vor, Sie erstellen mehrere Jahre lang Code, und die ganze Zeit träumen Sie davon, ihn umzugestalten. Wenn sich die Gelegenheit ergibt, stellt sich heraus, dass alle Ideen und Konzepte nicht sehr gut sind oder überhaupt nicht funktionieren. Der Traum erweist sich als falsch.

Gleichzeitig hört ein Unternehmen, wie es normalerweise bei der Bewertung von Fristen der Fall ist, eine Sache, die Entwicklung eine andere. Darüber hinaus teilt sich das Geschäft immer noch in zwei Teile, und dann beginnt es, Druck auf die Fristen auszuüben und möchte gestern ein neues Produkt bekommen. Um Stunde X stellt sich heraus, dass die Entwicklung glaubt, dass es noch 3-4 Monate sind, und das Unternehmen hat gestern auf die Veröffentlichung gewartet. Jeder ist verärgert, das Team beginnt zu reißen.

Was hast du getan

Wir haben eine groß angelegte Retrospektive über unser Leben durchgeführt und gezeigt, was Entwickler und Teamleiter am meisten beunruhigt.

Die Notwendigkeit, die Funktionalität zu wiederholen , und oft dreimal. Um ehrlich zu sein, befand sich genau die Hälfte der Probleme auf der Seite der Problemstellung, die zweite Hälfte auf der Implementierungsseite. Die Entwickler waren jedoch natürlich fest davon überzeugt, dass das gesamte Problem in der Formulierung des Problems lag. Auf der Seite der Task Direktoren war das gleiche. Niemand will sich für falsch oder schuldig halten, jeder sagt, dass das Problem auf der anderen Seite liegt.

Unterstützung für die alte Anwendung . Ein Dienst mit einem Publikum von mehreren Millionen Dollar kann nicht einfach aufgegeben werden. Parallel zum Schreiben eines neuen Produkts muss etwas mit dem alten getan werden. Das ist furchtbar nervig!

Implementierung eines Designsystems. Wir sind sehr stolz auf diese Richtung: Sie ermöglicht es Ihnen wirklich, sehr komplexe Dinge schnell zu erledigen, und das Produkt sieht einheitlich aus. Aber ich musste Designer darin schulen, was JSON ist, und Designer mussten Entwicklern vermitteln, dass das Erscheinungsbild ebenfalls sehr wichtig ist. Viele Kopien wurden darüber gebrochen.

Mangel an Informationen und Antworten auf die Frage „Warum?“. Ohne Value Stream verstehen einige Entwickler nicht mehr, warum sie etwas tun. Die Informationsübertragung wurde unterbrochen, und die Ursache-Wirkungs-Beziehung war teilweise verschwunden. Diejenigen, die die Kraft fanden zu fragen, warum wir das taten, waren glücklich. Nicht sehr kommunikative Leute dachten, dass Idioten irgendwo oben sitzen und Dinge erfinden, die nicht entworfen werden können.

Fehlende Dokumentation zu neuen Geschäftsregeln. Aufgrund des Mangels an Informationen fehlte eine Dokumentation, in der dargelegt wurde, wie die Anwendung ordnungsgemäß funktionieren sollte.

Jeder probierte die Rolle eines Architekten aus und nicht jeder mochte es. Für mich war es die größte Entdeckung. Zum ersten Mal schätzten die Teamleiter die Fristen für die Bearbeitung von Anträgen auf etwa anderthalb Jahre, was wertlos ist. Dies geschah, weil jeder Teamleiter alle Teile des Systems durch sich selbst hindurchlassen wollte, das heißt, er wollte die Anwendungsarchitektur wirklich nicht delegieren und zerlegen, sondern alles für sich behalten.

Mit diesem Ansatz benötigen Sie wirklich anderthalb Jahre, um die Architektur zu überarbeiten. Aber mit solchen Begriffen in dieser Welt gibt es nichts zu tun. Nach langen Diskussionen kamen wir daher zu dem Schluss, dass die architektonischen Funktionen des Teamleiters an bestimmte erfahrene Kämpfer aus der Entwicklung in bestimmten Schlüsselbereichen delegiert werden sollten, die unter anderem teilnehmen und sich wie ein Architekt fühlen wollten.

Es stellte sich als interessante Tatsache heraus - es stellt sich heraus, dass es unangenehm ist, Verantwortung zu übernehmen.

Sich selbst als Architekt oder Teamleiter zu bezeichnen und Teamleiter zu sein, sind zwei große Unterschiede. Es stellte sich heraus, dass nicht jeder bereit war zu akzeptieren, dass dies nur in Ihrer Verantwortung liegt, wenn Sie aufpassen und eine Bekehrung verschwenden.

Ich war naiv und dachte aus irgendeinem Grund, dass jeder in unserem Team solchen Mut besaß. Ich habe vergessen, dass man vor Timlid reifen und ein wenig erwachsen werden muss. Im Laufe des Jahres gingen viele von uns diese Richtung durch, und einige erkannten, dass sie nicht erwachsen werden wollten, sondern in der Breite und keine Teamleiter sein wollten.

So beheben Sie die Situation

Neben der Zerlegung und Differenzierung der Rollen von Timlid in verschiedene architektonische Bereiche haben wir die sogenannten Flying Retaliation Units (VOC) gebildet und Qualitätskontrollspezialisten (QS) für sie gewonnen. Erstens waren sie freier als alle anderen - es gibt noch kein neues Produkt, und Sie können jetzt Testfall und Testsuite für nachfolgende Regressionen schreiben.

Dann stellte sich heraus, dass die Geschäftsregeln noch nicht vollständig formuliert sind und das Unternehmen nicht viele Leute hat, die wissen, wie die neue Anwendung funktionieren sollte.

Wir haben die folgenden Aufgaben für die Qualitätssicherung festgelegt:

• Wir benötigen eine aktuelle Dokumentation zu Geschäftsregeln und der Logik, in der die Anwendung arbeitet.
• Es werden Anhänger der neuen Geschäftslogik benötigt, nicht nur Manager und technische Manager.

Da wir eine neue Anwendung haben und diese erneut ausführen müssen, benötigen wir Mitarbeiter, die Fragen stellen können wie: Wie wird mit einem solchen Fehler umgegangen, wie sollte sich die Anwendung in einer solchen Situation verhalten?Ich wiederhole, die Hauptfälle wurden beschrieben, aber der Teufel steckt im Detail - die gleichen 20% mussten geschlossen werden.

Wir haben begonnen, dynamische Mikrobefehle zu erstellen. Trotz der Tatsache, dass Menschen nirgendwo transplantiert wurden, sondern an ein Produkt einer bestimmten Richtung gebunden waren, war eine Person aus der Qualitätssicherung, die methodisch an der Projektarbeit beteiligt war, verantwortlich für:

• Sammeln von Fragen von Entwicklern, Erstellen von Fragebögen;
• Organisation und Aufzeichnung von Sitzungen;
• Formalisierung der Dokumentation;
• Schreiben von Testfällen und Testsuiten im Voraus.

, , , . , , , , . , SmartTV 6-7 , , . -, .

. , .

« » , , .

?

2018 , — , , . . , , . «, ,» — .

, , 2016 Value Stream. , . , , . .

, , .

, , . , , , 2018 4 . , , , .

.

.

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

: , , , . . .

Das TeamLead Conf- Programm in St. Petersburg ist fast fertig. Lassen Sie uns ein paar Läufe machen, den letzten Schliff hinzufügen, um alle geplanten Themen zu enthüllen, und über die Berichte in Blöcken sprechen. Im Moment können Sie die Liste der Berichte unabhängig auswerten und den 23. und 24. September für das Pumpen von Teamkollegenfähigkeiten reservieren .