Artikel versenden

Von LKWs und Bussen – Wissensmanagement in der Software-Entwicklung




 

// / /

Schon Heraklit von Ephesus wusste „Nichts ist so beständig wie der Wandel“. Dies gilt insbesondere für Unternehmen. Jeder Verantwortliche im Projekt-Geschäft muss damit rechnen, dass Wissens-Träger in Zukunft nicht mehr zur Verfügung stehen könnten. Sei es, weil sie den Arbeitsplatz wechseln, Verträge mit externen Firmen auslaufen oder sie aus anderen Gründen nicht mehr verfügbar sind. Bei wichtigen politischen Amtsträgern minimiert man die Möglichkeit des gleichzeitigen Ausfalls mehrerer Personen, indem sie z.B. nicht gemeinsam mit einem Flugzeug verreisen dürfen.

Im Bereich der Software-Entwicklung ist Wissen nicht an Ämter gebunden. Daher haben wir die Möglichkeit Methoden und Werkzeuge einzusetzen, um Wissen besser zu verteilen und somit die Auswirkungen eines möglichen Verlusts zu minimieren. Doch bevor wir uns Mittel und Wege überlegen, wie wir Wissen verteilen, brauchen wir Metriken, die uns dabei helfen zu sehen und zu verstehen, ob wir ein Problem haben und wie groß unser mögliches Problem ist.

In jedem Projekt gibt es Mitarbeiter, Teams oder andere Personengruppen, die in bestimmten Bereichen des Projektes Wissensmonopole inne haben. Dafür gibt es in der Softwareentwicklung zwei (auch unter anderem Namen und mit anderem Berechnungsverfahren bekannte) Kennzahlen.

TruckNumber (oder Truck/Bus-Faktor)

Die TruckNumber gibt die Anzahl der Personen an, die, wenn sie von einem LKW überfahren werden würden (oder einfach nur das Unternehmen verlassen, ihren Lebensstil ändern würden etc.), das Projekt ernsthaft in Gefahr brächten. Also erhöht jeder, der der einzige Spezialist für einen bestimmten Bereich innerhalb des Projektes ist, die TruckNumber um eins. Wenn er ginge, gäbe es niemanden mehr, der diesen Bereich verwalten und pflegen könnte. Bei gut funktionierenden Teams und bei guter Cross-Team Kommunikation sollte diese Nummer bei 0 sein. Jede Position ist quasi mindestens doppelt besetzt. Ist die TruckNumber größer, so ist dies ein Indikator dafür, dass zu wenig Tools und Methoden verwendet werden, die Wissen im Unternehmen verteilen.

SmallestBusQueueAccidentNumber

Die SmallestBusQueueAccidentNumber ist die kleinste Anzahl an Mitarbeitern die bei einem gemeinsamen Busunfall das Projekt ernsthaft in Gefahr brächten. Um diese Zahl zu bestimmen, wählt man z.B. die Mitarbeiter, die auch die TruckNumber erhöhen würden oder die kleinste Gruppe an Spezialisten für einen bestimmten Bereich. Hier gilt also, je größer die Zahl, desto besser ist das Wissen im Projekt distribuiert. Bestimmt man also diese Zahl, so weiß man ebenfalls, in welchem Bereich das Wissen am schlechtesten verteilt ist. Das Optimum ist hier, wenn die SmallestBusQueueAccidentNumber gleich der Größe der am Projekt beteiligten Personen ist.

Sollte die TruckNumber größer 0 sein, so sind Techniken wie Pair Programming empfehlenswert und ratsam. Beim Pair Programming arbeiten zwei Entwickler gemeinsam an einem Problem und Rechner. Einer der beiden nimmt die Rollte des Navigators (der Wissensträger) ein, der andere die des Drivers. Der Navigator sagt, wo es lang geht, was und wie es programmiert wird. Der Driver implementiert, was der Navigator vorgibt. So lernt der Driver vom Navigator und das Wissen verteilt sich auf mehrere Schultern, die TruckNumber verringert sich.

Stellt man fest, dass die SmallestBusQueueAccidentNumber klein ist, so ist dies ein Indikator dafür, dass die Kommunikation zwischen den Teams oder einzelnen Entwicklern nicht optimal ist. Als Abhilfe empfehle ich Social Events, wie z.B. Hackathons, Coding Dojos oder Brown Bag Talks. Vor allem der Brown Bag Talk, bei dem eine Person während des Mittagessens zu einem bestimmten Thema eine kurze Präsentation hält, ist mit nur geringen Kosten und wenig Aufwand verbunden und dennoch sehr effektiv.
Doch auch wenn Veranstaltungen Zeit und somit auch Geld kosten, kann man sie als Chance begreifen, die Produktivität nachhaltig zu steigern und die SmallestBusQueueAccidentNumber zu verringern. So ist man für mögliche, auch plötzliche Veränderungen gewappnet. Denn, um es mit Heinemann zu sagen, „Wer nichts verändern will, wird auch das verlieren, was er bewahren möchte.“

Quelle Foto: © twixx – Fotolia.com

| Keine Kommentare

 
Top | Impressum | Datenschutz