Was tut ein Programmmanager?

Die geheime Zutat für wirklich gute Software ist ein guter Programmmanager. Und wahrscheinlich habt ihr in eurem Team keinen von der Sorte, weil: die allerwenigsten haben einen.

Um mehr zu erfahren, lies William Poundstones "How Would You Move Mount Fuji?"

Jabe Blumenthal, ein Programmierer im Mac-Excel-Team Ende der 80er, hat diese Bezeichnung für eine andere Aufgabe wiederverwertet. Er hatte bemerkt, dass Softwareentwicklung so kompliziert geworden war, dass die Programmierer keine Zeit dafür fanden herauszufinden, wie sie ihre Software bedienbar und nützlich machen konnten. Das Marketing schimpfte wie Rumpelstielzchen, sie hätten Kundenwünsche weiterzugeben, aber keiner war da, der ihnen zuhörte oder ihr Betriebswirtsprech in Funktionsbeschreibungen hätte übersetzen können. Vieles im Zusammenhang mit dem Produktgestaltung war arbeitsintensiv: mit Anwendern reden, Bedienbarkeit testen, Konkurrenzprodukte beurteilen, und sich den Kopf zerbrechen, was man einfacher machen könnte. Die meisten Programmierer hatten einfach keine Zeit dafür (und konnten sowas auch nicht besonders gut). Blumenthal nahm die Position des "Programmmanagers", und erfand den Beruf neu.

Was tut ein Programmmanager?

Ab sofort würde ein Programmmanager folgendes tun:

1. Oberflächen gestalten
2. Fachkonzepte schreiben
3. Teams koordinieren
4. Anwalt der Kunden spielen, und
5. Bermuda-Shorts tragen.

Für kleine Softwareprodukte genügt wohl ein Programmmanager, für größere wird man mehr als einen brauchen. Jeder ist dann verantwortlich für eine Untermenge der Funktionalität. Je ein Programmmanager für vier Programmierer ist eine gute Faustregel, und falls es schwerfallen sollte, die Arbeit aufzuteilen, so habe ich folgendes von Mike Conte gelernt: Bestimme die Funktionalität anhand der Benutzeraktionen. Twitter könnte man beispielsweise in die folgenden vier Benutzeraktionen aufteilen:

1. Anmelden und starten
2. Mitteilungen schreiben und lesen
3. Einstellungen verändern
4. Suchen

Programmmanager war ich zum ersten Mal bei Microsoft im Excel-Projekt, und zwar für die Benutzeraktionen, die wir "Kundenanpassung" nannten, das war das Arbeiten mit Skripten und Makros. Zunächst hatte ich herauszufinden, was die Kunden brauchten. Das tat ich, indem ich mit so vielen Kunden wie möglich sprach, bis es langweilig wurde, weil ich immer wieder dasgleiche zu hören bekam. Ich verwandte viel Zeit darauf im Gespräch mit Entwicklern herauszufinden, was sinnvollerweise in 18 Monaten realisiert werden kann. Dann redete ich lange an das Visual-Basic-Team hin, ob sie uns nicht einen Compiler, einen Text- und einen Dialogeditor liefern könnten, die für die Excel-Makrosprache geeignet wären. Dann musste ich mit Apple reden, wo sie gerade ihre eigene universelle Makrosprache AppleScript entwickelten. Und mit den anderen Software-Teams bei Microsoft, das waren hauptsächlich Word, Access, Project und Mail, weil die sich meist an Excel orientierten. Der Hauptteil der Arbeit bestand aus reden; also Sitzungen, E-Mails, Telefongespräche. Das hat mich für's Leben gezeichnet - ich hab' mich jetzt in mein Büro verkrochen, voller Angst, das Telefon könnte klingeln.

