Lehren aus einem vergrabenen Projekt

Ursprünglicher Autor: Brandon Keepers
  • Übersetzung
Dieser Text basiert auf meiner Präsentation auf GRWebDev . Dies ist die Geschichte eines Projekts, das auf GitHub abgebrochen und begraben wurde, sowie die Lektion, die aus der Arbeit daran gezogen wurde.


Im Oktober 2012 haben wir ein Team zusammengestellt, um ein Produkt zu entwickeln, mit dem GitHub, Inc. neue Märkte erschließen kann. Dieses Produkt sollte als Ergebnis der Weiterentwicklung einiger interner Tools entstehen, die wir entwickelt haben, um Präsentationen in unserem Hauptquartier in San Francisco aufzuzeichnen und sie unseren Remote-Mitarbeitern vorzuführen.

Als sich unser 6-köpfiges Team zu Beginn des Projekts versammelte, wussten wir zwei Dinge:
1) Wir hatten einige interne Entwicklungen für die Aufzeichnung von Verhandlungen. und
2) Wir hatten Erfahrung mit der Erstellung einer Website zum Teilen von Präsentationsfolien ( speakerdeck.com ).

Unsere Mission war es, diese beiden Dinge zu einem Produkt zu kombinieren, mit dem jedes Unternehmen oder jede Gruppe von Benutzern Aufzeichnungen von Gesprächen (Verhandlungen) aufzeichnen und wiedergeben kann teile sie.

Nach 11 Monaten beschloss unser Team, die Arbeit an diesem Projekt einzustellen.

Entwickeln Sie eine gemeinsame Vision



Unsere Teammitglieder haben noch nie zusammengearbeitet. Wir hatten keine gemeinsame Erfahrung und es gab kein Vertrauen. Im typischen GitHub-Stil hatten wir weder einen Manager noch eine Roadmap. Keiner von uns wusste genau, was im Allgemeinen unser Produkt sein sollte?

Die besten Programme kommen von Teams, in denen jeder eine gemeinsame Vision teilt, sich wirklich um das Ergebnis kümmert und motiviert ist, dies zu erreichen. Dieses Maß an Beteiligung kann nur erreicht werden, wenn jeder an der Bildung einer gemeinsamen Vision beteiligt ist und einen Teil davon „besitzt“.

Allmählich gewannen wir das gegenseitige Vertrauen und unsere Vorstellungen über das Produkt vereinten sich, aber zu diesem Zeitpunkt waren 6 Monate vergangen.

Lektion 1: Erstellen Sie eine einzelne Produktvision in einem Team

Definieren Sie "Erfolg" und "Misserfolg"



An einem Ort wie GitHub, an dem es keine Manager oder engen Fristen gibt, besteht die Versuchung zu glauben, dass „wenn ich nur mein Bestes für ein„ cooles “Projekt gebe, das mich anmacht, dann wird alles auf magische Weise„ gut “ und schön. " Das ist eine Lüge. Erfolg ist eine Menge Arbeit. Erfolg entsteht, wenn Sie kritische Fehler gezielt vermeiden und trotzdem viel Glück haben.

Es gibt keine Zauberformel für den Erfolg, und das sage ich Ihnen nicht. Aber ich weiß, dass Sie nicht sagen können, ob Sie es erreicht haben oder nicht, wenn Sie nicht wissen, wie Sie es nach welchen Kriterien bewerten sollen. Wir haben 6 Monate an dem Projekt gearbeitet, bevor wir das erste Mal zusammen am Tisch saßen und besprachen, was als Erfolg gewertet werden kann und was am Projekt gescheitert ist.

Lektion 2: Wenn Sie eine gemeinsame Vision entwickelt haben, entwickeln Sie eine Definition des Erfolgs und, was ebenso wichtig ist, eine Definition des Scheiterns (Scheiterns). Setzen Sie sich Ziele auf dem Weg zum "Erfolg" und überprüfen Sie anhand dieser Ziele regelmäßig den Projektstatus

