Die Denkweise des Entwicklers in Wachstumsprojekten

Wenn Sie Entwickler in einem Startup oder einem wachsenden Projekt sind, reicht es nicht aus, viele Technologien zu beherrschen und zu wissen, wie man komplexe, hochbelastete Dienste erstellt. In meiner Karriere war ich an vielen wachsenden Projekten beteiligt und habe zwei Startups von Grund auf aufgebaut. In diesem Artikel teile ich meine Erfahrungen darüber, worauf man sich bei der Entwicklung konzentrieren sollte und warum Perfektionismus selbst die besten Ideen verdirbt.

Werkzeuge sind ein Mittel, kein Zweck

Für jeden Entwickler ist es eine echte Herausforderung, ein Projekt zu starten. Es ist ganz natürlich, das Gefühl zu haben, alles perfekt machen zu müssen. Ich habe eine Weile gebraucht, um zu erkennen, dass der Wunsch nach Perfektionismus meistens die Angst widerspiegelt, dass Kollegen mich für einen zusätzlichen „Druck“ oder die Nichtverwendung eines Musters oder Tools verurteilen. Und dann passiert es: Der Produktionsserver bricht zusammen, Kunden beschweren sich, ich werde gefeuert und die Welt geht unter.

Jedes Tool, Muster oder jede Programmiersprache ist nur ein Tool , kein Ziel. Stellen Sie sich häufiger die Frage: Warum brauche ich das jetzt? Was wird es bieten? Welche Kennzahlen werden dadurch verbessert? Beispiel: Warum jetzt einen Linter konfigurieren? Warum CI/CD jetzt anpassen? Wenn Sie 10 Mal am Tag eine Bereitstellung durchführen, brauchen Sie es wahrscheinlich. Wenn Sie einmal pro Woche oder Monat eine Version bereitstellen, brauchen Sie es höchstwahrscheinlich nicht. Wenn die CI/CD-Anpassung viel Zeit in Anspruch nimmt, aber weder die Entwicklung beschleunigt noch dem Projekt und den Kunden einen Mehrwert bringt, sollte sie dann jetzt implementiert werden?

Bei einem Hobbyprojekt ist es sinnvoll, etwas Neues auszuprobieren: die Struktur des Repository und des Codes endlos zu verbessern, mit Mustern zu experimentieren usw. In diesem Fall sind die von uns implementierten Tools das Ziel . Das Hauptziel eines Produktionsprojekts besteht darin, den Kunden einen Mehrwert zu bieten. Die Kunden werden nie erfahren, dass wir doppelte Anführungszeichen statt einfacher Anführungszeichen und Singletons verwenden und dass es keinen Hardcode gibt.

Refactoring ist nur dann erforderlich, wenn dadurch die Entwicklungsgeschwindigkeit und -leistung verbessert, Fehler reduziert oder der Rückstand aufgelöst wird.

Das Engagement für Qualität sollte den Zielen des Produkts folgen, nicht Ihrem Wunsch nach Perfektionismus. Daher ist es wichtig, sich daran zu erinnern: Ein Entwickler in einem wachsenden Projekt ist niemals ein Perfektionist.

Der Geschäftswert steht an erster Stelle

Für einen Entwickler in einem wachsenden Projekt ist es wichtig, den Geschäftswert zu verstehen. Wenn Sie es gewohnt sind, ein normaler Entwickler zu sein, der nur nach vorgefertigten Spezifikationen codiert, kann dies zunächst eine Herausforderung sein.

Wenn das Produkt gerade erst geboren wird, ist der Wert für die Benutzer noch nicht bewiesen, aber der zu beweisende Wert ist im Kopf der Stakeholder vorhanden. In dieser Phase können Sie den Fehler machen, die Codebasis mit unnötiger Logik zu überladen. Sie müssen beispielsweise einen Auftragshandler schreiben. Sie erstellen eine Tabelle mit Aufträgen in der Datenbank und eine zweite Tabelle mit Auftragstypen, obwohl es bisher nur einen Typ gibt.

