© best_vector/Shutterstock.com
Windows Developer
Gute Zielsetzung und Teamregeln begründen gemeinschaftlichen Projekterfolg

Über Brücken gehen

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.

Judith Andresen


Auf Entwicklerkonferenzen wird in den Kaffeepausen neben technischen Herausforderungen und den neuesten Softwarelösungen gerne über unbequeme 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 abzuliefern. 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 gern, 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

Der Arbeitsalltag vieler Unternehmen ist geprägt von einem impliziten Wasserfall- bzw. V-Modell, in dem 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 SystemarchitekturAufsetzen der SystemarchitekturKonzeption der Softwarearchitektur ImplementierungTestsAuslieferung

Grafisches Design, inhaltliche Texte sowie Grafiken werden im Prozess zugeliefert. Damit liegen die wesentlichen 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 ist die Featureliste.

Aber auch Entwicklungsteams, 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 unterschie...

Windows Developer
Gute Zielsetzung und Teamregeln begründen gemeinschaftlichen Projekterfolg

Über Brücken gehen

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.

Judith Andresen


Auf Entwicklerkonferenzen wird in den Kaffeepausen neben technischen Herausforderungen und den neuesten Softwarelösungen gerne über unbequeme 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 abzuliefern. 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 gern, 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

Der Arbeitsalltag vieler Unternehmen ist geprägt von einem impliziten Wasserfall- bzw. V-Modell, in dem 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 SystemarchitekturAufsetzen der SystemarchitekturKonzeption der Softwarearchitektur ImplementierungTestsAuslieferung

Grafisches Design, inhaltliche Texte sowie Grafiken werden im Prozess zugeliefert. Damit liegen die wesentlichen 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 ist die Featureliste.

Aber auch Entwicklungsteams, 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 unterschie...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang