Tipps für ein gelungenes Projektmanagement durch Weglassen

Und täglich grüßt das Murmeltier …
Kommentare

In der Softwareentwicklung kämpft man bei der Umsetzung von Projekten oftmals mit den gleichen kleinen oder auch großen Problemen. Man muss Dinge priorisieren, Aufwände schätzen und nebenbei noch zu einem Meeting. Was davon nun sinnvoll ist oder auch nicht, darüber ließe sich stundenlang streiten. Doch eigentlich möchte man das gar nicht. Gerne hätte man ein paar kleine Rezepte, um sich solche Probleme zu ersparen.

Ab und zu wundert man sich schon, wie alltäglich gewordene Dinge wie E-Mails oder Meetings im Projektalltag zu regelrechten Foltergeräten mutieren. Selbst wenn man sich mittlerweile an gewisse Umstände gewöhnt hat, möchte man sich dennoch nicht damit abfinden. Also legt man sich mit der Zeit kleine Gedankenspiele zurecht, wenn mal wieder der alltägliche Wahnsinn ausbricht. Man experimentiert und probiert dabei verschiedene Lösungswege aus. Aus diesen sich ständig wiederholenden Situationen haben sich mittlerweile praktikable Ideen entwickelt. Diese Ideen erheben aber ganz sicher nicht den Anspruch, die große Antwort auf alles zu sein. Sie sollen im Arbeitsalltag einfach eine Hilfe sein.

Der Nullaufwand

Ein Problem, auf das man häufiger trifft, ist das ständige Auftreten von Aufgaben, die sich nebenher erledigen lassen. Es kann auch sein, dass bei einer Aufgabe nur eine Hilfestellung erwartet wird. Meistens geht es aber schlicht darum, dass der Aufwand nicht so groß ist, dass man ihn messen müsste – kurzerhand als Nullaufwand bezeichnet.

Wie kann also ein Aufwand aussehen, dessen Zeitaufwand wirklich bei null liegt? Das Einspielen eines Updates auf einem Server vielleicht. Hier übernimmt das Betriebssystem die Arbeit. Allerdings müssen nach einem Update die Anwendungen auf dem Server überprüft werden, um sicherzustellen, dass sie noch immer funktionieren. Das benötigt Zeit und ist mit Sicherheit kein Nullaufwand. Wie sieht es denn mit dem berühmten Einzeiler im Code aus? Diese Änderung kann doch nichts kosten, oder? Wenn man davon ausgeht, dass jede Änderung mithilfe des Vieraugenprinzips geprüft wird, schon. Eventuell müssen auch Unit Tests, die Dokumentation und das Anwendungshandbuch angepasst werden. Zusätzlich ist die Änderung auch noch an alle Clients zu verteilen. Von einem Nullaufwand kann man also nicht sprechen.

Diese Beispiele zeigen, dass es einen Nullaufwand nicht gibt. Wäre er nicht wirklich null, müsste man ihn nicht beachten. Vielleicht sieht es auf den ersten Blick nach wenig Arbeit aus. Das ist durchaus legitim. Man sollte sich nur nicht dazu hinreißen lassen, alles auf die leichte Schulter zu nehmen. Wie in der Physik folgt aus jeder Aktion auch eine Reaktion. Letztere wird dabei von den meisten übersehen und nicht eingeplant.

Was ist denn nun wichtiger?

Wenn es darum geht, Ideen und neue Funktionen für eine Anwendung zu entwickeln, sind eigentlich immer alle Beteiligten mit Begeisterung dabei. Das Business wünscht sich eine Automatisierung des Bestellvorgangs, der Vorstand einen E-Mail-Report. Doch auch andere Abteilungen haben ihre Wünsche. So wünschen sich die Entwickler ein automatisiertes Deployment. Die Marketingabteilung möchte eine neue Schriftart, die dem Corporate Design entspricht und einen Like-Button, um die soziale Medienkompetenz des Unternehmens unter Beweis zu stellen.

