Heute setzen wir unsere Bekanntschaft mit dem Buch " Team Geek: The Ideal IT Company " von Brian Fitzpatrick und Ben Collins-Sussman fort, das sich der Kommunikation "at work" in all ihren Formen widmet. Das letzte Mal haben wir mit der Kommunikation innerhalb des Teams begonnen und hauptsächlich darüber gesprochen, wie sich die Denkweise jedes einzelnen Mitarbeiters auf ihn auswirkt. Dieses Mal müssen wir das Team breiter betrachten - als eine vereinte Gruppe mit einer eigenen internen Kultur, die irgendwie geformt ist und für etwas benötigt wird.
Teamkultur ist eine Reihe von Kenntnissen, Werten und Zielen, die für eine bestimmte Gruppe von Programmierern spezifisch sind. Dazu gehören die Methoden zum Erstellen von Programmcode, der Kommunikationsstil zwischen Personen und die Organisation des Workflows - es gibt viele Komponenten. Einige von ihnen sind nicht zu kritisch, sie kommen und gehen leicht (zum Beispiel der Brauch, freitags Pizza zu bestellen und Brettspiele zu spielen), andere bilden das "Rückgrat" der Kultur und können ganze Generationen von Programmierern überleben (zum Beispiel) Verfahren für die Prozesse der Code-Inspektion, Prüfung, Dokumentation usw. Weiter).
In seiner ursprünglichen Form wird die Kultur normalerweise von den Gründern und dem ursprünglichen technischen Team festgelegt. In der Folge entwickelt es sich unweigerlich weiter und erfährt Änderungen, aber für starke, bewährte Teams (Google, Apple, Microsoft, Oracle kann als Beispiel angeführt werden) bleibt das ursprüngliche Gesicht meist bis zu einem gewissen Grad erhalten - die Verbindung zu den Wurzeln geht nicht vollständig verloren.
Entgegen dem weit verbreiteten Missverständnis liegt die Teamkultur nicht ganz in den Händen und im Gewissen des Leiters. Wenn es wirklich existiert (darüber, was passiert, wenn es wirklich keine Kultur gibt, werden wir etwas später sprechen), wird es von fast allen Mitarbeitern ausgestrahlt. Dies wird deutlich, wenn Sie sich ansehen, wie sich ein Newbie-Team normalerweise integriert. Der neue Entwickler bekommt eine Vorstellung davon, wie es hier akzeptiert wird, was wichtig ist und was durch die Interaktion mit Kollegen unwichtig ist: Was wird in seinem Code beachtet, wie und in welchem Ton erklären sie die Notwendigkeit von Korrekturen, wie Konflikte sind behoben.
Autarke Teamkultur: eine Bäckereimetapher
Warum an Teamkultur arbeiten?
Die Kultur des Teams ist also eine Art diffuse Mischung aus unterschiedlichen Einstellungen und Vereinbarungen, die es Menschen, die zusammenarbeiten, ermöglicht, auf derselben Wellenlänge zu bleiben. Es stellt sich natürlich die Frage: Lohnt es sich, sich darüber Sorgen zu machen? Die gegenseitige Beeinflussung der Mitarbeiter im Arbeitsprozess erfolgt auf natürliche Weise, so dass sich wahrscheinlich jede Kultur von selbst bildet.
Das Problem hierbei ist, dass wie bei allen spontanen Prozessen eine sich spontan entwickelnde Kultur mehr Entropie erzeugt und unvorhersehbare Ergebnisse liefern kann. Mit anderen Worten, früher oder später wird es Menschen geben, die mit eigenen Händen entscheiden, "wie es hier üblich ist". Wenn sie sich als vernünftig herausstellen und in die gleiche Richtung handeln, wird das Ende glücklich sein. Aber meistens verwandelt es sich in die gleichen guten alten Bürokriege oder, noch schlimmer, in Verfallstaschen innerhalb des Teams.
Dinge loszulassen ist also nicht die beste Wahl. Oben haben wir darüber gesprochen, dass Kultur nicht gewaltsam vermittelt werden kann, aber Sie können sich ihrer Entstehung bewusst nähern. Wenn sich jeder Teilnehmer nicht nur gemäß den Grundsätzen des letzten Kapitels verhält, sondern auch versucht, sie auf die Ebene des Teams zu bringen, Aktionen unterdrückt, die für die Zusammenarbeit gefährlich sind, und keine Angst hat, gemeinsame Regeln für alle auszuhandeln, besteht das Risiko von unangenehmen Überraschungen nimmt ab.
Was soll die Teamkultur sein?
Es ist natürlich unmöglich, diese Frage eindeutig und erschöpfend zu beantworten. Die Kulturen sind äußerst vielfältig und das Spektrum an gesunden, produktiven Variationen ist breit. Gut organisierte und komfortable Arbeit kann sowohl in einem chaotischen Start-up, in dem jeder im Vorstand ist, als auch in einem großen Unternehmen mit klaren Prozessen und Abstand erfolgen. Der Versuch, für jedes der vielen Elemente einen Maßstab zu setzen, ist sinnlos.
Im Allgemeinen sollte Kultur sein:
- . . , , . , : .
- . , , , , . . , , – .
- . , , , : , , . , – , .
- . , , . , . , .
Kommunikationskanäle sind die am einfachsten zu kontrollierende Komponente der Kultur, und die Autoren widmen ihnen die größte Aufmerksamkeit. Bevor sie jedoch auf ihre Details eingehen, geben sie einige Tipps zu anderen, subtileren Elementen.
Wenn es darum geht , Entscheidungen zu treffenDann bevorzugen Programmierer zum größten Teil demokratische Modelle. Vielleicht liegt dies an ihrem berüchtigten Wunsch nach Unabhängigkeit, oder vielleicht ist die Tatsache, dass der Beruf von Natur aus kreativ ist, aber die Tatsache bleibt: Es ist wichtig, dass Entwickler eine Stimme haben und ihre eigenen Gedanken teilen können. Führungskräfte sollten dies bei der Organisation von Entscheidungsprozessen berücksichtigen. Es ist nicht notwendig, alle Probleme durch eine allgemeine Abstimmung zu lösen. Es reicht aus, dass die Mitarbeiter wirklich angehört werden, und das System setzt genügend Konsens voraus, damit sie sich als Eigentümer fühlen.
Wie für die Art der KommunikationSie sollte sich eher für betonte Höflichkeit als für Aggressivität interessieren. Das Problem bei Teams, die einen Schrei oder einen durchsetzungsfähigen Ton verwenden, um sich zu behaupten, besteht darin, dass sie Menschen mit einem ruhigeren Geist drängen und überwältigen. Eine Person, die zu Konflikten neigt, wird sich sowohl in einem aggressiven Umfeld als auch unter höflichen Menschen sehr wohl fühlen. Eine ruhige, zurückhaltende Person (von denen es viele unter Programmierern gibt) wird sich im Gegenteil nicht richtig in einem aggressiven Team öffnen können. Dementsprechend schneiden wir durch die Förderung oder einfach eine anstößige Art der Kommunikation automatisch einige der potenziell starken Mitarbeiter ab. Das ist unpraktisch.
Gleichzeitig sollte klar sein, dass die Kultur der Korrektheit und des gegenseitigen Respekts fragiler und anfälliger für äußere Einflüsse ist. Ein selbstbewusster Anfänger reicht aus, um die Harmonie zu erschüttern. Daher ist es sehr wichtig, allen Versuchen ein Ende zu setzen, gegen die akzeptierte Art der Kommunikation zu verstoßen und Menschen daran zu hindern, durch destruktives Verhalten Siege zu erringen. Der beste Weg, dies zu tun, besteht darin, sich einfach zu weigern, in einem aggressiven Ton zu kommunizieren.
Kommunikationskanäle
Wir haben festgestellt, dass die Fixierung und Weitergabe von Informationen eine entscheidende Rolle in der Teamkultur spielt. Unter modernen Bedingungen stehen uns zu diesem Zweck viele Werkzeuge zur Verfügung; Dieser Abschnitt bietet nur einen Überblick über die häufigsten.
Ein gemeinsames Merkmal erfolgreicher Teams ist, dass sie verschiedene Kommunikationskanäle aktiv nutzen, um sicherzustellen, dass jeder sowohl über die allgemeine Bewegungsrichtung als auch über den aktuellen Arbeitsfortschritt informiert ist. Gleichzeitig liegt der Schwerpunkt auf den Kanälen, die zum einen Informationen öffentlich zugänglich machen und zum anderen die Möglichkeiten der asynchronen Kommunikation optimal nutzen.
Darüber hinaus betrachten die Autoren eine Reihe spezifischer Werkzeuge, über die die Kommunikation in technischen Teams stattfindet. Klärung ihres Zwecks und ihrer Nutzungsregeln.
Missionsdefinition
Von einem solchen Titel wird sich der Leser-Programmierer wahrscheinlich selbst bekreuzen, aber tatsächlich ist nicht alles so beängstigend. In der technischen Arbeit wird die Mission auf der Ebene einzelner Projekte formuliert und zielt darauf ab, das Unternehmen nicht in vage verzierten Ausdrücken zu loben, sondern klar anzugeben, was getan wird und was nicht. Mit anderen Worten, ein Leitbild ist eine lakonische Definition der Richtung der Produktentwicklung und deren Einschränkung.
Sagen wir es so:
Die Mission von GWT ist es, die Benutzererfahrung im World Wide Web radikal zu verbessern, indem Entwickler vorhandene Java-Tools nutzen können, um AJAX-Anwendungen für jeden modernen Browser zu erstellen.
Als Mitarbeiter, die aktiv an Open-Source-Projekten beteiligt sind, konnten Fitzpatrick und Sussman aus eigener Erfahrung sehen, wie viel Zeit, Energie und Nerven eine solche Maßnahme auf lange Sicht für das Team sparen kann. Wenn ständig neue Mitglieder mit jeweils eigenen Ambitionen, Kommentaren und guten Ideen an der Arbeit teilnehmen, sollte der „Kern“ der Gruppe ein klares und einheitliches Verständnis für das Wesentliche des Projekts haben. Andernfalls wird die Arbeit entweder nach dem Szenario der Fabel über Schwan, Krebs und Hecht verlaufen oder aufgrund von Versuchen, diese Fragen auf dem Weg zu klären, ständig thrombusieren.
Dementsprechend ist ein Leitbild in zweierlei Hinsicht nützlich. Erstens, wenn unter den wichtigsten Stakeholdern Meinungsverschiedenheiten über die Ziele und den Umfang des Projekts bestehen, wird es sofort auftauchen und unverzüglich gelöst werden. Zweitens wird das Ergebnis der Diskussion ein Dokument mit den wichtigsten Thesen sein, auf das langweilige oder übermäßig eifrige Neuankömmlinge verwiesen werden können.
Das Leitbild gibt dem Team Halt bei Entscheidungen in Bezug auf das Projekt, sollte jedoch nicht als absolut unverletzlich angesehen werden. Manchmal (vor allem bei Startups) ändern sich die Ziele oder Umstände der Arbeit radikal. In Notsituationen ist es sinnvoll, ehrlich zu beurteilen, ob die ursprüngliche Mission noch relevant ist, und sie entsprechend zu ändern.
Projektdokumentation
Wenn die Mission darauf ausgelegt ist, eine einzige Antwort für alle Projektteilnehmer auf die Frage "Was" zu entwickeln, impliziert die Projektdokumentation eine ähnliche Arbeit an der Frage "Wie".
Das Projektdokument enthält eine detailliertere Skizze des zukünftigen Projekts und seiner technischen Füllung. In der Regel haben ein Eigentümer, zwei oder drei Autoren und eine ganze Reihe von Rezensenten ihre Kommentare abgegeben. Das Schreiben von Dokumentation, egal wie schwierig es ist, sich damit abzufinden, sollte der Arbeit am Code vorausgehen - der Moment, in dem keine einzige Zeile geschrieben wurde, ist am besten geeignet, um Kritik zu hören und Implementierungspläne anzupassen. Das fertige Projektdokument ist sehr praktisch, wenn Sie eine Roadmap erstellen, Arbeitsschritte hervorheben usw.
Konstruktionsdokumentation ist von Natur aus viel flexibler als das Leitbild, es ist kein Dogma, sondern eine lebende Substanz. Während des Entwicklungsprozesses müssen einige Details überarbeitet werden. Im Idealfall sollte die Dokumentation alle diese Änderungen in Echtzeit widerspiegeln, damit das Team auf dem Laufenden bleiben kann. In der Realität wird es leider oft nach der Veröffentlichung des Produkts bearbeitet.
Meetings
Viele Leute werden denken, dass es schön wäre, auch hier das Kreuzzeichen zu machen - Meetings haben unter Entwicklern einen ziemlich schlechten Ruf. Laut den Autoren liegt der Grund darin, dass sie schlecht organisiert sind und häufig dort eingesetzt werden, wo es sinnvoller wäre, sich einem asynchronen Kommunikationskanal zuzuwenden.
Ein gutes Beispiel für eine erfolglose Auswahl des Formats ist das „Meeting“, das mit einer bestimmten Regelmäßigkeit (normalerweise einmal pro Woche) und vielen Personen abgehalten wird. Normalerweise werden dort wichtige Ankündigungen gelesen, allgemeine Ergebnisse zusammengefasst und so weiter. Tatsächlich ist der gesamte Inhalt der Flyer sehr einfach und produktiv in eine elektronische Mailingliste zu übersetzen, außer in den Fällen, in denen genau eine breite kollektive Diskussion erforderlich ist.
Bei den Besprechungen, auf die Sie wirklich nicht verzichten können, sollten bei der Durchführung die folgenden Regeln beachtet werden:
- . – , , , . « » — . , - .
- , , . , . , , .
- . – .
- (, ). , – Google .
Mailinglisten
E-Mail ist ein sehr nützliches Tool zum Dokumentieren des Projektverlaufs im Hintergrund. Es ist viel einfacher, Informationen daraus zu extrahieren als aus Instant Messenger, wo es viel mehr Verkehr und viel weniger Regulierung gibt. Daher ist es ratsam, alle wichtigen Informationen in Mailinglisten zu senden, unabhängig davon, wo sie vorher geklungen haben: Kopien von Plänen und Notizen von Besprechungen, Ergebnisse von Diskussionen zu bestimmten Problemen, Projektdokumente, Fehleranalyse. Auf diese Weise wird ein zentrales Data Warehouse gebildet, in dem jederzeit zurückgegeben werden kann, um nicht nur bestimmte Informationen zu finden, sondern auch die Ursprünge von Entscheidungen und den Verlauf der Diskussion zu verfolgen. Natürlich muss das Archiv mit einer indizierten Suche ausgestattet sein.
Die Bedeutung der Dokumentation und dementsprechend der Mailings hängt davon ab, wie kompakt das Team im Raum platziert ist. Wenn einige Mitarbeiter remote arbeiten oder unregelmäßig im Büro erscheinen, wird die nachhaltige Praxis, wichtige Projektnachrichten per Post zu duplizieren, dringend erforderlich. Andernfalls werden die meisten Informationen, die "in der Luft liegen" (Diskussionen in Korridoren und in der Nähe von Tischen, mündliche Übermittlung neuer Informationen an diejenigen, die nicht an der Sitzung teilgenommen haben), an ihnen weitergegeben.
Wenn das Team groß und die Prozesse turbulent sind, werden die Teilnehmer bald in einem Strom heterogener Ankündigungen ertrinken. In dieser Situation ist die Dokumentation in verschiedene thematische Mailings (Entwicklung, Analyse des Programmcodes, Benutzerunterstützung, Testen usw.) unterteilt, an denen interessierte Mitarbeiter beteiligt sind. Es ist jedoch besser, mit einem Stream zu beginnen. Wenn eine Trennung erforderlich ist, wird dies Ihnen schnell mitgeteilt.
Online-Messenger
Messenger stehen irgendwo in der Mitte zwischen synchroner und asynchroner Kommunikation. Sie sind nicht optimal für die Dokumentation, aber für die schnelle Lösung von Problemen, insbesondere in verteilten Teams, unverzichtbar. Aus Sicht der Kommandokultur sind hier zwei Aspekte wichtig.
Erstens die Trennlinie zwischen privaten und öffentlichen Diskussionen. Die überwiegende Mehrheit der internen und kommerziellen Messenger bietet dem Benutzer die Möglichkeit, zwischen der Kommunikation mit einer bestimmten Person oder einer Gruppe von Personen zu wählen. Dies ist sehr praktisch. Laut Fitzpatrick und Sussman gab es in letzter Zeit jedoch eine Tendenz zur Isolation - Diskussionen finden zunehmend privat statt.
In mancher Hinsicht ist dies nicht schlecht - private Probleme werden definitiv nicht alle Mitarbeiter "verstopfen". Andererseits wird den Menschen die Möglichkeit genommen, den Verlauf der Diskussion zu verfolgen, ihre Kommentare einzufügen und sofort von den Änderungen zu erfahren. Neulinge verlieren auch viel, da sie viele wertvolle Informationen erhalten könnten, indem sie einfach aktive Diskussionen im allgemeinen Chat still lesen. Oft werden Diskussionen privat geführt, nicht weil sie zu nisch sind, sondern alle aus der gleichen Angst vor Verwundbarkeit: Sie möchten nicht vor allen Leuten Fragen stellen oder Vorschläge machen - was ist, wenn sie sich als dumm herausstellen? Entwickler sollten sich auf eine solche Motivation einlassen und versuchen, nicht zu verbergen, was klüger ist, um gemeinfrei zu bleiben.
Zweitens müssen Sie sich daran erinnern, dass Instant Messenger trotz aller sofortigen Reaktionen keinen vollständigen Ersatz für Live-Kommunikation darstellen. Sie haben keine Intonationen und Gesichtsausdrücke, die einige Sätze weicher oder klarer machen könnten. Dies erhöht das Risiko von Missverständnissen, die die Grundsätze der Bescheidenheit, des Respekts und des Vertrauens bedrohen, und dies sollte berücksichtigt werden.
Bug Tracking System
Dieses Tool ist nicht so häufig wie die oben genannten. Es kann unter bestimmten Bedingungen von großem Nutzen sein:
- Verfügbarkeit eines Verfahrens zur Verarbeitung und Sortierung von Fehlern, das deren rechtzeitige Registrierung und Korrektur sicherstellt. Wenn dem Debuggen des Systems nicht genügend Aufmerksamkeit geschenkt wird, wird es entweder nicht verwendet oder auf kleine Weise missbraucht.
- . « » , .
- . – .
- . , , .
Kommunikation als Teil der Entwicklung Die
Kommunikation im technischen Team erfolgt nicht nur um, sondern auch direkt innerhalb des Codes. Der Hauptkanal hier sind natürlich Entwicklerkommentare .
Die Autoren gehen kurz auf die Grundregeln des Code-Kommentierens ein, die wahrscheinlich jedem bekannt sind: Erklären Sie nicht, was getan wird, sondern warum es getan wird, versuchen Sie, auf der Ebene der Funktionen und Methoden zu kommentieren, lakonisch zu sein und sich nicht tragen zu lassen weg mit Details. Der Rest des Kommentarstils ist subjektiv, jedes Team entwickelt je nach den Bedürfnissen und der allgemeinen Atmosphäre seinen eigenen. Die Hauptsache ist, dass dieser allgemeine Stil im Prinzip existieren sollte; Die Tatsache der Einheitlichkeit ist in diesem Fall wichtiger als bestimmte Merkmale.
Eine andere Art der Kommunikation innerhalb des Codes ist die Zuordnung , dh die Signatur des Entwicklers in der Datei. Der Brauch, Ihren Namen in einem Dokument zu hinterlassen, reicht bis in die Antike zurück. In alten Programmen sieht man oft solche Autogramme:
Fitzpatrick und Sussman bestehen darauf, dass diese Unterschriften heute als anachronistisch angesehen werden sollten. Aus psychologischer Sicht bleibt der Wunsch, auf Urheberschaft hinzuweisen, natürlich und verständlich: Dies ist Ausdruck von Stolz und Verantwortungsbewusstsein für die geleistete Arbeit. Auf der praktischen Seite wirft dies jedoch mehr Probleme als Vorteile auf. Jetzt ist die Entwicklung, wie wir bereits im ersten Teil des Artikels festgestellt haben, zu einer Teamaktivität geworden. In der Realität können mehrere Personen gleichzeitig an einem Code beteiligt sein, was bedeutet, dass die Lösung des Problems der Urheberschaft zu Kontroversen, Ressentiments und letztendlich Zeitverschwendung führen kann.
In der aktuellen Umgebung ist es zweckmäßiger, die Urheberschaft auf Projektebene zu verfolgen, als direkt im Code. Wenn Sie genau herausfinden möchten, an wen Sie sich bei Fragen zu einem bestimmten Teil des Codes wenden können, hilft Ihnen das Versionskontrollsystem.
Nachdem wir den Kern der "menschlichen Dimension" in einem IT-Unternehmen von allen Seiten betrachtet haben, können wir uns den peripheren Schichten zuwenden: fremden Elementen, die Teams und Benutzer umgeben.