Soziale Aspekte der Softwareentwicklung
Softwareentwicklung ist ein soziotechnischer Prozess. Meistens reicht es nicht eine Gruppe von hochqualifizierten Spezialisten zu haben, wenn die Menschen nicht über gewisse soziale Kompetenz verfügen. Grundlage der sozialen Kompetenz ist Kommunikationsstärke. Auf dieser Seite präsentiere ich ein paar Gedanken zu dem Thema soziale Kompetenz und Kommunikation in Softwareprojekten.
Was ist eigentlich soziale Kompetenz? Es gibt unterschiedliche Definitionen dafür. Ich definiere es folgendermaßen: eine sozial kompetente Person kann mit den anderen in einer angenehmer Atmosphäre 3 Fragen klären: Was will ich? Was will der Andere? Wie verteilen wir die Rollen? Das setzt Kommunikationsgeschick voraus.
Die Kommunikation in Softwareprojekten geschieht in Rahmen der vordefinierten Strukturen und Prozesse. Damit sind wir bei dem Thema Softwareentwicklungsprozesse. Es gibt verschiedene Modelle für die Softwareentwicklungsprozess. Fast alle haben die Anforderungssammlung als erste Phase. Gerade in dieser Phase ist soziale Kompetenz und Kommunikationsstärke unabdingbar. Ein Gespräch mit dem Kunden oder einem Spezialisten zwecks Anforderungssammlung ist kein Verhör. Es begrenzt sich nicht auf geschlossene Fragen und lakonische Antworten. Es gilt immer erst eine positive, angenehme Gesprächsatmosphäre zu schaffen. Dem Begriff Anforderungssammlung ziehe ich der Begriff Anforderungsmanagement vor. Damit will ich betonen, dass es sich dabei um ein iteratives Prozess handelt. Man sollte sich nicht täuschen, dass alle Einzelheiten nach dem ersten Gespräch geklärt werden. Man sollte sich nicht frustriert füllen wenn nach einem Anforderungssammlungsgespräch das Vorhaben und die Wünsche des Kunden noch schwammige vorkommen. Es geht oft darum, dass der Kunde selber nicht genau weißt was er braucht. Er braucht Ihre Hilfe um dies mit Ihnen zusammen herauszufinden. Es geht darum oft unbewusste Wünsche des Kunden ans Licht zu führen. Schafft man das, gewinnt man den Kunden. Wie macht man das?
Erster Regel heißt Anschaulichkeit. Dazu gehören Bilder. Dazu gehören Prototypen. Je schneller man dem Kunden etwas vorführen kann desto schnelle kommt man in Projekt mit den Anforderungssammlung voran. Oft bekommt man wesentliche Informationen erst dann, wenn ein Prototyp bereits erstellt ist. Man zeigt den Prototyp dem Kunden und plötzlich bekommt man die Anforderungsdetails, die man so vermisst hat. Unser Gehirn reagiert eben am besten auf Bilder. Dies sollte man immer in Auge behalten.
Zweiter Regel heißt den Kunden mit ins Boot ziehen. Er sollte im Idealfall sich als Projektmitglied fühlen. Er sollte das Gefühl haben, dass er mit erfahrenen Spezialisten und Beratern arbeitet und etwas Gutes, qualitativ Hochwertiges entsteht.
Zurück zu Softwareentwicklungsprozessen. wie ich bereits erwähnt habe gibt es viele davon. Ich erwähne an dieser Stelle Wasserfall-Modell, Iteratives Modell, Prototyping, Agile Entwicklung, Scrum, Extreme Programming, Spiral Modell, etc. Auf den Seiten von Wikipedia findet man noch mehr davon. Ich unternehme hier ein Versuch die Prozesse zu strukturieren und die Vorteile und Nachteile von den bedeutendsten Prozessen zu beschreiben.
Am ältesten ist ein Wasserfallmodel. Es sieht strikte sequenzielle Phasen vor. Eine neue Phase beginnt erst dann, wenn die vorherige abgeschlossen ist. Man unterscheidet die folgende Phasen: Machbarkeitsanalyse, Anforderungsanalyse, Architektur und Softwaredesign, Kodierung und Tests, Integration und Tests, Einführung und anschließende Wartung. Zu den Vorteilen dieser Vorgehensweise gehören übersichtliche Planung, klare eindeutige Terminierung, Kontrolle nach dem Abschluss jeder Phase. Nachteile gibt es hier auch. Als größter Nachteil betrachte ich Mangel der Anschaulichkeit. Funktionierende, zeigbare Version der Software wird sehr spät erst in den letzten Phasen des Prozesses bereitgestellt. Hat man dann irgendwelche Designfehler gibt es meistens keine Möglichkeit sie zu korrigieren ohne große kommerzielle Verluste zu erleiden. Desweiter sind die bereits erwähnten schwammigen, ungenauen Anforderungen Killer-Faktor Nummer eins für diese Vorgehensweise.
Man hat es aus den Nachteilen von Wasserfallmodell gelernt und ein iteratives Entwicklungsmodell entwickelt. Bei der iterativen Vorgehensweise teilt man das große Vorhaben in kleinere besser handhabende Teile auf. Jeder Teil durchläuft die ähnlichen Phasen wie bei dem Wasserfallmodell. Die Phasen sind aber erheblich kürzer. Dadurch bekommt man die Möglichkeit bei eventuellen Fehlern oder Ungenauigkeiten ziemlich zeitnah einzugreifen und Missstand zu korrigieren. Den ungenauen, sich ändernden Anforderungen gegenüber steht man auch besser mit der iterative Vorgehensweise. Als Nachteilen des iterativen Models kann man erhöhter Kommunikationsbedarf betrachten. Dies ist natürlich Auslegungssache. Dieser erhöhte Kommunikationsbedarf kann auch positiv interpretiert werden. Sie hilft den Mitarbeitern sich zu entfalten. Die Projektmitglieder fühlen sich wohler was wiederum zu kleineren Personalfluktuationen - ist gleich kommerzieller Vorteil - führt.
Die Versionskontrolle hat bei dem klassischen Wasserfallmodell nicht so hohe Bedeutung wie bei der iterativer Vorgehensweise. Der Overhead dafür kann auch zu den Nachteilen gezählt werden. Ein weiterer Nachteil besteht darin, dass man bei der schlecht funktionierende Zusammenarbeit und nicht ausreichende Kontrolle der "Niemals fertig"-Gefahr laufen kann.
Was macht man wenn die Anforderungen so ungenau sind, das nicht mal iterative Vorgehensweise in Gang gesetzt werden kann? Man macht einen Prototyp. Der einfachste Prototyp ist nicht unbedingt ein Programm. Es können Bilder mit Workflows und Benutzeroberflächen sein. Die Bilder die dem Interviewierten helfen die Anforderungen genauer zu formulieren.
Auf genaue Beschreibung von Agile Entwicklung, Scrum, Extreme Programming und weiteren Prozessen möchte ich hier aus Platzgründen verzichten. Diese und andere Vorgehensweise beinhalten sowie die Wasserfallelemente als auch iterative Prozesselemente in verschiedenen Graden. Darüber hinaus begrenzen sich viele Modelle nicht nur auf Prozess. Sie definieren auch projektspezifische Rollen.
Zuletzt möchte ich noch zwei Empfehlungen geben, die aus meiner Erfahrung den Alltag in Softwareentwicklungsprojekten verbessern. Der erste ist ziemlich trivial - kleine Snacks. Es muss immer etwas Kleines zum Essen geben. Die effektive Kommunikation und Produktivität erfordern einen ressourcenvollen physiologischen Zustand. Um den möglichst stabil auf hohem Niveau zu halten, brauchen wir ab und zu zwischendurch eine Kleinigkeit zu essen. Das zweite betrifft die Tagesplanung und ist nicht physiologischer sondern psychologischer Natur. Man sollte die täglichen Aufgaben so organisieren, dass die letzte Aufgabe vor Feierabend mit Erfolg abgeschlossen wird. Mit anderen Wörtern man plant den einfachsten und angenehmsten Aufgaben für die Zeit direkt vor Feierabend. Das bewirkt, das man mit einem Erfolgserlebnis den Arbeitstag abschließt, Feierabend genießt und am nächsten Tag wieder voller Energie ist.
Bücherempfehlungen rund um Soziales und Kommunikation: Hier klicken
Schnell Überblick über System verschaffen - Checkliste: 7 Fragen zum System