Sollen alle Wünsche umgesetzt werden, müssen die Verantwortlichen festgelegen, in welcher Reihenfolge dies geschehen muss. Aber: Die einzelnen Ideen exakt zu priorisieren, erweist sich in der Praxis oft als problematisch. Wissen über die Art der Priorisierung kann hier Abhilfe schaffen.

Die MoSCow-Priorisierung beispielsweise ist ein gutes Mittel, um diese Probleme zu umgehen. Anstatt auf Zahlen zu setzen, dienen hierbei MUST, SHOULD, COULD und WON’T als direkte Indikatoren. Die Anwendung MUSS diese Funktion haben, ist gleichbedeutend mit: „Ohne diese Funktion brauchen wir gar nicht anzufangen“. Das trifft in unserem Fall auf den automatisierten Bestellvorgang zu, ohne den die ganze Software keinen Sinn hat. Danach SOLLTEN wir den E-Mail-Report für den Vorstand implementieren, damit seine Kennzahlen nicht jedes Mal von einem Datenbankspezialisten zusammengestellt werden müssen. Bei genügend Zeit KÖNNTEN wir auch noch das Deployment automatisieren. Dadurch haben die Entwickler mehr Zeit für andere Aufgaben. Die Ideen der Marketingabteilung werden leider NOCH NICHT umgesetzt. Für eine spätere Version ist die Umsetzung aber denkbar.

Bug oder kein Bug?

Fehler zu machen, sollte man jedem Menschen zugestehen. Denn irren ist menschlich. Fehler in der Softwareentwicklung werden als Bugs deklariert. Warum allerdings, weiß kaum jemand. Der Legende nach stammt der Begriff aus der grauen Vorzeit, als es Insekten tatsächlich noch möglich war, elektronische Leitungen anzuknabbern oder die mechanischen Teile eines Computers zu blockieren. Doch was zeichnet heute einen Bug aus?

Für die meisten Softwareprojekte gilt eine einfache Gleichung: Je weniger Fehler, umso besser ist die Software. Somit wird die Anzahl der Fehler in einem Programm gleichzeitig zu einem Indikator für die Qualität der Softwareentwicklung. Doch wie lässt sich beurteilen, was gut ist und was schlecht? Durch die Anzahl der Fehler in Relation zu den entwickelten Funktionen? Womit lässt sich die Information vergleichen? Eine Möglichkeit wäre, die gewonnenen Kennzahlen mit anderen Projekten zu vergleichen. Dazu müssen aber verschiedene Softwareprojekte miteinander vergleichbar sein, was ehrlich gesagt eine weitere gewagte These ist. Aber man kann es ja trotzdem versuchen oder einfach einen fiktiven Wert festlegen, den man als sinnvoll erachtet. „Die Anzahl der Bugs ist zu hoch“ ist ein Satz, den ich gerne höre. Am schönsten klingt er, wenn danach keine Erklärung folgt, was denn mit „zu hoch“ gemeint ist. Letztendlich sollte man auch keiner Statistik glauben, die man nicht selbst gefälscht hat. Es ist deshalb auch immer interessant, zu verfolgen, wer die Bugs meldet. Ein verbreitetes Muster ist der Anstieg von Bugs bei fehlendem Budget für neue Funktionen. Wenn Bugs als Wartungsarbeiten gelten, ist die Versuchung allzu groß, auf diesem Weg neue Anforderungen zu platzieren.

Die Frage nach Bug oder kein Bug ist also fast genauso tückisch, wie die von Hamlet nach dem „Sein oder Nichtsein“. Allerdings gibt es zwei gute Wege, mit der Frage umzugehen. Der erste ist etwas bürokratisch, aber dennoch effektiv. Denn EN ISO 9000:2005 definiert einen Fehler als „Nichterfüllung einer Anforderung“. Somit kann es keinen Bug ohne zuvor gestellte Anforderung geben. Im Zeitalter von JIRA, TFS und Co. darf also niemand einen Bug erstellen, ohne damit eine Anforderung zu verknüpfen. Der zweite Weg ist deutlich aufregender. Versuchen Sie es doch einfach mal ohne Bugs! Sie haben ja schon gelernt, Dinge zu priorisieren, also warum dann noch die Unterscheidung von Bug und Feature? Zumal auch ein Prozessmodell wie Scrum vollkommen ohne Bugs auskommt. Trauen Sie sich doch einfach mal!

