Die Messung des Umfangs eines Releases

Danke für das Feedback das wir von ihnen bekommen haben. Wir freuen uns natürlich darüber, dass ein Großteil davon positiv ist. Ich habe versucht die Emails so gut wie möglich zu beantworten. Zusammen mit Mitarbeitern aus den Arbeitsgruppen haben wir eine Diskussion in den Kommentaren zu dem Blog geführt. Jeder der Teilnehmer hat gute Arbeit geleistet Perspektiven über Gewünschtes und Anforderungen darzustellen. Ich finde es toll diese Emails zu bekommen und die Kommentare zu lesen. Es ist einfach fantastisch. Ich wollte nur sicherstellen dass sich jeder bewusst ist dass ich nicht jedes Email beantworten kann! Wir werden die Kommentare und Emails als Anregung nehmen welche Artikel wir schreiben sollen. Das Team freut sich über die positive Reaktion von allen die uns hier begleiten. Wir wissen dass wir energiegeladene Diskussionen vor uns haben und wir freuen uns darüber dass wir nun damit beginnen können.

Mit diesem Artikel hoffe ich den Dialog über die Art und Weise, wie wir innerhalb des „Win7 Teams“ denken, fortzusetzen – in einem gewissen Maße das Team auf diese Art zu erweitern und ihnen die Möglichkeit zu geben mehr an der Diskussion teilzunehmen wie wir ein Release planen. Diese Konversation über große und kleine Releases ähnelt sehr der Diskussion die ich mit meinem Chef führe wenn wir mit der Planung beginnen :-)

Man könnte meinen dass - wenn wir mit der Planung des Releases beginnen – die erste Frage ist, ob der Windows 7 Client ein „großes Release“ sein sollte oder nicht. Die Anführungszeichen rühren daher dass man das nicht wirklich entscheidet und dass es dafür auch nicht wirklich eine einzige Antwort gibt. Die Größe des Releases ist gleichwohl abhängig von der Perspektive über die Leistungsmerkmale als es von den Leistungsmerkmalen selbst. Man könnte gar fragen ob es ein Kompliment ist als „großes Release“ bezeichnet zu werden. Als Ingenieure legen wir am Anfang des Produktplanungsprozesses fest welcher Prozentsatz der Entwickler an dem Release arbeiten werden und über welchen Zeithorizont sich die Entwicklung bewegen soll. Dies führt dazu, dass sich Kunden selbst eine Meinung darüber bilden ob es ein „großes“ Release ist oder nicht – aber natürlich haben wir uns auch eine Meinung darüber gebildet. Auf dem Server Blog sprachen wir über den Zeitplan und legten auch unsere Meinung offen über das Ausmaß der Releases von Windows 7 Client und Server.

Unser Ziel ist es ein großartiges Release von Windows 7!

Über alle Kunden hinweg existiert immer die Perspektive, dass sich ein „großes“ Release dadurch auszeichnet dass alle Leistungsmerkmale für eben diese Kunden von Nutzen sind. Ein kleines Release zeichnet sich dadurch aus dass es „nichts für mich“ hat. Dadurch sollte es ziemlich einfach sein ein großes Release zu planen – man muss nur sicherstellen dass man die exakt richtigen Leistungsmerkmale für jeden Kunden hat (und da Leistung so wichtig ist soll es auch keine Funktionen darüber hinaus haben, selbst wenn andere Leute sie gerne hätten)! Als Ingenieure wissen wir dass ein solcher Design-Prozess unmöglich ist – gerade weil es die Norm ist dass zwei unterschiedliche Kunden exakt das Gegenteil verlangen. Gerade als ich diese Zeilen schreibe erhielt ich zwei Emails nacheinander wo jemand schreibt dass „niemand diesen Touch Screen Nonsens braucht“ und jemand anderer meint dass „(Win7) mehr ausgefeilte und robuste Touch-Fähigkeiten benötigt“.

Wenn man nur unverlangtes und unstrukturiertes Feedback bekommt sieht man diese Gegensätze ganz besonders. Ich bin mir sicher dass die Leser dies auch an den Blog-Kommentaren bemerken.

Lassen sie mich das Spektrum an möglichen Release-Umfängen anhand einiger Kundentypen erläutern: Endbenutzer, Entwickler, Partner, IT-Experten und „Beeinflusser“.

Endbenutzer sind meist sehr pragmatisch bei ihrer Entscheidung über den Umfang eines Releases. Für den Endbenutzer ist es meist ein großer Schritt wenn sie den Wunsch verspüren den Computer für ein neues Release aufzurüsten oder sich einen neuen Rechner zuzulegen. Wir könnten dies ein „großes“ Release bezeichnen. Ziemlich einfach - ein „großes“ Release ist gut für jeden Beteiligten. Auf der anderen Seite kann man sich auch vorstellen, dass ein Release wirklich „cool“ ist und dass es Leute gerne kaufen möchten, die Anforderungen an Speicher oder neue Treiber jedoch hoch sind oder man neue Hardware benötigt um alle Möglichkeiten auszureizen. Unter diesem Aspekt kann ein großes Release ein wenig an Attraktivität verlieren, da es einiges an Aufwand erfordert. Natürlich wissen wir, was Endbenutzer fordern: dass alle ihre Wunsch-Features auf ihrer Wunsch-Hardware funktionieren – denn dann ist es ein tolles Produkt das man haben muss (ob es ein großes Release ist oder nicht).

Entwickler sehen ein Release unter einem anderem Blickwinkel. Natürlich ist es für Entwickler ein großes Release wenn neue Programmierschnittstellen (APIs) und Funktionen zur Verfügung stehen, die in ihrer Software Anwendung finden – wiederum ziemlich einfach. Es könnte auch der Fall sein, dass ein vorheriges Release viele neue APIs anbot und dass Entwickler sich gerade erst damit vertraut machen. Dann wollen Entwickler nur eine Vervollständigung dieser APIs und vielleicht Geschwindigkeitsverbesserungen. So könnte man meinen dass ein erstes Release ein „großes“ und ein nachfolgendes zweites Release ein „kleines“ ist. Wenn man aber die Geschichte von Softwareprodukten betrachtet, sieht man, dass diese „kleinen“ sich sehr oft zu großen Releases entwickeln – Windows 3.1, Office 4.2, selbst Windows XP SP2. In jedem dieser Fälle wandten sich die Entwickler diesen „kleinen“ Releases zu, aber aus dem Blickwinkel des Marktes waren dies „große“. Der Grund warum Entwickler diese neuen APIs nutzen wollen ist, dass sie ihre Produkte von anderen unterscheidbar machen wollen oder dass sie ihr Spezialwissen einsetzen wollen – und nicht weil sie diese APIs „einfach so“ verwenden wollen. In diesem Sinne kann ein Release für einen ISV ein großes sein wenn es dazu führt, dass genug Ressourcen zur Verfügung stehen um auf neue APIs zu setzen weil sie sich auf Dinge konzentrieren können die für sie wichtig sind.

Partner repräsentieren ein breites Spektrum an Leuten die PCs bauen, Hardware entwerfen und die Infrastruktur schaffen, die wir als das Ökosystem sehen an dem Windows teilnimmt. Partner sehen ein Release als „groß“, wenn es neue Möglichkeiten schafft und deshalb meist mit viel Veränderung verbunden ist und das Feld öffnet neue Hardware und Infrastruktur an Kunden auszuliefern. Auf der anderen Seite werden Inkompatibilitäten meist unter einem negativen Blickwinkel gesehen, da Partner bereits Geliefertes ändern müssen um es mit dem neuen Release kompatibel zu machen und sich nicht mit neuen Projekten auseinander setzen können. Wenn sich Partner – aus einer Vielzahl an Gründen – dafür entscheiden, diese Arbeit nicht zu tun, kann das Release aus einem Mangel an Unterstützung des Ökosystems als „kleines“ wahrgenommen werden. So kann eine große Veränderung wiederum unter dem Aspekt eines „kleinen“ und eines „großen“ Releases betrachtet werden.

IT-Experten werden oft als von Natur aus konservativ charakterisiert und nehmen deshalb zu Veränderungen oft eine negative Haltung ein. Da sich ihre Rolle auf betriebswirtschaftliche Aspekte konzentriert wird die Evaluierung von Softwareprodukten immer unter der Linse von Rentabilität betrachtet. Für einen IT-Experten ist ein „großes“ Release eines, das zu signifikanter wirtschaftlicher Wertschöpfung führt. Diese Wertschöpfung kann beispielhaft als eine signifikante Investition im Management der Software verstanden werden. Für Endbenutzer oder Entwickler jedoch könnten die gleichen Leistungsmerkmale uninteressant sein und in keiner Weise als „großes“ oder „kleines“ Release tituliert werden.

Beeinflusser sind jene Personen, deren Geschäft es ist Beratung, Analyse und unterschiedliche Blickwinkel zu unserer Software anzubieten. Diese Personen messen ein Release oft am Umfang der Veränderungen. Große Veränderungen bedeuten ein großes Release. Eine große Veränderung kann z.B. ein Architekturwechsel sein wie z.B. der Wechsel von Windows 9x auf Windows 2000 – obwohl beide Produkte gleich aussahen, gab es viel über Veränderungen unter der Oberfläche zu berichten. Für Analysten war es damit definitiv ein großes Release. Große Veränderungen können auch mit der Benutzeroberfläche verbunden sein, da diese einfach wahrzunehmen sind und damit für viel Diskussion sorgen. „Groß“ für jede dieser Veränderungen kann aber als wenig positiv gewertet werden, da Architekturänderungen potenziell Inkompatibilität bedeuten können. Neue Benutzeroberfläche bedeutet Lernbedarf und Abschied von Bekanntem.

Wir haben viele Kommentare bekommen und ich habe viele Emails erhalten die sich mit der Architekturänderung von Windows als Symbol eines großen Releases befassen. Wir haben auch viel Feedback darüber erhalten, dass ein Release dann groß“ ist wenn es Vergangenes nicht mehr unterstützt. Generalisierend kann man sagen, dass Leute oft annehmen, dass eine Veränderung der Architektur zu verbesserter Geschwindigkeit oder geringerem Speicherverbrauch führt. Solche Vergleiche sind immer schwierig, da sie den Status-Quo mit einer Version vergleichen, in der wir alle bekannten Probleme behoben haben, aber noch nicht wissen welche Probleme wir geschaffen haben oder welche Dinge nicht mehr funktionieren. So anstatt ein großes Release relativ an der Implementierung zu messen macht es glaube ich mehr Sinn, den Erfolg eines Releases relativ am Nutzen der wie auch immer gewählten Implementierung zu bewerten. Wir werden diesen Teil der Diskussion definitiv weiterführen – hier gibt es großen Bedarf an Dialog.

Es ist wichtig die richtige Balance zu finden. Wir können große Veränderungen für alle Kunden durchführen wenn wir die Betroffenen ausreichend vorbereiten. Wir können auch durch kleine Veränderungen große Wirkung erzielen, wenn es die richtigen Veränderungen zur richtigen Zeit sind, und diese werden über längere Zeit als großes Release wahrgenommen.

Wir haben über Timing und die Art und Weise wie wir ein Team strukturieren gesprochen, so werden sie ein Gefühl dafür haben über die „Inputs“ des Projektes. Wenn wir gut genug zugehört und unsere Anstrengungen korrekt fokussiert haben, dann wird jedes Kundensegment Dinge finden die das Release attraktiv machen. Und wenn wir gut über das Produkt kommunizieren, dann können sogar Dinge, die als „Problem“ wahrgenommen werden könnten, in einem breiteren Kontext des Ökosystems – wo jeder kollektiv davon profitiert wenn einige signifikant profitieren – erscheinen.

Aus unserer Perspektive haben wir unser vollständiges Engineering-Team und einen umfangreichen Zeitplan eingesetzt um das Windows 7 Client Betriebssystem in die Realität umzusetzen. Damit ist dies – nach jeder Definition – ein großes Projekt. Wir haben die Absicht dass Windows 7 ein großartiges Release wird.

Ich hoffe, dass ihnen dies geholfen hat zu sehen, dass Perspektive alles ist wenn es für den Kunden jeglichen Typs darauf ankommt zu entscheiden, wie groß ein Release nun wirklich ist.

---Steven

Comments

• Anonymous
  August 26, 2008
  The comment has been removed