Der zweite Schritt war das Skizzieren einer Vision: ein allgemein gehaltenes Dokument darüber, wie Visual Basic in Excel arbeiten würde, wie ein paar Beispiel-Makros aussehen würden. Das würden die wichtigsten Funktionen sein, und so würden wir die Probleme der Kunden lösen. Als ich damit nicht allzuviel Widerspruch generiert hatte, begann ich mit einem sehr viel detaillierteren Konzept, welches bis zum kleinsten Detail beschrieb, wie alles für den Benutzer aussehen würde.

Das war das Fachkonzept (engl.: functional spec), kein Technisches Konzept, d.h. es sprach darüber, was der Benutzer sehen, nicht wie es implementiert werden würde. (Alles über Fachkonzepte ist hier beschrieben.) Ein Programmmanager kümmert sich nicht darum, wie das Entwicklerteam die Sachen intern implementiert. Immer wenn ich Kapitel des Konzepts an Ben Waldman, den Chefprogrammierer, schickte, setzten sich er und sein Team zusammen und kasperten aus, was intern zu tun sei, damit die Sache auch klappt. Sie dachten sich eine kompakte und ziemlich intelligente Tabelle aus, wo die von mir definierte objektorientierte Schnittstelle und interne Excel-Funktionen einander zugewiesen wurden; aber das ging mich schon nichts mehr an. Ich wusste nicht viel von Excels Interna, und wusste auch kaum was über die übliche Art der Implementierung.

Um die Wahrheit zu sagen, ich wusste überhaupt nichts. Frisch von der Uni hatte ich weder zum Kodieren genügend Erfahrung, noch konnte ich testen, ich konnte nicht dokumentieren, nicht verkaufen, und auch nicht auf Bedienbarkeit hin untersuchen. Zum Glück hatte Microsoft für jedes dieser Gebiete wirklich erfahrene Gurus zur Verfügung. Die lehrten mich all das, was ich heute weiß, und die machten auch die wirkliche Arbeit: Sie produzierten ein phantastisches Produkt. Beispielsweise wusste ich, dass Benutzer den Wert einer Tabellenzelle in eine Variable würden kopieren wollen:

        x = [A1] 

musste funktionieren. Ärgerlich war nur, dass eine Zelle entweder eine Zahl oder eine Zeichenkette enthalten konnte, und Basic benutzte Frühe Bindung ... man musste vor dem Benutzen DIM x als Integer, Float oder String festlegen.

Basic brauchte also neue, dynamische Typen, nur war ich nicht schlau genug, um das Problem zu lösen. Egal! Tim Corbett, ein Programmierer im Visual-Basic-Team fand heraus, wie's geht. So wurden Variant und IDispatch geboren, und Basic wurde zu einer dynamischen Sprache mit, was ihr Kiddies heutzutage "duck typing" nennt. Der Punkt ist der: Es war nicht mein Job, das Problem zu lösen, sondern ich musste erstens herausfinden, was die Kunden brauchten und zweitens sicherstellen, dass die Programmierer eine Lösung fanden.

War das Konzept erst einmal fertig und die Entwickler bei der Arbeit, blieb noch zweierlei in meiner Verantwortung: alle Fragen zu beantworten, die im Zusammenhang mit dem Entwurf hochkamen, und ... mit den anderen Teams zu kommunizieren, damit die Programmierer das nicht tun mussten. Ich traf mich mit den Testern, erklärte ihnen welches Verhalten vom Programm erwartet wurde und half bei der Testplanung. Ich traf mich mit dem Dokumentationsteam und stellte sicher, dass sie verstanden hatten, wie eine gute Einführung und eine Referenz für Excel-Basic zu schreiben war. Ich saß mit den Marketingleuten zusammen und sprach über die Vertriebsvorteile von VBA. Ich arbeitete mit Ergonomen zusammen, um Tauglichkeitstest zu entwickeln.

Ein Programmmanager geht zu vielen Sitzungen, produziert aber nur dieses eine schriftliche Konzept, weshalb sogar ein Grünschnabel wie ich, frisch von der Hochschule, den Job erledigen konnte. Um als Programmmanager zu arbeiten, brauchst du kein Veteran zu sein, mit 14 Jahren Programmiererfahrung auf dem Buckel. (Könnte sogar sein, dass du dann zuviel weißt, um ein guter Fürsprecher für den Kunden zu sein.)