Auf Abstand gehen

„Hier muss es so gehen, das gehört dorthin, und alles in allem könnte man das doch auch noch ganz anders machen …“ Wenn es um die Planung eines Softwareprojekts geht, ist man sich meistens in einem Punkt einig: man ist sich uneinig. Der Projektleiter weiß genau, wie lange es dauert, eine Stored Procedure des SQL Servers zu optimieren. Die Fachabteilung ist sich sicher, einen Prozess entwickelt zu haben, der die Softwareentwicklung revolutioniert, während die Softwareentwickler das Firmenlogo im Webshop lieber durch einen viel cooleren Barcode ersetzen würden.

Es liegt in der Natur des Menschen, den Versuch zu unternehmen, alles zu verstehen. Mit dem Verstehen kommt automatisch auch das „Verbessern wollen“. Diese eigentlich sehr positive Eigenschaft des Menschen kann gerade in der Softwareentwicklung zu Problemen führen. Da Software in vielen Fällen als Hilfsmittel in anderen Domänen eingesetzt wird, trifft man im Projektalltag sehr häufig auf eine Konstellation aus Entwicklung, Fachabteilung und Projektmanagement. Sind am Anfang noch alle am Gebiet des anderen interessiert, kann dies im Verlauf eines Projekts auch umschlagen. Vor allem dann, wenn es im Projekt nicht so gut läuft wie erwartet. Die Gründe dafür treten in den Hintergrund. Dann wird das Interesse oftmals als Kontrolle oder als Bevormundung ausgelegt.

In solch einem Moment ist es wichtig, kontrolliert auf Abstand zu gehen. Oftmals kann es sehr entspannend sein, etwas nicht zu wissen. Denn im spezialisierten Kontext der Softwareentwicklung hat man leider nicht immer die Zeit, sich als Einzelperson mit allem zu beschäftigen. Deshalb kann es hilfreich sein, Entscheidungen auch jemand anderem zu überlassen. Geld, Arbeitszeiten und Position sorgen dafür, dass wir mit unserem Arbeitsplatz zufrieden sind. Aber Vertrauen, Lob und Anerkennung sind die Dinge, die uns im Arbeitsalltag motivieren.

Endlose E-Mails

Die E-Mail ist eine der ersten großen Errungenschaften des Informationszeitalters. Wie das Internet ist sie kaum noch aus unserem Leben wegzudenken. Im Berufsalltag ist sie mittlerweile genauso wichtig, wenn nicht sogar noch wichtiger, als das Telefon oder der klassische Geschäftsbrief. Doch mit ihrer Verbreitung kamen auch die Probleme. Hatte man am Anfang vielleicht eine E-Mail-Adresse, so sind es mittlerweile oft mehrere. Im Laufe der Jahre wurde aus dem darkshadow84@underworld.com der Seriöse fabian.hoeger@musterbuerger.de. Und wehe, man hat die E-Mail einmal unbedacht herausgegeben oder bei einer Benutzerkennung im Onlineshop verwendet. Dann sind Spam und Viren Tür und Tor geöffnet. Als wäre das noch nicht genug, kommen im geschäftlichen Bereich auch noch unzählige Verteiler und E-Mails in Kopie hinzu.

Vielen Absendern ist oft nicht bewusst, dass sich die Kommunikation per E-Mail grundsätzlich von Telefonaten oder dem Gespräch mit dem Kollegen unterscheidet. Die E-Mail beruht auf asynchroner Kommunikation. Der Empfänger wird im Idealfall direkt antworten. Das kann bei dringenden Fragen ein Risiko sein, da der eine oder andere gerne vergisst, seine Abwesenheit einzutragen oder ein genutzter Verteiler nicht abgearbeitet wird. Man sollte sich auch bewusst machen, dass der Inhalt einer E-Mail immer Raum für Interpretationen lässt und durchaus missverstanden werden kann. Schnell kann sich so ein Ping-Pong-Spiel aus Fragen, Antworten und Missverständnissen entwickeln. Ein weiteres Beispiel dazu, wie schwierig die Kommunikation per E-Mail sein kann, ist, wenn Kollegen in Kopie sind, die mit dem Inhalt einer E-Mail eigentlich nichts zu tun haben.

