Kategorie: Projektwelt

Ich möchte zwischendurch mal mit einem Zitat aus einem meiner Lieblings-Fachbücher aufwarten. Dieses beiden Zitat-Absätze fassen in wenigen Worten die Unwegbarkeiten zusammen, denen auch ich in 30 Jahren Projekttätigkeit nicht selten ausgesetzt war.

Ungenaue Planung und Verfolgung des Projektes

Dürftig formulierte Anforderungen führen typischerweise zu falschen, häufig zu übertrieben optimistischen Schätzungen, da die im Projekt verborgene Komplexität nicht erkannt wurde. Die unvermeintliche Folge sind Termin- und Budgetüberschreitungen.

Das Planen eines Projektes, dessen Systemziele und Systemanforderungen nicht klar festgelegt sind, gleicht einem Stochern im Nebel. Es ist immer wieder faszinierend, mit welcher Überzeugung Projektleiter Zeit- und Kostenpläne erstellen und aktualisieren, obwohl ihnen die Sinnlosigkeit ihrer Tätigkeit eigentlich bewusst sein sollte.

Aus dem Buch „Requirements Engineering und -Management“
von Chris Rupp

Dazu eine Anmerkung von mir

Ich habe mich oft mit der Wahrnehmung konfrontiert gesehen, dass man doch angeblich viel zu viel Projektzeit für ein Projekt einplanen würde und alles daher viel zu teuer kalkuliert.

Wenn man dann auch noch als Unerfahrener auf Einschätzungen von Entwicklern hört, die einem erklären, dass alles vermutlich weniger aufwändig ist, gießt das noch mehr Öl in das „siehste-geht-doch-günstiger-Feuer“.

Wieso sagt nun der erfahrene Projektmanager, dass alles länger dauert und der Entwickler mehr oder weniger das Gegenteil?

Wenn man einen Entwickler mit schwammigen und/oder unvollständigen Formulierungen und Zielen brieft und eine Einschätzung erhält, ist diese dank unterschlagener oder unvollständiger Infos oft für’n Arsch.

Das ist dann die Phase 1 eines erfolgreichen Selbstbelügens in Projekten und einer der Gründe, warum weltweit so viele Projekte scheitern bzw. mindestens einmal weit über die Zeit- und Finanz-Stränge hinausschlagen.

Studie belegt: In 70% der Unternehmen scheitern IT-Projekte wegen unterschiedlicher Planungssichten

Die Phasen des Selbstbelügens werde ich bei Zeiten noch einmal genauer erörtern.

Der erfahrene Projektleiter hingegen hat schon Pferde kotzen sehen, vor der Apotheke.

Immer wieder kam und kommt es zu Situationen, in denen man auf seinen Webseiten Funktionen umsetzen oder Partner einbinden möchte, die durch das Einbinden einer JS-Datei total schnell und easy auf eine Seite gelangen könnten.

Das kann für kleine Websites auch ein gängiges Modell sein. Wenn man aber große Websites betreut, die wirklich Milliarden an Seitenaufrufen im Monat generieren oder einen für eine Firma betriebskritischen Charakter vorweisen und dort bereits komplexeste Funktionen ablaufen, dann kann man auf die Behauptung, man müsse nur ein JS einbinden und sich um nichts weiter kümmern, nur mit einem freundlichen aber bestimmten „You wish!“ antworten.

Immer, wenn jemand so etwas äußert, ist markant Vorsicht geboten. Mindestens mal muss das ausgiebig und optimaler Weise unter Realbedingungen getestet werden. Und am besten schaut man sich im Detail ganz genau an, was das Stück Software macht, das man sich da auf die Seite holt. Denn jedes eingebundene JavaScript erhält die volle Macht über die Seite.

Und dabei kann so vieles passieren:

• Die Performance der Seite geht in die Knie
• Die Datenmenge wird schlagartig größer
• Andere Funktionen laufen nicht mehr
• Unerklärliche Dinge passieren
• Nutzer werden mal eben zu einer Dritt-Seite „entführt“, um denen da ein Cookie zu verpassen und wieder zurückzuleiten
• Datenschutzverstöße
• Sicherheitslücken

Du brauchst dich um nichts kümmern

Als ich bei einem meiner Kunden vor einigen Jahren neu anfing und das Initalbriefing zu den zahlreichen kleinen und großen Anforderungen erhielt, die ich betreuen durfte, wurde mir eines der Projekte folgendermaßen vorgestellt:

„Das ist ABCD, hier wissen schon alle Bescheid, du musst dich um nichts kümmern. Das geht nächste Woche live. Da kommt nur ein Stück JavaScript auf unsere Seite.“

Natürlich beglückt man neue Kunden nicht mit einem „You wish!“ sondern ich antwortete mit „alles klar!“.

Als dann kaum zwei Tage später der erste Entwickler auf mich zu kam und fragte, was genau hier denn gemacht werden sollte, zeichnete sich irgendwie bereits ab, dass das wohl doch nicht so reibungslos über die Bühne gehen würde, wie man sich das eingangs so dachte.

Genau genommen, war nämlich gar nix klar, was die Implementierung und Auswirkung auf die Seite angeht. Und es begann feinstes Projekt-Gedöns:

1. Die Software wurde auf einer Messe in den USA präsentiert mit „ihr müsst nur ein Stück JavaScript auf die Seite einbinden, ganz einfach, dann könnt ihr damit Geld verdienen“.
2. Die Software wurde von einer Führungsperson eingekauft, die üblicher Weise nicht fokussiert ist auf den Einkauf oder die Implementierung von Software
3. Die Software wurde an der IT-Abteilung vorbei eingekauft und es wurde auch nicht geprüft, ob das so einfach implementierbar ist. Klar, denn es musste ja nur ein Stück JavaScript auf die Seite.
4. Es wurde bereits via Pressemitteilung angemerkt, dass wir nun diesen Dienstleister einbinden und das in den folgenden Wochen live gehen würde.
5. Erste Tests nach Implementierung warfen Fragen auf:
   1. Wie genau soll das denn alles im Adminbereich des Anbieter konfiguriert werden? Es hat sich nämlich bis zu diesem Zeitpunkt keiner Gedanken über die Fachlichkeit gemacht.
   2. Ja genau, es gibt einen Adminbereich, wo alles auch noch konfiguriert werden muss. Sowas kann ja keiner ahnen.
   3. Auf welchen Seitentypen oder in welchen Bereichen soll die Software denn laufen?
   4. Wie soll das gute Ding denn aussehen? UX, Design?
   5. Wie läuft das denn mit denn Apps?
   6. Ist das kompatibel mit allen Geräten und Betriebssystemversionen, die wir grundsätzlich unterstützen wollen?
6. Man war not amused, dass ich so viele Fragen stellte und aufzeigen musste, dass man den avisierten Zeitrahmen mit großer Wahrscheinlichkeit mal gepflegt vergessen kann.

Nach 6 Monaten umfangreichen Analysierens, Konzipierens, Implementierens, Testens und sehr sehr viel Kommunikation zwischen verschiedensten Parteien ging es es dann endlich live. Also nur knapp etwas mehr als die vorgegebene eine Woche.

