Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Wahrscheinlich ist die Entscheidung für jeden Produktowner ein Klassiker: Worauf den Schwerpunkt legen – Features oder Qualität? Oft steckt hinter der Frage jedoch mehr.
Termindruck kommt in der Praxis oft durch Faktoren zustande, die ein einzelner Produktowner nur schwer beeinflussen kann, wie zum Beispiel das Ziel der gesamten Firma, möglichst oft ein komplettes Release abzuliefern, das dann noch möglichst viele neue Funktionen enthalten soll.
Ein kurzes Zitat sollte uns zum Denken anregen. Es zeigt, daß es vielleicht machmal sinnvoller sein könnte, ein Feature zu abzusagen, als die Qualität zu kompromittieren.
Lange war das MS Windows Betriebssystem das Ziel von Hackerangriffen, und ist fast ständig mit irgendeiner Sicherheitslücke in der Presse aufgetaucht. Dies hat dazu geführt, daß zunehmend Kunden verunsichert wurden, und auf andere Produkte umgeschwenkt sind.
Um die jüngsten Releases fehlerfreier zu machen, hat Microsoft den Entwicklungsprozess fundamental verändert. Früher hat man dort nach der Wasserfallmethode entwickelt, und sich regelmäßig viel vorgenommen. Hierbei wird ein großes Release erstellt das dann vor der Auslieferung umfangreich getestet wird.
Heute nutzt man moderne Methoden der Qualitätssicherung, wie zum Beispiel das Test Driven Development, oder das Pair Programming. Diese Methoden sehen auf den ersten Blick teuer aus, sind es aber nicht, wenn man genauer hinschaut.
Beim Test Driven Development erstellt man zuerst einen Test, und dann das produktive Coding, d.h man testet das Coding aus sich heraus. Beim Pair Programming entwickeln zwei Personen zusammen ein Programm, und korrigieren sich gegenseitig.
Diese Methoden machen sich bezahlt, wie folgendes Zitat zeigt, das aus dem Artikel →Google and Oracle overtake Microsoft in security flaws stammt:
Google and Oracle have overtaken Microsoft as the vendors with the most vulnerabilities, according to Trend Micro’s Third Quarter Threat Report.
Dort steht aber noch mehr, nämlich, daß bei Google und Oracle die zwei Klassiker zu solchen Problemen führen, daß sie sicher früher oder später den Verkaufserfolg ihrer Software negativ beeinflussen:
„… the short cycles between product releases, which limit how much bug testing can be done.
acquisition of Sun and its Java products by Oracle in 2009 had caused the latter’s code-base to become large and complicated to maintain, contributing to the rise in exploitable bugs.“
Die Klassiker, die ich meine, sind kurze Releasezyklen, und Probleme, den Code zu warten (und Bugs auszubauen).
Gegen die kurzen Releasezyklen kann man als einzelner Produktowner wenig tun, außer vielleicht, daß man aufpasst, sich nicht zuviel Featurewünsche vorzunehmen, und, daß man darauf achtet, diese Features ausreichend zu testen.
Um Coding wartbar zu machen helfen einem allerdings die oben erwähnten Methoden, und ganz besonders eine Methode mit Namen „Clean Code“. Hierbei arbeitet man regelmäßig an der Verbesserung des Codings, um dessen Wartbarkeit zu verbessern. Da hierbei keine Funktionalität entsteht, sollte man allerdings aufpassen, daß man die Aufwände sorgsam plant.
Hier finden Sie weiterführende Informationen zum heutigen Thema im Internet:
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
