Inspired. Marty Cagan

Чтение книги онлайн.

Читать онлайн книгу Inspired - Marty Cagan страница 15

Inspired - Marty Cagan

Скачать книгу

Engineers gerechtfertigt sein – oder sogar mehr.

      In der Praxis ergibt sich eine Obergrenze für ein Team, die normalerweise bei etwa acht bis zwölf Programmierern erreicht ist. Sicher haben Sie schon mal von der Zwei-Pizza-Regel gehört, die dazu dienen soll, Teams in dieser Größenordnung zu halten.

      Wichtiger als die tatsächliche Größe des Teams ist jedoch das Gleichgewicht der Qualifikationen, die erforderlich sind, um die richtigen Dinge herzustellen und diese Dinge auch richtig herzustellen.

      Beachten Sie, dass ich noch nichts darüber gesagt habe, wer für wen arbeitet.

      Bei einem Produktteam geht es nicht um Hierarchien – es hat eine bewusst flache Organisationsstruktur. Für gewöhnlich leistet jeder in einem Produktteam einen individuellen Beitrag und es gibt keinen Vorgesetzten.

      Um das absolut klarzustellen: Der Product Manager ist niemandes Chef im Produktteam.

      Ein Produktteam ist eine Gruppe von hoch qualifizierten Personen, die sich für einen längeren Zeitraum zusammenschließen, um schwierige geschäftliche Probleme zu lösen.

      Die Art ihrer Beziehung wird hauptsächlich durch echte Zusammenarbeit definiert. Dabei verstehe ich Zusammenarbeit nicht als abgedroschene Phrase. Es geht viel mehr darum, dass Produkt, Design und Technik im wörtlichen Sinne zusammen Lösungen erarbeiten. Dazu später noch viel mehr, fürs Erste ist es für Sie wichtig, zu verstehen, dass hier keine Hierarchie vorliegt.

      Ich habe auch noch nichts darüber gesagt, wo die Mitglieder des Teams physisch verortet sind. Auch wenn das nicht immer möglich ist, geben wir uns größte Mühe, dieses Team am selben Ort arbeiten zu lassen.

      Am selben Ort bedeutet, dass die Teammitglieder tatsächlich direkt nebeneinandersitzen. Also nicht im selben Gebäude und auch nicht auf derselben Etage. Es bedeutet, so nah beieinander, dass sie einander mühelos auf die Bildschirme schauen können.

      Ich weiß, das klingt ein bisschen altmodisch, und die Tools für Zusammenarbeit über räumliche Grenzen hinweg werden immer besser, aber die besten Unternehmen haben den Wert eines gemeinsamen Standorts für Teams erkannt.

      Falls Sie jemals zu einem Team mit gemeinsamem Standort gehört haben, wissen Sie bereits, was ich meine. Aber Sie werden an der Art, wie wir unsere Arbeit in einem Produktteam erledigen, erkennen, dass eine spezielle Dynamik entsteht, wenn ein Team zusammensitzt, zusammen zu Mittag isst und persönliche Beziehungen zueinander knüpft.

      Ich bin mir darüber im Klaren, dass dies ein etwas emotionales Thema sein kann. Aus persönlichen Gründen leben etliche Menschen nicht an ihrem Arbeitsort und ihre Lebensgrundlage hängt davon ab, dass sie effektiv aus der Entfernung arbeiten.

      Zudem ist das auch einer der Gründe, warum wir wesentlich lieber Festangestellte im Produktteam haben als befristete Auftragnehmer oder Dienstleister. Es ist viel leichter, einen gemeinsamen Standort zu haben und ein beständiges Teammitglied zu sein, wenn man fest angestellt ist.

      Es ist völlig in Ordnung, wenn ein Unternehmen mehrere Standorte hat, solange wir nach Kräften darauf hinwirken, dass an jedem davon zusammensitzende Teams arbeiten.

      Wir werden uns später noch damit beschäftigen, was wir tun können, wenn es nicht möglich ist, dass alle Teammitglieder zusammensitzen.

      Haben Sie erst einmal die Grundlagen für ein Produktteam geschaffen, stellt sich als Nächstes diese große Frage: Wo liegt der Zuständigkeitsbereich jedes Teams? Das heißt, wofür ist jedes Team verantwortlich?

      Einer der dazugehörigen Parameter ist die Art der zu erledigenden Arbeit und es ist wichtig, dass ein Produktteam die Verantwortung für die gesamte Arbeit trägt – Projekte, Features, Bugfixing, Performance, Optimierungen und inhaltliche Änderungen –, also für wirklich alles, was mit seinem Produkt zusammenhängt.

      Der andere Aspekt ist der Arbeitsumfang. In einigen Unternehmen ist das Produktteam für ein komplettes Produkt zuständig. Heutzutage ist es jedoch häufiger so, dass das Produkt komplett identisch mit dem Kundenerlebnis ist (denken Sie nur an Facebook oder PayPal), und jedes Team ist verantwortlich für irgendeinen kleineren, aber bedeutsamen Teil dieses Erlebnisses.

      Sie arbeiten beispielsweise in einem Team bei eBay, das für eine Technologie verantwortlich ist, die Betrug aufdeckt und verhindert, oder für Tools und Dienstleistungen für gewerbliche Anbieter. Oder Ihr Team ist bei Facebook zuständig für den Newsfeed, für eine native iOS App oder für die Einsatzmöglichkeiten, die für einen bestimmten vertikalen Markt erforderlich sind.

      In einem kleinen Start-up ist das einfach, denn hier gibt es üblicherweise nur ein oder wenige Teams, in denen Sie leicht Dinge aufteilen können.

      Doch wenn ein Unternehmen wächst, erweitert sich die Anzahl der Teams von einer Handvoll zu zwanzig, fünfzig oder mehr Teams in großen Produktunternehmen. Die Koordination wird schwieriger (dazu mehr im Abschnitt Product @ Scale), doch das Konzept ist sehr gut skalierbar und genau genommen einer der Hauptfaktoren für die Skalierbarkeit.

      Manchmal, oder genauer gesagt sehr häufig, definieren wir die Teams weitgehend aufgrund der Architektur. Das ist recht verbreitet, weil die Architektur die Technologieplattform bestimmt, und das erfordert oft verschiedene Arten von technischem Fachwissen.

      Auf jeden Fall ist das Alignment zwischen Product Management und Engineering von größter Bedeutung. Deshalb setzen sich der Head of Product und der Head of Engineering normalerweise zusammen, um Größe und Zuständigkeitsbereich der Teams festzulegen.

      Ich kann Ihnen sagen, dass es keine perfekte Aufteilung des Kuchens gibt. Machen Sie sich bewusst: Wenn Sie das eine optimieren, geht das auf Kosten von etwas anderem. Entscheiden Sie also, was Ihnen am wichtigsten ist, und halten Sie sich daran.

      Ich habe schon mehrfach erwähnt, dass diese Teams dauerhaft zusammenbleiben müssen, aber ich habe nicht gesagt, ob damit ein paar Monate oder mehrere Jahre gemeint sind.

      Grundsätzlich gilt, dass wir uns sehr bemühen, die Teams zusammenzuhalten und Stabilität zu gewährleisten.

      Natürlich gibt es

Скачать книгу