Die Ursachen für diese Kommunikationsprobleme liegen oft im Inhalt der E-Mail begründet. Häufig handelt es sich nicht um Ankündigungen, Informationen oder Zusammenfassungen, sondern um dringende Probleme, Aufgaben oder Fragen, die sich im Laufe der Kommunikation als sehr komplex darstellen können. Es lohnt sich deshalb, vor dem Schreiben einer E-Mail zu überlegen, ob der Inhalt der E-Mail statisch oder dynamisch ist. Ist der Inhalt dynamisch, ist es häufig besser, zum Telefonhörer zu greifen oder den Kollegen direkt an seinem Arbeitsplatz aufzusuchen, um Fragen zu klären, oder Informationen einzuholen. Das beseitigt mögliche Unklarheiten und fördert nebenbei die Zusammenarbeit mit den Kollegen. Ziele lassen sich durch gezielte Kommunikation und Informationsbeschaffung viel schneller erreichen.

Nach Richtlinie XY ist das aber nicht erlaubt

Sobald in Deutschland mehrere Personen miteinander arbeiten, gehört es zum guten Ton Richtlinien aufzustellen, alles zu reglementieren oder als Gesetz festzuhalten. Es gibt Bauvorschriften die genau festlegen, wie viele Bäume man in seinem Garten haben muss. Steuergesetze legen fest, wie viel vom erwirtschafteten Gewinn dem Staat gehört. Böse Zungen behaupten sogar, die Krümmung der Banane in der EU sei strengstens geregelt. An jedem Stammtisch wird darüber geredet und geflucht. Umso interessanter ist die Tatsache, dass wir oft selbst gerne die Dinge reglementieren, mit denen wir uns täglich im Arbeitsumfeld beschäftigen.

Coderichtlinien sind in jedem Softwareprojekt ein absolutes Muss. Nur so kann die Lesbarkeit und Wartbarkeit des Quellcodes gesichert werden. Deshalb werden oftmals schon im Vorfeld des Projekts Namenskonventionen diskutiert und festgelegt. Ob private Methoden mit einem großen oder kleinen Buchstaben beginnen, scheint dann oftmals wichtiger als deren Inhalt. Es ist jedem bewusst, dass dies keinen Einfluss auf die Software hat. Dennoch scheint es unglaublich wichtig, solche Dinge festzulegen. Ist man mit den getroffenen Richtlinien zufrieden, wird das Ganze in einem Dokument festgehalten. Fertig ist das Gesetzbuch für jeden Softwareentwickler. In einem zweiten Schritt wird dann die Softwareentwicklung mithilfe von Software kontrolliert. Dann ist es nicht mehr möglich, sich nicht an die Richtlinien zu halten. Ein jedes Fehlverhalten wird beim Kompilieren angezeigt und muss noch vor dem Einchecken behoben werden. „Schöne, heile Entwicklerwelt“, könnte man meinen. Allerdings sieht die Realität oftmals anders aus. Die Dokumente für Coderichtlinien werden in wochenlanger Arbeit erstellt, um dann schon nach Stunden veraltet zu sein. Das gilt auch für die automatisierten Kontrollen, die es nötig machen, lange Korrekturen durchzuführen, ohne dass das Programm danach schneller oder effizienter läuft. Ob eine Leerzeile oder gleich drei, das macht für den Compiler keinen Unterschied. Vergessen wird hierbei aber auch, dass es für den Entwickler keinen Unterschied macht. Menschen sind es gewohnt, Texte unterschiedlicher Autoren, Schriftarten und Themen zu lesen. Dabei sind sie mehr als jeder Compiler in der Lage, diese Inhalte zu interpretieren.

