🏟️ 🍞 🛁 So bringen Sie Nachbarn dazu, an ihrem Projekt oder InnerSource für eine Bank zu arbeiten ↕️ 👨‍👧‍👦 🧗🏻

Was ist Entwicklung in Sber? In den Augen eines gewöhnlichen IT-Spezialisten: „Hier wurde der Code geschrieben, gehen Sie dorthin!“ Aber das ist seit langem ein Stereotyp und sie sind nicht gut. Die rasante Entwicklung von Open Source zeigt, dass eine solche Kultur längst überholt ist und Unternehmen (wenn sie klug sind) den silobasierten Entwicklungsansatz lange überarbeitet haben. Die Veröffentlichung sämtlicher Bankensoftware in Open Source ist ein ~~wirksamer Weg, um Selbstmord zu begehen, eine~~ ziemlich kontroverse Entscheidung, und es ist eine Art Zwischenstufe erforderlich. Mit der Größe der Bank können wir unser internes Open Source starten, anstatt zu versuchen, zu überprüfen, was wir allen zeigen können, und vor Angst um unsere kleinen großen Geheimnisse zu zittern.

Was ist eine InnerSource?

Im Jahr 2000 beschrieb Tim O'Reilly den Begriff innere Quelle als einen möglichen Schritt in Richtung eines geschlossenen Unternehmens, das in die schöne Open-Source-Welt eintritt. Dies ist die Anwendung von Best Practices aus Open Source innerhalb des Unternehmens: von allgemeiner Offenheit und proaktiver gegenseitiger Unterstützung bis zur Bildung eines Marktes für die besten Lösungen. Das Unternehmen schreibt weiterhin proprietären Code, aber jeder seiner Mitarbeiter hat die Möglichkeit, jedes interne System zu verfeinern.

Die Vorteile von InnerSource können lange Zeit aufgelistet werden: Verkürzung der Markteinführungszeit, Verbesserung der Codequalität, Ersetzen externer Einstellungen durch interne Einstellungen, Verbesserung der teamübergreifenden Interaktion usw.

Die Schwierigkeit liegt in der Tatsache, dass alles, was oben beschrieben wurde, eine Änderung der Kommunikationskultur zwischen Mitarbeitern und Teams erfordert, und dies ist in einer Organisation, die seit Jahrzehnten anders arbeitet, nicht so einfach.

Natürlich ist die Sberbank nicht das einzige Unternehmen, das so etwas unternommen hat. Im Jahr 2015 wurde die InnerSource Commons- Community gegründet , die den Ansatz populär machte und die Lücke aus dem Begriff entfernte, um das Auffinden in Suchmaschinen zu erleichtern. Diese Community hat die Erfahrungen von Dutzenden von Unternehmen gesammelt, effektive Empfehlungen für die Implementierung von InnerSource in Ihrem Unternehmen abgegeben und veranstaltet zweimal im Jahr eine Konferenz zum Erfahrungsaustausch. Es gibt immer noch viele bekannte Technologieunternehmen, die dies ~~seit Pechenegs und Polovtsy getan haben,~~ bevor es zum Mainstream wurde.

In Russland ist unseres Wissens nur ein großer Einzelhändler auf dem Markt für Baudienstleistungen mit einem grünen Logo aktiv an der absichtlichen Implementierung von InnerSource beteiligt. Andere Unternehmen machen entweder keine Werbung für ihre Erfahrungen oder beteiligen sich nicht an der Community.

Jedes dieser Unternehmen hat seine eigenen positiven und negativen Erfahrungen. Die allgemeine Schlussfolgerung in diesem Fall ist sehr ähnlich: Die köstlichsten Vorteile können nur unter Beteiligung der überwiegenden Mehrheit erzielt werden.

Warum sollte ich es sammeln?

Fast jedes Gespräch über die Entwicklung in der Sberbank kommt auf die Frage, wie viele Programmierer Sie dort haben. Im ganzen Land haben wir mehr als zehntausend von ihnen, sie arbeiten aktiv an Tausenden von Komponenten, Systemen, Bibliotheken und ähnlichen. Infolge solcher Mengen müssen wir jeden Tag die Probleme des Managements von Abhängigkeiten von verwandten Teams, des Führungsverhältnisses und der Phasen von Merkur lösen.

Am Ende der Umfrage darüber, was die Ingenieure verletzt hat, wurde Ende 2018 in Sber beschlossen, ein Stammes-SberWorks zu schaffen, das alles im Zusammenhang mit den Prozessen und Werkzeugen für die Herstellung von Software in der Bank übernahm. Die Aufgaben und Ziele der Einheit folgten fast vollständig aus der Liste der gesammelten Schmerzen der Entwickler.

