Organisationsmuster dienen der Lösung von Problemstellungen durch das Hinzufügen einer Struktur zu einem System aus Menschen, wie etwa Firmen, politischen Parteien, dem Militär und anderen Organisationen.
Geschichte Während Organisationsmuster bereits sehr lange existieren, geht der Begriff des Musters auf den Architekten Christopher Alexander zurück. Die Ideen Alexanders wurden Anfang der 1990er Jahre in der Softwareentwicklung übernommen und später auf Organisationen ausgeweitet.
Organisationsformen
Organisationsdesignmuster
Projektmanagementmuster Gemeinschaft des Vertrauens Die persönlichen Beziehungen zwischen Mitarbeiten haben einen wesentlichen Einfluss auf die Effektivität eines Teams. Deshalb ist es wichtig eine Gemeinschaft des Vertrauens (englisch: community of trust) aufzubauen. Ohne Vertrauen zwischen den Mitarbeitern ist die Kommunikation eingeschränkt und Arbeitsabläufe müssen unabhängig bewältigt werden, was zu einem mehrfachen Aufwand führt.
Um die Gemeinschaft zu stärken, ist es wichtig, selbst Vertrauen in die anderen zu zeigen. Zugriffsbeschränkungen auf Informationen oder bürokratische Hürden bei Arbeitsabläufen können das Vertrauen beeinträchtigen, weshalb es wichtig ist Mitarbeitern über ihre eigenen Arbeitsabläufe die Kontrolle zu übergeben. Zudem benötigen die Mitarbeiter das Gefühl bei Entscheidungen einen Einfluss zu haben, da sie dadurch den Entscheidungen eines Entscheidungsträgers eher Vertrauen schenken. Auch fühlen sich die Mitarbeiter dadurch eher dazu verpflichtet Verantwortung für die übertragenen Aufgaben zu übernehmen. Dies ist deshalb wichtig, da einer anderen Person eine Verantwortung nicht gegeben werden kann (sie kann lediglich für ihre Taten Rechenschaftspflichtig sein), sondern die entsprechende Person die Verantwortung selbst übernehmen muss.
Ermächtigung Bei der Ermächtigung (englisch: empowerment) wird bewusst auf die Kontrolle über untergebene Mitarbeiter verzichtet. Im Gegensatz zur Gemeinschaft des Vertrauens die auf einem (impliziten) bilateralen Abkommen beruht, geht die Ermächtigung unidirektional von einer übergeordneten Stelle aus. Das Ziel der Ermächtigung ist einerseits die Gemeinschaft des Vertrauens auszubauen und andererseits die übergeordneten Stellen durch einen Abbau von Bürokratie zu entlasten.
Einschätzung des Zeitplans Eine Einschätzung des Zeitplans (englisch: size the schedule) wird durchgeführt, wenn das zu erstellende Produkt verstanden ist und die Projektgröße abgeschätzt werden kann.
Sowohl zu eng gefasste als auch zu groß angelegte Zeitpläne sind negativ zu bewerten. Zu eng gefasste Zeitpläne führen zu einer Überbeanspruchung der Mitarbeiter und zu einem Nichteinhalten von vereinbarten Terminen oder der Auslieferung eines minderwertigen Produktes. Dadurch werden auch nachfolgende Organisationseinheiten bzw. der Kunde beeinträchtigt. Zu groß angelegte Zeitpläne erhöhen die Kosten für den Kunden durch das Verschwenden von Zeit auf Nebensächlichkeiten. Beides führt zu verpassten Marktchancen.
Einer Beschleunigung von Arbeitsabläufen durch eine Erhöhung der Mitarbeiterzahl steht oft das Brooks’sche Gesetz und das Amdahlsche Gesetz gegenüber.
Die Mitarbeiter, die am Projekt arbeiten, sollten an der Einschätzung der Projektzeit – vor allem für den eigenen Arbeitsaufwand – mitarbeiten. Gute Einschätzungen können hierbei mit finanziellen Anreizen oder zusätzlicher Freizeit belohnt werden. Zudem sollten zwei Zeiteinschätzungen erstellt werden. Ein interner Zeitplan der in Absprache mit den Mitarbeitern erstellt wird, sowie ein externer, welcher mit dem Kunden vereinbart wird. Der externe Zeitplan sollte hierbei für ein mittelgroßes Projekt ein bis zwei Wochen bzw. zwei bis drei Monate über dem internen Zeitplan liegen, um eventuelle Überschreitungen abfangen zu können.
Comparable Work Comparable Work ist ein Muster, welches von Ward Cunningham wie folgt definiert wurde:
Siehe auch: Scrum.
Get on with it Bei get on with it oder auch partial evaluation wird das Projekt bereits gestartet, obwohl noch nicht alle Anforderungen klar sind. Auch sind Abhängigkeiten im Detail oft nicht vorhersehbar und ergeben sich oft erst gegen Ende eines Projektverlaufs. Sobald die Richtung der Projektentwicklung abschätzbar ist, sollte daher mit den Dingen begonnen werden, für die eine hohe Zuversicht besteht. In dieser Phase kann bereits nach einem informellen Arbeitsplan gearbeitet werden und Prototypen können ausgearbeitet werden. Die Prototypen geben zugleich eine Einsicht wie die Struktur des fertigen Produkts aussehen kann und ermöglicht das Benennen von stable bases. Oft werden früh gestartete Projekte in Form von Skunk works ausgeführt. Diese werden am besten parallel zu anderen Geschäftsprozessen ausgeführt und nutzen dabei nicht ausgelastete Ressourcen.
Dieses Muster führt zu einer Beschleunigung der Fertigstellung des Produktes. Da jedoch Arbeit aufgrund von sich ändernden Anforderungen teilweise verworfen werden muss, sollte dieses Muster nicht eingesetzt werden, wenn es sich bei der für die Aufgabe benötigten Ressourcen um einen Engpass handelt, von dem auch andere Prozesse abhängig sind. Auch bedarf es einer guten Kommunikation mit nachfolgenden Einheiten mittels responsibilities engage und hallway chatter.
Siehe auch: Build prototypes.
Named stable bases Named stable bases sind definierte Schnittstellen zwischen Projektteilen. Diese werden benannt, wenn der Projektplan erstellt wurde und die Entwicklung des Produktes gestartet ist. Durch die definierten Schnittstellen erlangen die einzelnen Teams ein gemeinsames Verständnis für das zu entwickelnde Produkt und können auf ein definiertes Grundverhalten aufbauen. Die Menge der festgelegten und benannten Schnittstellen sollte dabei regelmäßig (z. B. wöchentlich) erweitert werden.
Die Entwicklung von Prototypen stellt einen Weg dar, eine Grundmenge an Schnittstellen zu definieren.
Siehe auch: Build prototypes, Programming Episodes.
Inkrementelle Integration Bei der inkrementellen Integration (englisch: incremental integration) werden die Teile eines zu entwickelnden Produktes regelmäßig zusammengefügt. Hierdurch werden größere Integrationsprobleme im späten Entwicklungsstadium des Produktes vermieden. Der Entwicklungsstand wird aufgezeichnet und zu einer neuen stable base, auf der die weitere Entwicklung des Produktes aufgebaut wird.
Private world Als private world (private Welt) wird eine Arbeitsumgebung bezeichnet, über die ein einzelner Mitarbeiter alleine verfügt und alle nötigen Werkzeuge bereitstellt, die für die Tätigkeiten des entsprechenden Mitarbeiters nötig sind.
Private worlds sind häufig in der Softwareentwicklung anzutreffen, bei dem ein Programmierer neben der Integrierte Entwicklungsumgebung und dem Compiler auch über einen lokalen Snapshot der zu entwickelnden Software (d. h. einer named stable base) und den benötigten Programmbibliotheken verfügt, um die Software jederzeit erstellen und testen zu können.
Build prototypes Build Prototypes (baue Prototypen) ist ein Grundsatz, der den Bau eines Prototyps des zu erstellenden Produkts empfiehlt. Am Prototyp wird das Konzept des Produktes ersichtlich und es können mögliche Probleme des Produktes bereits frühzeitig erkannt und in der weiteren Produktentwicklung in Form von zu testenden Anforderungen berücksichtigt werden.
Durch den Prototyp kommen Änderungsanforderungen an das Produkt bereits frühzeitig, wodurch teure Fehlentwicklungen vermieden werden. Es ist hierbei ratsam den Kunden in die Entwicklung mit einzubeziehen und Feedback zum Prototyp einzuholen.
Take no small slips Take no small slips (etwa: mache keine kleinen Ausrutscher) ist anzuwenden, wenn ein Projekt hinter dem Zeitplan liegt. Wenn der geplante Fertigstellungstermin immer wieder um einige wenige Tage verschoben wird, sinkt das Vertrauen in den Projektplan. Daher sollte der Fertigstellungstermin gleich um einen größeren Bereich, ggf. mit eingeplanter Sicherheit, verschoben werden.
Der Projektstatus sollte etwa einmal wöchentlich überprüft und dabei der voraussichtliche Fertigstellungstermin aufgrund statistischer Daten erneut eingeschätzt werden.
Arbeitsteilung Arbeitsteilung (englisch: work split) ist eine Methode um sich auf die wichtigen Tätigkeiten zu konzentrieren, indem das Team aufgeteilt wird und weniger wichtige Tätigkeiten in Untergruppen verlagert wird. Die wichtigen Tätigkeiten sollten hierbei nicht mehr als die Hälfte des Teams beschäftigen, während unwichtige Tätigkeiten entfallen können.
Eine Arbeitsteilung sollte angewandt werden, wenn wichtige Ziele hinter dem Zeitplan liegen, weil das Team mit der Erreichung weniger wichtiger Ziele beschäftigt ist.
Completion headroom Wenn für jede Arbeitsgruppe in einem Projekt der voraussichtliche Fertigstellungstermin berechnet wird, so wird die Differenz zwischen dem voraussichtlichen Fertigstellungstermin und dem geplanten Fertigstellungstermin als completion headroom (wörtlich: Fertigstellungs-Kopffreiheit) bezeichnet.
Diese Differenz sollte mindestens einmal pro Woche neu berechnet werden, um mit geeigneten Maßnahmen durch das Management gegensteuern zu können, falls die Differenz zu stark ansteigen sollte. Hierbei eignet sich unter anderem eine Neupriorisierung und anschließende Aufteilung der Tätigkeiten sowie ggf. das Verschieben des geplanten Fertigstellungstermins.
Implizite Anforderungen Implizite Anforderungen (implied requirements) sind Anforderungen, die der Kunde hat, ohne dass diese explizit aufgelistet werden. Implizite Anforderungen entstehen, indem die einzelnen Funktionen des zu entwickelnden Produktes aufgeteilt und benannt werden.
Speziell in der Softwareentwicklung können implizite Anforderungen Sicherheit, Performance, Logging, Backup-Strategien, Fehlerbehandlungen, Wartbarkeit, Anpassbarkeit an veränderte Geschäftsprozesse usw. beinhalten.
Warteschlange Eine Warteschlange (englisch: work queue) ist eine priorisierte Liste implizierter Anforderungen, also noch zu tätigenden Arbeiten. Die Reihenfolge der Tätigkeiten ändert sich, wenn sich die Anforderungen ändern.
Eine Warteschlange entspricht dem Backlog in Scrum.
Eine Warteschlange ist deutlich einfacher zu handhaben und übersichtlicher als ein traditioneller Netzplan aus Gantt-Diagrammen, der schwerer zu erstellen ist, die beteiligten Personen mit Details überfordert und zudem großteils verworfen werden muss, falls sich die Anforderungen ändern.
Recommitment Meeting Ein Recommitment Meeting ist ein Treffen des Projektmanagements und führender Entwickler eines Projekts, wenn implizite Anforderungen nicht innerhalb des vorgesehenen Zeitplans eingehalten werden können. Hierbei gilt es zu klären, wie eine benötigte Funktionalität mit dem kleinstmöglichen Aufwand zu realisieren ist. Anschließend wird der Zeitplan mit Hilfe eines Work-Queue-Berichts aktualisiert.
Informal Labor Plan Ein Informal Labor Plan ist ein öffentlicher Richtzeitplan. Individuen oder Kleingruppen erstellen eigene kurzzeitige Zeitpläne, um die Arbeit so einzuteilen, dass der vom Management aufgestellte Zeitplan bestmöglich eingehalten werden kann. Der Projektmanager überwacht den Zeitplan lediglich mit einer groben Auflösung, während sich die Mitarbeiter selbstständig um die Details kümmern und sich untereinander zur Einhaltung ihres Zeitplans verpflichten.
Development-Episode Bei einer Development-Episode kümmern sich alle Mitarbeiter eines Teams um dasselbe Problem. Hierdurch werden die unterschiedlichen Stärken der einzelnen Personen kombiniert, um eine bestmögliche Lösung zu erzielen. Als Nebeneffekt wird Wissen von Spezialisten auf die anderen Mitarbeiter übertragen, wobei auch das Ansehen der Spezialisten innerhalb der Gruppe steigt.
Developer Controls Process