Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Gerade, wenn Sie im Produktmanagement einer großen Firma arbeiten, kennen Sie Statusreports sicherlich zur Genüge. Manche Manager lieben sie so sehr, daß sie ihre Teams jede Woche mit solchen Reports beschäftigen. Typischerweise werden die Einzelreports der Teams dann über mehrere Hierarchiestufen konsolidiert, und dienen ganz am Ende zur Information des Senior Managements.
Eigentlich kenne ich niemanden, der diese Reports gerne erstellt, und ich sehe auch immer wieder Manager, die den Anschein geben, als hätten sie die Reports überhaupt nicht gelesen. Viel gravierender ist aber noch: Statusreports leiden regelmäßig am „Stille-Post-Syndrom„, d.h. eine negative Statusaussage wird umso positiver, je höher sie in der Hierarchie klettert. Am Ende bekommt das Senior Management eine ganz andere Nachricht vermittelt, als die Nachricht, die ein einzelnes Team formuliert hat.
Die Frage ist: Brauchen wir Statusreports, und wenn ja, wie können wir diese Statusupdates möglichst einfach erstellen, und was sollte in diesen Reports stehen?
Eigentlich möchte das Management mittels Statusbericht erfahren in welchen Bereichen die Entwicklung zielgerichtet vorankommt, und wo es gerade hakt. Getreu der Regel „Management by Exception“ stellt man sich vor, daß man an solchen Stellen leitend eingreifen kann, so man denn den Statusbericht hat.
Ich will nur auf zwei Gründe eingehen, die zeigen, daß Statusreports diesem Anspruch nicht gerecht werden.
In einer großen Firma muß man für einen Statusbericht aber bereits so viele Informationen verarbeiten, daß es naheliegt, daß diese Berichte am Ende nur sehr grobe Angaben enthalten kann. Nun sind die meisten Themen zudem inhaltlich nicht so einfach aufgebaut, als dass es gelingen würde, sämtliche Randinformation darin zu verpacken, die notwendig wäre, um den Status zu verstehen. Auch hängen die Statusinformationen stark vom Manager ab: Der eine liebt Zahlen, der nächste will nur „Probleme“ sehen, etc. Daher ist es weder einfach, den Statusupdate pointiert darzustellen, als auch sich darauf einzustellen, welche Information nun darin erscheinen soll.
Viele Mitarbeiter geben sich trotzdem sehr viel Mühe mit dem Verfassen des Berichts, um darin auf jede Eventualität vorbereitet zu sein. Meiner Erfahrung nach gibt es aber auch Mitarbeiter, die sehr wohl wissen, daß sie die Frage nach den Inhalten trotz Statusreport sowieso noch einmal mündlich beantworten müssen.
Normalerweise werden Statusinformationen zu festgelegten Zeitpunkten eingefordert. Zu diesen Berichtszeitpunkten ist jedermann damit beschäftigt, die Statusinformationen zusammenzustellen. Da die Reports an das Management gehen, haben sie eine hohe Priorität. Normalerweise unterbrechen diese Sammelaktivitäten daher sehr effektvoll die produktive Arbeit, an z.B. Kundenanforderungen.
Ein weitere Aspekt betrifft die Arbeitsmenge. Weil Reports sich an das Management richten, ist es zudem nicht mit der einfachen Information getan. Besonders, wenn kritische Sachverhalte dargestellt werden, werden Berichte gerne revidiert, oder sonstwie konsolidiert, nur damit die betreffenden Stellen nicht schlecht dargestellt werden. Neben dem immensen Aufwand, den die Berichte erfordern, sind die Informationen dann auch oft schon veraltet.
Es gibt mehrere Möglichkeiten, Statusreports einzuschränken, oder sogar obsolet zu machen. Vorher sollte man sich aber einen Überblick über den jeweiligen Zweck verschaffen, da leider nicht jede Statusinformation eingespart werden kann.
Manche Reports haben „rechtlichen“ Charakter. Zum Beispiel werden Spezifikationen auf eine besondere Art gespeichert, um die Urheberschaft beweisen zu können, oder es werden Teststati erfaßt, um ggfs den Produkthaftungsgesetzen zu genügen.
Bevor man jegliches Reporting einstellt, sollte man sicherstellen, daß solche Informationen auch danach noch erhoben und gespeichert werden. Rechtlich relevante Statusreports, sind also unbedingt wichtig. Sie sollten aber so einfach und simpel wie möglich sein.
Viele Statusinformationen werden gesammelt, um auf Informationslücken aufmerksam zumachen. Wenn zum Beispiel jede Abteilung die Erledigung eines Items zurückgemeldet hat, nur eine Abteilung noch keine Nachricht gegeben hat, möchte und muß man diese Abweichung finden.
Solche Statuslücken lassen sich sehr gut mit (softwarebasierten) Workflows schliessen, indem zum Beispiel eine geschäftskritische Software eingesetzt wird, die die Abweichungen prüft, und die betreffenden Abteilungen informiert.
Den größten Effekt haben sicher die Methoden. Auf der einen Seite hilft die Ausrichtung der Entwicklung nach agilen Vorgehensmodellen dabei, viele Statusreports überflüssig zu machen. In einer agilen Entwicklungsabteilung werden zum Beispiel sehr viele Entscheidungen auf Teamebene getroffen, die in einer Abteilung, die nach der Wasserfallmethode arbeitet noch auf Managementebene getroffen wird.
Wenn sich Statusanforderungen nicht per Methode obsolet machen lassen, kann man darüber nachdenken, (Software-) werkzeuge einzusetzen, die bestimmte Aspekte der Abwicklung besser unterstützen, und die daneben bessere Daten liefern.
Zum Beispiel können Projektmanagementsysteme dabei helfen, die Erstellung eines Releases zu unterstützen, und den Überblick über den Fortschritt zu behalten. Systeme, die dazu ausgelegt sind, die Bugs- und Kundensupportanfragen zu unterstützen kann man einsetzen, um die gesamte Kundenkorrespondenz der Entwicklung zu managen.
Wenn solche Systeme zudem noch regelmäßig Statusinformationen aufbereiten, sind Sie von einem automatisierten Statusreporting nicht weit entfernt. Wenn Sie zudem Reportingsysteme einsetzen, mit denen sich das Management selbst die erforderlichen Daten zusammensammeln kann, können Sie auch die Daten abhandeln, die sich nicht automatisch verarbeiten lassen.
Das Management will Probleme und Abweichungen in Erfahrung bringen, um darauf reagieren zu können. Trotz aller Automatisierungsbestrebungen handelt es sich hierbei also um wichtige Informationen. Viele konventionelle Reports sind aber nur eine alternative Audrucksform einer Problembeschreibung, und einer Abweichungsanalyse.
Um Probleme und Abweichungen sinnvoll, und ohne Reportingoverhead bearbeiten zu können, sollten sie sich einen einfachen Prozess installieren, über den Sie an die Problembeschreibungen herankommen, und mit dem Sie die Problembearbeitung managen können. Um zu vermeiden, daß die formulierten Probleme zu unspezifisch werden, sollten Sie die Formulierung von Incidents wenigen Mitarbeitern überlassen, die hierfür ggfs extra geschult sind.
Gute Managementsysteme entlasten Ihre Produktmanager, und Entwickler von unnötigen Reportingfunktionen. Guten Systemen sind die folgenden Eigenschaften gemein:
Wer je einmal den üblichen manuellen Statusreport geschrieben hat, weiß wahrscheinlich was damit gemeint ist.
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