Nehmen wir an, Sie tun dies, weil der Stakeholder darauf besteht, dass diese Logik eines Tages benötigt werden könnte. In Wirklichkeit wird sie möglicherweise nie benötigt. Erstellen Sie keine unnötigen Entitäten, wenn sie jetzt keinen Wert haben, und – noch wichtiger – verschwenden Sie dafür weder Geschäftszeit noch Geschäftsgeld.

Eine berechtigte Frage könnte gestellt werden: „Werde ich mit einem Stakeholder streiten?“ Nun, manchmal wird das so sein. Stakeholder erwarten detaillierte Analysen. Die Besonderheiten wachsender Projekte sind meistens ein Mangel an Ressourcen, daher müssen Entwickler über analytische Fähigkeiten verfügen. Sie müssen den Wert der Funktionen für das Produkt ständig validieren, da seine Lebensfähigkeit buchstäblich davon abhängt.

Wenn Sie sich zu sehr verausgaben, gehen Ihrem Unternehmen die Ressourcen aus und Sie müssen das Repository archivieren.

Stellen Sie viele Fragen: „Warum implementieren wir diese Funktion jetzt? Sollten wir dieses Problem jetzt lösen? Existiert dieses Problem überhaupt?“ Es ist genau dasselbe wie oben bei Technologien beschrieben. Die Fähigkeit, die richtigen Fragen zu stellen, zeigt Ihre Professionalität. Sie sollten Ihre Zeit und Geschäftsressourcen nur für Dinge verwenden, die Ihren Kunden wirklich einen Mehrwert bieten.

Hackathons sind ein gutes Beispiel dafür, wie das Verständnis des Geschäftswerts das Ergebnis beeinflusst. Innerhalb einer begrenzten Zeit muss eine nicht ideale, aber praktikable Lösung für ein klar definiertes Problem präsentiert werden. Wenn Entwickler vom Projekt inspiriert sind und klar verstehen, warum sie es tun, ist das Ergebnis sogar in 2 Tagen gut.

Der Plan hängt von den Risiken ab

Stellen Sie sich ein Strategiespiel vor: Sie haben einen Holzfäller und einen Rekruten. Das Ziel ist es, einen Krieger zu erschaffen. Zuerst muss der Holzfäller Holz sammeln und eine Kaserne bauen, in der der Rekrut eine militärische Ausbildung erhalten kann. Um das Holz zu ernten, muss der Holzfäller den Wald durch einen unerforschten Teil der Karte erreichen. Der Karte nach zu urteilen, kann der Wald an einem Spieltag erreicht werden, das Holzfällen dauert etwa einen halben Tag und der Bau der Kaserne dauert eine Woche. Die Kaserne wird also in etwa zehn Tagen erscheinen.

Der Holzfäller braucht fast einen Tag, um zum Wald zu gelangen, aber plötzlich versperrt der Fluss den Weg. Das Ziel ändert sich: Wir müssen einen Damm, eine Brücke oder ein Boot bauen, um auf die andere Seite zu gelangen, oder vielleicht ist es besser, anderswo nach Wäldern zu suchen. Eine voreilige Bewertung führt zum Scheitern der Strategie. Hätte der Späher zuerst einen unentdeckten Teil der Karte erkundet, hätte dieses Risiko vermieden werden können.

Ein erfahrener Entwickler erkennt Risiken, die für die Stakeholder nicht offensichtlich sind: Integrationen mit Diensten von Drittanbietern, die Komplexität der Erweiterung der Codebasis usw. Es liegt in Ihrer Verantwortung, die Risiken zu bewerten und davor zu warnen. Meistens sind sich die Stakeholder dieser Risiken nicht bewusst, aber sie beeinflussen die Bewertung, die für sie wichtig ist.

Eine Beispielaufgabe: Integration Ihres Dienstes mit einem Zahlungsdienst. Richten Sie zunächst den Zahlungsdienst ein, erhalten Sie Zugriff und untersuchen Sie, wo etwas schiefgehen kann. Machen Sie sich vor der Integration mit der Vorgehensweise vertraut. Es ist besser, einen Tag mit der Recherche zu verbringen, als nach zwei oder drei Wochen Entwicklung festzustellen, dass die Funktion nicht rechtzeitig fertiggestellt werden kann oder die Integration fehlgeschlagen ist, weil der Zahlungsdienst die Bedingungen geändert oder die Unterstützung für die benötigte Funktion deaktiviert hat.

Nachdem Sie die Risiken ermittelt haben, müssen Sie die Arbeit planen und eine Zeitschätzung für die Aufgabe abgeben. Dies ist das Framework, das ich verwende:

• Schreiben Sie Szenarien oder visualisieren Sie diese an Bord: Der Benutzer klickt beispielsweise auf eine Schaltfläche und das Dokument wird heruntergeladen. Wählen Sie Ansätze, die Sie verstehen.

• Analysieren Sie, wie das Skript aus technischer Sicht funktionieren könnte. Je mehr Optionen, desto besser. Ich bewerte die Optionen und wähle eine potenziell skalierbare Lösung mit minimierten Risiken, die das Problem am schnellsten lösen würde.

• Teilen Sie die Szenarien in logische Teile auf, die codiert werden müssen.

• Schätzen Sie jeden Teil in Tagen und multiplizieren Sie ihn dann mit dem Koeffizienten 1,11. Das ist mein persönlicher magischer Koeffizient, der mein Geburtstag am 11. Oktober ist. Das ist natürlich ein Witz (oder auch nicht). Mein Rat ist, je nach Projektumfang ein paar zusätzliche Tage oder sogar Wochen zur Schätzung hinzuzufügen. Während wir versuchen, so viele Risiken wie möglich vorherzusehen, können einige nicht vorhergesehen werden. Es ist besser, die Dinge früher zu erledigen, als keinen Erfolg zu haben.

  
  

  Scheuen Sie sich nicht, eine höhere Schätzung abzugeben: Wenn ein Stakeholder fragt: „Können Sie das nicht schneller machen?“, antworten Sie nicht einfach „Nein“, sondern begründen Sie, warum. Erzählen Sie von den Risiken, demonstrieren Sie Szenarien und geben Sie Beispiele. Der Stakeholder muss verstehen, dass Sie das Problem analysiert und nicht nur zufällig bewertet haben.

Wichtiger Aspekt: Auch Ihr Geisteszustand ist ein Risiko. Planen Sie Ihren Urlaub und achten Sie auf Ihre geistige Gesundheit, um motiviert zu bleiben und nicht auszubrennen: Es liegt in Ihrer Verantwortung.

MVP ist kein Raumschiff

Die Frage „Wie erstelle ich ein MVP?“ beschäftigt mich schon meine ganze Karriere lang. Klingt einfach – Minimum Viable Product.

Wikipedia-Definition:

Ein Minimum Viable Product (MVP) ist eine Version eines Produkts mit gerade genug Funktionen, um von ersten Kunden genutzt werden zu können, die dann Feedback für die zukünftige Produktentwicklung liefern können.

Ich habe oft beobachtet, dass es beim Erstellen eines MVP manchmal eher wie der Bau eines Raumschiffs ist, der unglaublich viel Zeit in Anspruch nimmt. Das Hauptziel in der MVP-Phase besteht darin, schnelles Feedback vom Kunden zu erhalten und auf der Grundlage dieses Feedbacks mit den Stakeholdern zu vereinbaren, ob wir „geradeaus gehen“ oder „rechts abbiegen“. Der beste Weg, Feedback zu sammeln, sind Kennzahlen. Es ist großartig, wenn sie auch ohne sie erfolgreich sind, aber wenn nicht, wissen Sie zumindest, warum.

Ich erzähle Ihnen von meinem ersten MVP. Ich habe viele Tools und Frameworks gefunden: UML, Design Patterns, Roadmap, Story Points, System Requirement Specification, ADR, UI-Tests usw. Ich habe mich entschieden, sie alle zu verwenden, weil diese Frameworks in großen Unternehmen verwendet werden und ich auf Konferenzen, Vorträgen und YouTube davon gehört habe.

Der Zweck des Dienstes bestand darin, Daten über Testläufe zu speichern. Ich stellte einen einjährigen Fahrplan zusammen, zeichnete eine detaillierte Architektur in UML , verbrachte viel Zeit damit, ein Framework für das Backend auszuwählen, richtete ein System für Tests und Protokolle in Sentry ein und berechnete die Belastung bei vielen Benutzern anstelle der erwarteten 10-15. Ich wollte das perfekte Projekt machen.

Die Fertigstellung der ersten Version dauerte 6 Monate. Man konnte sich alle Starts und Diagramme ansehen und Berichte herunterladen, aber es gab ein Problem mit der Datenerfassung. Zwei- bis dreimal pro Woche erschien ein fehlerhafter Bericht, der die Nutzung des Dienstes unmöglich machte, aber ich hielt mich hartnäckig an den Plan.

In den nächsten Jahren hatte ich viele verschiedene Projekte und versuchte, mein Startup zu gründen. Ich lernte etwas über Marketing, Vertrieb und Kundenprobleme. Die Erfahrung veränderte meine Denkweise und ermöglichte es mir, die Ansätze zu entwickeln, die ich in diesem Artikel teile. Ich werde eine aktuelle Aufgabe beschreiben, um zu demonstrieren, wie sie in der Praxis funktionierten.

Ich musste die API-Methode beschleunigen, deren Langsamkeit die Benutzer nervte. Der Plan war, sie in einen separaten Dienst vom Monolithen zu verschieben, wo es aufgrund vieler Integrationen mit internen Diensten und Datenstrukturen Schwierigkeiten gab. Dieses Projekt war experimentell – niemand wusste, ob eine Beschleunigung möglich war.

Natürlich könnte ich einfach vorschlagen, alles neu zu schreiben und perfekt zu machen. Ich begann mit der Untersuchung des Monolithen und der internen Dienste und untersuchte die Risiken von Integrationen. Dann erstellte ich mithilfe eines einfachen Diagramms in Miro eine Strategie, zerlegte alles in Iterationen und begann erst dann mit der Arbeit.

Von Zeit zu Zeit gab es Probleme mit Integrationen, von denen der Stakeholder als Erster erfuhr. Diese haben wir zunächst gelöst. Ja, es gab noch technische Schulden im Projekt: Linter, unvollständige Tests, alte Schemata in der Datenbank – aber das Problem der Clients wurde gelöst.

Alle Iterationen trafen das Ziel und beim vierten Versuch erreichten wir 100 %. Es würde 10 Iterationen erfordern, um alles von Grund auf neu zu schreiben, aber selbst in kürzerer Zeit erhielten wir einen skalierbaren Dienst, der das Problem löste. Die einzige Frage ist der Ansatz.

Kodex eines Entwicklers in einem wachsenden Projekt

• Lassen Sie Perfektionismus hinter sich. Die Welt ist zwar voller Technologien, die Probleme lösen, aber Sie müssen nicht alles wissen, um Projekte für die Menschen nützlich zu machen.

• Verwenden Sie nach Möglichkeit vorgefertigte Lösungen.

• Der Geschäftswert steht an erster Stelle. Benutzer kommen nicht wegen eines Produkts, sondern wegen einer Lösung für ihr Problem.

• Bewerten Sie Risiken von Anfang an und kommunizieren Sie diese klar an die Stakeholder.

• Machen Sie kurzfristige Pläne. Wenn die Aufgabe schon seit zwei Jahren im Rückstand ist, brauchen die Benutzer sie höchstwahrscheinlich nicht.

• Sammeln Sie Feedback und Kennzahlen auf jede erdenkliche Weise. Kennzahlen sind ein zuverlässiger Weg, um Wachstumspunkte zu finden.

• Skalierbare Lösungen können erreicht werden, auch wenn zu Beginn nicht die „richtigen“ Engineering-Muster verwendet werden.