Das ist natürlich in der Projektwelt nichts Ungewöhnliches. Böse Zungen behaupten ja immer, dass man bei einer Projektlaufzeit-Schätzung diese immer verdoppeln und die nächst höhere Zeiteinheit nehmen soll. Wenn man also sagt, das Ganze dauert 4 Tage, dann sind es eigentlich 8 Wochen.

Als wir damit nun aber tatsächlich live waren, passierten interessante Dinge, die trotz ausgiebiger Tests zuvor nicht aufgefallen waren und die sich auch keiner auf Anhieb erklären konnte. Geschweige denn, dass am Anfang bereits deutlich war, dass der neue Dienstleister dieses Problem verursachen würde, da Dienstleister und der Bereich des auftretenden Problems „eigentlich“ gar nichts direkt miteinander zu tun hatten.

Es passierte Folgendes:

Es gibt Werbebanner, die aus mehreren einzelnen Werbepositionen bestehen und zusammen eine große Werbefläche ergeben. In diesem Fall ein sogenanntes Fireplace Ad. Dieses Fireplace Ad zeigte in dem linken Teil Werbung von irgendwas, was der AdServer gerade so auslieferte, und im mittleren und rechten Teil die eigentlich gewünschte Werbung eines Autoherstellers. D.h. die große Werbefläche, die aus 3 Teilen ein Gesamtbild zeigen soll, und auch nur in vollständiger Form sinnvoll ist und gezählt werden darf, war kaputt.

Es ist einem Kunden auch schwer zu erklären, warum sein Fahrzeughersteller-Werbemittel zu einen Drittel aus Tütensuppen-Werbung bestehen sollte.

Sowas hat natürlich erst einmal Implikationen auf die Vermarktung bzw. die Kundenbeziehung. Reges Treiben und Verlust der kommunikativen Etikette sind dann häufig zu verzeichnen. Denn der Kunde bezahlt (viel) Geld, sein Werbemittel wird aber nicht korrekt ausgeliefert und erzielt damit nicht den gewünschten Effekt. Also muss man das Problem lösen und Kompensation zahlen und/oder entsprechende Werbeauslieferungen nachliefern.

Was wir dann herausbekommen haben:

Das lustige neue JavaScript entführte den Nutzer für den unmerkbaren Bruchteil einer Sekunde zu einer Seite des Anbieters, um dort ein Cookie zu verarbeiten und schickte ihn dann wieder zurück. Das kann gutgehen, muss es aber nicht.

Das hatte zufolge, dass der AdServer, der auch via JavaScript auf der Seite eingebunden ist, beim Laden eben dieser Seite schon mal losgelaufen ist und den ersten Teil des Fireplace-ADs offiziell auslieferte. Und während er gerade im Begriff war, das auch mit den anderen Teilen des Werbemittels zu tun, kam das neue JavaScript des anderen Anbieters mit einer Blutgrätsche von rechts, zog den Nutzer auf die besagte andere Seite. D.h. alle anderen in dem Moment laufenden JavaScript-Aktionen auf unserer Seite wurden natürlich unterbrochen, weil der Nutzer physikalisch nicht mehr da war sondern halt woanders in diesem Internetz.

Als dann der Nutzer wieder zurückgeleitet wurde, lief der AdServer wieder los und hätte nun alle drei Teile der Werbung laden können.

Nur leider gab es ein Frequency-Capping auf dem Werbemittel, welches dafür sorgte, dass eine Werbung nur ein einziges Mal pro Nutzer ausgeliefert werden sollte. D.h. der erste Teil der Werbung war technisch gesehen schon ausgeliefert, auch wenn der Nutzer das nie gesehen hat, weil er ja im Millisekundenbereich entführt wurde. Aber der AdServer ist ja ein Computer und bekommt Dinge schneller mit als ein Mensch. Daher hat er sich die bereits erfolgte Auslieferung gemerkt und darf entsprechend hier die Werbung nicht noch mal ausliefern.

Doof gelaufen. Ungünstige Konstellation verschiedenster Parameter. Und der Zeitraum, bis man so etwas identifiziert und auf einem Live-System gefixt hat, kann mal ein paar Stunden bis Tage dauern.

Zurück zum eigentlichen Thema

Mit jedem JavaScript, was man sich auf eine Seite holt, kann es zu Herausforderungen kommen. Insbesondere weiß man nie, wann ein Stück JavaScript anfängt oder wann ein anderes genau endet oder wo sie sich da torpedieren.

Man sollte also immer wissen, was die eingebundenen JS-Bibliotheken auf der eigenen Seite so veranstalten und auch wann sie da ihre Party feiern. Wenn man das vorher nicht weiß und ggfls. auch nicht die passenden Testcases bereit hält, dann kann mal Blödsinn passieren. Im Zweifel auch sehr teurer Blödsinn.

Würde man jetzt anfangen wollen, zu koordinieren, wann welches JS losläuft und bspw. immer warten würde, bis das nächste starten darf, ja, das könnte man machen. Aber man möchte seinen Nutzern die fertige gerenderte Website auch so schnell wie möglich anzeigen und ihn nicht durch immens lange Ladezeiten verprellen. Von der Komplexität bei der Implementierung wollen wir an dieser Stelle noch gar nicht sprechen.

Da bleiben nur folgende Dinge, die man mitnehmen sollte:

• Augen auf, beim JavaScript-Kauf!
• Traue niemandem, der behauptet, man müsse nur ein JavaScript auf die Seite einbinden und sich ansonsten um nichts kümmern. Insbesondere keinem gewieften Vertriebsmenschen. Egal wie nett sie/er einem den Kaffee (mit oder ohne Schuss) einschenkt.
• Lasst niemanden Software für ein Unternehmen einkaufen, ohne das mit Kollegen*innen zu besprechen, die das ggfls. sinnvoll bewerten könnten.

Und wenn wir ehrlich sind, gilt das nicht nur für Websites und JavaScript sondern für jegliche Bibliotheken, die man sich in seine (auch klassischen) Softwareprojekte einverleibt.

Nicht nur während Corona-Zeiten gültig:

Stay save, get tested!

Der nachfolgende Artikel hat fachlich wenig Tiefgreifendes zu erzählen sondern beschäftigt sich mit einer Basisfragestellung, die mich während meines mittlerweile fast 3 Jahrzehnte andauernden (IT-)Werdegangs ständig begleitet:

Du machst doch auch was mit Computer, oder?

Seit ich im fortgeschrittenen Alter von 17 Jahren das Elternhaus verlassen und mich in Hamburg niedergelassen habe, um was mit Computer zu machen, ist dieser Satz präsent. Und grundsätzlich haben die Personen, die das fragen, schon mal den Nagel auf den Kopf getroffen: Ich mache tatsächlich was mit Computern.

Gleichzeitig steht der Satz aber auch für reichlich Unwissen über diese Materie, was ich den meisten, ob der Komplexität der IT- oder auch allgemeinen Projekt- und Geschäfts-Welt, nicht verübeln und das absolut nachvollziehen kann. Und er hat sich witziger Weise seit 30 Jahren nicht verändert. So aktuell wie am ersten Tag.

„Du macht doch auch was mit Computer, oder?“

Die Frage steht also für eine mangelnde Vorstellungskraft bzw. mangelnde Erfahrungen, dass man, wenn man was mit Computer macht, auch Dinge tut, die nicht mit Druckerkabeln, Windows-Installationen oder Router-Neustarts zu tun haben. Und ganz wichtig: nein, man kommt auch nicht günstiger an Computer ran. Spätestens bei dem letzten Satz bricht für viele eine (Vorstellungs-)Welt zusammen.

Vielleicht ist es auch nur die logische Konsequenz der technologischen Weiterentwicklung und ein Generationskonflikt. Vielleicht auch ein etwas deutlicherer als er bei vorherigen Generationen merkbar war. Der Technologie-Sprung in den letzten 30 Jahren, insbesondere mit Einführung von Informationstechnologie, war vermutlich zuvor in der Weltgeschichte noch nie so hoch in so kurzer Zeit.

In den Anfangsjahren habe ich meinen Eltern und auch anderen aus meiner Herkunfts-Area (sowohl vor als auch hinterm Deich) versucht zu erklären, was ich so mit Computern mache. Selbst ganz am Anfang, als ich tatsächlich noch (wenn auch nur zu einem Teil meiner Zeit) Computer zusammengebaut und Netzwerke eingerichtet habe, habe ich jedoch auch Assembler, Cobol, C oder Pascal gelernt und auch schon mal kleine Programme geschrieben sowie Personen in der Bedienung von PCs oder konkreten Software-Produkten geschult. Damals noch sowas Verrücktes wie Word Perfect (oder Schlimmeres) auf MS-DOS-Basis. Oder ich habe – und das war damals dann schon eine gehobenere Beschäftigung – kleinen Firmen beigestanden, mit Adressdatendateien und bspw. Word Perfect, Serienbriefe zu erstellen und zu verschicken oder auch denen schon damals zu erläutern, wie man ein Offline-Mailing überhaupt grundsätzlich strukturell und inhaltlich sinnvoll aufbaut. Spannungskurve, Goldener Schnitt, above the fold und so’n Gedöns. Und ja, auch 1992 schon mit Grafiken.

Spätestens nach „Kobold“ sind auf jeden Fall 95% meiner Zuhörerschaft ausgestiegen.

Dabei wissen selbst Politiker heutzutage, dass man mit „Kobold“ tolle Autobatterien bauen kann. Aber egal, anderes Thema in Sachen „Neuland“.

Was kann er denn eigentlich?

Diese mangelnde Fortstellungskraft sorgt dafür, dass ich all die Jahre zahlreich und insbesondere in Bezug auf Problemstellungen befragt wurde, welche irgendwie was mit Computern und deren natürlichen Lebensräumen in (semi-)privaten Haushalten zu tun hatten. Und da ich das immer alles beantworten konnte, hat sich in den Köpfen festgesetzt, dass ich genau dafür und nur dafür da wäre, das meine Kernkompetenz sei und ich auch gar nichts Anderes weiß und es auch total toll finde, mich mit solchen Sachen herumschlagen zu dürfen.

Und ja, natürlich habe ich einiges an Know-How, wenn es darum geht, sich mit solchen Dingen auseinanderzusetzen. Ich weiß auch, wie man die Fritz-Box so konfiguriert, dass man das Home-Internet mit dem DSL- oder Kabel-Anschluss zum Laufen bekommt und wie man schlau ein WLAN aufbaut oder ein Nebengebäude, das hinter den Stallungen für die Bediensteten errichtet wurde, ohne Netzwerkkabel sondern per Strom noch sinnvoll ins Internet bekommt. Und auch, dass nun Staubsauger mit einem sprechen oder Teppanyakis, die nach Erstinstallation für einen GetTogether mit den Jungs und Bierflaschen zum Staunen und Fachsimpeln taugen, aber danach nie wieder benutzt wurden, ist eine logische Konsequenz für mich. Alles technisch-evolutionär nachvollziehbar. Auch auf „Zigbee“ antworte ich nicht mit „Gesundheit!“, ich kenne den Unterschied zwischen POP3, IMAP und SMTP, ich weiß was DNS, CNAME, TTL oder MX-Eintrag bedeuten und was man damit macht und vor allem wo und ein Ping hat nicht unbedingt immer was mit der Jagd auf einen roten Oktober zu tun. Als Kind habe ich sogar mal ein Seepferdchen gemacht und ein bisschen Dänisch kann ich auch.
Danke LaRed und Bjarne Mädel für diesen Klassiker mit dem Dänisch.

Aber all das summiert sich nicht mal auf einen Prozentpunkt des Basiswissens, welches notwendig ist, um den Job zu machen, den ich heute mache.

Es hat im Laufe der Jahre für eine intensive Ermüdung gesorgt, wenn man sich doch ständig weiterentwickelt und neue Herausforderungen und Aufgabengebiete gesucht hat, man aber immer noch und viel zu oft mit nervigen Basics Dritter beschäftigen durfte und nicht gelernt hat, nein zu sagen.

Ich weiß nichts mehr

Ich habe irgendwann den Absprung geschafft und konnte den Eindruck (zumindest im privaten Umfeld) vermitteln, dass ich eigentlich gar nicht mehr viel weiß, wenn es darum geht, dass das Internet kaputt ist, der Rechner nicht mehr läuft, was eine Fehlermeldung bedeutet, die vom Nutzer ungelesen weggeklickt wird und ich weiß auch nicht mehr, was noch das Passwort für wessen E-Mail-Account oder Strato-Login war. Und wenn der Sohn vom Nachbarn irgendwo was am Router verstellt oder Plugins installiert, kann man auch manchmal einfach nicht mehr helfen.

Ich muss mir selber über 100 Passwörter für was-weiß-ich.de merken und die meisten scheitern schon daran, sich ein einziges zu verinnerlichen. Oder sie schreiben das dann auf einen Zettel und kleben den direkt neben dem Bildschirm. Chapeau!
Mein Blutdruck ist mir mittlerweile doch etwas wichtiger, als zu versuchen, alle Menschen auf dieser Welt in Home-IT-Basics missionieren zu wollen. Sowas mache ich nur noch für eine auserlesene, kleine Gruppe.

By the way, kurze Anekdote: Letzt habe ich jemanden bei einer Installation begleiten dürfen, am Ende derer er ein neues Passwort für seinen Apple eingetippt hat. Das Ergebnis: Ein einziges aber durchaus charmantes Leerzeichen.
Vermutlich ist das so unglaublich, dass es keine Hacker-Software der Welt herausbekommen würde. Die denken sich auch, so beachtlich kann niemand sein, nur ein einziges Zeichen einzugeben und dann auch noch ein Leerzeichen. Ich möchte Apple an dieser Stelle auch ein Stück weit beglückwünschen, dass sie so etwas überhaupt zulassen.

Und wieso erzähle ich das alles?

Mein täglich Job basiert irgendwie auf all dem Krams (außer das mit dem Seepferdchen) bzw. dem dafür notwendigen, umfangreichen Wissen, auch wenn ich sowas wie eben beschrieben nicht mehr selber mache bzw. es mir völlig ausreicht, meine eigene IT-Welt im Haus administrieren zu „dürfen“.

Ich benutzte Informationstechnologie, um große Projekte und Welten zu schaffen, um zu kommunizieren und zu verwalten, um Prozesse zu optimieren und Herr der Lage zu bleiben, zu coden (programmieren) oder zu designen. Und sehr sehr selten auch, um mal ein Spiel zu spielen. Aber ich beschäftige mich nicht mehr mit dem Computer zum Selbstzweck und ich lasse mich auch nicht mehr vom Computer beschäftigen. Der Computer ist ein professionelles Tool, auf dem viel Software läuft, und das hat zu funktionieren. Und es muss performant funktionieren, um Requirements-Engineering, Business-Analyse, Agile Transformation, Prozesse, Projektmanagement, Beratung, Schulung in komplexen und deutlich erklärungsbedürftigen Geschäftsumfeldern ausüben zu können. Und was einem noch so einfällt.

Wenn du nun den Personen, die bei „Kobold“ bereits ausgestiegen sind, das alles erläutern möchtest, stehst du auf verlorenem Posten. Man schafft es einfach nicht, das landschaftlich zu beschreiben, was man tut und wie wichtig das ist oder wer davon profitiert, weil man dann vom Hundertsten ins Tausendste abdriften müsste, da evolutionär- und generationsbedingt keine ausreichenden Basics vorhanden sind, geschweige denn eine Vorstellungskraft für das große Ganze und dessen Zusammenhänge und das man vielleicht gar nicht mehr was mit Computer macht sondern dies „nur noch“ als Werkzeug nutzt, um ganz andere Dinge zu schaffen.

---

Ich: „Ja, wenn du auf das X klickst, schließt sich das Fenster. Der Knopf daneben blendet das Fenster nur aus und du siehst das dann unten in der Task-Leiste!“

Andere so: „Task-Leiste???“

---

Und ich habe es auch aufgegeben. Die Eltern und sonstige übrigens auch. Beruht also auf Gegenseitigkeit. Die haben sich wohl mittlerweile damit zufrieden gegeben, dass man mit dem Quatsch, den ich (und viele andere) mache/n, ausreichend monetäre Mittel erwirtschaften kann, um sich Nutella statt Nusskati leisten zu können.

Ich möchte hiermit anmerken, dass ich Nusskati geiler finde als Nutella. Unabhängig davon verachte ich die gesamte Palmöl-Industrie und deren Auswirkungen auf den Planeten und beschränke mich mit dem Konsum auf wenige Happenings im Jahr. Bspw. ein Nusskati-Brötchen zum jährlichen Bad.

Veränderung

Irgendwann vor nicht all zu langer Zeit merkten die Eltern gegenüber Dritten an, dass der Jung wohl in einer Agentur arbeiten würde. Das war dann der Dolchstoß ins Herz (mit Umdrehen und Herausziehen) zu diesem historischen Werdegang. Ohne die Arbeit von Agenturen schmälern zu wollen.

Andere so: „Als Grafiker?“

Eltern: „Nein, der macht da was mit Computer!“

Im Moment arbeite ich für ein einigermaßen renommiertes Print-Magazin mit Online-Ableger. Wenn das erzählt wird dann:

Andere so: „Als Redakteur?“

Eltern: … Sie können es schon ahnen.

Ich habe noch einige Jahre bis zur dann nicht vorhandenen Rente, das kann daher nicht alles gewesen sein und die Geschichte geht sicherlich noch weiter.

Und ich bin auch total gespannt, vor welchen Herausforderungen unsere Generation später oder bald stehen wird. Ich erwarte da irgendwelche Bio-Schnittstellen, die unser alterndes Hirn nicht verarbeiten kann. Und während wir dann erfolglos versuchen, den ausschließlich via bio-interface steuerbaren und fahrbaren Gartenhäcksler zu bedienen, der dann unkontrolliert durch Muttis Tulpen pflügt, werden wir von unseren Kindern kopfschüttelnd ausgelacht.

Ich mache halt nur was mit Computer.

Fangen wir mit dem Innbegriff aller Rollen an: Projektmanager oder Projektleiter. Alles klar! Oder um es mit den Worten guter alter Waschmittelherstellerwerbung zu sagen:
Da weiß man, was man hat. Guten Abend!

Ehrlicherweise bin auch ich und auch heute noch immer wieder überrascht, mit welch unterschiedliche Wahrnehmung diese Rolle in verschiedenen Unternehmen gesehen und gelebt wird:

Der eine koordiniert die Projekte, coded selber und installiert auch gleich das Dokumentenmanagementsystem vor Ort beim Kunden in einem Schweizer Hochsicherheitsberg und hat nach Weihnachten enorme Probleme, wieder in den Serverraum zu gelangen, weil die Gewichtskontrolle anschlägt und den Zugang verweigert.

Der andere macht eigentlich nichts Anderes als Termine für Meetings zu suchen und Kollegen einzuladen, Agenden zu formulieren, Protokolle zu schreiben und vielleicht noch Kostenpläne zu administrieren. Den Rest der Arbeit erledigt schon jemand Anderes aus dem Projektteam. Es gibt keinen tiefen, fachlichen Einblick in die Materie. Und vielleicht wird die ein oder andere Agenda auch mal vergessen.

Noch ein anderer ist eigentlich nur ein besserer oder schlechterer, „kommunikativer“ Durchlauferhitzer mit gefährlichem Viertelwissen, was zu laufend grünen Status führt, bis es auf einmal und dann aber ganz schnell derbe rot wird.

Wiederum andere sind systemisch unterwegs und versuchen ­– oft auch ohne tieferes Detailwissen zur projektierenden Materie – durch Methodiken und geschickte Fragestellungen die dem Projekt zugewiesenen Spezialisten so einzubinden, dass am Ende etwas Sinnvolles dabei herauskommt.

Und dann gibt es da sicherlich noch (wenn auch wenige) Projektleiter, die alles machen und auch können, was notwendig ist, damit ein Projekt irgendwie zu einem Erfolg führt: Beratung, Projektleitung, Controlling, Business Analyse, Anforderungsmanagement, ein paar Prozesse hier und da, ein wenig UX und Design, den ein oder anderen Code selbst ins Repository einschmuggeln, Testing, Workshops und die schmieren dann auch noch die Krabbenbrötchen für die nächste Retro.
Vielleicht lässt man die dann aber lieber nicht auf politisch sensible Projekte los. Weil irgendwas können auch die nicht gut.

Sicherlich gibt es dann noch verschiedene Mischformen der eben angemerkten aber ganz bestimmt nicht vollständigen Punkte.

Und im Detail?

Lösen wir uns einmal von den verschiedenen Wahrnehmungen und Ausprägungen, könnte ein Konsens zu dieser Rolle wie folgt aussehen:

Projektmanager…

• … sind dahingehend verantwortlich, dass in einem bestimmten (ggfls. zeitlichen und oder finanziellen) Rahmen ein Projekt zu einem (positiven oder auch negativem) Abschluss geführt wird. Dazu könnte gehören :
  • Zieldefinitionen, inkl. Termin- und Kostenziele
  • Risikoanalyse
  • Verantwortungsbereiche abgrenzen
  • Teamzusammenstellung
  • Ressourcenplanung
  • Grobe Planung des Gesamtablaufs
  • Aufteilung in Teilprojekte
  • detaillierte Budgetplanung
  • Definition von Prozessen im Projekt
• … analysieren, priorisieren und optimieren Anforderungen oder sorgen dafür, dass dies von anderen Projektteilnehmern erledigt wird. Dazu könnte gehören:
  • Business-Analyse
  • Anforderungsmanagement
  • Ausarbeitung/Ausformulierung der Anforderungen (Konzepte, Wireframes, Tickets, User-Stories, Lastenhefte, Pflichtenhefte, User-Flows, Workflows, diverse Arten von Schaubilder)
  • ggfls. Veranstaltung von entsprechenden Workshops (Ideenfindung, Detaildurchsprache)
• … koordinieren alle Tätigkeiten innerhalb eines Projektes und halten diese auch nach. Dazu könnten auch gehören:
  • ToDo-/Issue-Tracking (egal, ob in Excel, Jira oder monday-tuesday-wednesday.com, Hauptsache es gibt eine Übersicht, in der alle Tasks eingetragen und nachgehalten werden)
  • Koordination von Workshops zur Abstimmung von Issues
• … koordinieren Meetings, in dem sie diese vorbereiten (Agenden), nachbereiten (Sitzungsprotokolle) und Aufgaben daraus ableiten und nachverfolgen (Issue-Tracking)
  • Einladung und Vorbereitung zu Meetings (Es gibt nichts Schlimmeres als in Meetings eingeladen zu werden, zu denen es keine Agenda gibt. Kaffeeklatsch ist vorprogrammiert.)
  • Meeting-Protokolle (super „zielführend“ sind Meetings, zu denen es keine Protokolle gibt, als auch keine Festlegungen, welche Punkte wie besprochen und entschieden wurden und von wem bis wann nun erledigt werden, ganz zu schweigen von vielen passiven Äußerungen wie „ja, das müsste man dann mal irgendwie klären“).
• … sind Ansprechpartner in nahezu allen Belangen für Kunden, Stakeholder, Projektmitglieder und sonstige Parteien, die irgendwas zu einem Projekt beisteuern müssen, wissen wollen oder ein berechtigtes Interesse daran haben, eingebunden zu werden.
  • Erstellung laufender Reportings und Status-Präsentationen
  • ggfls. Zusatzveranstaltungen (bspw. Townhalls)
• … kümmern sich um Eskalationen:
  • Sichtweisen/Wahrnemungen beteiligter Streithähne aufnehmen
  • Vermitteln, schlichten
  • Mediationen durchführen oder durchführen lassen
  • Retrospektiven veranstalten
  • ggfls. Adressierung nach „oben“

Das macht der alles?

Bei kleineren Projekten ist es wahrscheinlich, dass viele der o.a. Aktivitäten von einem Projektmanager ausgeführt werden. Vorausgesetzt, die Befähigung für alle Punkte ist vorhanden.
Bei größeren Projekten hingegen kann davon ausgegangen werden, dass die koordinativen und steuernden Tätigkeiten überwiegen und insbesondere konzeptionelle Teile von Spezialisten übernommen werden. Letzteres nicht nur ob der schieren Menge an ToDos sondern auch weg des inhaltlichen Anspruches. Spezialisten arbeiten meist fundierter in ihrem Kompetenzrahmen als es Allrounder hinbekämen.

Sobald ein Projekt bzw. die Menge der irgendwie daran teilnehmenden Personen größer wird, ist es meist fortgeschritten charmant zu wissen, wer denn eigentlich welche Rolle hat.

Wenn man sich jedoch mit dem Thema Rollen näher beschäftigt, wird man merken, dass bereits die Klärung von Rollen ein eignes Projekt darstellen kann. Zumindst bei sehr großen Projekten und vielen Teilnehmern oder einem größeren Kernteam.

Und wenn wir das tun, werden wir ebenfalls sehr schnell sehen, dass es nicht ausreichend ist, nur die Rollen zu vergeben sondern auch zu klären, was genau die Rollen bedeuten. Also welche Aufgaben oder Verantwortlichkeiten hat denn welche der Rollen?

Und weiterhin werden wir sehr schnell an den Punkt angelangen, wo wir uns neben der Definition von Rollen auch intensivere Gedanken über einen Prozess machen müssen:

• Wer kommt denn zu welchem Zeitpunkt mit Projektanforderungen auf wen genau zu?
• Wer entscheidet wann, welche Anforderungen wichtig sind, welche später umgesetzt werden dürfen oder welche direkt in die Tonne weitergeleitet werden?
• Wer wird angerufen, wenn sich Jan-Cedric und Paris-Jaqueline nicht einig werden?
• Welche Regelmeetings benötigen wir denn für ein Projekt oder in der Firma?
• Und machen wir das ganze Wasserfall oder Scrum oder Kanban oder ScrumBan oder mit einem agilen Wasserfall?
• Und was ist überhaupt mit dem Empfang und dem Catering?

Was ist deine Mission?

Bei vielen Rollenbezeichnungen ist nur anhand der Benennung nicht unbedingt hundertprozentig klar, was die exakten Aufgaben sind. Wenn wir jemandem die Rolle als bspw. Projektleiter zusprechen, können wir grob vermuten, was dessen Aufgabe ist, wissen tun wir es zu dem Zeitpunkt aber nicht wirklich.

Wenn wir nun Rollen oder Rollenbezeichnungen definieren, egal ob es sich um allgemein bekannte und gängige oder firmen- bzw. projektintern speziell definierte Bezeichnungen handelt (bspw. „head over heels incoming communications assistant“), so meinen wir letztendlich eine Menge an zugewiesenen Verantwortungen bzw. Aufgaben.

Solange jedoch nicht im Detail niedergeschrieben oder anderweitig nachvollziehbar verankert ist, welche Aufgaben und Verantwortungen eine Rolle wirklich hat, differieren Wahrnehmung, Erwartungshaltung und Realität meist stark. Mit den üblichen Folgen für Projekte: Verwirrung und fehlgeleitete Schafe.

Neben der Definition von Rollen gibt es darüber hinaus noch eine weitere Problemstellung: Hat die Person überhaupt das entsprechende Skill-Set oder das Standing, eine bestimmte Rolle einnehmen zu können? Denn wir werden kaum eine direkt frisch vom Studium stammende Person an ein betriebskritisches System einer Bank lassen wollen, wo dazu noch ein Haufen Director- und C-Level-Persönlichkeiten orchestriert werden müssen.

Da diese Problemstellung mit diesen Rollen aber eine grundsätzliche ist, werden wir sie an dieser Stelle nicht behandeln (können) und fokussieren uns auf die Bezeichnungen und Definitionen. Vielleicht finde ich irgendwann einmal die Zeit, mich konstruktiv und hilfreich mit Skill-Sets auseinander zu setzen.

Da ich nicht anfangen möchte, zusammenzustellen, wie viel interessante Rollenbezeichnungen es in Unternehmen gibt, mit dem man auf den ersten Blick nichts anfangen kann (egal ob deutsch oder englisch), wollen wir uns mal auf die üblichen Verdächtigen in (größeren) Projekten konzentrieren.

Die einzelnen Rollen betrachten wir auf eigenen Seiten in unpriorisierter Reihenfolge:

Es folgen bald:

Ich bin viele Jahre als Freiberufler durch den europäischen Raum gereist, um frohe Kunde zu verbreiten in Sachen Projekt-Realisierung. Genau genommen wurde ich gebucht, um Projekte zu realisieren oder – und das prozentual nicht zu wenig – zu retten. Und um ganz nebenbei noch ein wenig Struktur reinzubringen und good practices zu vermitteln.

Dabei habe ich die folgenden Erkenntnisse sammeln dürfen, welche ich bei über 80% der Projekte vorfand:

1. Viele versuchen oft, fachlich-logisch oder technisch komplexe Projekte erst einmal selber anzugehen, obwohl die notwendigen Skill-Sets ggfls. gar nicht vorhanden waren.
2. Obwohl ich schon frühzeitig im Gespräch war, bin ich oft erst dann gebucht worden, wenn der Karren schon knietief im Morast steckte.
3. Ich bin immer als „Projektmanager“ gebucht worden, obwohl meine Kernkompetenzen eigentlich woanders liegen, und ich habe aber dennoch fast ausschließlich meine Kernkompetenzen ausgeübt und nicht das Projekt „gemanaged“, im klassischen Sinne.

Die drei Punkte schauen wir und jetzt noch mal genauer an.

Wir fangen schon mal an

Obwohl in überraschend vielen Fällen am Anfang gar nicht so richtig klar ist, was eigentlich im Detail realisiert werden soll, habe ich eine Frage sehr oft gehört:

„Könnt ihr nicht schon mal anfangen?“

Das ist so, als würde ich den Tischlermeister bitten, doch schon mal anzufangen, die neue Küche zu bauen. Welche Fronten dran sollen und welche Schränke ich benötige, … ach, das können wir doch später klären.

Solch Herangehensweisen zeigten und zeigen, dass sich Viele der inhaltlichen und prozessualen Tragweite eines Projektes gar nicht bewusst sind. Und damit lässt sich auch zumindest verstehen, warum ebenso Viele glauben, dass man komplexe Projekte auch von Personen steuern lassen kann, die weder das prozessuale, steuernde noch logische Verständnis für das zu realisierende Produkt oder Projekt vorweisen können. Von technischen Aspekten einmal ganz abgesehen.

Insbesondere wenn Projekte primär einen Bunte-Bilder-Charakter haben, also einen Marketing-Fokus besitzen, bspw. eine Biermarken-Seite oder eine Firmenpräsenz, wird gern mal jemand Junioriges in die Position des Projektmanagers erhoben, weil er oder sie gerade frisch vom Marketing-Studium durch ein Assessment an einen freien Arbeitsplatz neben dem Drucker gestolpert und verfügbar ist.

„Dann kann die/der gleich mal zeigen, was sie/er kann!“

… oder auch nicht kann.

Für manche dieser armen Seelen, die glauben, dass man ihnen mit so einem Projekt einen Gefallen getan hat und eine Chance geboten hat, sich zu beweisen, ist XML eine chinesische Nudelsuppe. Und genau so sieht das Ergebnis dann auch aus.

Das Thema „gescheiterte Projekte“ gehe ich irgendwann in einem separaten Beitrag einmal an.

Der Karren ist wieder frei

Die möglichen Folgen von vergaloppierten Projekten können vielschichtig sein:

• Zeit und Geld verbraten
• unzufriedene Kunden und auch Mitarbeiter
• Image-Schäden
• komplette Projektstops
• im worstcase auch Firmeninsolvenzen

In komplexen Projekten gilt daher meistens: „Wer spart, zahlt doppelt!“ Oder noch schlimmer. Insbesondere an der Besetzung von Schlüsselpositionen entscheidet sich oft der Erfolg eines Projektes. Wer da nicht zum richtigen Zeitpunkt weiß, was wann zu tun und was noch zu klären ist, läuft gern mal wochenlang komplett im grünen Status bis ins offene Messer.

Wenn dann jemand (auch Externe) gefunden und auf das Projekt gesetzt wird, um den Versuch zu starten, dieses zu retten, sind meist erst einmal die folgenden und nicht selten schmerzlichen Schritte zu durchleben:

• Einarbeitung in vorhanden Prozesse des Auftragnehmers/Auftraggebers/Projektes
• Einarbeitung in den aktuellen Projektstand
• Einarbeitung in den bisherigen Verlauf (Kommunikation, Anforderungen, Entscheidungen, Entwicklungsschritte)
• Identifikation der Problemstellungen
• Initiale Schritte zur Behebung einleiten
• Die Fragen des Kunden beantworten, wie das denn alles sein könne und warum er das nun noch mal alles erklären muss und wann wird das Projekt denn jetzt fertig.

Eigentlich bin ich was Anderes

Jetzt ist es passiert, ein Projekt ist gegen die Wand gefahren, ich werde als „Projektmanager“ oder „Projektleiter“ gebucht und soll retten, was zu retten ist.

Nach den üblichen Einarbeitungsschritten stellen wir dann fest:
Nicht das klassische Projektmanagement war das Problem. Denn offensichtlich haben sich viele Projektbeteiligte ja irgendwie zusammengefunden und Dinge begonnen oder schon realisiert, von denen alle der Meinung waren, dass es gut ist, das zu tun.

Nein, es ist das verfluchte alte Leiden der Kommunikation sowie differierender Wahrnehmungen und Erwartungshaltungen. Das kannten bestimmt schon die alten Römer.

Es sitzen also zahlreiche erwachsene Personen in Meetingräumen, Video- und Telefonkonferenzen und schaffen es nicht, zu definieren, was denn eigentlich Phase ist, in diesem Projekt. Der eine sagt grün, der andere versteht rot, beide nicken zustimmend, der Designer designt terrakotta-orange, der Entwickler leitet mangels sauberem Briefings ein eher fäkales Braun ab und am Ende schreit man sich an.

Es ist also nicht das Problem, dass man sich zum Arbeiten zusammenfindet und vielleicht sogar eine einigermaßen schlauen Arbeitsprozess gefunden hat, sondern die Anforderungen sind einfach komplett unklar. Oder schwammig. Oder nicht fachlich durchdacht. Oder nicht logisch durchdacht. Oder mit der Direktoren-Ebene nicht abgeglichen. Oder alles zusammen.

Ein Projektmanager bringt also nichts, wenn sich die restlichen Projektmitglieder nicht „belastbar“ verstehen und der PM diese Missverständnisse nicht ausräumen bzw. nicht einmal identifizieren kann oder nicht klar ist, wer eigentlich das Sagen hat.

Entweder braucht man dann einen Business Analysten oder Requirements-Engineer oder beides oder am besten einen business-analysierenden, Anforderungsmanager mit Projektsteuerungsambitionen.

Zugegeben: Diese gibt es nicht wie Sand am Meer. Nicht einmal in der Sandmenge der Sandkiste meines Sohnes. Selbst die Skills einzeln zu finden, gleicht oft schon einer Suche nach der Büroklammer im Papiermülleimer.

Was bleibt? Wenn du niemanden hast oder einkaufen kannst, der dafür sorgt, dass soetwas nicht passiert, dann gibt es eigentlich nur die folgenden Möglichkeiten:

1. Lass die Finger von solchen Projekten…
2. … oder hör auf zu heulen und nimm diesen Riesen-Stress mit allen Auswirkungen hin.
3. … oder staffe dein Projekt richtig.

Rollen

Das Thema Projekt-Rollen oder erforderliche Skill-Sets gehe ich in einem separaten Beitrag noch einmal an. Die Erkenntnis für den Moment:
Es zeigt sich noch zu häufig, dass viele Entscheider gar nicht dafür sensibilisiert sind, welche Rollen bzw. Skill-Sets mit welchem Qualifizierungsgrad an welcher Stelle und zu welchem Zeitpunkt erforderlich sind.

Erst seit 2021 habe ich merkbar das Gefühl, dass zunehmend solche Skill-Sets gesucht werden. Seit Anfang 2021 erhalte ich nicht nur erstmalig sondern auch gleich so dermaßen viele Anfragen über XING und LinkedIn, in denen Anforderungsmanager oder Product Owner gesucht werden, so dass ich nicht mal mehr die Zeit finde, allen absagen zu können.

Vielleicht ist man da auf einem guten Weg.

Natürlich ist das Problem nicht neu. Auch vor 25 Jahren gab es das schon. Da standen und fielen Projekte jedoch damit, ob man einen „guten“ oder einen „schlechten“ Projektmanager hatte. Alles schön subsumiert unter Projektmanagement. Oder Kundenberatung.

Oder: Wie man Missverständnisse bei Anforderungen vermeiden muss.

Wir lernen von Kindesbeinen an, wie wir uns im Optimalfall in der Gesellschaft zu bewegen haben. Dazu zählen auch zahlreiche akzeptierte Kommunikationsmuster: Wie sprechen wir jemanden an, den wir nicht kennen, wie sprechen wir als Kind einen Erwachsenen an, wie verhalten wir uns kommunikativ im Berufsleben.

Zugegeben, insbesondere unter Freunden oder schlimmer noch, unter alten (männlichen) Buddies, sind die unterirdischsten Schimpfworte als guter Opener einer gesellschaftlich akzeptierten Begrüßung etabliert. Dabei sind Einleitung wie „na, alte Ratte“ noch in der Kategorie „Charmant“ einzustufen.

Ansonsten gilt aber unangetastet ein höfliches Raster: Sehr geehrte Frau…, sehr geehrter Herr …, guten Tag, bitte, danke, das wäre sehr nett, würden Sie freundlicher Weise, ich hätte sehr gern das und das, auf Wiedersehen, tschö mit ö, usw.

Es gibt einen Bereich, in dem man diese verinnerlichten und rückenmarksgesteuerten Floskeln sowie andere, gelernte Kommunikationsraster (bspw. publizistischer Natur), tunlichst unterlassen sollte: IT-Projekte. Genauer gesagt, in einem Teilbereich, dem Requirements-Engineering bzw. Anforderungsmanagement.

Holen wir einmal kurz aus:

Im Requirements-Engineering geht es darum, sämtliche Anforderungen einer (oft großen) Gruppe von Stakeholdern (Personen, die eine Anforderung an ein Produkt haben), zu analysieren und so zusammenzutragen, dass diese von spezialisierten Kräften (software-)technisch umgesetzt werden können.
Ein weit verbreitetes Problem sind dabei die nicht durchdachten und schwammig formulierten Anforderungen. Während ich mich zum Thema „nicht durchdachte und schwammige Anforderungen“ an anderer Stelle äußern werde, gehen wir in dieser Abhandlung fiktiv davon aus, dass die Anforderungen grundsätzlich inhaltlich und fachlich durchdacht sind. Bleibt also „nur noch“ die Formulierung der Anforderungen.

Dabei sind zwei Primäraspekte zu berücksichtigen:

1. Wie formuliere ich so, dass eindeutig klar wird, was gemeint ist?

2. Wie schaffe ich es, alle unnützen Informationen auszufiltern?

Ob und wie sich das mit Mustern der hippen Agil-Welt vereinbaren lässt oder ob sich das sogar beißt, dazu werde ich mich an anderer Stelle später separat auslassen.

Wie formuliere ich so, dass eindeutig klar wird, was gemeint ist?

Das, was gewünscht ist, muss unmissverständlich von jedem lesenden Lebewesen auf diesem Planeten dasselbe und eindeutige Verständnis für das „was“ hervorrufen. Wir sprechen hier also von interpretationsspielraumfreien Texten.

Zugegeben: Das hinzubekommen, ist schwierig bis unmöglich. Es muss also eine bestmögliche Annäherung an „unmissverständlich“ und „interpretationsspielraumfrei“ geben.

Aber grundsätzlich gilt, wenn ein Entwickler etwas Emotionsloses und letztendlich auf Einsen und Nullen (also fließt Strom oder fließt keiner) basiertes Stück Logik in Form einer Software umsetzen muss, dann müssen die Anfroderungen verdammt noch mal eindeutig formuliert sein.

Wenn man seine Anforderungen nicht verständlich zusammentragen kann, passiert das, was keiner will aber zum Tagesgeschäft der meisten Firmen oder Projekte gehört:

„Ach, das haben wir uns aber ganz anders vorgestellt!“

Dieser Satz steht stellvertretend für:

• vergebens aufgewandte Entwickler-Zeit
• verbranntes Budget
• vergeudete Zeit grundsätzlich
• Frustaufbau
• Strapazieren von zwischenmenschlichen Beziehungen

Typische Probleme bei der Aufnahme und Formulierung von Anforderungen sind:

• Kommunikationsprobleme, Sprachbarrieren
• widersprüchliche Sichten auf den Ist-Zustand
• unklare Zielvorstellungen des „was“
• hohe und nicht mehr greifbare Komplexität der zu lösenden Aufgaben
• sich ständig ändernde Ziele u. Anforderungen
  • marktbedingt (Märkte sollen sich angeblich sehr schnell ändern können)
  • oder weil bereits mit unabgestimmten oder unklaren Anforderungen einfach mal losgelegt wurde
• schlechte Qualität der Anforderungsbeschreibung
  • mehrdeutig, redundant, widersprüchlich, ungenau…
  • unnötige Produktmerkmale

Natürlich verstecken sich viele Firmen mittlerweile hinter der Agilität und behaupten, man müsse sich einfach viel mehr unterhalten.

Ja klar, wenn man nicht in der Lage ist, seine Anforderungen klar zu strukturieren und zu formulieren, kann man viel intensiver direkt mit den Entwicklern sprechen und Unklarheiten ggfls. durch viele Einzeltherapien aus dem Weg räumen. Aber dann muss man auch hinnehmen, dass man die wenig verfügbare und kostbare Entwicklerressourcen-Zeit zu einem Großteil verbrät anstatt sie entwickeln zu lassen.

Wir müssen darüber hinaus noch zwischen fachlichen und funktionalen Anforderungen unterscheiden und konzentrieren uns in diesem Fall auf ersteres.

Ein paar kleine Beispiele:

„Das Produkt soll das Wetter der nächsten 24 Stunden anzeigen!“

Hierbei ist bspw. unklar, ob das aktuelle Wetter der nächsten 24 Stunden angezeigt werden soll oder ob das für die nächsten 24 Stunden vorhergesagte Wetter angezeigt werden soll.

„Der Zustand der Patienten wird automatisch untersucht und aufgezeichnet!“

In diesem Fall könnte gemeint sein, dass sowohl automatisch aufgezeichnet als auch automatisch untersucht wird, oder dass nur automatisch untersucht wird und manuell aufgezeichnet.

„Wenn der Nutzer den Papierstreifen einsetzt, wird das Tamagotchi auf die Standard-Werte zurückgesetzt!“

Die Anforderung beschreibt ein technisches Gerät, bei welchem mit einem virtuellen Charakter gespielt werden kann. Sowohl der virtuelle Charakter als auch das Gerät selbst heißen „Tamagotchi“, so dass nicht eindeutig ist, ob das Gerät oder lediglich der Charakter auf die Standardwerte zurückgesetzt werden soll.

„Wenn der Nutzer den L-Button drückt, wird der Alarm ausgeschaltet!“

Unklar ist, ob ein ggfls. aktivierte Alarm ausgeschaltet wird oder die grundsätzliche Fähigkeit des Systems, Alarme auszulösen.

Oder zum Abschluss ein Klassiker

 „Schatz, wir haben kein Brot mehr, könntest du bitte zum Supermarkt gehen und eins holen? Und wenn sie Eier haben, bring 6 Stück mit.“

Was wird passieren? Er bringt 6 Stück Brot mit und keinerlei Eier. Und hat aus logischer Sicht alles richtig gemacht.

Das sind nur einige sehr einfache Beispiele. Die mögliche Menge der Unklarheiten und Fehlinterpretationen ist grenzenlos groß.

Wie schaffe ich es, alle unnützen Informationen auszufiltern?

Kommen wir nun zur Unhöflichkeit und betrachten dazu folgendes Beispiel:

„Es wäre schön, wenn die Software hier eine Meldung ausgeben könnte, wenn mit nicht zu großem Aufwand machbar. Wenn zu viel Aufwand, dann könnte man das auch weglassen.“

Kling total nett. Netter Kollege. Mit dem will man auch gern mal ein Bier trinken oder was Leckereres. Das hilft nur im Projekt niemandem weiter. Hier haben wir eine Anforderung, die aus unklaren und sinnlosen Anforderungen besteht. Nehmen wir zuerst die Höflichkeitsmuster aus der Anforderung, dann bleibt:

„Die Software gibt hier eine Meldung aus, wenn Aufwand nicht zu groß, ansonsten könnte man das weglassen.“

Die Entscheidung, ob etwas umgesetzt wird oder nicht, ist im Normalfall nicht Bestandteil einer Anforderung sondern gehört in eine separate Bewertungs- und Priorisierungs-Skala.

Übrig bleibt:

„Die Software gibt hier eine Meldung aus.“

Durch das Weglassen von Floskeln sehen wir die folgenden Effekte:

• Die Anforderung wird präziser
• Es muss weniger geschrieben werden (weniger Zeit)
• Es muss weniger Sinnloses interpretiert und rausgefiltert werden. Das spart noch mal Zeit und wir nähern uns einer Unmissverständlichkeit.

Und jetzt alles zusammen

Wenn wir jetzt noch die Erkenntnisse aus dem vorherigen Abschnitt einfließen lassen, haben wir nach Wegfiltern der sinnlosen Floskeln noch diverse Unklarheiten zu beseitigen bzw. verständlich zu machen:

• Die Software → Welche Software genau?
• hier → Wo ist hier „hier“? Wenn jemand in der anderen Seite des Raumes sitzt, wird das vielleicht als „da“ interpretiert? Das haben wir schon in der Sesamstraße gelernt: https://www.youtube.com/watch?v=Z-MRqTJMapY
• hier → „hier“ ist in diesem Fall vielleicht nicht nur eine Frage nach dem „wo“ sondern auch nach dem „wann“?
• eine Meldung → Was für eine Meldung? Was sagt die Meldung aus? Wie sieht sie optisch aus? Wie verhält sie sich?

Würden wir nun noch die Bedingungen für eine Bewertungs- und Priorisierungs-Skala hinterfragen und einfließen lassen, auch wenn wir sie eigentlich losgelöst von der eigentlichen Anforderung betrachten wollen, dann:

• großer Aufwand → Ab wann ist ein Aufwand zu groß? Ist die Umsetzungsdauer gemeint oder der Ressourcen-Aufwand? Und wenn ja, wie viel davon?
• Könnte → Wenn Aufwand zu groß, was dann? Was bedeutet könnte? Gar nichts machen oder eine einfachere Lösung umsetzen oder erst Rücksprache oder machen wir das vom Wetter abhängig?

Aus

„Die Software gibt hier eine Meldung aus.“

könnte man bspw. folgendes machen:

„Der Content Editor zeigt beim Speichern eines Artikels eine Meldung ‚Artikel erfolgreich gespeichert‘. Das Fenster ist ein Standard-Alert-Fenster mit weißer Schrift auf rotem Hintergrund. Das Fenster schließt sich nach vier Sekunden selbständig oder das Fenster schließt sich sofort bei beliebigem Mausklick. Umsetzung nur, wenn Aufwand <= 2 Personentage und Umsetzungsdauer <= eine Woche.“

Bzw. gliedern wir die Entscheidung, ob etwas getan werden soll in unsere Bewertungs- und Priorisierungs-Skala aus und setzen das Ganze noch etwas mehr als Stichpunktliste, um die Umsetzung später deutlich besser abnehmen zu können (Akzeptanzkriterien, Testszenarien), dann:

1. Der Content Editor zeigt beim Speichern eines Artikels eine Meldung ‚Artikel erfolgreich gespeichert‘.
2. Das Fenster ist ein Standard-Alert-Fenster mit weißer Schrift auf rotem Hintergrund.
3. Das Fenster schließt sich nach vier Sekunden selbständig.
4. Das Fenster schließt auch bei beliebigem Mausklick.

Was haben wir alles gemacht?

• Nicht hilfreiche Floskeln entfernt.
• Unpräzise Anforderungen eindeutig gemacht
  • gestückelte, kleine Sätze
  • schwammige oder unklare Anforderungen wurden ausformuliert
• Listen bringen Verständlichkeit, bessere Testbarkeit und bessere Abnahme-Möglichkeit
• Nummerierungen (bzw. eindeutige und globale IDs) bringen Transparenz in Abhängigkeiten und Zusammenhänge.
  Man kann mit IDs eindeutig Anforderungen verknüpfen und auch viel transparenter drüber sprechen.

Wer muss das alles tun?

In etablierten Projektstrukturen gibt es eine Kompetenz-Ebene mit der Bezeichnung „Requirements-Engineering“ oder bei Abneigung gegen Anglizismen heißt es dann Anforderungsmanagement. Gibt es diese nicht, turnt meist eine übergreifend anayltisch und konzeptionell qualifizierte Projektmangement-Instanz durchs Projekt. Die machen das, was da oben steht. Teilweise in stunden-/tagelangen Workshops mit den Stakeholdern, indem alles hinterfragt und finalisiert ausformuliert wird.

Bei vielen mir bekannten Firmen ist das ein wenig anders. Es gibt nahezu keine gewerkeübergreifende Analyse- und Konzeptionskompetenz und auch keine für diese Tätigkeit abgestellte Personenmenge. Und das schon gar nicht auf Detailebene. Dazu kommt eine Vielzahl an Anforderungsstellern, die auf verschiedenste Zielsysteme schießen. Bei der Menge an Personen und Anforderungen können die Anforderungen nicht von einer Person aufgenommen, analysiert und konzeptionell finalisiert werden. Das ist von der schieren Menge her nicht machbar. So müssen Anforderungen bereits von den Stakeholdern oder eine spezialisierten Gruppe an Stakeholdern zumindest annähernd in der o.a. Qualität formuliert werden.

Das bedeutet?

Hört auf zu schwafeln und bitte, danke, hätte, könnte in Anforderungen prosaisch zu verpacken. Bringt es auf den Punkt. Sagt, was gefordert ist.