Erstellen Sie sinnvolle künstliche Einschränkungen



Unser Projekt litt unter einem gravierenden Mangel an Einschränkungen. Geld war kein Problem, mit der Zeit waren wir nicht an irgendetwas gebunden und wir bestimmten selbst die Menge der Produktfunktionen. Nicht jeder im Leben hat so ein Unglück gehabt. Ohne Grenzen können Sie "Wichtigkeit" nicht definieren. Wenn „alles wichtig ist“, ist es unmöglich, Prioritäten zu setzen und Entscheidungen zu treffen.

Es ist allgemein bekannt, dass die Auswahl zu vieler Optionen unser Gehirn „lähmt“. Unser Gehirn ist sehr gut, wenn Sie schnell aus mehreren Optionen auswählen müssen. Wenn es jedoch zu viele Optionen gibt, wechselt das Gehirn zu einer langsamen Aufzählung aller Optionen mit einem Vergleich aller möglichen Details.

Das gleiche passiert in Projekten. Softwareentwicklung für alle Anforderungen "sofort" - lähmt. Die Software wird „nach Funktion zu einem Zeitpunkt“ erstellt. Wählen Sie Grenzen, damit Sie sich auf das konzentrieren können, was gerade wichtig ist.

Meilensteine ​​sind eine Form solcher Einschränkungen (manche nennen sie "Fristen", aber ich bevorzuge "Meilensteine"). Ein Meilenstein ist ein bestimmtes Datum, an dem Sie ein bestimmtes Ziel erreichen. Feste Termine sollten NIEMALS einen Geltungsbereich (eine Reihe spezifischer Anforderungen) beinhalten. Wenn Sie 60 Stunden pro Woche arbeiten, um die Meilensteine ​​zu erreichen, dann verstehen Sie nicht, wovon ich spreche. Die Einschränkung sollte niemanden zwingen, MEHR zu arbeiten. Es sollte Ihnen helfen, BESSER zu arbeiten.

Wählen Sie einen vernünftigen Meilenstein, zum Beispiel "Erster Beta-Benutzer in 2 Wochen ab heute" oder "Erster Verkauf in 3 Monaten". Ohne festen Umfang werden Termine im Wesentlichen zu Zielen. Menschen haben in der Regel eine inhärente Motivation, „ein Ziel zu erreichen“.

Ändern Sie die Fristen nicht, um weitere Funktionen zu "beenden". Wenn die Frist gekommen ist, legen Sie dar, was ist. Das mag schrecklich klingen, aber glauben Sie mir, sobald Sie dies tun, werden Sie schnell lernen, sich auf Dinge zu konzentrieren, die wirklich wichtig sind und das Projekt immer in Betrieb zu halten.

Lektion 3: Erstellen Sie künstliche Einschränkungen, die Ihnen helfen, Fehler zu vermeiden und erfolgreich zu sein

Menschen bedeuten mehr als ein Produkt.



In den ersten 9 Monaten war ich mehr über das Ergebnis des Projekts besorgt als über die Leute im Team. Ich habe meine Meinung zu Ideen, Design und Code zum Ausdruck gebracht und dabei davon ausgegangen, dass das Wichtigste in unserer Kommunikation die Schaffung eines qualitativ hochwertigen Produkts ist. Ich habe mich geirrt

Jeder im Team litt unter Burnout. Die ständigen Mühlsteine ​​gegenseitiger Kritik prägen jeden von uns. Wir haben die Motivation verloren, an Dingen zu arbeiten, die uns bisher so fasziniert haben, weil sich herausstellen könnte, dass alles, was Sie getan haben, bald „wertlos“ oder „falsch gemacht“ ist.

Lektion 4: Wenn Sie sich für Menschen interessieren, kümmert sich das Projekt um sich selbst. Ersparen Sie sich keine Mühe, um sicherzustellen, dass jeder im Team das mag, was er tut. Glückliche Menschen schaffen bessere Produkte.

Misserfolg ist kein Misserfolg



Die Beendigung eines Projekts kann für die Menschen eine verheerende Erfahrung sein. Viele Kollegen kamen damals mit der Frage auf mich zu: „Sind Sie wie Sie selbst?“ Mit dem Anschein, dass ich einen geliebten Menschen verloren habe. Es hat viel Erfahrung gekostet, aber nach und nach habe ich gelernt, die „Fehler“ richtig wahrzunehmen.

Erfolg ist ein schlechter Lehrer. Da es keine Erfolgsformel gibt und diese so inkonsistent ist, macht es die "Voreingenommenheit des Überlebenden" schwierig zu verstehen, was genau zum Erfolg geführt hat. Es ist praktisch unmöglich festzustellen, ob ein Team „dank“ oder „entgegen“ der Projekttätigkeit zum Erfolg gekommen ist.

Ein Projekt anzuhalten (abzubrechen) ist eine großartige und lehrreiche Lektion. Die Entscheidung zum Abbruch ist das Ergebnis einer gründlichen ausgewogenen Analyse, ob es möglich ist, die für das Projekt aufgewendeten Ressourcen mit größerem Nutzen an anderer Stelle einzusetzen. Das Schwierigste dabei ist, diese Entscheidung im frühesten Moment zu treffen, um keine Ressourcen in etwas offensichtlich Nutzloses zu investieren.

Lektion 5: „Fehler“ ist, wenn Sie lernen, wie Sie das nächste Mal besser werden. Ich mag Misserfolge.

Warum haben wir das Projekt abgebrochen?



Wir haben in den letzten 11 Monaten viele nützliche Lektionen erhalten. Das Obige erschien mir persönlich am wichtigsten. Keiner dieser Fehler führte jedoch dazu, dass das Projekt verkleinert wurde.

Unser Slogan für github.com (die Seite) lautet: "Wir schaffen gemeinsam bessere Programme." Während wir wachsen und uns entwickeln, werden wir ständig mit der Frage konfrontiert, ob dies eine angemessene Beschreibung der Vision von GitHub, Inc (Unternehmen) ist. Wir sagen oft, dass unsere Vision vom Unternehmen so beschrieben werden kann, dass es "einfacher ist, zusammen zu arbeiten als einzeln". Angesichts der Tatsache, dass bis zu 75% unserer Mitarbeiter remote arbeiten, ist die Zusammenarbeit für Sie und Ihre Kollegen in verschiedenen Zeitzonen besonders unproblematisch. Wir stehen vor einzigartigen Herausforderungen, die für die meisten Unternehmen nicht typisch sind.

GitHub hat immer den Wunsch der Open-Source-Community geteilt, Programme zu entwickeln, die uns helfen, Probleme zu lösen, die uns verletzen. Wir spüren den Schmerz, der bei der Zusammenarbeit (aus der Ferne) auftritt, und sind daher immer bereit, "diese Kruste zu kratzen". Aber ich denke, wir verstehen die Probleme, die bei der Zusammenarbeit an Software-Code auftreten , viel besser . Die Erstellung eines Tools, das die Zusammenarbeit in anderen Bereichen erleichtert, erfordert ein sehr gutes Verständnis verschiedener spezifischer Probleme.

Am Ende haben wir beschlossen, das Projekt zu kürzen, weil Er passte nicht in die Vision, wohin GitHub wollte. Ich würde gerne glauben, dass wir unter anderen Umständen diese Lektionen berücksichtigen und dennoch in der Lage sind, ein funktionsfähiges Produkt herauszubringen. Oder vielleicht hätten wir diese Lektionen nicht gelernt, wenn wir nicht „gescheitert“ wären.

Wie auch immer, ich bin dankbar, dass ich diese Lektionen erhalten habe und erwarte, dass ich dieses Wissen bei meinem nächsten Projekt anwenden kann.

Jetzt auch beliebt: