10 Setzer für 30 Teams. Bist du verrückt

Hallo allerseits! Mein Name ist Kostya und ich leite die Layoutabteilung bei Wrike .
Derzeit arbeiten 10 Mitarbeiter in unserer Abteilung, und alle diese Mitarbeiter kamen zu unterschiedlichen Zeiten in das Unternehmen. Sie haben unterschiedliche Erfahrungen und Aufgaben in separaten Teams. Gleichzeitig sind alle Mitarbeiter hervorragende Spezialisten, die es zusammen mit zehn Mitarbeitern schaffen, den Layoutbedarf des gesamten Produkts zu decken.

In diesem Artikel möchte ich darüber sprechen, welche Praktiken uns helfen, das technische Gesamtniveau des Teams unter Einhaltung der gleichen Arbeitsansätze in Einklang zu bringen und den Jungs Entwicklungsmöglichkeiten zu geben, damit sie besser werden und die Benutzeroberfläche unseres Produkts verbessern können.

Für diejenigen, die viele Buchstaben haben, gibt es ein Video .



Und jetzt ein kleiner Kontext. Wir sind ein Wrike-Produktunternehmen, das sich der Entwicklung eines einzigen Produkts widmet. Dies ist eine Single Page Application (SPA) für die Zusammenarbeit bei Aufgaben und Projekten. Insgesamt beschäftigt das Unternehmen mehr als 700 Mitarbeiter und mehr als 300 Ingenieure arbeiten an der Entwicklung. Alle Mitarbeiter sind in 30 Produktteams unterteilt - jedes von ihnen arbeitet nach der Scrum-Methodik und besteht aus verschiedenen Spezialisten: Back-End, Front-End, Tester, Layout-Designer, UX-Designer usw. Jedes Team arbeitet an einem eigenen Produkt. Alle diese Teile werden dann zu einem großen Produkt zusammengesetzt, das von mehr als 16.000 Unternehmen auf der ganzen Welt verwendet wird.

Das Produkt ist so groß und komplex, dass es für uns wichtig ist, klar zwischen Frontend-Entwicklern, die Geschäftslogik auf dem Client erstellen, und UI-Entwicklern zu unterscheiden, im Wesentlichen Codierern, die sich nur mit dem Layout von Schnittstellen befassen, dies jedoch mit maximalem Eintauchen und entsprechend mit maximaler Qualität.

Gleichzeitig glauben wir nicht, dass der Layout-Designer eine Zwischenstufe der Entwicklung im Frontend-Entwickler darstellt. Für uns ist dies ein separater Entwicklungszweig mit einem eigenen Stapel von Technologien und einer eigenen Komplexität. Nicht jeder Layout-Designer sollte programmieren können, aber nicht jeder Frontend-Entwickler sollte in der Lage sein, zu setzen.

Trotz der Tatsache, dass nur 30 Teams in Wrike arbeiten, decken zehn Codierer den Bedarf von nur 20 ab. Tatsache ist, dass nicht alle Teams an Aufgaben arbeiten, um die Benutzeroberfläche zu ändern, sodass nur 20 von ihnen mit ihrem permanenten Layout-Designer „bewaffnet“ sind.

Wrikes Team ist verteilt, wir haben mehrere Büros auf der ganzen Welt: von San Diego bis Woronesch. Das Hauptentwicklungszentrum befindet sich in St. Petersburg, ein Teil der Entwicklung befindet sich in Woronesch, und jetzt wird in Prag ein Büro eröffnet, in das einige der Produktteams umziehen werden.

Wenn so viele Menschen in verschiedenen Teams, Städten und Ländern an einem Produkt arbeiten, kann es schwierig sein, einen einheitlichen Ansatz beizubehalten. Die Ingenieure haben das gleiche Niveau und folglich die Konsistenz und die gleich hohe Qualität des Codes. Wenn Sie dies nicht besonders beachten, können verschiedene Probleme auftreten.

Stellen Sie sich vor, Sie sind Schriftsetzer und arbeiten in Ihrem Produktteam. Eines schönen Tages im Mai kommen Leute aus einem anderen Team zu Ihnen und bitten dringend um Hilfe: Ihr Layout-Designer wurde einige Tage vor der wichtigen Veröffentlichung krank und er muss schnell ersetzt werden, nachdem er alles erledigt hat, was er unterwegs nicht hatte. Sie sind momentan nicht sehr beschäftigt und erklären sich bereit zu helfen: Es dauert nur ein paar Tage. Als nächstes laden Sie das Repository herunter, an dem Ihr Kollege gearbeitet hat, und ... ertrinken eine Woche lang darin, um herauszufinden, was dort vor sich geht. Schlaflose Nächte, zerrissene Fristen und ein nervöses Häkchen werden Ihnen als Bonus gegeben.

Oder noch schlimmer - Sie sind der gleiche kranke Kodierer. Und wenn Sie die Krankenliste verlassen, aktualisieren Sie Ihr Repository und erhalten von Ihrem Kollegen 28 Commits, die die schlanke Architektur von Anfang an vollständig zerstören. Warum so? Weil Ihr Kollege nachts hart gearbeitet hat, ohne Ihre Ideen und die Fähigkeit zur Synchronisierung mit dem Autor zu kennen. Und anscheinend ist die aktuelle Aufgabe irgendwie erledigt, aber die Weiterentwicklung dieses Codes wird ein Albtraum sein. Alles muss überarbeitet werden, und es ist gut, wenn Sie es dem Team erklären und eine weitere Woche lang an dem arbeiten können, was anscheinend getan wurde.

Ich bin seit einiger Zeit in der Webentwicklung tätig: Ich habe als Entwickler und Manager gearbeitet. Er hat in Webstudios, Agenturen und im Outsourcing der Produktion gearbeitet, und jetzt arbeite ich in einem Produktteam. Ich habe alles gesehen, ich habe ähnliche Situationen mit dem Ansturm und in viel kleineren Unternehmen als Wrike gesehen. Daher bin ich sehr froh, dass es in Wrike, zumindest im Hinblick auf die Entwicklung der Benutzeroberfläche, keine solchen Situationen gibt und nicht geben kann, und ich bin bereit, Praktiken auszutauschen, die uns dabei helfen, dies zu vermeiden.

Wenn Sie darüber nachdenken, ist im Allgemeinen klar, dass sich das Ganze in Menschen und Prozessen befindet. Es sind Menschen, die Code schreiben, sie sind es, die Prozesse aufbauen und irgendwie interagieren. Menschen sind sowohl eine Quelle von Lösungen als auch eine Quelle von Problemen. Und wenn wir über Ingenieure sprechen, dann scheint alles einfach zu sein. Um keine Probleme zu haben, müssen einige Bedingungen beachtet werden:

1. Alle Jungs müssen gleich hoch sein. Jeder nutzt die gesamte Palette der erforderlichen Technologien, kennt alle Stärken und Grenzen, kennt sich in den Prozessen gut aus und hält an denselben Ansätzen fest. Dann können Sie die Aufgabe in der Tat jedem Ingenieur geben, und er wird sie ebenso lösen wie jedem anderen Kollegen.
2. Jeder schreibt Code gleich gut. Na ja, oder zumindest genauso. In Kombination mit dem ersten Absatz erhalten wir dann tatsächlich einen konsistenten, gut gepflegten Code, mit dem jedes Teammitglied arbeiten kann.
3. Jeder weiß wer was macht. Dies senkt die Einstiegsschwelle beim Umschalten zwischen Aufgaben, und selbst wenn jemand krank wird oder aus einem anderen Grund aus dem Workflow ausfällt, ist einer der Kollegen verfügbar: Dies verringert die Wahrscheinlichkeit des sogenannten Busfaktors.
4. Teammitglieder "teilen das Knospen". Die Anzahl der Teams wächst ebenso wie der Bedarf an Ingenieuren. Es ist bereits schwierig, solche Leute einzustellen, die den ersten drei Punkten entsprechen. Es wäre also schön, wenn bestehende Leute unter Beibehaltung des aktuellen Wissens das Knospen oder Klonen teilen könnten. Dann gibt es ja keine Probleme mit der Skalierung;
5. Bringe allen das Fliegen bei. Für ein Unternehmen mit mehreren Niederlassungen in verschiedenen Ländern ist es erforderlich, Personen aus verschiedenen Niederlassungen an einem Ort zusammenzubringen, da der Wert der nonverbalen Kommunikation für die Herstellung von Kommunikation kaum überschätzt werden kann. Und es wäre schön, wenn die Jungs, wenn sie sich mit jemandem synchronisieren müssten, einfach in ein anderes Büro „fliegen“ könnten, wie in Comics. Dann wird es vielleicht keine Probleme mit der Verteilung von Teams auf der ganzen Welt geben.

Und wenn all dies irgendwie in einem Ingenieur implementiert ist, dann ist es irgendwie falsch, es als "Layout-Designer" zu bezeichnen, und ein Titel wie "Universal-Layout-Designer im luftleeren Raum" ist besser.

Es scheint unmöglich zu sein, alle diese Punkte zu erfüllen, insbesondere die letzten beiden. Aber wir in der Layoutabteilung von Wrike sind dem sehr nahe. Und jetzt erzähle ich Ihnen von 7 Praktiken, die uns helfen, dem Ideal, nach dem wir streben, so nahe wie möglich zu kommen.

1. Aktuelle Liste der Kompetenzen

Wenn wir wissen, welche Aufgaben zu lösen sind, müssen wir verstehen, welche Kompetenzen erforderlich sind, um sie zu lösen. Natürlich wäre es gut für alle, alles auf der Welt zu wissen, aber objektiv ist dies unmöglich, und es lohnt sich, die Mindestliste an Wissen hervorzuheben, die zumindest jemand in der Abteilung haben sollte, und besser für alle.

Was gibt es? Klare Anforderungen an die Kandidaten - je näher sein Wissen an der Liste der erforderlichen Kompetenzen liegt, desto besser.

Wie macht man das? Irgendwann versammelten wir uns in der gesamten Abteilung und schrieben in einigen Besprechungen alle Technologien auf Papier, die wir bereits verwenden oder die wir studieren und in Zukunft einsetzen möchten. Und mit Hilfe der Moderation kamen wir zu einer Liste von Kompetenzen, mit denen absolut jeder einverstanden ist.

Infolgedessen enthält unsere Liste der Kompetenzen sowohl sehr abstrakte Dinge, zum Beispiel die Fähigkeit, Informationen schnell zu finden, als auch sehr spezifische Technologien bis hin zu den spezifischen Befehlen des Konsolendienstprogramms git, die unserer Meinung nach verwendet werden sollten.
Gleichzeitig ist es völlig normal, dass zu einem bestimmten Zeitpunkt nur ein oder zwei Personen in einer Abteilung über eine der Kompetenzen verfügen. In dieser Phase ist die Hauptsache, dass zumindest jemand über dieses Wissen verfügt, andernfalls stellt sich heraus, dass die Abteilung mit Aufgaben konfrontiert ist, die überhaupt niemand hat nicht in der Lage zu lösen.

Nachdem wir die vollständige Liste der Kompetenzen fertiggestellt haben, haben wir sie bequem in 13 Richtungen gruppiert. Hier sind sie:

• Die Fähigkeit zu googeln;
• Umwelt (Werkzeuge, Git, Aufschlag usw.);
• HTML
• CSS
• Allgemeine Ansätze (HTML / CSS);
• UI-Kit;
• Scrum;
• Winkel + Pfeil;
• Codeüberprüfung;
• JS;
• Programmiergrundlagen;
• Benutzeroberfläche / Schnittstellen;
• Hotkeys

Und wenn dasselbe HTML / CSS gängige Industriestandards sind und wir erwarten können, dass die Kandidaten mit ihnen vertraut sind, dann gab es ganz bestimmte Dinge. Zum Beispiel unsere interne UI Kit-Bibliothek. Oder unsere internen spezifischen Tools, Merkmale der Umgebung, Merkmale von Ansätzen zur Lösung bestimmter Probleme usw. Der gleiche Dart Angular (wir schreiben das Frontend des Produkts auf Dart) ist eine eher seltene Sache. Nur wenige Leute haben damit gearbeitet und erwarten, dass mindestens einer dieser Standards einem potenziellen Kandidaten bekannt ist - zumindest naiv. Es stellt sich heraus, dass selbst wenn wir einen erfahrenen Spezialisten einstellen, dieser immer noch nicht die Hälfte dessen weiß, was wir für die erfolgreiche Erfüllung unserer Aufgaben für notwendig halten. Es stellt sich heraus, dass die Einstellung und Anpassung einer neuen Person an ein Team immer ein wenig Training ist. Und je mehr Wissen angesammelt wird, desto komplexer und langwieriger wird das Training.

Es stellt sich heraus, dass es einfach unmöglich ist, eine Person zu finden, die unsere Anforderungen an technisches Fachwissen zu 100% erfüllt, und wir müssen sie lernen. Ein Anfänger muss also über bestimmte Lernfähigkeiten verfügen. Und das sind persönliche Merkmale, die sogenannten Soft Skills.

Wenn die Abteilung und das Produkt klein sind und das gesammelte Wissen klein ist, ist es vorteilhaft, Mitarbeiter mit hohem Fachwissen einzustellen, um es in einem Team zu teilen. Und hier setzen sich bereits Hard Skills durch.

Wenn die Abteilung wächst und gleichzeitig das gesammelte Wissen über das Produkt zunimmt, wird es unrentabel, Kinder mit umfassender Erfahrung einzustellen, da es für sie schwieriger wird, sich an neue Realitäten anzupassen, die sich nur schwer schnell ändern lassen. Und hier ist es nützlich, Leute einzustellen, die, auch wenn sie nicht über viel technisches Fachwissen verfügen, sich aber schnell anpassen und die erforderlichen Technologien erlernen können. Und Soft Skills treten in den Vordergrund - nämlich hohe Lernfähigkeit, gute Kommunikationsfähigkeiten. Und es ist wichtig, dass eine Person bereits etablierte Werte teilt und das Team stärkt und nicht anfängt, damit zu kämpfen. Es geht um den sogenannten Cultural Fit.

Es ist wichtig, dass eine Person, die sich einem Team angeschlossen hat, so schnell wie möglich ein Verständnis für Technologien und Prozesse hat und Vorteile bringt. Und das bringt uns zu einer zweiten wichtigen Praxis:

2. Onboarding mit integriertem Training

Wir haben bereits entschieden, dass es nicht ausreicht, nur erfahrene Mitarbeiter einzustellen, und wir müssen ihm unmittelbar nach dem Arbeitsantritt schnell und effektiv beibringen, was er derzeit nicht weiß. Und es spielt keine Rolle, ob dies etwas Alltägliches ist, wie z. B. Flex oder Grid, oder ein bestimmtes Werkzeug, das außerhalb von Wrike einfach nicht zu finden war.

Zu diesem Zweck verwenden wir Onboarding - vom englischen „On-Board“ - den Prozess der Anpassung einer neuen Person an ein Team. Bei Wrike geht es jedoch nicht nur darum, wo ein Neuling einen Job hat und wo er sich seine Aufgaben ansehen kann. Wir haben erkannt, dass Onboarding für uns wie Weiterbildungskurse ist - eine Art mehrmonatige Schulung: mit einer Einschätzung des aktuellen Niveaus, einem Schulungsplan, einem Mentor-Mentor, mehreren Schulungen zu Produkt, Technologien und Prozessen. Nach den Ergebnissen des Onboarding erwarten wir, dass eine Person alles lernt, was zur Erfüllung ihrer Aufgaben erforderlich ist, und selbst den erfahrensten Mitarbeitern der Abteilung in ihren Fähigkeiten so nahe wie möglich kommt.

Im Allgemeinen ist der Prozess unseres Onboarding ein Thema für einen separaten Artikel, aber im Moment möchte ich auf eine wichtige Sache eingehen: die Rose der Kompetenzen.

Basierend auf den zuvor formulierten Kompetenzgruppen können wir jeden Mitarbeiter oder sogar einen Kandidaten in jeder Richtung bewerten und ein solches radiales Diagramm erstellen:



Jeder Strahl ist eine bestimmte Gruppe von Fähigkeiten. Der Punkt ist der Prozentsatz der gemeisterten Technologien und Ansätze, die dieser Gruppe innewohnen. Je mehr ein Mensch weiß und weiß wie, desto näher kommt sein Diagramm dem idealen Kreis. Derjenige, der absolut alle Fähigkeiten aus unserer Kompetenzliste hat, ist der sehr sphärische Layoutdesigner in einem Vakuum, das wir brauchen.

Es ist wichtig zu verstehen, dass ein solches Diagramm (auch bekannt als die Rose der Kompetenzen) nicht für die Leistungsüberprüfung verwendet wird. Das heißt, wir verwenden es nicht, um zu verstehen, wer ein guter Layoutdesigner und wer ein schlechter ist. In jedem Bereich gibt es kein Mindestniveau, unter das man nicht fallen kann. Diese Tabelle gibt Aufschluss darüber, wo eine Person Stärken hat und wo Wachstumspunkte liegen. Wir sind darauf vorbereitet, dass jeder in der Abteilung etwas nicht weiß, besonders wenn es ein Anfänger ist. Wenn man jedoch die Rose der Kompetenzen betrachtet, ist es leicht zu verstehen, welche Dinge überhaupt herausgezogen werden sollten.

Wenn ein Neuling zu uns kommt, wird eine solche Rose für ihn gebaut, und sie erstellen zusammen mit ihrem Mentor einen Trainingsplan für 2-3 Monate, in dem eine Person gepumpt wird und sich dem gewünschten Ideal nähert.

Und den Ergebnissen zufolge wird die Rose nach Abschluss dieses Trainings wieder aufgebaut, und es werden Fortschritte sichtbar.



Wir erwarten nicht 100% Ergebnis in jede Richtung, es ist wichtig für uns, dass es signifikante Fortschritte gibt. Tatsächlich kann dieses Diagramm auch nach Abschluss des Onboarding verwendet werden, um nicht still zu stehen und sich weiterzuentwickeln. Jemand kann seine eigenen interessierenden Richtungen bis zu 100% und noch weiter pumpen, und jemand kann eine neue Richtung hinzufügen und sich von einem Schriftsetzer in einen angrenzenden Bereich entwickeln. Wir haben auch solche Beispiele und Praktiken.

Was gibt es? Ein klarer Entwicklungsplan für Anfänger. So bringen wir alle auf eine Ebene und minimieren die Kluft zwischen den „Oldies“ und den „Newcomern“.

Dies reduziert außerdem die Anforderungen an die Kandidaten: Wenn Sie noch trainieren, ist es dann nicht egal, wofür? Infolgedessen haben wir keine wirklich zwingenden Anforderungen an Hard Skills für Kandidaten. Es ist klar, dass wir ohne Grundkenntnisse überhaupt keine Mitarbeiter einstellen können, aber in der Onboarding-Phase kann viel gelernt werden. Die Hauptsache ist, dass eine Person fähig ist, und der Rest ist ein Geschäft.

Wir wissen also, wen wir suchen, welche Fähigkeiten benötigt werden und wie wir sie trainieren können, aber dieses Wissen ist heute relevant. Und der Front-End-Zug rast mit voller Geschwindigkeit und schmiert alle, die gestolpert sind, und hält mit den Schienen Schritt. Und wir brauchen eine Art Prozess zur Einführung neuen Wissens, damit die gesamte Abteilung nicht hinter den modernen Anforderungen zurückbleibt. Und das bringt uns zu einer dritten guten Praxis:

3. Regelmäßige Trainingsaktivitäten

Um mit der modernen Welt Schritt zu halten, ist es wichtig zu überwachen, was in ihr geschieht. Besuchen Sie Konferenzen, lesen Sie Fachartikel, probieren Sie neue Technologien aus und implementieren Sie sie in Ihre Arbeit.

Es wäre seltsam, alle zu allen verfügbaren Konferenzen und Kursen zu ziehen. Dies ist nicht effektiv. Aber einer der Jungs lernt auf die eine oder andere Weise etwas alleine oder mit Unterstützung von Wrike - wir schicken zu Konferenzen, bezahlen für spezielle Kurse und unterstützen im Allgemeinen in jeder Hinsicht diejenigen, die pumpen wollen. Und wenn es im gesamten Informationsfluss möglich ist, etwas Nützliches für sich selbst herauszufischen, wäre es schön, es in die Abteilung zu bringen und Wissen mit allen zu teilen. Hierzu helfen uns regelmäßige interne Schulungsveranstaltungen. Aber wie kann man verstehen, wer und was die gesamte Abteilung unterrichten kann? Die gleiche Kompetenzsteigerung hilft uns dabei. Aber nicht im Kontext jedes Mitarbeiters, sondern im Kontext der gesamten Abteilung.



Wenn Sie sich ein solches Diagramm ansehen, ist es einfach, einen Experten in einem bestimmten Bereich auszuwählen und Ihr Wissen mit allen anderen zu teilen.

Sie können auch sehen, dass trotz der Tatsache, dass wir selbst einen bestimmten Wissensstand in einem der Bereiche festgelegt haben, niemand in der Abteilung zu 100% über Kenntnisse verfügt. Dies ist eine Gelegenheit, einen externen Experten zu gewinnen, der einen Workshop oder Vortrag für uns abhält und den allgemeinen Wissensstand in der gesamten Abteilung erhöht. Zum Beispiel, weil wir die Grundlagen der Dart-Sprache lernen mussten, fanden wir einen Mentor im Unternehmen - einen starken Entwickler, der für die gesamte Layout-Abteilung einen Kurs über Dart hielt. Das hat uns nicht zu Entwicklern gemacht, weil es keine solche Aufgabe gab, aber zumindest verstehen wir jetzt das Frontend besser. Oder vielleicht wird jemand, der die neue Technologie gespürt hat, darüber nachdenken, wie man in FE umschult, was auch gut ist.

Wir müssen nur noch regelmäßig die Liste unserer Kompetenzen überprüfen und durch neue relevante Technologien ergänzen. Dann wird die Rose wieder aufgebaut, und wir werden das allgemeine Niveau der Abteilung sehen, wir werden in der Lage sein, es zu verwalten, und wir werden niemals hinter dem Front-End-Motor zurückbleiben.

Wir haben also eine Reihe cooler Spezialisten, die ungefähr gleich stark sind und nicht hinter den aktuellen Trends zurückbleiben. Und wir wissen sogar, wie wir ihre Reihen auffüllen können. Wie kann man nun ihre Arbeit synchronisieren? Die vierte wichtige Praxis hilft uns dabei:

4. Obligatorische Gegenprüfung

Ich möchte Sie daran erinnern, dass alle unsere Arbeiten in Produktteams ausgeführt werden. Und jedes Team, dessen Aufgaben mit dem Ändern der Benutzeroberfläche verbunden sind, verfügt über einen eigenen permanenten Schriftsetzer. Ein Schriftsetzer kann mehrere Befehle haben, aber nur, wenn einer nicht zu 100% geladen wird. Und wenn Sie den Spezialisten mit sich allein lassen, entwickelt er früher oder später seine eigene Art des Satzes, die der Rest nie erfahren wird.

Damit dies nicht geschieht und die gleichen Aufgaben von allen ungefähr gleich gelöst werden, durchlaufen jede Aufgabe und jede Zusammenführungsanforderung einen obligatorischen Überprüfungscode.

Es ist wichtig, die Codeüberprüfung nicht so sehr als die Steuerungsfunktion zu betrachten, damit niemand etwas Schlechtes in den Master einbringt, sondern in der Phase, in der sich zwei Ingenieure aus verschiedenen Teams mit unterschiedlichem Hintergrund und unterschiedlichen Aufgaben darauf einigten, wie sie gelöst werden sollen das eine oder andere Problem.

Was gibt eine Gegenbewertung?

In der Überprüfungsphase erhalten Sie eine Außenansicht - wie die Aufgabe besser erledigt werden kann, wodurch die Anzahl der Fehler verringert und der Code konsistent wird. Es ist auch ein gegenseitiger Lernprozess - der Autor des Codes besteht nicht nur die „Validierung“ des Prüfers, sondern der Prüfer kann auch sehen, wie das Problem gelöst wurde, und es in Betrieb nehmen. Im Rahmen des Cross-Review-Prozesses werden gemeinsame Reisen entwickelt und im gesamten Unternehmen verteilt.

Nachdem wir gemeinsame Ansätze entwickelt haben, wäre es schön, sie irgendwo zu speichern, damit Anfänger dieses Wissen nicht nur von Kollegen, sondern auch unabhängig voneinander erhalten können. Dies führt uns zu folgender wichtiger Praxis:

5. Codestil und automatisches Flusen

Es ist wichtig, dass der Code mit den in der Abteilung entwickelten allgemeinen Regeln übereinstimmt. Das Grundlegendste ist Codestyle, das allen gemeinsam ist. Es ist wichtig, dass diese Regeln klar festgelegt und für jede Person im Unternehmen öffentlich zugänglich sind. Weil Sie nie im Voraus erraten werden, wer mit Ihrem Code arbeiten muss.

Besser noch, stellen Sie sicher, dass der Code den angegebenen Regeln entspricht, die vom Linter automatisch überprüft werden: Maschinen sollten leiden, nicht Menschen. Zum Beispiel haben wir Flusen für Markup-Vorlagen und Flusen von weniger Dateien entwickelt und implementiert.

Was gibt automatisches Flusen?

Erstens ist es banal, Code zu schreiben - alle Fehler werden direkt im Code hervorgehoben, während Sie sich noch im Kontext befinden. Und Sie müssen sich nicht durch Überprüfen des Codestils ablenken lassen: Dies wird vom IDE-Plugin durchgeführt.

