Coaching

Wie funktioniert Wissensübermittlung? Früher waren diese Fragen klarer zu beantworten: Es gab Literatur, in die man sich einarbeitetet. Beim Lesen waren »Kollateralschäden« in Form eines breiteren Wissenspektrums geradezu unvermeidlich, da man nicht so einfach die notwendigen Informationen von (letztlich höchst sinnvollen) Zusatzinformationen trennen konnte.

Dies hat sich geändert, die Tendenz, fehlendes Wissen aus einer Internetrecherche abzuleiten, hat das klassische Studium eines Buches weitgehend abgelöst. Dabei besteht jedoch die Gefahr, sich nur ein »Inselwissen« anzueignen und mehr oder minder ungeprüft Codeschnipsel und Halbwissen aus Blogs oder Foren zu kopieren und in seinen Code zu integrieren. Doch wie kann unter solchen Umständen ein profundes Wissen um die Programmierung einer komplexen Technologie wie der Oracle-Datenbank entstehen?

Basierend auf unseren Projekterfahrungen existieren zwei Möglichkeiten:

  1. Die Teammitglieder besuchen Schulungen und versuchen, das dort aufgezeigte Wissen auf ihre Projekte zu übertragen
  2. Ein erfahrenes Teammitglied nimmt sich den Kollegen an die Hand und entwickelt mit ihm zusammen eine Funktionalität, um ihm das Wissen zu vermitteln.

Schulungen haben den Nachteil, dass in drei oder fünf Tagen nicht das Wissen aufgebaut werden kann, das erforderlich wäre, um wirklich umfassend zu verstehen, welche Optionen zur Lösung einer Problemstellung zur Verfügung stehen. Zudem leiden diese Schulungen darunter, dass normalerweise nur solche Schulungen ausgewählt werden, die aus Sicht des Entwicklers für das Problem sinnvoll sind. Diese Entscheidung ist oftmals durch mangelnde Kenntnis über die Alternativen suboptimal.

Der erfahrene Kollege, wenn es diesen im Projekt gibt, ist normalerweise auch der am meisten belastete Kollege des Teams. Daher ist ein Wissenstransfer schwierig. Zudem: Hat auch dieser Kollege ausreichend alternative Projekterfahrung, um Alternativen wirklich abschätzen zu können, oder ist er deshalb erfahren, weil er sich einfach schon länger im »eigenen Saft des Projekts gedreht« hat? Ein weiteres Problem besteht häufig darin, dass ein erfahrener Entwickler nicht notwendigerweise auch ein erfahrener Didakt sein muss.

Coaching greift an genau diesem Punkt an. Es kommen erfahrene, externe Kollegen ins Team, deren Aufgabe darin besteht, 

  • die Problemstellung des Projekts zu erfassen
  • auf Basis der eigenen Erfahrung, den Anforderungen aus dem Projekt und den (fachlichen und personellen) Möglichkeiten des Teams Lösungsvarianten vorzuschlagen
  • die Lösung, auf die man sich geeinigt hat, zusammen mit dem Team zu realisieren
  • durch interne Schulungen oder Workshops das Wissen im Team zu verbreiten und zu stabilisieren
  • und sich idealerweise nach einiger Zeit überflüssig zu machen, weil das Team die eingeschlagene Richtung selbständig weiter verfolgen kann.

Dabei sollte sich das Coaching nicht nur auf rein fachliche Aspekte der Programmierung beziehen, sondern auch die Infrastruktur einbeziehen:

  • Wie kann der Code sinnvoll versioniert werden?
  • Besteht eine CI/CD-Infrastruktur, wie kann diese angemessen aufgebaut werden?
  • Gibt es ein automatisiertes Testkonzept, wie kann es realisiert werden?
  • Ist die Architektur der Anwendung angemessen, wartbar und ausreichend sicher?

Ein Problem des Coachings besteht in einem einfachen Punkt:

Trauen Sie dem Coach genügend Fachwissen zu oder wird dieser selbsternannte Coach mehr Schaden anrichten als Lösungen schaffen?

Vertrauen erwächst zunächst aus der Referenzenliste, dann aus den Veröffentlichungen, schließlich aus einem persönlichen Kennenlernen und einem Versuch in einem begrenzten Projekt. Hierfür stehen wir gern zur Verfügung. Wir favorisieren Projekte, in denen wir unser Wissen an das Team weitergeben können. Letztlich überwiegt die persönliche Genugtuung, die positive Entwicklung eines Teams zu verfolgen, der Versuchung, das Projekt über Gebühr zu verlängern. Hierfür stehen wir mit unserem Namen und aus voller Überzeugung. Testen Sie uns!