Versenden Sie kleinere Softwareeinheiten und begrenzen Sie die Größe Ihrer lokalen Host-Zweigstellen

In den letzten zehn Jahren, in denen ich HackerNoon leitete, habe ich mit vielen talentierten Softwareentwicklern zusammengearbeitet, und zu Beginn ihrer Amtszeit sage ich meist das Gleiche: Versenden Sie kleinere Softwareeinheiten und begrenzen Sie die Größe Ihrer lokalen Host-Filialen. Warum? Hier sind die beiden Hauptgründe und ein großes Problem:

1. Benutzer profitieren stärker von Ihrer Arbeit und geben Feedback zu Ihrer Arbeit, während Sie weiter an der Fertigstellung des Projekts arbeiten.

Wenn Sie ein Projekt haben, das 6 Monate Arbeit erfordert und erst 6 Monate lang in Betrieb geht, sind das 5 Monate und 30 Tage, in denen die Benutzer keinen Nutzen aus Ihrer Arbeit ziehen. Erst wenn es online ist, hat der Rest des Internets überhaupt eine Chance, von dem zu profitieren, was Sie versenden. Und selbst dann beginnt der gewaltige, harte Kampf um die Akzeptanz. Wenn Sie stattdessen einen Teil des Projekts jede Woche versenden würden, würden die Benutzer über den Lebenszyklus des Projekts hinweg an Wert gewinnen.

Dane Lyons , mein ehemaliger Kollege, hat es mir gegenüber einmal so ausgedrückt: „Wir sollten weiterhin atomare Werteinheiten hinzufügen und so viele Veröffentlichungen wie nötig machen.“ Wir könnten problemlos 10 Releases zu [Funktionalität] haben, bevor wir damit zufrieden sind und bereit sind, weiterzumachen.“

Als CEO beurteile ich Neueinstellungen oft danach, wie lange es dauert, bis sie zu profitablen Mitarbeitern werden. Im Vertrieb ist dies eindeutiger: Überstiegen ihre Verkäufe ihre Vergütung? Natürlich gibt es noch andere Dinge zu berücksichtigen, wie Grenzkosten für Marketing, Infrastruktur usw., aber wie auch immer man es betrachtet, es ist schwieriger zu messen, wie sich ein Softwareentwickler auf das Endergebnis auswirkt als ein Verkäufer. Wenn Sie als Softwareentwickler in eine neue Rolle einsteigen, empfehle ich Ihnen, zunächst einmal erfolgreich zu versuchen, einzelne Aufgaben aneinanderzureihen, bevor Sie sich an die Homeruns machen.

Im Spiel der Softwareentwicklung gibt es keine allgemeingültigen Regeln für die Höhe des Punktestands. Sicher, einige Leute weisen Punktesysteme zu und andere definieren KPIs, aber letztendlich sind es die Menschen, die Ihr Produkt verwenden, die bestimmen, ob und wie Sie Wert schaffen oder nicht. Wenn Sie früher versenden, erhalten Sie früher Feedback. Den Leuten, die Ihre Software verwenden, wird deutlicher gemacht, wie die nächste Atomeinheit des Projekts gebaut werden soll und nicht.

2. Je weiter Ihre Branche von der Produktionsrealität abweicht, desto schwieriger ist es für Teamkollegen, zu Ihrem Projekt beizutragen und angrenzende Projekte voranzutreiben.

Die externen Auswirkungen, die dadurch entstehen, dass nicht die aktuellste Version ausgeliefert wird, sind auf den ersten Blick möglicherweise schwerer zu erkennen. Alles ist verbunden. In einem Produkt wie HackerNoon existieren die Profilseite und die Story-Seite nicht im Vakuum; Sie existieren als verbundene Seiten innerhalb eines Produkts. Wenn Änderungen an der Funktionsweise einer Seite auftreten, wirkt sich dies auf die Funktionsweise aller damit verbundenen Seiten aus.

Wenn Ihre lokale Niederlassung sehr groß ist, funktionieren andere Änderungen, die an damit verbundenen Seiten oder Funktionen vorgenommen werden, oft nicht mehr, sobald Ihre übergewichtige Niederlassung schließlich in die Produktion geht. Das macht Dinge kaputt. Dadurch entstehen Fehler. Dies erzwingt die Notwendigkeit, die Arbeit zu wiederholen. Dies weckt bei Ihren Teamkollegen den Wunsch, nicht mit Ihnen zusammenarbeiten zu wollen. Dies könnte sogar zu einem Produkterlebnis führen, das schlechter ist als das, das Sie bereits hatten, vor all der Arbeit, die Sie in Ihre Filiale vor Ort gesteckt haben.

Indem Sie kleinere Änderungen regelmäßiger vornehmen, ermöglichen Sie anderen, einen Beitrag zu leisten. Sie haben das Gefühl, dass das, was sie liefern, auch funktionieren wird, weil Sie sich beide bereits auf die Produktionsbasis geeinigt haben. Inkrementell ist deine beste Freundin. Es verbindet Sie mit der Realität. Wenn sich die inkrementellen Änderungen negativ auf das Produkt auswirken, warum glauben Sie dann, dass sich größere Änderungen in die gleiche Richtung positiv auf das Produkterlebnis auswirken werden?

Und das Wichtigste ist: Haben Sie keine Angst vor mutigen Projekten, die zu zu großen Zweigen werden könnten, denn Sie sind ein schlechter Trottel, der in der Lage ist, die Art und Weise, wie dieses verdammte Ding für die Menschen funktioniert, zu verändern.

Bei manchen Projekten muss es sich einfach um große Zweigstellen handeln. Dinge mit massiven Abhängigkeiten wie neue Datenbanken können beispielsweise so tief in der bestehenden Nutzung verwurzelt sein, dass es am besten ist, die Zeit zurückzudrehen und das Projekt wie eine jährliche On-Premise-Version 2.0 anzugehen. Und die Entwicklung anderer bahnbrechender Technologien wie ChatGPT hat so lange gedauert, dass es für die Einführung einfach keinen Sinn ergeben würde, eine untrainierte, unvollständige, beschissene UX-Version der neuen Technologie zu veröffentlichen. Machen Sie große Schwünge. Wenn Sie die Landebahn haben. Wenn Sie das Team an Bord haben. Aber überheb dich nicht. In den meisten Fällen geht es bei der Softwareentwicklung nicht darum, das Rad neu zu erfinden. Es geht einfach darum, die nächste Atomeinheit auszuliefern.