Entwicklung, Qualitätssicherung und Betrieb – schon bei der Zusammenarbeit in den technischen Disziplinen hapert es oft. Für ein gutes Gelingen eines Projekts müssen in die Projektarbeit weitere Disziplinen integriert werden. Diese Integration ist nicht leicht, lohnt sich aber.
Eine gute Zielsetzung & Teamregeln begründen einen gemeinschaftlichen Projekterfolg
Auf Entwicklerkonferenzen wird in den Kaffeepausen neben technischen Herausforderungen und den neuesten Software-Lösungen gerne über unbequemen Designer im aktuellen Projekt gelästert. Diese Schilderungen des Arbeitsalltags münden gerne in Ausbrüchen über die „unfähigen Pixelschubser“.
Die Gesprächsteilnehmer eint der Wille, ein gutes Arbeitsergebnis abliefern zu wollen. Dieser Wille wird unterlaufen durch diejenigen Projektbeteiligten, die die Arbeit durch falsche oder mangelhafte Zulieferungen erschweren bzw. die Arbeit nahezu unmöglich machen. Die Zuarbeit anderer wird als aktive Behinderung der eigenen Exzellenz empfunden. Das wird nicht emotionslos hingenommen, sondern dieses Unterlaufen des eigenen Qualitätsanspruchs wird deutlich aufgezeigt. Schließlich möchte jeder gut liefern. Und wer hat es schon gerne, wenn er nicht so exzellent liefern kann, wie er könnte, weil das aktiv verhindert wird?
Diese Wahrheit gilt aller Wahrscheinlichkeit nach auch für alle anderen Projektbeteiligten. Die Projektmanager, Konzepter, Designer, Berater, Qualitätsmanager, DevOps und Ops möchten auch ihr Bestes geben – und fühlen sich womöglich durch die Aktivitäten anderer eingeschränkt.
Arbeitsalltag: implizites Wasserfall- bzw. V-Modell
Wasserfall- bzw. V-Modell, in welchem IT-Projekte arbeitsteilig in verschiedenen Disziplinen nacheinander gelöst werden. Während die Leitungsebene – als interner Auftraggeber oder zusammen mit dem externen Auftraggeber – die Zielsetzung für das Projekt festlegt, erfolgt in Arbeitsschritten die Bearbeitung des Projekts:
- Formulierung der System-Architektur
- Aufsetzen der System-Architektur
- Konzeption der Software-Architektur
- Implementierung
- Tests
- Auslieferung
Graphisches Design, inhaltliche Texte sowie Grafiken werden im Prozess zugeliefert. Damit liegen sind wesentliche Komponenten außerhalb des Entwicklungsteams. Sowohl die Zielsetzung des Projekts als auch die grafische Ausgestaltung sind im Selbstverständnis vieler Projektteams Zulieferungen. Alternativ dazu wird die Zielsetzung des Projekts nicht reflektiert, entscheidend sie die Feature-Liste.
Aber auch Entwicklungsteam, die nach agiler Methodik arbeiten, schließen häufig andere, Nicht-IT-Disziplinen aus dem eigentlichen Projektteam aus. Auch hier stellt sich die Frage, ob dieser Zuschnitt des Projektteams zielführend ist.
Wer ist das Projektteam?
Fragt man Projektbeteiligte danach, wer genau zum Projektteam gehört, werden oft sehr unterschiedliche Antworten (zum Teil mit extrem kleinen Schnittmengen!) gegeben. Durch plötzlich im Projekt auftauchende Personen, „die auch noch eine Meinung haben“, wird das häufig das eigentliche Projektziel konterkariert.
Wie soll ein Team sich auf ein gemeinsames Ziel und die Durchführungsform einigen, wenn gar nicht klar ist, wer an dieser Ziel- und Regeldefinition beteiligt ist?
Zum Beginn des Projekts sind daher die Beteiligten, deren Rollen und Beitrag zum Projekt zu bestimmen. Dabei ist auch zu klären, welche Disziplinen im Team mitarbeiten – und welcher Beitrag als Zulieferung für das Projektteam verstanden wird. Inhaltliche Aussagen werden vom Projektteam getroffen. Zulieferungen erfolgen ohne Einflussnahme auf die Projektleitlinien. Gleichzeitig ist zu klären, ob und welcher Form Mitarbeiter bzw. Kunden, die zukünftig den Regelbetrieb der Anwendung übernehmen werden, in die Teamarbeit integriert werden. Dies kann in Form einer Zulieferung erfolgen (z.B. über regelmäßige Informationstreffen über den Projektstand); es kann aber auch eine direkte Teambeteiligung (z.B. für den Betrieb) sinnvoll sein.
Während des Projekts kann graphisches Design nur einzelne Schritte bzw. Status der Anwendung visualisieren. Der „Joy of Use“, das Anwendererlebnis [2], entsteht bei der zusammenhängenden Nutzung der einzeln definierten Schritte. Dabei ist Teil dieses Erlebnisses, ob und welche Daten in einer adäquaten (d.h. vom Anwender erwarteten) Aufbereitungsform in den einzelnen Schritten angezeigt und integriert werden. Zur Ausgestaltung dieses Anwendererlebnis sind also mindestens zwei Disziplinen gefragt. Meist wird auch das Know-How des Marketing zur Markenführung und -gestaltung notwendig sein, um das Projektziel einzulösen.
Die Bedeutung des Marketing wächst für die IT – und umgekehrt
Die Technologieberatung Gartner prognostiziert [3], dass in fünf Jahren die Marketing-Ausgaben für Informationstechnologie höher als die der IT-Abteilungen selbst sein werden. Die Denkweise des Marketing wird die Arbeit in und mit der IT entsprechend stärker prägen. Gleichzeitig wachsen die Anforderungen in der IT, um sichere, performante und wartbare Anwendungen bereitzustellen und über Zeit betreiben zu können. Diese gleichberechtigten Zielsetzungen sind während der Definition des Projektziels zu reflektieren und detailliert zu definieren.
Die IT hat am Gelingen von Projekten ihren Anteil, der über die Sicherstellung qualitätsvoller Anwendungen hinausgeht. Lars Hinrichs, Gründer von XING, kommentiert diesen Beitrag mit: „I am in love with engineers – because engineers innovate … businessmen copy“ [4]
Innovation entsteht durch Kombination bekannter Mechanismen und Techniken, welche in kleinen Funktionen weiterentwickelt wird. Durch die Kombination unterschiedlicher Disziplinen können das Wissen unterschiedlicher Bereiche zusammengebracht und innovativ erweitert werden. Damit dies geschieht, müssen die Beteiligten sich mit ihren Stärken und ihrem Beitrag zum Projekt anerkennen.
Leitung, Marketing & IT: täglich gemeinsam am Projekt
Arbeitet ein Unternehmen stark arbeitsteilig und mit stark gekapselten Projektphasen, erfordert dies in der Leitungsebene ein hohes Maß an detailliertem Wissen über die Anforderungen, die in den einzelnen Disziplinen formuliert werden. Liegt dieses Detailwissen nicht vor, werden Umsetzungsprobleme entstehen, weil die einzelnen Disziplinen sich gegenseitig in ihrer Arbeit behindern werden.
Dennoch ist es nach wie vor üblich, dass Unternehmensleitungen Zielsetzung und Vorgehensmodelle vorab definieren. Dieser häufig anzutreffenden Arbeitsteilung steht der agile Ansatz gegenüber. In den zwölf Prinzipien des agilen Manifests heißt es: „Business people and developers must work together daily throughout the project.“ [1] Damit fordern die Autoren und alle Mitzeichner des agilen Manifests, dass aus Zielgebern und Zulieferern der Wasserfall-Organisation Team-Mitglieder im agilen Projekt werden.
Teamarbeit: Ziele & Regeln
Erfolgreiche Teamarbeit gründet auf einem gemeinsamen Verständnis des Projektziels und gemeinsam erarbeiteten und gelebten Teamregeln.
Werden Teamregeln nicht explizit definiert, so werden sich Teamregeln implizit herausbilden. Für die tägliche Arbeit sind nicht explizit verabredete, sondern leise entstandene Regeln oft hinderlich. Erfordern diese „ungesagten“ Regeln doch von allen Interpretationsarbeit. Dabei werden häufig Denkmodelle und Erklärungsansätze für implizites Verhalten entwickelt, die oft in der Sache falsch sind. Daher ist es wichtig, das „Wie arbeiten wir am Projekt und zusammen?“ für alle nachvollziehbar zu klären.
Der erste Wurf der Teamregeln entsteht in einem initialen Meeting am Beginn des Projekts. Danach treffen sich alle Teammitglieder rhythmisch wiederkehrend (z.B. als Retrospektive), um die bisherige Arbeitsweise zu analysieren und durch neue Ansätze zu optimieren.
Die Frage „Wie arbeiten wir am Besten zusammen“ wird auf vielen Ebenen beantwortet. Mögliche Fragen sind:
- Wie ist der genaue Prozessablauf im Projekt? Wer macht wann was?
- Wer kann sich wann in welcher Form einbringen?
- Wie werden Entscheidungen getroffen? Können diese revidiert werden? Wenn ja, wie?
- Wie dokumentieren wir unsere Arbeit?
- Welche Umgangsformen finden wir gut? Welche meiden wir?
- Wann sind unsere Kernarbeitszeiten?
Damit die Teamregeln stets präsent sind, werden diese in einer Wandzeitung festgehalten bzw. in virtuellen Teams im Dashboard der Teamsoftware angezeigt.
Bei der Formulierung der Teamregeln ist besonders auf die Kommunikation zu achten. Wie redet das Team miteinander? Wie findet der Austausch über die nächsten Aufgaben statt? Wie werden Arbeitsergebnisse und Aufgaben dokumentiert?
Das Team einigt sich über Kommunikations- und Eskalationswege. Die Team-Mitglieder legen fest, auf welchem Weg welche Informationen geteilt, Aufgaben verteilt und Arbeitsergebnise gespeichert bzw. dokumentiert werden.
Viele Teams möchten sich zunächst nicht explizit über Kommunikation austauschen. Schließlich ist man ja „professionell“ und schon länger im Beruf. Diese Art der Meta-Kommunikation wird als überflüssig empfunden.
Kommunikationsformen können sich aber – auch in einem Unternehmen – fundamental unterscheiden. Diese Unterschiede treten in interdisziplinären Teams zu Tage. Deswegen ist es wichtig, sich auf einen „Grundton“ zu einigen und bei Bedarf direkt Kommunikationsformen zu benennen, die die jeweiligen Team-Mitglieder in der Arbeit behindern. Die häufig gemachte Ansage „Wir machen das erstmal heil, und hinterher sprechen wir darüber“ wird in vielen Teams nicht eingelöst. Deswegen ist der Austausch über störende Kommunikationsformen direkt zu suchen. Das Gleiche gilt für unterlaufende Erwartungshaltungen. Werden diese nicht erfüllt, befindet sich das Team im Bereich der ungesagten Erwartungen oder Teamregeln. Auch hier ist direktes Explizieren erforderlich!
Es ist auch zu klären, wie der elektronische Austausch aller Informationen stattfindet. Während die IT (egal, ob Entwickler oder Betrieb) eher auf Ticketsysteme steht, finden sich im Bereich von Marketing und Design eher Verfechter der E-Mail-Kommunikation (und -dokumentation).
Beide Vorgehen meiden das direkte Gespräch. Dies ist aber notwendig, damit unterschiedliche Sichtweisen und Vorgehen im Projektverlauf gesehen und gemeinsam auf Kurs gebracht werden können. Das Projektteam sollte sich regelmäßig, möglichst täglich, über den aktuellen Stand und die anstehenden Aufgaben austauschen. Bei diesem Austausch ist darauf zu achten, dass die am Austausch Beteiligten alle Informationen aufnehmen und bewerten können. Dabei ist die Angabe von Dateibezeichnungen für Konzeptionsdokumente genauso wenig zielführend wie die Meldung, dass das Ticket #123 gefixt sei.
Neben der elektronischen Dokumentation ist die Visualisierung auf einer Wandzeitung zu empfehlen. Die Wandzeitung wird so zum Mittelpunkt des direkten Austauschs über das Projekt. Alle Beteiligten können mit einem Blick anstehende und abgearbeiteteAufgaben erkennen. Die gemeinsame Risikoanalyse fällt mit Blick auf die Wandzeitung leichter, weil Abhängigkeiten direkt zu erkennen sind.
Auf die Kommunikation kommt es an
Die Wandzeitung bildet die Brücke in die elektronische Dokumentation des Projekts (d.h. zum Projekttool oder Ticketsystem). Die Benennung der Aufgaben auf der Wandzeitung sollte mit dem elektronischen Dokumentationssysteme übereinstimmen (oder es sollten die geltenden Identifikationsnummern zusätzlich auf der Wandzeitung genannt werden). Die Benennungen für die Aufgaben sind so zu wählen, dass alle Projektbeteiligten diese verstehen.
Die Fachsprachen der an Software-Projekten beteiligten Disziplinen sind sehr unterschiedlich. Neben der Software-Architekten, der Software-Entwicklern und der Betriebs-Mannschaft sind auch Unternehmensstrategen, Produktmanager, Konzepter, Designer und Projektmanager beteiligt. Bei allen Anforderungsdefinitionen ist darauf zu achten, dass die Zielsetzung von allen Beteiligten verstanden wird.
Das Team sollte hier vermeiden, Anforderungen „halb-technisch“ zu formulieren. Entweder sind Anforderungen als fachliche Use-Cases – oder als reine technische Anforderung – formuliert. Eine Mischformulierung wird zu Fehlannahmen im Team führen.
Viele Projektanforderungen enthalten den Satz, dass das Produkt „state of the art“ sein müsse. Dass dieser Satz nicht einheitlich interpretiert werden kann, liegt daran, dass diese Formulierung nicht SMART ist, schließlich bedeutet „state of the art“ für jede Disziplin etwas Anderes. Um hier gemeinsam zu einem Projektziel zu kommen, hilft es, Standards für die jeweilige Disziplin und ein Beispiel bzw. eine Idee für „state of the art“ der jeweiligen Disziplin zu benennen. Das Team kann dann bewusst entscheiden, welche Ausprägung ein gemeinsames „state of the art“ annehmen kann.
Die Forderung, dass Aufgaben für alle verständlich formuliert werden, erzwingt zu Beginn des Projekts einen häufigen Austausch. Die Interessen, Bedürfnisse und Aufgaben der Projektbeteiligten sind offenzulegen. Keineswegs muss jedes Team-Mitglied Experte im den anderen beteiligten Disziplinen werden. Jeder muss aber dafür sorgen, dass die Aufgabenstellungen, die sich aus der eigenen Disziplin heraus ergeben, allen anderen Beteiligten verständlich sind.
Das gemeinsame Projektziel eint das Team
Um die eigenen Aufgabenstellungen benennen zu können, muss jedes Team-Mitglied das Projektziel kennen und mittragen. Gerade bei einer Weiterentwicklung oder der Ablösung einer Anwendung ist darauf zu achten, dass Ziele formuliert werden. Die Weiterentwicklung oder Ablösung einer Anwendung als solches ist kein tragendes Ziel, sondern ist eine Maßnahme, um das eigentliche (fachliche und technische) Ziel einzulösen.
Bei der Zielformulierung ist darauf zu achten, dass das Ziel – und damit das Projekt – nicht zu groß gerät. In den zwölf Prinzipien des agilen Manifests heißt es dazu: „Simplicity – the art of maximizing the amount of work not done – is essential.“ [1]
Die Zielformulierung erfolgt SMART und in Abstimmung mit dem Auftraggeber des Projekts.
| Zielsetzung | Bedeutung für das Projektziel | |
| S | Spezifisch |
Das Ziel ist klar und eindeutig formuliert. Die Zieldarstellung erfolgt präzise in einfachen Worten in kurzen Sätzen. Dies verhindert Fehlinterpretationen des
Ziels. |
| M | Messbar | Das Projektziel wird mit messbaren Kriterien unterlegt. Die Zielsetzung ist so zu formulieren, dass eine eindeutige Messung des Projekterfolgs möglich ist. |
| A | Annehmbar | Das Ziel ist so formuliert, dass das Projektteam die Aufgabe annehmen kann und möchte. Das Team akzeptiert das Ziel und nimmt die Aufgaben, die darin liegt, an. |
| R | Realistisch | Das definierte Ziel ist erreichbar. Auch wenn durch das Projekt Neuland betreten wird, erscheint das Ziels machbar. |
| T | Terminiert | Das Ziel soll an einem definierten Datum erreicht werden. |
In einem klassischen Projekt mit Lastenheft ist darauf zu achten, dass die Zielsetzung des Projekts klar durch den Auftraggeber benannt wird. Häufig sind die genannten Ziele weder „messbar“ noch „realistisch“ im Sinne einer SMARTen Formulierung. Ist dies der Fall, ist in Absprache mit dem potenziellen Auftraggeber die Zielsetzung im Pflichtenheft zu explizieren. Falls die Projektgröße eine Ausformulierung der Zielsetzung im Rahmen der Pflichtenheft-Erstellung nicht erlaubt, ist ein entsprechendes Verfahren am Beginn des Projekts zu budgetieren. Das Verfahren ist so anzulegen, dass Auftraggeber, Projektsteuerung und Projektteam an der Entstehung beteiligt sind. Ob und welcher Form das Projektteam auch unternehmensstrategische Aussagen mit der Zielsetzung des Projekts beeinflussen kann, hängt stark von der Zusammensetzung des interdisziplinären Teams ab.
Die Frage nach der Beteiligung an strategischen Aussagen ist häufig Streitpunkt in interdisziplinär und agil orientierten Teams. Da die gesamte Verantwortung für das Projekt vom Team getragen wird, liegt die Forderung nach Beteiligung unternehmensstrategischer Aussagen nahe. Wenn der Auftraggeber bzw. die Leitung nicht agil, sondern klassisch hierarchisch, aufgebaut sind, wird diese Forderung zu Unstimmigkeiten führen.
Hier ist ein umsichtiger Blick des Projektteams auf die herrschende Unternehmenskultur notwendig. Beschönigungen und Wunschvorstellungen führen dabei zu Zwist im Projektteam. Eine sachgerechte Einordnung und das Erkennen eigener Grenzen fördert das Erreichen des Teamziels. Gleichzeitig ist diese Forderung mit Maß zu betrachten; die Forderung könnte auch aus der Selbstüberschätzung des Teams entstehen.
Aus der Zielsetzung des Projekts leiten die Team-Mitglieder Maßnahmen und Aufgaben für das Projektteam ab. Hier ist genau darauf zu achten, dass alle Disziplinen einen Beitrag zur Diskussion leisten. Als Vorgehensmodell zur Diskussion der Projekt-Leitlinien bietet sich eine für das Gesamtprojekt adaptierte Form des ATAM-Vorgehens (Architecture Tradeoff Analysis Method, [5]) an.
Mit ATAM Vor- & Nachteile eines Vorgehens benennen
Mit ATAM leitet das Projektteam aus technischen und fachlichen Anforderungen, die sich aus dem Projektziel ergeben, mögliche Vorgehensmodelle ab. Diese Modelle werden eigenständig nebeneinander visualisiert. Die jeweilige Zielerfüllung wird in fachlicher und technischer Hinsicht bewertet.
Durch diese Darstellung werden für alle Projektbeteiligte und den Auftraggeber Vor- und Nachteile der jeweiligen Lösung offengelegt. Nach Priorisierung der Anforderungen wird ein Vorgehensmodell ausgewählt.
Bei der Definition der eigentlichen Projektarbeiten ist nochmals kritisch zu überprüfen, ob alle Personen, die initial und zukünftig mit der Anwendung arbeiten werden, bei der Formulierung des Projektziels gehört wurden. Je stärker die Beteiligung in dieser Projektphase ist, desto geringer ist die Gefahr, das während des Projektverlaufs komplett neue Anforderungen auftauchen.
Wenn das Projektteam in gemeinsamen Teamregeln ein Vorgehensmodell verankert hat, dass einen einfachen Umgang mit Anforderungsänderungen sicherstellt, werden kleinere und auch größere Anforderungsänderungen den Projektverlauf nicht gefährden.
Interdisziplinäre Zusammenarbeit: Stärken nutzen im Sinne des Projektziels
Buhlen Projektbeteiligte und Zulieferer um ihre Rolle und den Beitrag zum Projekt, werden innovative Lösungen unmöglich. Gleichzeitig ist die gefühlte Geringschätzung der eigenen Leistung Grundlage häufiger Projektkonflikte. Der Gegenentwurf zu einem hierarchischen Wasserfall-Vorgehen ist ein offenes, interdisziplinäres Projektvorgehen.
Der Weg zum Projekterfolgt ist geprägt von Kommunikation – Kommunikation über Zielsetzungen, Teamregeln und interdisziplinär definierten Aufgaben. Nicht jeder Schritt ist leicht. Zwingt dieser Austausch jeden Einzelnen, die eigenen – häufig bis dahin nicht wirklich klaren – Qualitätsansprüche und Anforderungen zu formulieren und im Sinne des Teamziels einzuordnen und zu bewerten.
Öffnet sich jeder Projektbeteiligte für Ansprüche und Anforderungen anderer Disziplinen, kann auf Grundlage eines gemeinschaftlichen Verständnis eine bisher nicht gedachte, innovative Lösung entstehen. Das als gemeinschaftlich entwickelte Ergebnis wird bei jedem Projektbeteiligten seinen Anspruch an Exzellenz erfüllen. Ein schönes Zielbild, für das sich die eine oder andere Klärungsrunde im Projektteam lohnt!
Dieser Artikel ist zuerst im Windows Developer, Ausgabe 01/2013, Software & Support Verlag erschienen.
- Nächster Artikel: Ankündigung: PHP Summit | Erfolgreiche Projekte basieren auf guter Zusammenarbeit
- Vorheriger Artikel: Methodenwissen für IT-Berater
Kommentar schreiben