Zeit zwischen Produkt- und Ingenieuraufwand aufteilen

In jedem Unternehmen, in dem ich tätig war, gab es eine Aufteilung der Zeit zwischen Produktinitiativen und Ingenieurarbeit. Die Prozentsätze änderten sich immer, manchmal 70 % Produkt, 30 % Ingenieurwesen, manchmal bis zu einer 50/50-Aufteilung. Die treibende Kraft ist sicherzustellen, dass das Ingenieurwesen einen Teil seiner Zeit mit der Entwicklung neuer Funktionen verbringt, aber auch sicherstellt, dass wir „unsere eigene“ Arbeit erledigen können, wie z. B. die Behebung technischer Schulden, die Aktualisierung von Systemen und die Dokumentation unseres Codes.

Das Problem ist, dass es eine Sache ist, dies von Anfang an zu sagen, und eine andere, es in die Realität umzusetzen. Es gibt einige Gründe, warum dieses Modell meiner Erfahrung nach gescheitert ist, nicht weil die Leute theoretisch nicht verstehen, dass es wertvoll ist, sondern weil es in der Praxis einige häufige Fallstricke gibt, über die man nachdenken muss. Wir werden einige dieser Szenarien aus der Perspektive eines Ingenieurleiters behandeln, damit wir einen guten Weg nach vorne aufzeigen können.

Die Probleme

Einige der unten aufgeführten Punkte sind Reaktionen und Planungen basierend auf dem, was schiefgehen kann. Lassen Sie uns also zuerst über die Herausforderungen sprechen, denen Sie begegnen können, wenn dies nicht richtig eingerichtet ist.

• Das Produkt kann Konflikte haben, entweder mit der Arbeit selbst oder mit dem damit verbundenen Zeitaufwand. Dies kann die Beziehung zwischen Produkt und Ingenieurwesen belasten. Wenn sie von der Überraschung getroffen werden, können die Grenzen Ihrer Arbeit potenziell restriktiver werden.
• Ihre Ingenieure verstehen möglicherweise nicht, was von ihnen erwartet wird. Die Parallelisierung von Bemühungen kann schwierig sein, daher kann der Aufbau eines guten Prozesses Klarheit schaffen.
• Der Wartungspfad sollte klar sein: Planen Sie ein riesiges System-Upgrade? Dies kann im Laufe der Zeit andere Teams beeinträchtigen, und wenn Sie sich über die endgültige Verantwortlichkeit nicht im Klaren sind, könnte es Sie noch einholen. 👻

So schön es auch ist, etwas Freiheit in Ihrer Ingenieurzeit zu haben, Kommunikation, Planung und klare Erwartungen können dazu beitragen, dass Sie die oben genannten Probleme vermeiden.

Kommunikation

Sobald Sie herausgefunden haben, welches Problem Sie angehen möchten, ist es entscheidend, **ein kurzes Einseiter zu verfassen**, das Sie mit Stakeholdern teilen können, über die Art der Arbeit, die dafür benötigte Zeit und warum sie wichtig ist.

Wenn es sich um ein großes Projekt handelt, können Sie diese Teile auch in GitHub/GitLab/Jira-Aufgaben aufteilen und ein Label für die Art der Arbeit hinzufügen. Das ist großartig, weil Sie Ihr bestehendes Projektmanagement-System nutzen können, um den Arbeitsumfang und die Erwartungen wöchentlich zu erhöhen. Es ist gut, den Dialog mit Ihren Produktpartnern über den Umfang und die Art der Arbeit offen zu halten, damit sie nicht von anderen erledigten Arbeiten überrascht werden. Dies wird stark von der Kultur des Teams und der Organisation abhängen.

Dies kann auch Ihren Ingenieuren Klarheit verschaffen. Wenn sie die Art der Arbeit und das, was von ihnen erwartet wird, verstehen, können sie die kleinen Probleme, aus denen ein Ganzes besteht, leichter angehen.

Sie werden feststellen, dass es aus Fokusgründen weniger sinnvoll ist, dass jeder Ingenieur seine Zeit auf Produkt- und Ingenieurprojekte aufteilt. Sie ziehen es vielleicht stattdessen vor, die Arbeit untereinander aufzuteilen: drei Leute für ein paar Wochen an Produktarbeit, einer für Ingenieurarbeit. Es gibt auch Zeiten, in denen alle einbezogen werden müssen, damit sie über das gleiche institutionelle Wissen verfügen (Migrationen können so sein, je nachdem, worum es geht). Ihr Ergebnis kann je nach Größe des Teams, dem Umfang der Produktarbeit und der Art des Projekts variieren. 

Auch hier hilft die Kommunikation – wenn Sie nicht sicher sind, welcher Weg der richtige ist, kann eine kleine Brainstorming-Sitzung mit der Gruppe helfen, wie Sie dies umsetzen wollen. Stellen Sie nur sicher, dass Sie alle auch über das *Warum* des Projekts informieren, während Sie dies tun.

Projektarten

Es gibt viele Arten von Projekten, die Sie in Ihrem Ingenieurteam einplanen können, und jede hat leicht unterschiedliche Ansätze, wie ich es gesehen habe. Lassen Sie uns also jede davon durchgehen.

Technische Schulden

Lassen Sie uns zuerst die technischen Schulden behandeln, da dies einer der häufigsten Arbeitsbereiche ist, der Ihr Team entlasten kann. Für jede Funktion, die Sie schreiben, verlieren Sie nicht nur Zeit bei der Produktentwicklung, wenn der Aufwand für das Ingenieurwesen verlangsamt wird, sondern Sie verlieren auch Geld in Form von Ingenieurzeitgehältern.

Ein wenig technische Schuld ist natürlich, besonders in kleineren Unternehmen, wo es finanziell sinnvoller ist, schnell voranzukommen, aber es gibt einige Punkte, an denen technische Schulden die Entwicklung und Veröffentlichungen lähmen und eine Codebasis instabil machen. Manchmal muss dies sofort geschehen, um sicherzustellen, dass alle Ihre Ingenieure effizient arbeiten können, und manchmal geschieht dies schrittweise.

In vielen Fällen handelt es sich bei technischen Schulden um Dinge, die man durch einen Bottom-up-Ansatz lernt: Die Entwickler, die am engsten mit dem System arbeiten, wissen am besten, welche technischen Schulden im Alltag bestehen, als Ingenieurmanager (EMs) typischerweise. Die Herausforderung für einen EM besteht darin, größere Muster zu erkennen, wie z. B. wenn sich viele Leute über dasselbe beschweren, anstatt eines Entwicklers, der eine starke Meinung haben mag. Wenn Sie sich vor Beginn dieser Art von Projekt umhören, kann das helfen – befragen Sie die Leute, wie viel Zeit sie ihrer Meinung nach in einer bestimmten Woche verschwenden, im Vergleich zu den Aussichten auf eine Alternative.

Manchmal sind technische Schulden eine Frage von umfangreichen Refactorings. **Ich habe gesehen, dass dies am besten funktioniert, wenn die Leute transparent darüber sind, welche Art von Pull Requests (PRs) notwendig sind.** Müssen Sie das CSS an einer Million Stellen aktualisieren? Oder alte Klassenkomponenten in Hooks konvertieren? Sie möchten wahrscheinlich keinen riesigen PR für alles, aber es macht auch keinen Sinn, diese Arbeit pro Komponente aufzuteilen. Arbeiten Sie im Team zusammen daran, wie viel jeder PR enthalten wird und *was von der Überprüfung erwartet wird*, damit Sie kein „Überprüfungslöchlein“ schaffen, während die Arbeit erledigt wird.

Innovative Projekte

Viele Unternehmen führen Hack-Week-/Innovationswochen-Projekte durch, bei denen Entwickler an einem Feature arbeiten können, das mit dem Produkt des Unternehmens in Verbindung steht, ohne Fesseln. Es ist eine großartige Zeit für Erkundungen, und ich habe gesehen, wie auf diese Weise einige leistungsstarke Features zu bekannten Anwendungen hinzugefügt wurden. Es ist auch unglaublich belebend für das Team, eine eigene Idee in die Tat umgesetzt zu sehen.

Das Problem bei der Durchführung solcher Projekte in der aufgeteilten Ingenieurzeit ist, dass sich das Produktteam manchmal ein wenig benachteiligt fühlen kann. Warum? Denken Sie aus ihrer Perspektive. Ihre Aufgabe ist es, diese Features voranzubringen, sorgfältig mit Stakeholdern zu planen, Roadmaps zusammenzustellen (oft basierend auf Unternehmensmetriken und Forschung) und in den Ingenieurzeitplan aufgenommen zu werden, normalerweise in Zusammenarbeit mit einem Projektmanager. Wenn Sie die Hälfte Ihrer Zeit mit der Entwicklung ungeplanter Features verbringen, können Sie potenziell einen bestehenden Projektplan abzweigen, einige der bekannten Forschungsergebnisse, die sie haben, missachten oder einfach den Prozess verlangsamen, um ein Kern-Make-or-Break-Feature zu erhalten, das sie benötigen.

Die Art und Weise, wie ich dies gut spielen sah, ist, wenn der EM von Anfang an mit dem Produkt kommuniziert. Betrachten Sie dies als Partnerschaft: Wenn das Produkt sagt, dass ein bestimmtes Feature keinen Sinn ergibt, haben sie wahrscheinlich einen guten Grund dafür. Wenn Sie einander zuhören können, gibt es wahrscheinlich einen Weg nach vorne, auf den Sie sich beide einigen können. 

Es ist auch gut, ihre Befürchtungen anzusprechen. Sind sie besorgt, dass nicht genug Zeit für Produktarbeit bleibt? Fragen Sie Ihr Team direkt, wie viele Wochen bei halber Zeit Ihrer Meinung nach dafür benötigt werden (mit der Erwartung, dass sich die Dinge verschieben können, sobald sie sich damit beschäftigen). Machen Sie allen klar, dass Sie nicht erwarten, dass es in einem irrsinnigen Tempo erledigt wird.

Letztendlich ist Kommunikation der Schlüssel. Idealerweise handelt es sich um kleine Projekte, die nichts davon beeinträchtigen, was parallel zur regulären Arbeit erledigt werden kann. Mein Vorschlag ist, es zunächst mit etwas sehr Kleinem zu versuchen, um zu sehen, welche Hürden es geben könnte, und um Vertrauen beim Produkt aufzubauen, dass Sie Ihre Arbeit trotzdem erledigen und nicht „entlaufen“.

Der letzte Teil davon ist herauszufinden, wer für Kennzahlen, Ergebnisse und das, was schiefgeht, verantwortlich ist. Ein Teil des Grundes, warum das Produkt die Richtung vorgibt, ist, dass es bei einem Scheitern zur Verantwortung gezogen wird. Stellen Sie sicher, dass Sie klarstellen, dass Sie als Ingenieurleiter die Verantwortung für die Ergebnisse übernehmen, sowohl die guten *als auch* die schlechten, um eine gute Beziehung aufrechtzuerhalten.

Langsame, fortlaufende Arbeit

Dies ist wahrscheinlich die klarste Art von Projekten und wird wahrscheinlich am wenigsten Widerstand hervorrufen. Beispiele für diese Art von Arbeit sind interne Dokumentation, Werkzeuge (wenn Sie kein dediziertes Werkzeugteam haben) oder kleine Wartungsarbeiten.

Die hierfür notwendige Kommunikation ist etwas anders als bei anderen Projekten, da es sich nicht unbedingt um ein einzelnes, abgrenzbares Projekt handelt, das Sie ausliefern, sondern um einen iterativen Prozess. Nehmen wir Dokumentation als Beispiel: Ich würde empfehlen, Zeit für interne Dokumentation in jeden Feature-Prozess einzubauen. 

Nehmen wir an, Sie haben eine neue Funktion erstellt, die Teams die Zusammenarbeit ermöglicht. Nicht jeder im Unternehmen weiß vielleicht, dass Sie einen Microservice für diese Funktion erstellt haben, welche Parameter erwartet werden oder wie Sie später Funktionalität hinzufügen können. Interne Dokumente können den Unterschied ausmachen, ob der Dienst genutzt wird, oder ob Ihr Team aufgefordert wird, mit jemandem zu pairen, jedes Mal, wenn jemand ihn nutzen muss. Oder schlimmer: Sie versuchen, ihn zu umgehen und herauszufinden, wie er funktioniert, und schaffen ein Durcheinander aus etwas, das schneller und effizienter hätte bearbeitet werden können.

Im Gegensatz zu Innovationsprojekten ist langsame, fortlaufende Arbeit typischerweise nichts, was die Leute wirklich gerne tun, daher funktioniert es am besten, einen Prozess und Erwartungen von Anfang an festzulegen. Interne Dokumentation ist ein manchmal versteckter, aber sehr wichtiger Teil eines gut funktionierenden Teams. Sie hilft beim Onboarding, bringt alle auf den gleichen Stand bezüglich der Systemarchitektur und kann Entwicklern sogar helfen, wirklich zu festigen, was sie gebaut haben, und darüber nachzudenken, wie sie es lösen.

Migrationen

Migrationen werden etwas anders gehandhabt als einige andere Arten von Projekten, da sie wahrscheinlich alle betreffen. Es gibt keine richtige Methode, und sie hängt auch stark davon ab, um welche Art von Migration es sich handelt – von Framework zu Framework, das Aufbrechen eines Monolithen und die Migration zu einem anderen Build-Prozess oder Server können unterschiedliche Ansätze haben. Da jede dieser Maßnahmen wahrscheinlich ein eigener Artikel wäre, gehen wir einige übergeordnete Optionen durch, die für die Organisation gelten.

• Mein erster Vorschlag ist, so viel Recherche wie möglich im Voraus zu betreiben, um jede Art von Migration zu verstehen, die Sie durchführen. Es gibt keine Möglichkeit, alles zu wissen, aber Sie möchten nicht auf halbem Weg durch einen Prozess feststellen, dass etwas Entscheidendes fehlt. Dies sind auch hilfreiche Informationen, die Sie mit Stakeholdern teilen können.
• Gibt es interne Debatten darüber, in welche Richtung Ihr Unternehmen gehen soll? **Zeitlich begrenzen Sie eine Zeiteinheit, um das Problem zu lösen und stellen Sie sicher, dass Sie am Ende einen klaren Entscheidungsträger haben.** Viele technische Probleme haben keine einzige „wahre“ Lösung, daher kann es helfen, wenn eine Person die Entscheidung trifft und alle anderen widersprechen und sich committen. Aber Sie möchten den Leuten auch einen Moment geben, ihre Meinung zu äußern, was sie zögern lässt, auch wenn sie nicht zustimmen – sie denken vielleicht an etwas, das Sie nicht bedacht haben.
• Dokumentieren Sie einen Migrationsplan, sowohl auf einer hohen Ebene als auch die Auswirkungen auf jedes Team. Dies ist auch eine großartige Gelegenheit, dem Produkt zu erklären, warum diese Arbeit wichtig ist: Wird Ihre Codebasis alt und kann nicht mehr gut mit anderen Bibliotheken und Tools zusammenarbeiten? Gab es einen neuen Build-Prozess, der Ihren Ingenieuren Zeit im Veröffentlichungsprozess sparen könnte? Helfen Sie ihnen zu verstehen, warum die Arbeit entscheidend ist.
• Seien Sie klar über Wartung und Verantwortung. Wenn ein Team einen Build-Prozess migriert, der dann Probleme für ein anderes Team verursacht, wer behebt die Probleme, um dieses Team zu entblocken? Dies sollten Sie entscheiden, bevor es passiert.
• Einige Migrationspfade erlauben es Ihnen, Dinge langsam über die Zeit oder Team für Team zu tun, oder einen Großteil der Arbeit im Voraus zu erledigen. Es gibt jedoch normalerweise eine Zeit, in der es entscheidend wird und alle Hände an Deck benötigt werden. Im Gegensatz zu einigen anderen Arbeiten, die parallelisiert werden können, **müssen Sie möglicherweise mit dem Produkt etwas vereinbaren, bei dem alle anderen Feature-Arbeiten für eine Weile gestoppt werden, während Sie das neue System in Betrieb nehmen.** Wenn Sie eng mit ihnen zusammenarbeiten, stellen Sie vielleicht fest, dass es Zeiten in der Saison gibt, in denen Sie von Natur aus mehr Kundenruhe haben, und dies Ihnen den nötigen Freiraum geben könnte, dies zu erledigen. Ich würde vorschlagen, dass Sie, wenn sie Ihnen erlauben, die Ingenieurzeit für eine Weile zu 100 % in Anspruch zu nehmen, den Gefallen erwidern; und sobald die Plattform stabil ist, 100 % der Zeit des Teams für Produktarbeit widmen.

Feiern Sie!

Dieser letzte Schritt mag optional erscheinen, ist aber meiner Meinung nach ein großes Ding. Ihr Team hat gerade etwas Unglaubliches geleistet: Sie haben Bemühungen parallelisiert, sie waren gute Partner für das Produkt, sie haben etwas für das Ingenieurwesen im Allgemeinen erledigt. Es ist entscheidend, die Arbeit wie eine Veröffentlichung zu feiern.

Das Team muss wissen, dass Sie diese Arbeit schätzen, weil sie oft undankbar, aber sehr wirkungsvoll ist. Es kann auch Vertrauen aufbauen, wenn man weiß, dass es, wenn zukünftig etwas Schwieriges auftaucht, tatsächlich auch zu seinem Karriereweg beiträgt. Das Feiern mit Ihrem Team, was Sie erreicht haben, kostet sehr wenig und hat große kulturelle Auswirkungen.

Buch kaufen

Dies ist nur ein Auszug aus der Art von Inhalten aus meinem neuesten Buch, das bald erscheint...