Die Softwareentwicklung macht ohne Regeln am meisten Spaß. Natürlich gibt es auch hier eine Ausnahme. Empfehlenswert ist es, Bücher zum Thema zu lesen: „Clean Code“ von Robert C. Martin sei hier als Standardwerk genannt. Das Buch ist keine sture Sammlung von Regeln, sondern beschreibt Techniken, mit denen Entwickler ihren Code „sauber“ halten können. Diese Techniken können als Grundlage dienen und jedem Entwicklerteam helfen, zu einem Konsens zu kommen, wie Code zu schreiben ist, und wie er lesbar bleibt – und das ohne großes Theater und ausschweifende Diskussionen.

Meetings, Meetings, Meetings

Zu guter Letzt noch ein Problem, das je nach Unternehmen regelrecht ausarten kann. Ebenso wie der Begriff „Meeting“ völlig überstrapaziert wird, ist es auch der Terminkalender eines jeden Entwicklers. Meetings am Morgen, am Mittag und am Abend lassen den Eindruck entstehen, der Arbeitstag bestehe nur noch aus Besprechungen.

Positiv an vielen Meetings ist die Tatsache, dass man beschäftigt wirkt. Man ist auf dem neuesten Stand und kann bei allem mitreden. Leider sind viele Meetings unproduktiv und führen zu keinem Ergebnis: Man ist am Ende einer Besprechung genauso schlau wie vorher. Eine Situation, die für alle Beteiligten unbefriedigend ist und mitunter kontraproduktiv sein kann. Immerhin muss man die Zeit mit einberechnen, die man benötigt, um sich auf die Besprechung vorzubereiten. Auch dauert es eine Zeit, bis man seine Arbeit wieder aufnimmt. Der Zeitverlust durch Meetings wird häufig unterschätzt. Ein effektiver Arbeitsfluss kommt in der Zeit zwischen zwei Meetings selten zustande.

Aber wie lassen sich unnötige Meetings vermeiden? Wer zu einem Meeting einlädt, sollte auf jeden Fall ein Ziel definieren. Ideal wäre es natürlich, nur dann zu einer Besprechung einzuladen, wenn am Ende auch wirklich eine Entscheidung getroffen wird. Ein reiner Informationsaustausch kann auch im Pausenraum, am Schreibtisch oder mithilfe von Dokumenten stattfinden. Schwieriger wird es, wenn man zu einem Meeting eine Einladung erhält. Hier ist es empfehlenswert, nachzufragen, ob eine Teilnahme am Meeting unbedingt nötig ist. Vor allem dann, wenn die Anzahl der Teilnehmer im Vergleich zur Länge des Meetings relativ hoch ist. Hier zeigt die Erfahrung, dass es sich meistens um informative Meetings handelt, bei denen eine Teilnahme nicht notwendig ist. In solchen Fällen bietet es sich an, die Zusammenfassung zu lesen.

Ende gut, alles gut?

Nicht ganz. Ich bin mir sicher, dass es immer wieder neue Probleme in der Anwendungsentwicklung und im Projektalltag gibt. Immerhin ist die Softwareentwicklung noch ein recht junges Handwerk. Während Architekten schon seit Jahrtausenden Häuser, Kathedralen und Stadien errichten, kommen Softwareentwickler gerade einmal auf ein halbes Jahrhundert Praxiserfahrung. Natürlich sind auch viele der aufgeführten Beispiele etwas übertrieben und durchaus mit einem Augenzwinkern zu verstehen. Man muss sich natürlich auch nicht zu hundert Prozent an die Vorschläge halten. Ab und zu sollte man schon einmal selbst experimentieren. Ich persönlich bin immer wieder erstaunt, wie sich viele Dinge doch von selbst organisieren lassen. Dinge, über die man stundenlang nachgedacht hat, die akribisch vorbereitet wurden und am Ende dann doch ganz anders gelaufen sind, aber nicht im negativen Sinne. Auch deshalb bin ich ein großer Freund der agilen Werte und der Selbstorganisation. Denn tatsächlich kommt man oft zu den besten Lösungen, wenn sich die Betroffenen selbst mit einem Problem beschäftigen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -