Bei GitLab ist udalenka kein Geschäftsrisiko, sondern ein Wettbewerbsvorteil.
Ich bin Produktmanager bei GitLab. Normalerweise mache ich die Planungsphase im DevOps-Lebenszyklus . Ich bin im November 2016 gekommen und bewundere seitdem, welche Sprünge und Grenzen GitLab als Produkt und als Team entwickelt. Viele Newcomer bitten mich um einen Kaffee über die GitLab-Kultur, insbesondere über Udalenka, weil wir nur so arbeiten . Im Laufe der Zeit haben sich meine Ansichten geändert, und ich möchte Ihnen sagen, warum udalenka mir nicht als Hindernis, sondern als Wettbewerbsvorteil erscheint. Jedenfalls für GitLab.
Wie ich mich daran gewöhnt habe
Als ich zu GitLab kam, schien mir udalenka ein Problem zu sein, das gelöst werden musste. Oder zumindest Kontrolle. Ich dachte, es sei ein Risiko. Zum Beispiel wollte ich mich jeden Tag mit meinem Team treffen. Unternehmen und Smart Books aus dem Silicon Valley sagen, dass Sie sich regelmäßig treffen und kommunizieren müssen, sonst ist es unmöglich, ein erfolgreiches Produkt zu schaffen und den Markt zu erobern. Zu meinem Entsetzen dieser Zeit haben wir uns nie getroffen (und werden es auch nicht tun). Und - eine seltsame Sache - wir haben fruchtbar zusammengearbeitet und Produkte nur unterwegs geliefert. Das habe ich sicher nicht erwartet.
Dann gewöhnte er sich daran , Produkte im Stil von GitLab herzustellen, und die Udalenka schien nicht so riskant zu sein. Es gibt natürlich ein paar Minuspunkte, aber der Rest ist pure Freude. Hier sind die Vor- und Nachteile von udalenka , wenn Sie interessiert sind.
Das Abwägen der Vor- und Nachteile reicht nicht aus, um die Bedeutung der Remote-Arbeit für GitLab zu beschreiben. Mit Remote (und anderen Schlüsselkomponenten von GitLab) schaffen wir sehr schnell Innovationen, was bedeutet, dass wir einen einzigartigen Wettbewerbsvorteil erzielen. Und hier ist warum.
Interdependente Komponenten
Udalenka passt dank wichtiger voneinander abhängiger Komponenten so gut in GitLab:
Asynchrone Kommunikation
Remote-Mitarbeiter sind auf dem ganzen Planeten verstreut und arbeiten in verschiedenen Zeitzonen. Daher bevorzugen wir asynchrone Kommunikation (normalerweise in Textform) , die räumlich und zeitlich erweitert ist. In diesem Format müssen Sie alles aufzeichnen und klar und deutlich ausgedrückt werden. Andernfalls ist dies nicht der Fall, da manchmal nur ein oder zwei Sätze pro Tag ausgetauscht werden können. Wir bevorzugen Text, da Text im Internet und in modernen Anwendungen (z. B. in GitLab-Aufgaben ) zum Organisieren, Suchen und für Hyperlinks geeignet ist. Text ist leicht zu analysieren und zu assimilieren. Dies ist eine sehr effektive Form der Kommunikation, insbesondere für die Zusammenarbeit.
Transparenz
Im Gegensatz zu Papierdokumenten im Büro können digitale asynchrone Nachrichten beliebig oft gesendet werden. Wir sind nicht wie in traditionellen Unternehmen von Mauern eingezäunt. Unsere Kommunikation und Arbeit sind standardmäßig transparent . Manchmal müssen Sie Berechtigungen hinzufügen und diese dann erneut verwalten. Dies ist ein zusätzlicher Aufwand. Wenn Sie eine Nachricht senden möchten, müssen Sie überlegen, wer sie empfangen soll, und Berechtigungen konfigurieren. Die Empfänger erhalten auch mehr Arbeit, da Sie nicht so einfach zum Inhalt gelangen. Dies ist ein zusätzlicher Kopfschmerz, und solche Dinge häufen sich. Wir versuchen sie zu vermeiden.
Und so ist es klar, dass jeder Ihre Nachricht sehen kann, auch wenn sie hier nicht funktioniert. Es ist also besser, sofort zu sagen.
Wenn alles transparent ist, ist es sehr einfach, die Wahrheit zu sagen, und es besteht kein Grund zu lügen. Dies ist nicht nur richtig, sondern auch für die langfristige Geschäftsentwicklung von Vorteil. Es ist beispielsweise klar, dass jeder Ihre Nachricht sehen kann, auch wenn sie hier nicht funktioniert. Es ist also besser, es sofort so zu sagen, wie es ist, und man gewöhnt sich schnell daran. Sie müssen nicht für jede eine eigene Version erfinden und sich dann noch daran erinnern, was Sie an wen gesendet haben. Sie haben eine Quelle der Wahrheit, und Sie werden darin nicht verwirrt sein. Es gibt keine anderen. Wir haben normalerweise diese Beschreibung im Ticket.
Alle tanzen!
Wenn jedem eine einzige Quelle der Wahrheit zur Verfügung steht, trägt jeder dazu bei . Jeder hat die gleichen Informationen und jeder kann damit arbeiten. Denken Sie daran, ich sagte, dass der Absender normalerweise denkt, wer die Nachricht erhalten wird? In unserem Fall kann etwas Nützliches von dort kommen, wo sie nicht gewartet haben. Ohne Transparenz geht das nicht: Künstliche Barrieren behindern eine mögliche Zusammenarbeit. Manchmal müssen gute Ideen reifen. Sie haben zum Beispiel eine Idee geäußert, aber die Bedingungen dafür sind nicht am besten geeignet. Und dann stellt sich heraus, dass es nur eine Frage der Zeit ist. In Zukunft wird jemand diese Idee ausgraben und unter Verwendung aller offenen Diskussionen und Entwicklungen weiterentwickeln.
Wenn jeder eine Idee einreichen kann, wird er zu einer Kutsche. In GitLab kommen manchmal die besten Lösungen für komplexe Probleme von völlig unterschiedlichen Teams. Aber wir haben immer noch die Verantwortlichen . Sie treffen Entscheidungen, wenn wir stecken bleiben.
Iteration
Wie kann man all diese Kommunikationen und die Zusammenarbeit sammeln, wenn sie im Wesentlichen transaktional, verteilt und unstrukturiert sind? Wir müssen iterativ arbeiten . Viele (einschließlich mir) glauben, dass sie die Iteration verstehen, bis sie zu GitLab kommen. Ich sehe ständig Neuankömmlinge, die überrascht sind, inwieweit wir dieses Konzept eingeführt haben. Das Produkt und der Code werden in minimalen Fragmenten geliefert, sodass der Entwickler sofort Feedback erhält und weiß, wo er als Nächstes arbeiten muss. In GitLab schneiden Sie winzige Teile ab und machen sich sofort an die Arbeit. Natürlich machen wir großartige Pläne, aber wir sind nicht auf eine detaillierte Analyse fixiert. Wir nehmen nur die kleinste Aufgabe und lösen sie. Jeden Tag des Wartens betrachten wir es als entgangenen Gewinn. Es ist besser, heute zumindest etwas zu tun und das Ergebnis sofort zu erhalten. Wir konzentrieren uns auf Maßnahmen .
Jeden Tag des Wartens betrachten wir es als entgangenen Gewinn. Es ist besser, heute zumindest etwas zu tun und das Ergebnis sofort zu erhalten.
Und kleine Fragmente haben kleine Probleme. Es ist logisch, dass mehr Menschen an kleineren Problemen interessiert sind: Das Betrachten der Ticketbeschreibung ist keine zweistündige Präsentation, in der Sie sich hinsetzen können. Und da das Problem standardmäßig transparent ist, kann es jeder lösen. Persönlich diskutiere ich jeden Tag parallel 20-30 Probleme. Ich hätte es kaum gemeistert, wenn ich jedes Mal zu besonderen Treffen gehen müsste. Infolgedessen habe ich zumindest irgendwie an einer unglaublichen Anzahl von Projekten teilgenommen. Multiplizieren Sie dies mit allen GitLab-Teams und dann mit der gesamten GitLab-Community. Es ist sofort klar, woher all diese Innovationen auf GitLab stammen.
GitLab leidet nicht unter der Fernbedienung, profitiert jedoch in vollem Umfang davon.
Abschließend
Ich habe hier über endlose Korrespondenz und einen Ideenbrunnen gesprochen. Also arbeiten wir. Es kommt vor, dass Neuankömmlinge in wenigen Wochen bemerken, dass sie in allen Diskussionen gleichzeitig festgefahren sind. Dies ist nicht überraschend, da wir uns weiterentwickeln, es immer mehr Ideen gibt, unser Netzwerk wächst und sich die Beziehungen zwischen uns vervielfachen. Aber ziemlich bald lernen Anfänger, nur die interessantesten auszuwählen. Ich denke, dies ist eine gute Strategie, weil gute Ideen mehr Aufmerksamkeit erregen und wir unserem kollektiven Verstand vertrauen. Wir brauchen aber immer noch klar definierte Rollen und Verantwortlichkeiten, damit enge Spezialisten und Entscheidungsträger unsere Innovationen nach rechts treiben
Richtung.
Und wie gehst du mit Udalenka um? Schreiben Sie einen Kommentar oder Tweet auf @gitlab .