Zweitens ist es einfacher, eine Codeüberprüfung durchzuführen und zu bestehen - in MR gibt es einfach keine Fehler und es können keine Fehler im Codestil auftreten, und Sie können sich genau auf das Wesentliche der Aufgabe konzentrieren.

Drittens ist das automatische Flusen beim Schreiben von Code auch eine Möglichkeit, den Codestil zu untersuchen. Es spielt keine Rolle, ob Sie bereits zum Zeitpunkt des Schreibens des Codes mit dem Codestil vertraut sind oder nicht. Wenn Sie versuchen, den Code festzuschreiben, zeigt der Linter eine Liste mit Fehlern und Links zu den Regeln an, gegen die genau in der Menge verstoßen wird, die Sie hier und jetzt benötigen . Und so werden Sie den Codestil unweigerlich durch Ausprobieren lernen.

Es scheint, dass trotz der Tatsache, dass jeder in verschiedenen Teams und bei verschiedenen Aufgaben arbeitet, viele Gemeinsamkeiten bestehen. Und sie müssen in der Lage sein zu koordinieren: wer, was und wann zu überprüfen, wer, wann, was, welche Regeln in den Codestil einzuführen sind und welche nicht usw. Alle diese Aktivitäten müssen synchronisiert werden können. Eine weitere wichtige Praxis hilft uns dabei:

6. Tägliches Aufstehen

Die Abteilung hat keine eigenen Sprints und Planungen (nur Produktteams, für die Layoutdesigner arbeiten), aber wir haben dennoch einige der Praktiken von Scrum gelernt. Das tägliche Aufstehen ist nämlich ein Treffen, für das wir dringende Themen sammeln und diskutieren: Wir diskutieren abgeschlossene und aktuelle Aufgaben und diskutieren zukünftige. Dies ist wichtig, wenn auch nur im Zusammenhang mit der Abfolge der Aufgaben für die Überprüfung. Als Bonus können Sie auftretende Probleme diskutieren, Ihre Kollegen um Rat fragen oder Neuigkeiten von Ihren Teams austauschen.

Es ist wichtig, dass der Stand-up-Vorgang schnell und nicht länger als 15 Minuten pro Tag dauert. Denn selbst 15 Minuten pro Tag, multipliziert mit 10 Personen, kosten 40-50 Mannstunden pro Monat. Es ist wie eine ganze Woche Arbeit einer Person. Daher sollte die Rallye selbst so kurz und effektiv wie möglich sein. Und nur wenn es Themen gibt, die eine separate Diskussion erfordern, fallen sie nicht in den Rahmen der Tageszeitung und werden von interessierten Personen separat diskutiert, ohne die Zeit anderer zu verschwenden.

Wir verwenden ein interaktives Whiteboard mit Aufgaben, mit denen jeder Layoutdesigner jederzeit aus jeder Stadt arbeiten kann. Bei der Tageszeitung verbinden sich alle, die sich in St. Petersburg in einem Schrank am Fernseher versammeln, auf dem diese Tafel angezeigt wird, und diejenigen, die in anderen Städten arbeiten, über Zoom. Zusätzlich zu Webcams führt dies zu Präsenz- und Verteilungsproblemen, die wir nicht haben.

Das tägliche Aufstehen gibt uns einen bestimmten gemeinsamen Informationsraum, in dem jede Frage bezüglich des Layouts gelöst werden kann - stellen Sie es einfach laut und der kollektive Verstand synthetisiert die Antwort, weil jemand bereits darauf gestoßen ist. Oder eine Gruppe interessierter Leute kann helfen, eine Lösung für eine neue ausgefallene Aufgabe zu finden.

Wir wissen also, wie man coole Spezialisten anstellt und ausbildet. Wir wissen, wie man ihre Aktionen koordiniert, um qualitativ hochwertigen Code aufrechtzuerhalten. Aber es gibt einen Hinterhalt - wenn jemand sich als Spezialist entwickeln und seine Arbeit gut machen will, dann wird er es tun, egal was passiert. Auch wenn all diese Prozesse nicht existieren. Sie helfen nur. Und wenn er nicht will, werden selbst ideale Prozesse und Super-Training eine Person nicht bewegen. Jeder sollte wirklich involviert sein und sich für das zukünftige Schicksal seines eigenen Unternehmens, des Unternehmens und des Produkts interessieren. Und dies ist die letzte auf der Liste, aber tatsächlich die wichtigste Praxis:

7. Jeder ist an Abteilungsprojekten beteiligt

Im Idealfall sollte jeder Mitarbeiter zumindest für das nächste Quartal einen verständlichen Plan für die Entwicklung seiner selbst und der Abteilung haben. Und es ist gut, wenn jeder es im Kopf hat. Der Strom der aktuellen Aufgaben hat jedoch nicht immer Zeit, darüber nachzudenken.

Damit niemand auf dem aktuellen Niveau bleibt und in seinem Team nicht „sauer“ wird, haben wir die Praxis regelmäßiger Einzelgespräche mit Ihrem Teamleiter oder -leiter eingeführt. In diesen Besprechungen können Sie über Ihre Entwicklung, die Entwicklung des Teams, der Abteilung und des Unternehmens sowie darüber sprechen, was Sie derzeit dafür tun können. Während des Meetings können Sie Feedback zu Ihrer Person erhalten und Aktionen koordinieren oder Feedback zu Ihren Aufgaben, zu den Prozessen im Team oder in der Abteilung geben und diese so beeinflussen.

Neben dem regulären 1: 1 liefen bei uns auch „Projekte“ gut. Auf die eine oder andere Weise müssen die Prozesse und Technologien in der Abteilung gepumpt, etwas Neues eingeführt und das Alte und Irrelevante entsorgt werden. Jeder in der Abteilung hat die Möglichkeit, eine solche Änderung vorzuschlagen, beispielsweise eine neue Technologie einzuführen. Oder schneiden Sie einen Legacy-Ansatz aus, der das Leben beeinträchtigt.

Und wenn eine solche Änderung wirklich nützlich ist, kann jeder das Projekt für seine Umsetzung übernehmen. Dies bedeutet, dass Sie unabhängig voneinander forschen oder arbeiten oder ein Projektteam zusammenstellen und dessen Aktivitäten verwalten, um die Ziele des Projekts zu erreichen. Dies erfordert häufig eine eingehende Untersuchung neuer Technologien oder die Suche nach Antworten auf zuvor unlösbare Fragen.

Jeder kann für sich das Projekt auswählen, das ihn interessiert. So entwickelt sich eine Person in einem für sie interessanten Bereich und pumpt die gesamte Abteilung.

Und einmal im Monat, damit die Arbeit an den Projekten für alle transparent ist, versammeln wir die gesamte Abteilung im Retro-Stil und teilen unsere Erfolge oder bieten neue Projekte an.

Diese sieben Praktiken ermöglichten es uns, innerhalb eines Jahres 6 Layoutdesigner einzustellen und in die Abteilung und die Teams zu integrieren. Im Moment ist dies fast ⅔ der gesamten Abteilung. Gutes Ergebnis.

Und was ist mit den Flügen?

Ohne Magie geht es nicht - alles dank der Magie der Automatisierung und unserer Reisefee Ane.
Wenn Sie aus irgendeinem Grund in einem anderen Büro sein müssen, um beispielsweise mit jemandem persönlich zu chatten, müssen Sie lediglich ein spezielles Formular direkt in Wrike ausfüllen und die Daten und den Zweck der Reise angeben. Und zur richtigen Zeit in der Post werden Flugtickets sein. Sie müssen sich nur noch einen Laptop und einen Reisepass schnappen und nicht zu spät zum Flug kommen. Unsere Schriftsetzer fliegen also ohne Probleme :)

Aber was ist, wenn Ihr Unternehmen noch keine solchen Praktiken hat?

Wenn Sie ein Teamleiter oder -leiter sind, ist der Rat sehr einfach: „Hier ist die Checkliste, nehmen Sie sie und implementieren Sie sie.“ Ich denke, jeder Leiter ist am Wachstum seiner Mitarbeiter und an der Qualität des Codes interessiert.

Und wenn Sie ein einfacher Schriftsetzer oder sogar ein Freiberufler sind, müssen Sie sich nicht auf die Unterstützung „aus der Luft“ verlassen? Seltsamerweise ist der Rat genau der gleiche.

Der Trick ist, dass die Umsetzung all dieser Praktiken keine großen Investitionen oder Arbeitskosten erfordert und auf Initiative gewöhnlicher Mitarbeiter „von unten nach oben“ gefördert werden kann. Die Hauptsache ist, dass es den Wunsch gibt, sich selbst zu pumpen und die Welt um dich herum zu verbessern.