Konflikte

Ohne Programmmanager wird der Normalo-Superschlau-Programmierer mit einer total verworrenen Benutzerschnittstelle daherkommen, die absolut sinnvoll ist ... WENN DU EIN VULKANIER BIST. Die besten Programmierer sind berüchtigte Intelligenzler und tun sich schwer, vorzustellen, wie das ist, wenn man sich keine 16 verschiedene Einbuchstaben-Befehlsparameter merken kann. Dieselben Programmierer neigen auch dazu, an ihrer ersten Idee kleben zu bleiben, vor allem dann, wenn sie den Kode schon geschrieben haben.

Mit das Beste, das ein Programmmanager zum Entwurfsprozess beisteuern kann, ist eine zweite Meinung, eine, die - so kann man hoffen - mehr Empathie aufbringt für diesen DAU mit seiner nervtötenden mentalen Schwäche, der doch tatsächlich erwartet, dass ein Programm benutzt werden kann, ohne das Handbuch gelesen zu haben, ohne eine Benutzerfunktion mit Emacs-Lisp zu schreiben, und ohne Zahlen im Kopf in Oktalwerte übersetzen zu können.

Tom Chi und Kevin Cheng

Eine gute Programmmanagerin wird ihre eigenen Ideen zu einer UI beisteuern, die besser oder auch schlechter als die der Programmierer sein können. Dann folgt eine lange Diskussion. Typischerweise schlägt die Programmmanagerin etwas für die Benutzer einfach zu verstehendes und benutzendes vor, etwa eine Telepathieschnittstelle und ein 30-Zoll-Monitor, der in die Hosentasche passt. Die Programmierer bevorzugen leicht zu kodierendes mit einer Befehlszeile ("Was ist denn daran nicht bedienerfreundlich?"), und mit einer Python-Schnittstelle natürlich.

Ich erinnere mich an eine beeindruckende Debatte während des Excel-5-Projekts, zwischen einem Entwickler, der die Pivot-Tabellen auf der Grafikebene oberhalb der Tabelle platzieren wollte, und dem Programmmanager, der darauf bestand, dass die Pivot-Tabellen in eine Tabellenzelle hineingehören. Darüber wurde seeehr lange gestritten. Am Ende setzte sich der Programmmanager durch, aber die endgültige Gestalt war dann sehr viel besser, als es die ursprünglichen Einzelvorschläge waren.

Um sicherzustellen, dass solche Debatten mit Respekt und auf einer vernünftigen Basis von Fakten stattfinden, müssen Programmmanager und Entwickler gleichgestellt sein. Ist der Entwickler nämlich dem Programmmanager unterstellt, so wird der irgentwann genug von der Diskussion haben und verkünden: "So, genug geredet! Jetzt machen wir das, wie ich es sage." Sind sie gleichgestellt, kann das nicht passieren. Das ist dann wie vor Gericht: Wir lassen ja auch nicht den Anwalt einer Seite gleichzeitig Richter sein. Wir arbeiten nach der Überlegung, dass sich die Wahrheit sehr wahrscheinlich in einem Diskussionsprozess zwischen Gleichgestellten herausbildet. Die Diskussion ist nur dann fair, wenn keine Seite einen unfairen Vorteil besitzt,

Heh, hallo! Das ist wichtig! Traümst du von Susi aus der 11. Klasse ... was wohl aus ihr geworden ist? Die ist jetzt Geistheilerin in Arizona, und außerdem wählt sie die Republikaner. Jetzt aber aufgepasst!
Programmierer dürfen nicht dem Programmmanager unterstellt werden. Das heißt zu Beispiel auch, dass weder Chefprogrammierer, noch Technischer Direktor, noch Vorstandsvorsitzender das Konzept schreiben dürfen.

Der häufigste Fehler in den allermeisten Firmen ist der, dass der Programmierchef das Konzept schreibt und das Produkt gestaltet. Ein Fehler ist das deshalb, weil das Design kein faires Verfahren bekommt; es wird nicht aus Konflikt und Diskussion heraus geboren, und wird deshalb auch nicht so gut, wie es werden könnte.

Ich musste das auf die harte Tour lernen. Bei Fog Creek Software war ich oft Programmmanager, und es war ein ständiger Kampf, die anderen daran zu erinnern, mit mir zu streiten, wenn ich 'was Falsches sagte. Wir sind keine große Firma, doch endlich wir groß genug, um mit echten Programmmanagern, mit Dan und Jason, zu arbeiten, und die Programmierer haben Spaß daran, mit ihnen zu streiten.

Natürlich, wenn Programmierer und Programmmanager gleichgestellt sind, gewinnen die Programmierer leicht die Oberhand. Mehrmals baten mich Programmierer, bei einem Streit mit dem Programmmanager einzugreifen:

"Wer schreibt den Kode?", fragte ich.

"Ich, aber..."

"Und wer bucht in die Quellenverwaltung ein?"

"Na ich, nehme ich an..."

"Wo liegt dann das Problem?", fragte ich, "Du hast doch Kontrolle über jedes kleinste Teil des Produkts. Was brauchst du denn noch? Einen Heiligenschein?"

Siehst du? Es stellt sich heraus, dass dieses System dem Programmmanager die Last überträgt, den Programmierer zu überzeugen. Denn es gibt immer das Risiko, dass der Programmierer an irgendeinem Punkt aufgibt, und einfach das tut, wonach ihm gerade ist. Als Programmmanager effektiv sein heißt also (a) recht haben, und (b) sich bei den Programmierern Respekt erarbeiten, so dass sie dir auch 'mal zugestehen können, Recht zu haben.

Wie verdienst du dir solchen Respekt?

Es hilft natürlich, wenn der Programmmanager selbst auch gut kodieren kann. Das ist aber unfair! Von Programmmanagern wird nämlich nicht erwartet, dass sie Kode schreiben. Programmierer neigen dazu ihresgleichen eher zu respektieren als Nichtprogrammierer, ganz egal wie schlau die sind. Es ist aber möglich, auch ohne Kodierkünste ein guter Programmmanager zu sein, nur ist es mühsamer, sich den Respekt der Programmierer zu verdienen.

Alternativ kann man sich Respekt beim Programmierteam erwerben, indem man Intelligenz, Offenheit, und Fairness in allen Diskussionen zeigt. Erzählt ein Programmmanager dummes Zeug, wird er von Programmierern schnell als Clown angesehen. Wird eine bestimmte Vorgehensweise zur persöhnlichen, emotional besetzten Angelegenheit, die schon ans Irrationale grenzt, wird man eine Menge Vertrauen verlieren ... Das gilt für beide Seiten, aber besonders Programmmanager müssen in der Debatte sachlich bleiben und willens, neue Erkenntnisse zuzulassen, und fähig, die eigene Meinung zu ändern, wenn die Argumente das erfordern. Und schließlich verlieren Programmmanager das Vertrauen der Programmierer, wenn bemerkt wird, dass sie Winkelzüge machen, dass sie heimlich mit dem Chef reden, dass sie versuchen, einen Streit über die Entzweien-und-Erobern-Strategie zu gewinnen anstatt mit einer Debatte über Vor- und Nachteile.

Und dann ist es vorbei! Das Programmierteam wird nicht mehr effektiv arbeiten. Die Programmierer werden sich ausklinken und tun, was sie sowieso tun wollten. Das führt zu schlechtem Kode, und zu und Zeitverschwendung, denn es ist ja nicht nur ein erfolgloser Programmmanager zu bezahlen, sondern dieser erfolglose Programmmanager veranlasst Sitzungen, verbrät damit anderer Leute Zeit, und der Kode wird doch nicht besser.

Konzepte? Wirklich? Das ist ja so unflexibel !

