Stell Dir vor, Du bist Projektleiter oder Projektleiterin in der Software-Entwicklung. Du hast in Deinem Projekt die typische Teamkonstellation, dass unterschiedliche Wissensstände im (Projekt-)Team zum Produkt oder Service vorliegen. Der beauftragte Projektliefergegenstand, der umgesetzt werden soll, wurde verstanden, aber in den Köpfen der Teams gibt es viele unterschiedliche Bilder dazu. Als Projektleiter hast Du die Aufgabe, eine gemeinsame Sprache zu finden und diese zum Beispiel in einem Big Picture zusammenzuführen.
Beim Know-how Aufbau sind unterschiedliche Sichtweisen aus den Fachbereichen, Erfahrungen von einzelnen Mitarbeitern, externen Projektmitarbeitern und dem Management zu berücksichtigen, um schließlich alle Beteiligten über diesen Transfer an den gewonnen Erfahrungen und Erkenntnissen zu partizipieren.
Das Produkt verstehen (ASSETS)
Du gibst ein Versprechen an Deinen Kunden/ Auftraggeber, für den das Produkt entwickelt wird, dass das Produkt ein Problem löst oder einen bestimmten Nutzen für sein Business bringt. Durch Anforderungen soll ein Ziel erreicht werden, von dem sich der Anforderer einen Nutzen verspricht. Kurz gesagt: Was kann das Produkt?
Know-how in den (Projekt-)Teams aufzubauen, aber auch vom Product Ownern zu erhalten, so dass ein Produkt für alle Stakeholder klar dargestellt ist, ist erforderlich. Dabei geht es in erster Linie nicht nur um die Transformation des Produkts, einen Mehrwert abzubilden oder um die Funktionalität des Produkts zu beschreiben. Sondern es geht darum, dass für das Produkt ein ausgeprägtes Verständnis in den Teams entstehen muss. Das bedeutet auf einer High-Level-Ebene, ich habe Produkt XY und das Produkt hat die Produkteigenschaften A-Z. Die Produkteigenschaften müssen weiter definiert werden.
Neulich las ich auf einem Kaffeebecher von einem IT-Unternehmen den Slogan: „Java ist kein Kaffee“, Produktverständnis einfach karikiert. Um bei dem Beispiel Kaffeebecher und unterschiedlichen Sichtweisen zu bleiben: Du sprichst mit mehreren Personen über das Design eines Kaffeebechers und glaubst, alle haben dazu das gleiche Bild im Kopf, wenn diese Personen einen Kaffeebecher malen, wird auf jedem Bild der Kaffeebecher eine andere Form und Farbe haben. Wir reden über einen Kaffeebecher, meinen aber beispielsweise einen blauen Kaffeebecher mit einem eckigen Griff und roten Punkten oder einen brauen Coffee-to-go-Becher mit einem weißen Deckel.
Den Zugang zum Produkt ermöglichen (CHANGE)
Beim Know-how Aufbau für ein Produkt oder Service geht es insbesondere um den Austausch unter Kollegen, es gibt verschiedene Strategien, um Know-how aufzubauen. Ein Ziel ist, in unbekanntes Terrain einzutreten und jedem Beteiligten einen Einstieg zu ermöglichen. Dies ist möglich über Offenheit.
Die Herausforderung ist, die unterschiedlichen Erfahrungen der Mitarbeiter zusammenzuführen, hierbei sollte ein Brainstorming der Start sein. Alle Fragen zum Produkt dürfen gestellt werden, bis hin zu ‚was machen wir eigentlich‘, um unsere Ziele zu erreichen, über ‚wie machen wir etwas‘.
Der Weg dorthin ist gesprächsintensiv, denn man stößt auf Widerstand, ich habe schon erlebt, dass dann solche Aussagen kommen:
- Sowas kannst Du nicht fragen!
- Ach, das Produkt ist doch klar, das wissen alle!
- Die Information braucht nicht jeder!
- Das ist aber viel zu kritisch.
- Wofür brauchen wir das?
- Wenn ich das gewusst hätte…
Die Sichtweise auf „was kann das Produkt eigentlich/ welcher Geschäftsfall liegt vor“, wird bei allen Stakeholdern sehr unterschiedlich sein, diese Sichtweise muss geschärft werden.
Die richtige Sprache im Team finden (WORKFLOW)
Mit Fokus auf „was hilft dem Thema, der Sache“ kann somit eine gute Kommunikation entstehen. Danach können Aufgaben verteilt werden, bestimmte Fragen zu erarbeiten. Um dann wieder zusammenzukommen und diese zu besprechen. Nur ein Workshop wird dafür nicht ausreichen, das ist ein Entstehungsprozess, um auf einen Konsens zu kommen. Die Ergebnisse sind immer in einer Präsentation oder Tool dokumentieren.
Um das Produkt, die Idee, den Service zu verstehen, müssen naive Fragen gestellt werden, im agilen Umfeld ist dafür die Formulierung von User Stories empfehlenswert. User Stories funktionieren auch bei komplexen technischen Services, wenn man abstrakt drauf schaut.
Papier ist geduldig, wenn man im Team gemeinsam formuliert, ist das ein Game-Changer, weil über die gemeinsame Präzisierung viel Erfahrung gebündelt wird und eine gute Diskussion entsteht.
In der Softwareentwicklung kann die Architektur den Softwaretestern auf Basis von Test Cases oder der System-Umgebung das Produkt, die Produkteigenschaften, den Service erklären.
Für den Know-how Aufbau muss ein festgelegter Teilnehmerkreis überlegen, wie Know-how aufgebaut werden soll, dafür gibt es unterschiedliche Herangehensweisen:
- das Produkt offen diskutieren
- Delta zum neuen Release abbilden und den Mehrwert besprechen
- Test Cases validieren und reviewen
- Ist-Daten von Anforderungen zusammenführen
- User Stories formulieren
- Backlog bewerten
Nach dem Projekt ist vor dem Projekt (LEARNINGS)
Der Know-how Aufbau kann vor einem Projekt oder während eines Projekts durchgeführt werden. Mein Erfahrungswert ist, dass das während des Projekts stattfindet. Die Ergebnisse vom durchgeführten Know-how Aufbau kannst Du mitnehmen und im weiteren Projektverlauf weiterentwickeln:
- für Deine Projekt- oder Produktgeschichte, die in Story Telling mündet,
- in der Softwareentwicklung für den Aufbau von Feature Teams (setzen Features von Anfang bis Ende um),
- ein Big Picture, das die Produkttransformation abbildet,
- für weniger Fehler im Entwicklungsprozess,
- für eine klare technische Abgrenzung und Schnittstellen,
- Werte schaffen, das sind Assets für Auftragnehmer und Auftraggeber,
- Vertrauen und gute Kommunikation durch Offenheit in den Teams,
- last but not least: ein klares Produktverständnis darüber, was der Produktnutzen ist