This text is only available in german.
Vor einem halben Jahr habe ich meine ersten Erfahrungen in einem größeren Entwicklungsteam [dokumentiert] (https://stevenschwenke.de/node/56){:target=”_blank”} und möchte diese nun erweitern und ergänzen. Auch im zweiten Teil möchte ich darauf hinweisen, dass dies ein Erfahrungsbericht ist, welcher keinen Anspruch auf Vollständigkeit oder universelle Anwendbarkeit erhebt.
1. Nachtrag #1 - Bibliotheken
Punkt fünf des letzten Berichtes handelte davon, dass Softwareentwickler Bücher und Fachartikel im Netz lesen und zusätzlich wenigstens einen Teil ihrer Arbeitszeit zur freien Informationsbeschaffung nutzen sollten. Nach dem Verfassen des ersten Berichts erzählte mir ein Freund, ebenfalls Softwareentwickler, stolz von seiner neuesten Eigenimplementierung. Was er da entwickelt hat, war ohne Frage interessant und hat eine Menge Arbeit gemacht. Jedoch gibt es genau diese Funktion heutzutage in fast allen Smartphones und neueren Laptops, wobei dort bereits vorhandene Bibliotheken genutzt wurden. Viel Zeit und Geld des Kunden hätte gespart werden können, wenn vorher nach einer entsprechenden Bibliothek gesucht worden wäre. Diese Ersparnis setzt allerdings auch “blindes Googlen” seitens des Entwicklers voraus. Im Druck nahender Deadlines ist das Finden und Bewerten einer passenden Bibliothek meist nicht zu schaffen. Hinzu kommt die Einarbeitung und Anpassung auf das aktuelle Problem. Deshalb muss ein Entwickler die Zeit (und Motviation) haben, sich während des Alltags in solche Bibliotheken einzuarbeiten.
2. “Der Bus-Faktor ist immer zu klein”
Die Nützlichkeit von Kaffeepausen mit den Kollegen wurde ebenfalls im letzten Bericht erwähnt und soll nun um ein Beispiel bereichert werden. So erhöht soziale Interaktion nicht nur das Wohlbefinden der Mitarbeiter, sondern steigert nebenbei den Bus-Faktor. Als Bus-Faktor wird die Anzahl von Menschen verstanden, die von einem Bus überfahren oder sonst irgendwie dauerhaft verhindert sein müssen, damit ein Projekt zum Stillstand kommt. Meinen Erfahrungen nach liegt dieser Faktor meist bei genau 1. So gibt es in vielen Projekten genau einen Spezialisten pro Aufgabenbereich. Im Normalbetrieb wird diese Besetzung als effizient und kostensparend empfunden. Wenn der Experte jedoch verhindert ist, kommt es zum Stillstand des entsprechenden Aufgabenbereiches. Im Alltag macht sich über diesen Worst-Case jedoch selten Jemand Gedanken. Niemand wird sich zum Beispiel dafür interessieren, wer eigentlich Zugang zur Datenbank hat. Ist der Datenbank-Experte aber mal nicht da und soll trotzdem zeitnah irgendwas mit der Datenbank gemacht werden, wird die Unterbesetzung deutlich. Dann ist es jedoch oft zu spät: Das Passwort steht (korrekterweise) nicht unter der Tastatur und der riesige Haufen ER-Schemas auf dem Schreibtisch des Datenbankers ist von keinem anderen Teammitglied lesbar.
Deshalb sollten geschäftskritische Funktionalitäten und Infrastruktur identifiziert werden. Es sollte bewußt gemacht werden, wer die wirklichen Wissensträger sind und für diese ein dauerhaftes Backup in Form eines Stellvertreters angelegt werden. Damit dieses Backup auf dem Laufenden bleibt, sind z.B. wöchentliche gemeinsame Reviews oder verordnete Kaffeepausen zu organisieren. Besonders elegant und ebenso selten umgesetzt ist natürlich das Anfertigen einer lesbaren, sich selbst aktualisierenden und für alle Teammitglieder zugänglichen Dokumentation.
3. “Das Google-Prinzip”
Google lockt mit einem besonderen Arbeitszeitmodell besonders junge Fachkräfte. So können 20% der Arbeitszeit und sämtliche Ressourcen des Arbeitsplatzes für ein eigenes Projekt verwendet werden. In der Praxis läuft das also auf eine vier-Tage-Woche hinaus, während am fünften Tag an einem “Spielprojekt” gearbeitet wird, welches am Ende Google gehört. Als Folge davon beschäftigen sich Mitarbeiter freiwillig und höchst motiviert mit einem oft anspruchsvollen Projekt, lernen dabei, tauschen sich mit Kollegen aus, entwickeln neue Ideen und machen freiwillig Überstunden. Der für mich wichtigste Aspekt ist dabei das autodidaktisch erworbene Wissen, welches jedem anderen Projekt dieses Mitarbeiters zugute kommt. Laut Freunden mit langjähriger Softwareentwicklungserfahrung sind 20% der Arbeitszeit für solch eine Fortbildung eigentlich noch zu wenig, “Es sollten 1/4 bis 1/3 der Arbeitszeit sein”. Solch eine Forderung dürfte im Rahmen der momentanen kommerziellen Softwareentwicklung in größeren Unternehmen auf taube Ohren oder gar Gelächter stoßen. Kleinere Firmen und besonders Startups beweisen jedoch oft, dass dieses Vorgehen nicht nur als Witz zu verstehen ist. Nutzt man die durch ein freiwillig durchgeführtes Projekt auftretende Energie als Teamleiter richtig, steigt sowohl die Motivation, als auch die Produktivität der Mitarbeiter.
4. “Der Fehler ist nicht da, wo du denkst.”
Desöfteren meinte ich beim Bugfixing schnell erfasst zu haben, was den Bug ausmacht und an welcher Stelle im Code welche Änderung vorzunehmen ist. Dementsprechend habe ich sofort mit den Änderungen begonnen. Oft hat sich nach einer Weile herausgestellt, dass der Fehler gar nicht da war, wo ich ihn vermutet hatte. Der schnelle Fix hat die Symptome gelindert, aber nicht die Ursache behoben. Deswegen ist es nicht verkehrt, nach dem Finden eines Fehlers kurz aus dem Fenster schauen und über die Konsequenzen der erdachten Änderung nachzudenken. Ist die schnelle Idee wirklich die beste Lösung? Wird dadurch die Architektur beeinflußt? Entspricht es dem Objektmodell? Diese Fragen sollte man sich besonders bei umfangreichen Änderungen stellen. Aus dem Fenster starrende Entwickler müssen also kein Zeichen von Faulheit sein.
5. “Insiderwitze sind gut. Insiderwitze sind schlecht.”
Oft habe ich in Teamsitzungen erlebt, dass Insider-Witze in Form von Kommentaren oder dem Nennen von Schlagwörtern gerissen wurden. Mal war es der Name einer ungeliebten Bibliothek, mal die Bezeichnung für ein nicht durchsetzbares Konzept. Solche Meme stärken das Gruppenbewusstsein ungemein, da gemeinsame Erlebnisse immer verbinden. Zusätzlich bleiben kritische Situationen im Bewusstsein und werden so wahrscheinlich weniger oft wiederholt. Dieser Effekt kann von Teamleitern gezielt ausgenutzt werden, indem Insiderwitze nicht nur akzeptiert, sondern gar gefördert werden.
Neben diesen positiven Eigenschaften können Insider für Neulinge zu einem Ausgrenzungsgefühl führen, da sie oft nur von langjährigen Teammitlgliedern verstanden werden können. Ich selbst wurde mehrere Male durch eben solche Witze inhaltlich abgehängt. Es ist also darauf zu achten, dass auch Neue im Team nach einer gewissen Eingewöhnungszeit wirklich zum Team gehören und wenigstens die wichtigsten Konzepte verstehen.
Der hier beschriebene Effekt ist nicht neu und wurde z.B. in ähnlicher Form von Tom DeMarco in “Peopleware” beschrieben. Dort hatte das “Black Testing Team” den Ruf, jede Software “kaputt testen” zu können. Das verbindende Element war z.B. die einheitlich getragene, schwarze Kleidung und der aktiv geförderte Ruf, beim Testen von Software gnadenlos gründlich zu sein.
6. “Das Problem ist komplex. Sehr gut!”
Die Worte “komplex” und “kompliziert” werden oft synonym verwendet, was falsch ist. Komplexe bestehen aus vielen Teilen, während etwas kompliziertes viele Wechselwirkungen innerhalb der einzelnen Teile aufweist und das große Ganze so schwieriger zu verstehen ist. In gewisser Weise sind die beiden Begriffe vergleichbar mit dem Prinzip der “High Cohesion, loose Coupling”. Es ist also anzustreben, ein kompliziertes Problem zu einem komplexen zu machen und Modularisierung zu fördern. Deshalb sind komplexe Probleme komplizierten Problemen vorzuziehen.
7. “Gib feedback!”
Ein sehr oft gehörtes Problem ist das fehlende Feedback vom Teamleiter oder den Entscheidungsträgern an die Softwareentwickler. Professionellen Entwicklern ist zwar bewußt, wie gut sie sind. Trotzdem möchte jeder Mensch wissen, wo er in der Leistungsskala des jeweiligen Teams oder Unternehmens steht. Demnach sind regelmäßige Feedback-Gespräche mit allen Mitgliedern des Teams unerlässlich und sollten den üblichen Regeln des Feedbacks entsprechen. (erst positive Aspekte, dann negative, dann Gespräch über Weiterentwicklung)