Auf dieser Seite
Vier Produkte neben der Kundenarbeit klingt nach einem Rezept für Chaos. Was es handhabbar macht, ist kein Heldentum, sondern ein langweiliger Wochenplan, an den wir uns größtenteils halten.
Die Form der Woche
Montag: Support und Triage
Zuerst werden alle Postfächer geleert. Fehlerberichte werden reproduziert, gelabelt und entweder am selben Tag behoben oder eingeplant. Mit den Nutzern anzufangen hält den Rest der Woche ehrlich in Bezug darauf, was zählt.
Dienstag und Mittwoch: Entwickeln
Zwei ungestörte Tage an jeweils einem Produkt. Benachrichtigungen sind aus, und es werden keine Meetings angesetzt. Der Großteil der eigentlichen Feature-Arbeit geschieht hier.
Donnerstag: Review und Vorbereitung
Code-Review, Tests und Release Notes. Releases werden am Donnerstag vorbereitet, aber nicht am Donnerstagnachmittag ausgeliefert.
Freitag: Schreiben und Planen
Dokumentation, Blogbeiträge, Changelogs und der Plan für die nächste Woche. Schreiben zwingt uns, zu erklären, was wir gebaut haben, und beim Erklären zeigt sich oft, was wir falsch gemacht haben.
Warum donnerstagnachmittags nichts live geht
Geht bei einem Release am Donnerstagnachmittag etwas kaputt, wird es nachts repariert oder bleibt bis zum Wochenende defekt. Wir liefern dienstag- oder mittwochvormittags aus, wenn Zeit bleibt, es zu beobachten und zurückzurollen.
Ein Produkt pro Block
Statt jeden Tag alle vier Produkte anzufassen, gehört jeder Arbeitsblock zu einem Produkt. Die Kosten des Wechsels zwischen Codebasen sind vor allem die Kosten, den Kontext neu zu laden, daher vermeiden wir es, öfter als einmal am Tag zu wechseln.
Was nicht passt
Vorfälle halten sich nicht an den Zeitplan. Wenn etwas ausfällt, steht alles andere still. Wir halten Puffer im Plan vor, indem wir uns nur auf etwa drei Viertel der verfügbaren Zeit festlegen.
Was wir ändern würden
Der Zeitplan funktioniert nur, wenn jeder Block geschützt bleibt, und Wissen sammelt sich trotzdem leicht bei demjenigen, der ein Feature gebaut hat. Ein Teil des Plans für dieses Jahr ist eine Dokumentation, die gut genug ist, damit jeder Engineer jedes der vier Produkte übernehmen könnte.
Probieren Sie es selbst aus
Sie brauchen keine vier Produkte, damit das nützlich ist. Wählen Sie einen Tag für Support, einen Tag zum Schreiben und einen Tag, an dem Sie nie deployen – und beobachten Sie, was sich ändert.
Fanden Sie das nützlich? Teilen Sie es mit Ihrem Team.
Auf LinkedIn teilen
