die konkrete (d. h. real ausgeführte) Folge von Schritten, die ein bestimmtes, konkretes Ergebnis haben. Wir sprechen hier von einem Projekt.Software wird in aller Regel im Rahmen eines Projekts entwickelt und bearbeitet. Dieses Kapitel befasst sich mit den begrifflichen Grundlagen und mit der statischen Struktur von Projekten; das folgende Kapitel 8 behandelt den Ablauf und die Leitung des Projekts. Grundsätzliche Fragen der Anlage und Strukturierung von Projekten werden dann in den Kapiteln 9 (Vorgehensmodelle) und 10 (Prozessmodelle) behandelt.
Eine triviale Aufgabe, beispielsweise eine einfache Handreichung (Kauf einer Zeitung, Anschließen eines Rechners an das vorhandene Stromnetz), ist schnell und leicht lösbar; es wäre unsinnig, sie als Folge einzelner Aktionen zu beschreiben und dafür organisatorischen Aufwand zu betreiben. In der Frühzeit der Informatik (in den Fünfzigerjahren) wurde die Programmierung der Rechner als eine solche für Fachleute triviale Aufgabe betrachtet. Die Programme entstanden in den Köpfen der Programmierer und wurden direkt codiert, meist auf Papierformulare, die anschließend von Schreibkräften, den »Locherinnen«, auf Lochkarten übertragen wurden. Kleine Schwierigkeiten wie Programmierfehler und Inkonsistenzen wurden als unvermeidlich und beherrschbar beurteilt.
Etwa ab 1960 nahmen die Probleme der Software-Entwicklung zu und drangen ins Bewusstsein der Betroffenen. Die Entwicklung wurde gegliedert und modelliert, es entstanden mehr oder minder detaillierte Arbeitsanleitungen (z. B. für die Programmierung mit HIPO, »hierarchy plus input, process, output«; Überblick in Yau, Tsai, 1986). Die Systematik und die Dokumentation sollten dafür sorgen, dass mit akzeptablem Aufwand gute, fehlerarme Software entsteht. Auch mit den seit Mitte der Fünfzigerjahre entstandenen »höheren Programmiersprachen« (FORTRAN, ALGOL, COBOL, PL/I) wurde dieses Ziel verfolgt. Ohnehin vertraten viele Fachleute im akademischen Bereich die Meinung, dass alle Software-Probleme technische Probleme seien, dass man also mit der richtigen Programmiersprache und einigen elementaren Programmierregeln (»structured programming«, vgl. das Buch mit diesem Titel von Dahl, Dijkstra, Hoare, 1972) alle Probleme lösen könne.
Für einen einzelnen Entwickler reichen diese Regeln aus; wenn er sie beachtet, kann er überschaubare Aufgaben systematisch mit gutem Erfolg bearbeiten. In größeren Projekten, in denen einige oder viele Leute arbeiten, klappt die Abstimmung und die Zusammenarbeit keineswegs von selbst. Neben dem Programmieren im Kleinen (programming in the small) auf Code-Ebene gewann das Programmieren im Großen (programming in the large) an Bedeutung und an Beachtung. Der viel zitierte Artikel von DeRemer und Kron (1976, tatsächlich zuerst 1974 erschienen) signalisiert diese damals neue Sicht.
Um sicherzustellen, dass alle erforderlichen Schritte wirklich durchgeführt werden, wurden Vorgehens- oder Prozessmodelle (Kapitel 9 und 10) formuliert und eingeführt. Aber auch ein solches Modell ist noch kein Garant dafür, dass es – sinnvoll – umgesetzt wird. Darum machte man sich in den Achtzigerjahren daran, die Qualität der Prozesse systematisch zu beurteilen und zu verbessern (siehe Kap. 11).
Leider sind auf diesem Gebiet keine befriedigend klaren Begriffe entstanden. Das Allerweltswort »Prozess« (von lat. procedere, fortschreiten) scheint auf den ersten Blick auszureichen; eine Verwechslung mit dem »Rechenprozess« droht kaum.
process — (1) A sequence of steps performed for a given purpose; for example, the software development process.
(2) See also: task; job.
(3) To perform operations on data.
software development process — The process by which user needs are translated into a software product. The process involves translating user needs into software requirements, transforming the software requirements into design, implementing the design in code, testing the code, and sometimes, installing and checking out the software for operational use.
Note: These activities may overlap or be performed iteratively.
IEEE Std 610.12 (1990)
Aber in diesen Definitionen stecken zwei unterschiedliche Interpretationen, die eine auf der Modellebene, die andere auf der Ebene konkreter Gegenstände: Ein Prozess ist danach
die konkrete (d. h. real ausgeführte) Folge von Schritten, die ein bestimmtes, konkretes Ergebnis haben. Wir sprechen hier von einem Projekt.
eine abstrakte Folge von Schritten, die beliebig vielen Projekten zu Grunde liegt, ihnen als Muster, also Modell, dienen kann.
Es geht hier – wie an vielen Stellen der Informatik – um die Unterscheidung zwischen Modell und Gegenstand. Weil diese Unterscheidung vielen Menschen Schwierigkeiten macht, soll sie in Tabelle 7–1 ganz deutlich werden.
Modell |
Gegenstand |
Theaterstück |
Aufführung |
Schallplatte, Musik-CD |
einmalige Wiedergabe des Inhalts |
Programm |
Programmausführung |
Klasse |
Objekt |
Vorgehensmodell |
Projektablauf |
Prozessmodell |
Projekt (inkl. Organisation) |
Tab. 7–1 Modell und Gegenstand
Jedem Projekt liegt unvermeidlich ein Prozess zu Grunde, also eine Vorstellung, wie ein Projekt ablaufen soll und kann. In vielen Fällen ist dieser Prozess weder bewusst gewählt noch niedergeschrieben oder sonst wie explizit formuliert. Das Projekt wird so durchgeführt, wie Projekte immer durchgeführt werden. Wenn aber ausdrücklich vorgegeben ist, wie Projekte ablaufen sollen, dann haben wir ein Vorgehens- oder Prozessmodell vor uns.
Die meisten Autoren verwenden die Wörter Prozessmodell und Vorgehensmodell als Synonyme. Wir gebrauchen sie in unterschiedlicher Bedeutung: So, wie das Wort »Prozess« mehr Aspekte einschließt als das »Vorgehen«, so gehören zum Prozessmodell neben einem Vorgehensmodell, das seinen Kern bildet, auch die Organisationsstrukturen, die Vorgaben für das Projektmanagement und die Qualitätssicherung, die Dokumentation und die Konfigurationsverwaltung. In der Analogie der Tabelle 7–1 kann man sagen, dass ein Theaterstück, ergänzt um alle Angaben zu den Rollen, den Kostümen und dem Bühnenbild, auch zur äußeren Form der Aufführung, dem Prozessmodell entspricht; die Reclam-Ausgabe des Stücks entspricht dem Vorgehensmodell.
Diese Deutung steckt implizit im Wort »Prozessverbesserung« (process improvement). Dabei geht es vor allem gerade um diejenigen Punkte, die im Vorgehensmodell nicht angesprochen werden. Auch die historische Entwicklung lässt die Unterscheidung sinnvoll erscheinen: Nachdem in den Siebziger- und den frühen Achtzigerjahren zunächst die Vorgehensmodelle (Wasserfallmodell und andere) entstanden waren, wurde deutlich, dass ohne Verbesserung der Strukturen, ohne Qualitätssicherung usw., der Projekterfolg Glückssache bleibt. Darum werden in den jüngeren Prozessmodellen (Unified Process, Extreme Programming usw.) auch diese Aspekte behandelt.
Wir versuchen darum, die Wörter Projekt, Vorgehen und Prozess, Vorgehensund Prozessmodell konsequent in ihren präzisen Bedeutungen zu verwenden. Die Literatur und der Sprachgebrauch, auch die Zweifelsfälle, werden aber verhindern, dass die Abgrenzung perfekt gelingt.
Dieses Kapitel ist dem Software-Projekt gewidmet, das folgende dem Projektleiter. Vorgehensmodelle werden in Kapitel 9, Prozessmodelle in Kapitel 10 behandelt.
Viele Regeln und Erfahrungen sind für alle technischen Entwicklungsprojekte gültig, es spielt keine Rolle, ob es um die Entwicklung einer Elektronik, einer Maschine oder einer Software geht. In allen Fällen kommt es darauf an, die Zusammenarbeit der Menschen so zu organisieren und die Bedingungen so zu beeinflussen, dass die Ziele des Projekts sicher erreicht werden können. Einige Besonderheiten der Software-Projekte sind auf die speziellen Eigenschaften der Software zurückzuführen (siehe Abschnitt 2.3.2), vor allem auf die Unsichtbarkeit des Produkts. Thayer (1997) definiert:
project — A temporary activity that is characterized by having a start date, specific objectives and constraints, established responsibilities, a budget and schedule, and a completion date. If the objective of the project is to develop a software system, then it is sometimes called a software development or software engineering project.
Diese Definition ist uns zu eng, denn kaum ein Projekt hat stabile Ziele und Randbedingungen. Man kann geradezu das Gegenteil feststellen, also dass fast jedes Projekt instabilen Rahmenbedingungen unterworfen ist. Was lässt sich über (Software-)Projekte wirklich Allgemeingültiges aussagen? Wir stellen im Einzelnen fest:
Die Laufzeit jedes Projekts ist begrenzt.
Jedes Projekt hat einen »Erzeuger« (= eine Person oder Institution, die es initiiert hat, typischerweise das höhere Management). Der Projekteigentümer ist der Erzeuger oder vertritt dessen Interessen. Ihm ist der Projektleiter verantwortlich.
Jedes Projekt hat einen Zweck, verfolgt also ein Bündel von Zielen. Das wichtigste Ziel ist in der Regel, eine Software herzustellen oder zu verändern; diese Software ist also das Resultat des Projekts, das Produkt. Andere wichtige Ziele sind die Erweiterung des Know-hows, die Bereitstellung von Bausteinen für spätere Projekte oder die Auslastung der Mitarbeiter.
Werden die Ziele in hohem Maße erreicht, so ist das Projekt erfolgreich.
Das Produkt hat einen Abnehmer oder wird (hoffentlich) einen haben. Dieser Abnehmer ist der Kunde. Die späteren Anwender gehören zum Kunden.
Das Projekt verbindet Menschen, Resultate (Zwischen- und Endprodukte) und Hilfsmittel (Ressourcen). Die Organisation bestimmt deren Rollen und Beziehungen und die Schnittstellen des Projekts nach außen.
Projekte unterscheiden sich formal durch die Art der Auftragsbeziehung und der Abrechnung. Auch wenn diese Merkmale prinzipiell nichts mit dem Gegenstand des Projekts zu tun haben, sind doch bestimmte Inhalte für bestimmte Projektarten typisch. Wir unterscheiden darum die in Tabelle 7–2 aufgeführten vier Projekttypen; auf diese nehmen wir Bezug, wenn wir Aussagen auf Projekte bestimmten Typs einschränken. Natürlich gibt es auch hier gleitende Übergänge, Mischungen und Grenzfälle.
Projektart |
Ergebnis |
Auftraggeber |
|||
internes Marketing |
externer Kunde |
internes Management |
Verkauf / ext. Kunde |
||
Entwicklungsprojekt |
Produkte, Systeme für den Markt |
x |
(x) |
(x) |
|
Auftragsprojekt |
Kundenspezifisches Software-System |
|
x |
|
|
EDV-Projekt |
Datenverwaltung, Informationssysteme |
|
(x) |
x |
|
Systemprojekt |
Industrieanlagen, technische Systeme |
|
|
(x) |
x |
Tab. 7–2 Typische Projektkonstellationen
Wir verwenden nachfolgend das Wort »Hersteller« als Oberbegriff für alle Organisationen, die irgendetwas, insbesondere Software, produzieren. Auch Dienstleistungen sind eingeschlossen. Damit können auch Behörden, Universitäten und Einzelpersonen unter den Begriff des Herstellers fallen.
Ein Software-Produkt wird entwickelt, damit es später auf dem Markt angeboten werden kann. Auftraggeber (und damit quasi Kunde) ist in diesem Fall die Marketingabteilung des Herstellers, das Geld kommt aus dem Entwicklungsbudget.
Typische Produkte sind Programmpakete, die ein in der Anwendung oft vorkommendes Problem lösen (»Standard-Software«, »Shrinkware« wegen der Schrumpffolie, in die die Kartons mit CD/DVD und Handbuch verpackt sind).
Ein Hersteller entwickelt die Software nach den Wünschen eines externen Auftraggebers. Die Rollen sind klar verteilt, zwischen dem Hersteller und dem Auftraggeber besteht ein Vertrag, in dem im Allgemeinen Lieferungen mit Zahlungen verknüpft sind. Da es sich um eine Spezialanfertigung handelt, werden viele Merkmale des Projekts, z. B. die eingesetzten Programmiersprachen oder der Stil der Dokumentation, vom Kunden vorgegeben.
Im Hause wird Software für den eigenen Bedarf entwickelt. Hersteller und Auftraggeber sind in derselben Organisation, die Bezahlung erfolgt mit »Papiergeld«, die Kosten werden also zwischen Abteilungen verrechnet, es gibt keinen echten Geldfluss. Konflikte werden durch den gemeinsamen Vorgesetzten gelöst.
Hier geht es meist um Informationssysteme im weitesten Sinne, also um Datenverwaltung oder »IT« (»EDV«), das Resultat dient der Rationalisierung interner Abläufe. In Banken und Versicherungen dominieren solche Projekte.
Ein Kunde bestellt ein komplexes System, z. B. eine Industrieanlage oder ein Navigationssystem für den Einsatz im Auto. Das System enthält mehr oder minder viel Software. Die Software-Leute erbringen ihre Leistung also zusammen mit den übrigen Ingenieuren des Herstellers. Der Kunde kann entweder das ganze System als »Black Box« einkaufen oder auf die Struktur und damit auf die Abgrenzung zwischen Hard- und Software Einfluss nehmen. Im ersten Fall funktioniert die Kommunikation ähnlich wie bei einem EDV-Projekt, denn die Vorgaben kommen aus dem eigenen Hause, im zweiten Fall sind die Beziehungen zum Kunden wie bei Auftragsprojekten.
Entwickelt ein Hersteller ein Produkt aus Hard- und Software, z. B. ein Radio, dann mischen sich Merkmale der Entwicklungsprojekte und der Systemprojekte.
Für die Behandlung im Lehrbuch eignen sich die Auftragsprojekte am besten, denn die Positionen und Interessen der Beteiligten sind offensichtlich; auf der Herstellerseite geht es ausschließlich um Software. Mit dem Trend zur Ausgliederung der Infrastruktur, von der Kantine bis zur IT, sinkt die Zahl der EDV-Projekte im Sinne der Definition oben. Die großen Software-Hersteller wie Microsoft oder Rechnersystemanbieter wie Apple führen reine Entwicklungsprojekte durch; bei den kleineren Herstellern gehen die Entwicklungsprojekte oft aus Auftragsprojekten hervor; was für einen einzigen Kunden entwickelt wurde, lässt sich eventuell generalisieren und damit auf dem Markt verkaufen. In Systemprojekten sind die Anforderungen bezüglich der Software-Qualität typischerweise am höchsten, denn bei einem »Embedded System«, z. B. einem Lift oder einer Fahrzeugstabilisierung, ist die Toleranz gegenüber Ausfall und Fehlfunktion wesentlich geringer als bei einem Textsystem, dessen Versagen dann und wann einen Neustart des PCs erfordert.
Software-Entwicklung ist ein arbeitsteiliger Prozess, an dem viele Personen in unterschiedlichen Rollen beteiligt sind. Eine wichtige Aufgabe des Projektmanagements besteht darin, die am Projekt beteiligten Personen – das Projektteam – zu organisieren. Je nach Größe des Projekts kann das Projektteam in mehrere Teams unterteilt werden. Ein Team sollte einen definierten Bereich bearbeiten und aus höchstens fünf bis sieben Personen bestehen.
Im Folgenden werden einige typische Organisationsformen für Teams vorgestellt. Diese Übersicht ist natürlich holzschnittartig vereinfacht, in der Praxis gibt es alle möglichen Mischformen.
Wer allein an einer Aufgabe arbeitet, bildet quasi ein »Ein-Personen-Team«. In der Praxis gibt es viele der sogenannten Einzelkämpfer, weil bei der Wartung und Weiterentwicklung von Produkten oder Produktvarianten Aufgabenpakete entstehen, die sich nicht mehr sinnvoll über mehrere Personen verteilen lassen. Zudem hat ein Einzelkämpfer in seiner »Gruppe« keinen Kommunikationsaufwand.
Aber die Nachteile überwiegen deutlich: Dem Einzelkämpfer fehlen Gesprächspartner, die eine Diskussion möglich machen und Mängel, insbesondere das Fehlen der Dokumentation, kritisieren. Wenn er ausfällt, ist die Einarbeitung eines Nachfolgers zeitraubend und mühsam. Man sollte darum einen gewissen Mehraufwand in Kauf nehmen, um mehrere Einzelkämpfer so in Gruppen zu organisieren, dass jeder die Arbeiten seiner Kollegen kommentieren und unterstützen, notfalls auch übernehmen kann.
Eine Gruppe aus zwei Personen entsteht entweder durch den freien Beschluss der Beteiligten oder durch die Weisung an einen »Sherpa«, einen zuvor allein arbeitenden Spezialisten zu unterstützen. Im ersten Fall entsteht ein »Doppel«, im zweiten ein »Tandem«, das ja bekanntlich nur dem vorderen Fahrer erlaubt, die Richtung zu bestimmen.
Die Tandem-Lösung kann auch den Zweck haben, das Wissen des Spezialisten auf zwei Köpfe zu verteilen; dann ist der Juniorpartner kein Sherpa, sondern ein Schüler. Im Tandem ist die Führungsaufgabe auf die Delegation von Aufgaben und ggf. auf die (Mit-)Teilung des Wissens beschränkt. Beim »Extreme Programming« (siehe Abschnitt 10.6) entstehen durch das Pair Programming Doppel (oder auch Tandems); sie sollen für eine kontinuierliche Qualitätssicherung sorgen.
Im Doppel gibt es keine Führung, sondern (hoffentlich) Einvernehmen.
In einem anarchischen Team (Jones, 1990) arbeiten die Entwickler im Wesentlichen autonom, nach eigenen Vorgaben und Maßstäben. Hierarchische Beziehungen fehlen oder werden faktisch ignoriert, weil der Wille, die Zeit oder die Fähigkeit zur Führung fehlt.
Vorteile
Die Entwickler arbeiten selbstbestimmt, es gibt keine Hierarchie-Probleme und kaum bürokratische Hindernisse.
Nachteile
Standards und Normen lassen sich nicht durchsetzen und werden dementsprechend auch nicht eingehalten. Ob die erforderlichen Resultate entstehen, ist Glückssache (d. h., gewisse Dokumente entstehen in aller Regel nicht). Planung und Abstimmung sowie die Einführung neuer Methoden und Werkzeuge sind von der Laune der Mitarbeiter abhängig. Die Organisation insgesamt ist nicht lernfähig.
Anarchisch organisierte, d. h. praktisch nicht organisierte Teams, sind typischerweise in Organisationen mit schwacher Führungsstruktur anzutreffen, also in Behörden, Forschungseinrichtungen und auch in vielen Firmen. Klein- und Kleinstgruppen (Einzelkämpfer) können in der Regel als anarchisch eingestuft werden.
Offiziell gibt es diese Organisationsform natürlich nicht; sie ist als demokratisches oder hierarchisches Team getarnt.
Das demokratische Team ist ähnlich aufgebaut wie das anarchische Team. Demokratisch bedeutet in diesem Zusammenhang, dass alle Mitglieder gemeinsam verabredete Ziele verfolgen. Dies setzt natürlich ein diszipliniertes Verhalten bei allen Beteiligten voraus. Da es trotzdem Situationen geben kann, in denen kein Konsens gefunden oder keine Entscheidung getroffen werden kann, gibt es im demokratischen Team eine ausgezeichnete Person (primus inter pares), die, wenn nötig, Entscheidungen fällt oder Ziele und Vorgaben festlegt.
Die Fähigkeiten der Teammitglieder werden optimal genutzt, alle sind an Entscheidungen beteiligt. Probleme, die auftreten, werden frühzeitig erkannt und nach Absprache gemeinsam bekämpft.
Nachteile
Da sich das Team häufig absprechen muss, ist der Kommunikationsaufwand hoch. Das kann zur Lähmung führen, wenn die gemeinsamen Ziele nicht ausreichen, um bestimmte Entscheidungen zu treffen, und Fraktionen entstehen.
Diese Organisationsform gibt es (unter günstigen Umständen) in Forschungsgruppen. Auch in kleineren Software-Unternehmen findet man demokratische Teams; sie bleiben dann meist über mehrere Projekte zusammen. Die demokratische Struktur schwindet, wenn die Gruppe später wächst; dann sind die ursprünglichen Mitglieder unvermeidlich »more equal than the others« (Orwell).
Ein hierarchisch organisiertes Team steht unter der Leitung einer Person. Sie ist als Projektleiter (oder Projektmanager) für das Projekt verantwortlich. Der Projektleiter kann auch der Linienvorgesetzte der Mitarbeiter sein (siehe Projektorganisation in Abschnitt 7.5).
Der Projektleiter plant und verteilt die durchzuführenden Aufgaben, kontrolliert den Fortschritt und ist an qualitätssichernden Maßnahmen sowie an technischen Entscheidungen beteiligt. In sehr großen Projekten wird das Projektteam in weitere hierarchisch organisierte Teams unterteilt. So entsteht eine baumartige Organisationsstruktur mit klar definierten Kompetenzen und Pflichten.
Vorteile
Die Kommunikationsstrukturen sind einfach, die Zuständigkeiten und Pflichten klar verteilt, und auf Mitarbeiterebene können die Mitglieder des Teams verhältnismäßig leicht ausgetauscht werden. Die baumartige Struktur schafft gute Übersicht.
Nachteile
Wenn ein großes Projekt über mehrere Stufen in Teams unterteilt wird, werden die Kommunikationswege vom Gesamtprojektleiter bis zur Mitarbeiterebene lang. Dadurch kommen wichtige Informationen spät, unvollständig oder gar nicht bei den Mitarbeitern an. Ist der Projektleiter seiner Aufgabe nicht gewachsen, so wird das Projekt wahrscheinlich scheitern, selbst dann, wenn die Entwickler gute Arbeit leisten. Die »kleinen Indianer« sind oft mit der Information, die sie bekommen, und mit ihrer Beteiligung an Entscheidungen unzufrieden und entsprechend wenig zur Kooperation motiviert.
Hierarchisch organisierte Teams sind die traditionelle Organisationsform vieler Unternehmen und Behörden.
Dies ist eine spezielle Form des hierarchischen Teams. Sie unterscheidet sich vom oben beschriebenen hierarchischen Team im Wesentlichen dadurch, dass der Leiter (der Chief Programmer) auch oder vor allem technisch-konstruktiv führt und dass die Rollen im Projektteam differenziert werden. Der Chief Programmer ist zentral in alle Entwicklungsaktivitäten eingebunden. So entwirft er die Architektur des Systems, implementiert zentrale und wichtige Komponenten und prüft die Implementierungen der anderen Mitglieder. Darum kann diese Funktion nicht mit Chef-Programmierer übersetzt werden (die Konnotation des Wortes »Chef« ist irreführend), es handelt sich vielmehr um einen Vorarbeiter im Projekt.
Der Chief Programmer hat einen Stellvertreter (Backup Programmer), der ihn unterstützt und wenn nötig ersetzt. Der Bibliothekar (Librarian) übernimmt alle Verwaltungsfunktionen, die Programmierer, häufig Spezialisten (z. B. für die Datenbankprogrammierung), entwickeln nach den Vorgaben des Chief Programmers Komponenten. Zusätzlich kann es weitere Spezialisten geben, z. B. Dokumentierer oder Tester.
Vorteile
Das Team kann – wie ein Operationsteam in der Chirurgie, das das Vorbild dieser Struktur war – außerordentlich effizient arbeiten, die Kommunikations- und Entscheidungswege sind kurz.
Nachteile
An den Chief Programmer werden hohe Ansprüche in technischer, organisatorischer und sozialer Hinsicht gestellt. Darum ist diese Rolle auch mit einem hohen Risiko behaftet. Wird die Rolle durch eine entsprechend kompetente Person besetzt, dann kann das Team hervorragende Leistungen erbringen; ist der Chief Programmer seiner Aufgabe nicht gewachsen, dann ist der Misserfolg garantiert.
H.D. Mills (IBM, Federal Systems Division) hat diese Organisationsform erfunden (Baker, 1972). Es ist unklar, wo und mit welchem Erfolg sie sonst eingesetzt wurde. Uns ist keine Organisation bekannt, die für ihre Projekte Chief-Programmer-Teams bildet.
Trotzdem kann man nicht behaupten, dass die dem Chief-Programmer-Team zu Grunde liegende Idee keine Rolle spielt. Ein Projektleiter im hierarchischen Team (Abschnitt 7.4.4) war oft ein guter Entwickler, bevor ihm die Projektleitung übertragen wurde (siehe Abschnitt 8.7.1). Nun fällt es ihm schwer, seinen Mitarbeitern nur zuzusehen, wie sie Software entwickeln, also tun, was er selbst gern täte. Wenn dann auch noch Entwickler fehlen, mogelt er sich gern in die (hier gar nicht vorgesehene) Rolle des Chief Programmers und vernachlässigt seine Führungsaufgabe. Das schadet in der Regel dem Projekt. Wenn der Kapitän Kohlen in den Kessel schaufelt, ist niemand auf der Brücke, um Eisberge rechtzeitig zu entdecken.
Alle Hersteller haben Organisationsstrukturen, die die Aufgabenverteilung und die Beziehungen der Mitarbeiter untereinander vorgeben. Diese Strukturen bezeichnet man als Primärorganisation. Mit der Einstellung bei einem Hersteller wird der neue Angestellte Teil der Primärorganisation. Durch diese Organisation ist alles festgelegt, was grundsätzlich statischer Natur ist. In den meisten Fällen bekommt der Mitarbeiter einen bestimmten Platz in der Linienorganisation des Herstellers, also innerhalb der Hierarchie.
Zusätzlich kann es eine Sekundärorganisation geben, beispielsweise die Zusammenfassung von Mitarbeitern in einer Projektgruppe, die in der Primärorganisation nicht existiert. Je nach Gewicht und Art der Primär- und Sekundärorganisation unterscheidet man verschiedene Organisationsformen. Natürlich geht es hier stets um die Organisation von Software-Herstellern.
Wenn ein Hersteller nur und immer wieder ähnliche Aufgaben zu lösen hat, beispielsweise die Ausrüstung von Arztpraxen mit Rechnern und Software oder die Implementierung von Compilern für verschiedene Sprachen und Plattformen, dann können für die einzelnen Teilaufgaben Gruppen oder Abteilungen geschaffen werden, in denen die jeweiligen Spezialisten arbeiten. Das Produkt entsteht durch das Zusammenwirken aller oder vieler Abteilungen.
Dazu reicht die Linienorganisation aus, eine Sekundärorganisation ist nicht erforderlich. So, wie es am Fließband einen Arbeiter gibt, der nur die Räder auf der linken Fahrzeugseite montiert, so gibt es bei einem funktional organisierten Software-Hersteller Rollen, die jeweils für einen bestimmten Schritt der Konstruktion oder Prüfung zuständig sind.
Vorteile
Die funktionale Organisation arbeitet wie das Räderwerk einer Uhr. In den Abteilungen oder Gruppen sitzen die Spezialisten für die einzelnen Aufgaben. Es gibt keine Konflikte um Zuordnungen und Prioritäten. Die Zuordnung der Personen ist stabil, die Nachteile der reinen Projektorganisation (siehe Abschnitt 7.5.2) gibt es nicht.
Nachteile
Die funktionale Organisation ist starr, unflexibel und kaum in der Lage, auf Änderungen der Umgebung zu reagieren. Da die Leistung, wie oben gesagt, durch das Zusammenwirken vieler erbracht wird, gibt es kein Projekt und damit auch keine Identifikation mit dem Projekt; wenn etwas schiefgeht, ist niemand zuständig. Behörden, Musterbeispiele dieser Organisationsform, sind für solche Schwächen bekannt.
Bei der reinen Projektorganisation wird das Projektteam als eine temporäre Struktur in die Firmenorganisation eingebunden. Dieses Team wird vom Projektleiter geführt. Alle Mitglieder treten zu Beginn ihres Einsatzes in die Organisation des Projekts über und verlassen sie wieder, nachdem ihre Aufgabe erfüllt ist. Mit dem Abschluss des Projekts wird die Struktur aufgelöst.
Wir sehen hier eine ausgeprägte Sekundärorganisation (die Projektgruppen), die Primärorganisation ist schwach. Im Extremfall kann sie ganz fehlen, wenn nämlich die Mitarbeiter von Fall zu Fall nur für ein einziges Projekt eingestellt werden.
Vorteile
Auf Änderungen der Aufgabe und der Umgebungsbedingungen kann ein Projekt sehr rasch reagieren, die Kompetenzen des Projektleiters sind umfassend und klar. Das Projektteam ist auf das Projekt zugeschnitten, und seine Mitglieder identifizieren sich mit dem Projekt. Erfolg oder Misserfolg sind leicht zuzuordnen, die Mitarbeiter sind darum hoch motiviert, Schwierigkeiten zu vermeiden oder zu überwinden.
Nachteile
Beginn und Ende des Projekts sind mit vielen Veränderungen für die beteiligten Personen verbunden, darum auch mit Unsicherheit, Leerlauf und Frustration. Der Projektleiter steht vor dem Dilemma, dass er nur zu Beginn des Projekts in einer Position ist, in der er Bedingungen stellen kann. Er wird darum versuchen, gleich zu Anfang ausreichend viele qualifizierte Leute für sein Projekt zu bekommen (und damit oft genug anderen Projekten zu entziehen). Andererseits sind nicht alle Leute dauernd sinnvoll einzusetzen, vor allem nicht am Projektbeginn. Eine fatale Folge ist oft der rasche Eintritt in die Implementierung, die alle freien Kapazitäten bindet, aber erhebliche Risiken schafft, wenn die Konzeption des Systems noch nicht abgeschlossen war. So kommt es zu dem gefürchteten »Code now, think later«. Oft ist es auch unsinnig, Spezialisten für die gesamte Projektdauer zu binden.
Die reine Projektorganisation ist bei großen und schwierigen Projekten, die erhebliche Risiken bergen, die einzig mögliche Organisationsform, da sie es erlaubt, die passenden Mitarbeiter auszuwählen oder einzustellen und im Projekt straff zu führen. Das berühmte Manhattan-Projekt zeigt die Stärken der Projektorganisation: Nur die totale Ausrichtung aller verfügbaren Experten auf das Projektziel machte es möglich, in drei Kriegsjahren (ab 1942) die Atombombe zu entwickeln.
Da sowohl die funktionale Organisation als auch die reine Projektorganisation große, komplementäre Vor- und Nachteile haben, lag es nahe, eine Synthese zu versuchen. Das Resultat ist die Matrixorganisation. Darin sind Primär- und Sekundärorganisation gleich gewichtet, jeder Mitarbeiter hat also seinen festen Platz in der Linie und gleichzeitig seine Rolle in einem Projekt oder in mehreren Projekten. Die Abbildung 7–1 zeigt die Situation, dass ein Mitarbeiter M der Abteilung Z in zwei Projekten (X und Y) arbeitet und entsprechend zwei Projektleiter und einen Linienvorgesetzten hat.
Damit kann man sich die Gesamtorganisation als Matrix vorstellen, wobei die Spalten die Organisationseinheiten (Linienstruktur), die Zeilen die Projekte darstellen. Theoretisch sind Projektleitung und Linie gleichberechtigt, de facto erweist sich aber meistens eine der beiden Parteien als stärker und trifft Entscheidungen, die ihren definierten Kompetenzbereich überschreiten.
Vorteile
Die Mitarbeiter können den Projekten flexibel zugeordnet werden, ohne dass sie auf die feste Zuordnung zu einem bestimmten Linienvorgesetzten und seiner Abteilung verzichten müssten. Da es Projekte und Projektleiter gibt, ist das Problem der mangelnden Identifikation gegenüber der funktionalen Projektorganisation entschärft.
Nachteile
Jeder Mitarbeiter bekommt durch die Matrixorganisation (mindestens) zwei Chefs, den einen auf unbegrenzte Zeit, den anderen für die Dauer eines Projekts. Das schafft Probleme, wenn es Konflikte gibt, weil die beiden Vorgesetzten unterschiedliche Ziele verfolgen. Der Projektleiter will sein Projekt erfolgreich abschließen und braucht dazu den Mitarbeiter; der Linienvorgesetzte hat ihn für eine Schulung freigestellt oder einem anderen Projekt zugesagt. Meist ist die Linie stärker, weil ein Projekt langfristig keine Sicherheit bieten kann. Die Projektleiter verlieren weiter an Einfluss, wenn die Mitarbeiter in mehr als einem Projekt stecken und Prioritäten setzen müssen.
Fast alle großen Firmen wenden die Matrixorganisation an; denn anders lässt sich eine Personalführung und -entwicklung nicht realisieren. Wie gut die Sache funktioniert, hängt letztlich aber von der Firmenkultur ab. Günstig ist eine Atmosphäre der Kooperation und des Vertrauens. Wenn die Manager gegeneinander Stellungskriege führen und keine Skrupel haben, Projektleiter zu ernennen, ohne ihnen ein Mindestmaß an Kompetenzen einzuräumen, wird die Matrixorganisation zur Geisterbahn.