Hier kommt der zweite Teil meiner "Menschen hinter den Produkten" Serie. Da Buck ein ziemlich langes Interview gegeben hat teile ich das in zwei Teile.
In diesem ersten Teil spricht Buck über die verschiedenen Program Manager Rollen bei Microsoft und wie Kunden am besten Feedback zum Produkt geben können. Im zweiten Teil geht es dann um die verschiedenen Seiten von SQL Server Management, um Powershell, um ein verstecktes Highlight in Management Studio und darum, wie Buck zu Micrsoft gekommen ist.
Have Fun,
Steffen
Und sorry für das Gegenlicht im Bild.
Buck Woody
Hallo Buck, wenn ich Dich richtig verstehe hast Du eine neue Position namens „Community PM“, PM steht für Program Manager. Was machst Du eigentlich? Was ist ein Community PM?
Es gibt drei Arten von PMs, zu mindestens in der SQL Server Organisation hier bei Microsoft
Die erste Art von PM, das, was ich vorher gemacht habe, ist ein Feature PM. Ein Feature PM ist verantwortlich für ein bestimmtes Feature in einem Produkt, in meinem Fall SQL Server Management Studio. Ihm „gehört“ das gesamte Feature, das heißt, der PM schreibt die Spezifikation dafür, rechtfertigt, dass daran gearbeitet wird. Wir bekommen ein paar Entwickler, ein paar Tester und einen Dokumentierer, wir arbeiten auch mit Marketing zusammen – und mit der Rechtsabteilung. Und dann betreuen wir das Feature von der Wiege bis zur Bahre. Wir sprechen darüber. Wir verwalten das Projekt, es ist also auch etwas Projektmanagement dabei, aber die Rolle heißt Program Manager, das heißt Arbeit mit Entwicklern, Testern und Dokumentation um alles, was mit dem Feature zu tun hat umzusetzen. Bei mir selbst waren es vier solche Features, die Teil von SQL Server 2008 wurden. Ich war da erst seit ein paar Monaten in der SQL Server Gruppe und habe diese Features in das Produkt hineinbekommen. Ich musste mich also ziemlich schnell einarbeiten.
Die zweite Art von Program Manager, die wir haben ist der Release PM, und das sind die Leute, die sich mit dem Prozess beschäftigen, etwas fertigzustellen und in die Hände der Kunden zu übergeben. Die Testautomatisierung, die Zusammenstellung zum Produkt, die automatischen Builds, bei denen jede Nacht das gesamte Produkt kompiliert und erstellt wird, die Berichte an die verschiedenen Manager wo wir stehen, solche Sachen. Das ist eine Rolle, die ich hier bei Microsoft nie innehatte und die ich vielleicht später mal machen könnte.
Den Community PM gibt es nicht in jeder Produktgruppe bei Microsoft. Die Gruppen sind viel kleiner als Du Dir das vielleicht vorstellst. Im Produktentwicklungszyklus arbeiten die Gruppen immer nur an einem Teil einer ganz bestimmten Sache. Viele Leute glauben, dass es ein Riesenteam gibt das alles in SQL Server programmiert. In Wirklichkeit sind das aber viele kleinere Teams. Diese Teams interagieren häufig nicht direkt mit den Kunden, weil sie sich in einer größeren Organisation befinden, die Leute wie Evangelists und ähnliches haben. Wenn eine Gruppe eine bestimmte Größe erreicht oder eine besondere Strategie hat dann fangen sie an, mit verschiedenen Gruppen von Kunden zu interagieren. Eine dieser Gruppen sind die Kunden im TAP Program, dem Technical Adoption Program. Das sind meist große Kunden die einwilligen, unsere Betasoftware, die CTPs, im Produktiveinsatz zu verwenden und uns Feedback zu geben. Von unserer Seite versprechen wir, diesen Kunden dabei zu helfen und ihnen bei Problemen schnell mit Fixes und ähnlichem zu helfen. Das sind die einzigen Kunden, für die Produktivbetrieb mit CTPs voll supportet ist und die auch von einer CTP-Version auf die finale Version upgraden können. Mit diesen Kunden zu arbeiten ist eine meiner Aufgaben. Ich arbeite auch mit den Most Valued Professionals (MVPs) und anderen Gruppen, die wir SQL Professionals nennen, wie SQL Insiders, SQL Rangers. Einige davon sind kommerziell, andere sind Freiwillige. Wir arbeiten mit PASS und ähnlichen User Groups. Ich arbeite mit diesen Communities um ihnen beim Verständnis von tieferen, Level 400, technischen Themen zu helfen, damit sie wiederum ihren Communities helfen können. Die dritte Gruppe ist die Allgemeinheit. Menschen, die unser Produkt jeden Tag verwenden. Im Falle eines DBAs oder eines Entwicklers ist das ein wenig anders, denn das sind nicht wirklich Endbenutzer wie ein Office Benutzer. Viele dieser Leute erstellen selbst Software. Wir müssen diesen Kunden also helfen, ihre eigene Software besser zu machen. Ich arbeite mit denen mit Hilfe von Blogs (http://blogs.msdn.com/buckwoody/), Präsentationen, Whitepaper, solche Sachen.
Was ich in der Realität in dieser Gruppe tun soll ist, die Möglichkeit zu schaffen, dass unsere gesamte Gruppe, nicht nur ich, zur Community spricht und dass die Community mit uns reden und Feedback geben kann. Im Endeffekt halte ich viele Briefings und Präsentationen, aber ich helfe auch anderen dabei, das zu tun. Das ist meine Rolle. Sie ist neu in dieser Gruppe, und nicht jede Gruppe hat diese Rolle. Aber Manageability, die Möglichkeit, SQL Server zu verwalten ist ein Verkaufsargument geworden. Mit anderen Worten: Jede Datenbank hat viele Features. Oracle hat viele Features, IBM, und Sybase haben viele Features, wir haben viele Feature. Wir sind also alle im Wettbewerb im selben Bereich. Wo wir Mehrwert schaffen ist die Kombination aus all diesen vielen Features und der Möglichkeit, sie einfach zu verwalten. Und wir haben schon immer den Anspruch, einfacher verwaltbar zu sein. Manche verstehen das so, dass SQL Server simpler ist. Das ist nicht so, wir verbergen die Komplexität nur, indem wir bessere Management-Tools anbieten. Meine Rolle ist es, das zu den Kunden zu kommunizieren.
Du hast viel darüber gesprochen, wie Du die Kommunikation von der Produktgruppe zu den Kunden unterstützt. Aber wenn jetzt ein Kunde sagt „Ich wünschte, die SQL Server Managementtools würden dies oder jenes tun“, was soll so ein Kunde tun? Dir eine E-Mail schreiben?
Das ist eine exzellente Frage. Wir haben zwei Hauptwege um das zu tun. Der eine ist untergeordnete, der andere ist der beste Weg das zu tun. Der erste Weg ist, dass wir auf Konferenzen und Veranstaltungen sind. Viele Mitarbeiter in unserer Gruppe halten Präsentationen. Viele kennen vielleicht Richard Waymire oder Dan Jones und einige andere Kollegen einschließlich mir. In diesen Präsentationen fragen wir immer nach Feedback und Ideen zu dem, was wir präsentieren und insgesamt zur Administration von SQL Server. Und die Kunden kommen auch zu uns und sprechen uns an, um über Bugs oder Wünsche zu sprechen. Das machen wir gern. Aber was wir insbesondere hören wollen ist: Was würde deinen Tag besser machen? Wir haben viele Quellen für solche Ideen. Uns selbst, Wettbewerber, Kunden und so weiter. Aber wie kommen diese Ideen zu uns? Es gibt eine Site namens Connect (http://connect.microsoft.com). Auf dieser Site (gemeint: Im SQL Server Bereich: https://connect.microsoft.com/sqlserver) kann man nach der Idee suchen.
Wenn es die Idee im Feedback schon gibt dann bitten wir die Kunden, das zu validieren und zu bewerten. Validierung bedeutet: Ja, das finde ich auch. Bewerten bedeutet: So wichtig ist mir das. Wenn die Suche ergibt, dass es die Idee noch nicht gibt, dann kann man einen neuen Eintrag erstellen. Da wird auch nach dem Bereich des Produkts für den Vorschlag gefragt. Das sorgt dafür, dass dieser Connect-Eintrag direkt an das Team geht, zu dessen Bereich es gehört und es auf die Bugliste des Teams kommt. Und das bedeutet, dass sich jemand im Team darum kümmern muss.
Lass mich das noch mal klarstellen: Auch wenn es ein Vorschlag und kein Fehler in SQL Server ist geht das in unser Bug Tracking System?
Das ist korrekt. Wir haben verschiedene Klassifizierungen in unserem System. Es ist kein reines Bug Tracking System, es ist ein Issue Tracking System. Alles basiert auf Visual Studio Team System. Dort erscheinen die Einträge dann entweder als „Defect“, also etwas, was wir haben hat einen Fehler und funktioniert nicht so, wie wir das wollten Es kann ein „Enhancement Request“ sein, das bedeutet: Etwas, was wir haben funktioniert so wie wir es wollen, aber der Kunde meint, es sollte mehr tun. Und eine weitere Kategorie nennt sich „DCR“ (Design Change Request) und das bedeutet: „Das gibt es gar nicht, und ich möchte es haben“. All das wird wie gesagt bewertet. Je mehr Kunden das wichtig finden umso höhere Priorität hat es für uns. Daraus wird dann nach verschiedenen Kriterien ein Ranking erstellt und es kommt in eine Liste namens GRIL, Grand Improvement List. Und das sagt uns dann, woran wir in der nächsten Version arbeiten werden. Da gibt es einige Bug Fixes, einige Enhancements und einige neue Features. Eine Rückmeldung über Connect ist also der beste Weg, Wünsche an uns zu senden.
--- Ende Teil 1 ---