Es gibt viele Softwarefirmen, wo Konzepte zu einem Denkmal hirnlosen bürokratischen Papierkrams wurde, so dass daraus ganze Gegenbewegungen erwuchsen um eine zentrale Idee herum, nämlich Konzepte nicht zu schreiben. Diese Leute sind schlecht beraten. Ein Fachkonzept ist das Herzstück jeder flexiblen Entwicklung, weil es schnelles Iterieren über viele mögliche Entwürfe erlaubt. Verglichen mit Programmkode ist ein schriftliches Konzept sehr leicht zu ändern. Der Vorgang des Konzeptschreibens alleine zwingt dich schon dazu, den Entwurf, von dem du glaubtest, es wäre in deinem Kopf bereits fertig, nochmal zu durchdenken. Es hilft, schnell die Schwachstellen zu finden und durch weitere Varianten zu iterieren. Teams mit Fachkonzepten machen besser Produkte, weil sie die Chance hatten, mehr mögliche Lösungen zu erkunden. Sie schreiben auch ihren Kode schneller, weil sie zu Beginn schon ein klareres Bild davon haben, was gebraucht wird. Fachkonzepte sind dermaßen wichtig, dass es bei Fog Creek eine kurze, strikte Regel gibt: "Kein Kode ohne Konzept."

Die Form eines Fachkonzepts ist variabel. Alles, was darin stehen muss, ist, wie sich das Programm verhält. Es sagt nichts über die interne Arbeitsweise des Kodes. Du beginnst auf der obersten Ebene, mit der Beschreibung einer Vision, mit nicht mehr als einer Seite über die Essenz der neuen Funktionalität. Wenn das mal festgeklopft ist, kannst du eine Bildergeschichte mit Fensteratrappen entwickeln, die zeigt, wie der Benutzer sich durch die Anwendung bewegt, mit detaillierten Kommentaren, wie das funktioniert. Viel Funktionalität, besonders die UI-lastige, wird damit bereits abgedeckt. Und fertig. Das ist dein Konzept. Setzen, Jason Fried!

Hier lernst du gute Fachkonzepte schreiben: Lies meine vierteilige Artikelserie. Ein typisches, von mir geschriebenes Fachkonzept ist das zu Fog Creek Copilot.

Komplexe Funktionalität mit verstecktem Verhalten, das nicht durch die Bildergeschichte abgedeckt wird, musst du natürlich èn Detail beschreiben. In jedem Fall wird der Akt des Schreibens dir Probleme und Konflikte offenlegen, lange bevor Kode geschrieben wird. Wenn's dann soweit ist, gibt's weniger böse Überraschungen, die ein Überarbeiten, oder schlimmer noch, ein suboptimales Design erzwingen.

Wie lernt man "Programmmanager"?

Programmmanager werden besteht vor allem aus Lernen: Techniken lernen, Menschen kennenlernen, und lernen, wie man in einer Organisation effektiv handelt. Ein guter Programmmanager verbindet des Ingenieurs technischen Ansatz mit des Politikers Fähigkeit, Konsens zu erreichen. Während du daran arbeitetst, gibt es einige wenige Bücher, die du lesen solltest:

Soweit ich sehen kann ist Scott Berkuns Buch "Making Things Happen" das einzige, dass die gesamte Tätigkeit eines Programmmanagers abdeckt. Also fang' damit an. Scott war übrigens lange Jahre Programmmanager für den Internet Explorer.

Ein großer Teil der Arbeit für einen Programmmanager ist das Gestalten von Benutzerschnittstellen. Lies dazu Steve Krugs Buch "Don't Make Me Think", und dann mein eigenes: "User Interface Design for Programmers".

Schließlich ist - ich weiß, das klingt bizarr - Dale Carnegies "How to Win Friends & Influence People" aus dem Jahr 1938 eine phantastische Einführung in soziale Kompetenzen. Es ist das Buch, das ich allen Managementschülern bei Fog Creek als erstes zu lesen geben. Da wird dann immer gekichert, aber ich freue mich über das Ergebnis.