Ich schäme mich zuzugeben, dass der größte Schmerz Ende letzten Jahres das mangelnde Wissen darüber war, was die Nachbarn in der Werkstatt oder sogar im benachbarten Block im Freien tun. Aus diesem Grund haben wir nicht nur das Rad erfunden, sondern auch zwei (ersetzen Sie die gewünschte Anzahl) derselben Räder in verschiedenen Einheiten, sowohl in verschiedenen Städten als auch an benachbarten Arbeitsplätzen. Infolgedessen hatten unsere Teams große Ressourcen im Unternehmen, oft anstatt zum Mars zu fliegen, und liefen Rechen, ohne zu wissen, dass die benachbarten Rechen schon lange gesammelt worden waren.

Was tun mit all dem?

Zeit. Um die Probleme der Integration und der Suche nach den richtigen Personen zu lösen, erstellen Sie eine einzige API-Registrierung für alle Systeme der Bank mit einer großen Anzahl von Automatisierungen: Anrufgenerierung, Stubs für die nächste Version der API, Versionierung und dergleichen. Jetzt hat sich diese Registrierung in ein separates cooles Produkt verwandelt, das definitiv seines Artikels würdig ist, aber das ist eine andere Geschichte.

Zwei. Erstellen Sie eine Art "Regenschirm" mit einer einzigen Suchmaschine über alle Engineering-Tools (JIRA, Confluence, Bitbucket, Nexus) und kombinieren Sie die internen und externen Segmente (ja, berüchtigtes Alpha und Sigma).

Drei. Code, Rückstände und Artefakte, mit Ausnahme derjenigen, die das Öffnen der Sicherheit ausdrücklich verbieten, sollten allen Mitarbeitern des Unternehmens offen stehen.

Was wurde vorgeschlagen?

Bei der Kommunikation mit Entwicklern haben wir den Hauptgrund für ein derart geschlossenes Team in uns selbst identifiziert: die aktuellen Arten der Interaktion zwischen Produkten. Jede Diskussion über die Verfeinerung verwandter Systeme verlief nach einem von drei Szenarien.

"Warten"

Die häufigste Art der Interaktion. Das benachbarte Team legt eine Frist fest, die im Allgemeinen zu uns passt. Wir verschieben die Aufgabe tiefer in den Rückstand.
Im Allgemeinen eine akzeptable Option. Wenn die Kette jedoch von mehreren Teams abhängig ist und die Funktion wie gewohnt gestern in der Produktion angezeigt werden muss, müssen Sie nach Kompromissen suchen.

Kompromisse

Im Volksmund wird diese Methode als Eskalation bezeichnet. Nehmen Sie einen umfangreicheren Manager mit und kommen Sie zu einem benachbarten Team, um Ihre Aufgabe im Rückstand zu verschieben. Die Nachteile dieses Ansatzes liegen auf der Hand: Die meisten Teams können diese Karte nur wenige Male spielen. Danach verschlechtert sich die Beziehung zwischen den Teams.

„Temporärer permanenter Stummel“

Sägen Sie Ihr Frankenstein-Fahrrad mit Krücken und temporären Panzerfäusten, die die Funktionalität des Systems, auf dem die Sucht auftrat, duplizieren. Das traurigste, da es fast immer lange (wenn nicht für immer) bleibt, erzeugt eine Duplizierung des Codes, und das Team ist gezwungen, eine Krückenlösung zu unterstützen.

Wir haben einen vierten Weg vorgeschlagen. Verfeinern Sie die Codebasis des benachbarten Teams unter dessen sensibler Aufsicht, wodurch die Ausführungszeit verkürzt wird.

InnerSource

Nach Abschluss dieser Interaktion erhält das Team „A“ aus dem Bild wertvolles Feedback, fördert das Fachwissen in einem angrenzenden Bereich und reduziert die TTM seiner Verfeinerung. Mit Blick auf die Zukunft haben solche Interaktionen in der Bank schnell Tauschformate verschiedener Art erworben: Team „A“ schließt Aufgaben aus der technischen Verschuldung von Team „B“, während sie die erforderliche Verfeinerung durchführen.

Unser Weg

Ganz am Anfang schien es uns, dass wir Orte finden müssen, an denen InnerSource momentan maximal gefragt sein wird. Während wir darüber nachdachten, wie dies zu tun ist, ohne in einen Kreislauf endloser Umfragen zu geraten, würdigte die weise Führung die Idee und schlug vor, bis Ende des Jahres die hundertprozentige Bereitschaft von hundertprozentigen Sberbank-Systemen sicherzustellen. Wir spannten uns an, unser Manager fragte: "Was ist hundertprozentig?" Und die Anzahl der Systeme wurde um das 20-fache auf modern und / oder geschäftskritisch reduziert.

Danach begann der Routineprozess, diese Praxis in Teams zu verbreiten. Am Ende sahen wir eine überdachte Wiese mit einer Liste von Repositories und Regeln für die Arbeit mit jedem von ihnen.

Wir hatten eine Reihe von Besprechungen auf verschiedenen Ebenen, zuerst mit den technischen Leitern der Abteilungen, dann mit Teamleitern und Service-Eigentümern und schließlich mit Teammitgliedern. Wir haben Servicemitarbeiter gebeten, Informationen über das System selbst, den Entwicklungsstapel und Links zu Repositorys, Backlog und Dokumentation bereitzustellen. Bei den gleichen Treffen konnten wir Schmerzinformationen aus erster Hand erhalten: endloser Rückstand, Mangel an Ressourcen, alter Technologie-Stack (zum Beispiel Delphi).

Im Umlauf haben wir uns ein Verständnis für die starken und schwachen Glieder der Bank geschaffen. Es gab sehr ausgereifte Teams (zum Beispiel mobile Entwicklung), die bereits im industriellen Maßstab an den InnerSource-Prinzipien arbeiteten und eine Vielzahl von Kegeln und Ansätzen teilten. Es gab jedoch mehrere Teams (Hallo an die Pechenegs), die uns durch das Fehlen automatischer Tests, Protokollierung und Codeüberprüfungspraktiken entmutigten.

In unseren Teams gibt es eine große kulturelle Kluft zwischen "Meine Militäreinheit arbeitet an den richtigsten Aufgaben" und "Lass es uns cool zusammen machen". Die meisten Reaktionen waren ziemlich eintönig: "Wir wollen nicht den Code eines anderen nehmen und dann darauf antworten", "Wir wollen unseren Entwicklern nichts geben, weil sie gehen werden, aber es gibt sowieso keine Ressourcen". Zu diesem Zeitpunkt wurde beschlossen, mehr in Kultur als in Technologie zu investieren:

HR : Google, , 10 % .
PR : Microsoft, open source.
: , - Delphi GraphQL, 10 % , !
, API, JIRA- .

Mit einigen Fehlern haben wir gelernt, die in BitBucket stattfindenden Interaktionen zwischen Teams zu verfolgen, und haben Informationen erhalten, dass wir jeden Monat etwa 30-50 neue Autoren von InnerSource-Änderungen hinzugefügt haben. Die Zahl in Bezug auf die Anzahl der Entwickler in der Bank ist nicht sehr beeindruckend, aber dies sind nur Verbesserungen bei Geschäftsaufgaben.

Erwartungsgemäß wurden datengesteuerte Änderungen in verschiedenen Integrationsbussen und ETL-Diensten sehr beliebt. Dies lässt sich leicht durch die große Anzahl von Aufgaben und die geringen Kosten für Verbesserungen erklären.

Wir haben solche Verbesserungen am Beispiel unseres ESB sorgfältig untersucht. Für sie ist in naher Zukunft ein Übergang zu einer neuen Lösung geplant, sodass dem Team keine zusätzlichen Ressourcen zugewiesen wurden, während die Anfragen nach Überarbeitungen nur zunahmen. Bei InnerSource sahen die Jungs die Erlösung, zappelten schnell und stellten einen Priorizer zusammen, der Ihre Aufgabe so weit wie möglich erhöht, wenn Sie bereit sind, dies selbst zu tun. In Zahlen sieht es so aus: Von Oktober bis November wurden fast die Hälfte (101 von 209) Revisionsanträge von den Teams selbst bearbeitet. Dies führte zu einer Vervierfachung der Wartezeiten von 2,5 Monaten auf 2,5 Wochen.

Ganz unerwartet nahmen Designer aktiv teil, die gerne verwandten Teams helfen, wenn diese keine Ressourcen haben oder ein neues Aussehen benötigen. Wie sich herausstellte, gibt es einige Teams, die Designer zu 100% einsetzen können. Sie selbst sind kreativ und lieben es, den Fokus auf ein neues Produkt zu richten.

Nachwort

Die ersten Schritte zur Einführung von Transparenz und Interaktion zwischen Teams in einem Unternehmen, das es gewohnt ist, die Unternehmensgesetze einzuhalten, sind immer die schwierigsten. Wir können mit Sicherheit sagen, dass die ersten Wände durchbrochen wurden und eine ausreichende Anzahl erfolgreicher InnerSource-Geschichten gesammelt wurde, damit die Bewegung innerhalb der Sberbank an Dynamik gewinnt.

Die größte Herausforderung in der Zukunft besteht darin, das Goodhart-Gesetz zu umgehen . In jedem mittelständischen und großen Unternehmen muss die Effizienz gemessen werden: Überlegen Sie sich eine Zahl und lassen Sie sie wachsen. Auf einer Konferenz in Baltimore im vergangenen Herbst wurden mehrere Fälle vorgestellt, in denen die Festlegung von Zielen für die Bereitschaft von Teams und die Anzahl der Verbesserungen zur Sabotage von Metriken und zum Burnout von Bewegungsführern führten.

Wir glauben, dass die daraus resultierenden Vorteile den investierten Aufwand völlig entmutigen und Offenheit an sich unzählige Vorteile hat. Wir sind bereit, unseren Weg detaillierter zu beschreiben und Erfahrungen auszutauschen. Schreiben Sie telefonisch an - innersource@sberbank.ru . Küsse, Sberbank.