Bei PagerDuty streben wir danach, uns als Einzelpersonen und als Team zu verbessern und zu lernen. Dies manifestiert sich in Postmortems, Code-Reviews, Retrospektiven, Diskussionen in Slack/JIRA und Health-Check-Umfragen, um nur einige zu nennen. Es gibt auch Möglichkeiten, Interessengruppen beizutreten, an Sprint-Reviews und Tech-Talks teilzunehmen und zu lesen/schreiben Beiträge aus dem Tech-Blog .

Als Ingenieure sind wir auch versucht, ineffizienten Code umzugestalten, technische Schulden zu beseitigen und Arbeitsabläufe zu verbessern. Bei so vielen Dingen, an denen wir arbeiten könnten (und ich habe unsere Produkt- oder Infrastrukturarbeit in unseren Scrum-Teams noch nicht einmal erwähnt), ist es wichtig, genauer zu betrachten, wie wir unsere Zeit einteilen. Welche Projekte sollten beispielsweise Vorrang vor anderen haben und warum? Woran sollten wir arbeiten, um unsere Ziele effektiver zu erreichen?

Um diese Fragen zu beantworten, müssen wir die Hebelwirkung eines bestimmten Werkes beurteilen. Hebelwirkung, schreibt Edmond Lau in Der effektive Ingenieur wird durch eine einfache Gleichung definiert: Es handelt sich um den Wert bzw. die Wirkung, die pro investierter Zeit erzielt wird.

Mit anderen Worten: Hart arbeiten ist nicht dasselbe wie effektiv arbeiten. Es ist der Unterschied zwischen Beschäftigtsein und Produktivität. Man kann es auch als ROI der Entwicklung betrachten. Die Anzahl der Dinge, an denen wir möglicherweise arbeiten könnten, ist grenzenlos, doch unsere Zeit und Ressourcen sind begrenzt. Effektiv zu sein bedeutet, an den Dingen zu arbeiten, die den größten Wert bieten und dabei den geringsten Aufwand erfordern. Die 80-20-Regel, auch bekannt als Pareto-Prinzip Hier gilt: 80 Prozent des Ergebnisses sollten mit 20 Prozent Aufwand möglich sein.

Wie können wir unsere Hebelwirkung erhöhen?

Der ehemalige Intel-CEO Andrew Grove erklärt in seinem Buch Hohes Output-Management dass Ihre Gesamthebelwirkung – die Menge an Wert, die Sie pro Zeiteinheit produzieren – nur auf drei Arten gesteigert werden kann:

1. Indem die Zeit reduziert wird, die zum Abschließen einer bestimmten Aktivität benötigt wird.
2. Durch die Steigerung der Leistung einer bestimmten Aktivität.
3. Durch die Umstellung auf eine Tätigkeit mit höherer Hebelwirkung.

Tagsüber ist unsere Zeit mit einer Vielzahl von Aktivitäten ausgefüllt, von Besprechungen, E-Mails abrufen, Text in Confluence/Kommentaren/Blogs lesen/schreiben, Feedback zu Github/Confluence geben, an Slack-Diskussionen teilnehmen und Sprint-Arbeit leisten. Aber egal, was Sie tun, Sie sollten sich die folgenden Fragen stellen, um Ihre Hebelwirkung zu verbessern:

1. Wie kann ich diese Aktivität in kürzerer Zeit abschließen?
2. Wie kann ich den durch diese Aktivität erzeugten Wert steigern?
3. Gibt es etwas anderes, dem ich meine Zeit widmen könnte, das mehr Wert schafft?

Ich werde unten einige Beispiele geben.

Tagungen

Um ein Meeting effektiver zu gestalten, stellen Sie die folgenden Fragen:

1. Muss dieses Meeting eine Stunde dauern? Kann es in 30 Minuten erledigt werden? Oder besser noch in 15 Minuten?
2. Sind die Ziele des Meetings für alle klar? Sollten die Teilnehmer etwas vorbereitet haben? Sollten sie vorher etwas lesen?
3. Ist dieses Meeting überhaupt notwendig? Kann das Problem über Slack oder E-Mail gelöst werden?

E-Mails und Slack abrufen

Die Vorlieben für E-Mails und Slack sind von Person zu Person unterschiedlich und es lässt sich nicht leugnen, dass das Abrufen und Beantworten von E-Mails wertvoll ist (und das Gleiche gilt für das Lesen, Auf-dem-Laufenden-Bleiben und die Zusammenarbeit über Slack), aber ab wann hat all dies abnehmende Erträge? Mit anderen Worten: Ab wann wird es unserer Produktivität schädlich?

Bei ständigen Unterbrechungen im Laufe des Tages kann es schwierig sein, in die richtige Stimmung zu kommen, um so schnell Code zu produzieren wie dies Auktionator kann reden . Wenn ich beispielsweise ständig in Kommunikationstools (z. B. E-Mail, Slack, JIRA) hin und her plappere, arbeite ich in einem vorläufigen Zustand, in dem ich ständig mit Command + Tab zwischen verschiedenen Anwendungen wechsele, zwischen einer Menge Chrome-Tabs hin- und herwechsele und Code schreibe. Jetzt habe ich ein System, bei dem ich versuche, mindestens zwei bis drei Stunden pro Tag ununterbrochen, konzentriert und hochkonzentriert zu programmieren – was ich als „tiefe Arbeit“ bezeichne.

Cal Newport, Autor von Konzentrierte Arbeit , definiert dies wie folgt:

„Berufliche Tätigkeiten, die in einem Zustand ablenkungsfreier Konzentration ausgeführt werden und Ihre kognitiven Fähigkeiten an ihre Grenzen bringen. Diese Anstrengungen schaffen neuen Wert, verbessern Ihre Fähigkeiten und sind schwer zu reproduzieren.“

Ich habe dieses Konzept auch als fließen , geprägt vom Psychologen Mihaly Csikszentmihalyi. Menschen, die Flow erlebt haben, beschreiben es als „einen Zustand müheloser Konzentration, der so tief ist, dass sie ihr Zeitgefühl, ihr Gefühl für sich selbst und ihre Probleme verlieren.“

Wenn ich konzentriert arbeite, verwende ich normalerweise die Schlummerfunktion in Slack, die Benachrichtigungen für einen ausgewählten Zeitraum unterdrückt. Wenn ich dann an einem guten Punkt angekommen bin, an dem ich aufhören kann, schaue ich in regelmäßigen Abständen wieder bei Slack nach, um sicherzustellen, dass nichts in Gefahr ist.

Ich bin davon überzeugt, dass Ingenieure ihre beste Arbeit leisten, wenn sie konzentriert arbeiten, und ich ermutige andere, mindestens ein oder zwei Stunden am Tag konzentriert zu arbeiten, um zu sehen, ob sie produktiver sind. Verwechseln Sie dies nicht mit normaler/unkonzentrierter Programmierzeit. Idealerweise sollten wir versuchen, den ganzen Tag über zu programmieren, aber es gibt einen Unterschied zwischen abgelenktem/unkonzentriertem Programmieren und ununterbrochenem Programmieren – wenn ich konzentrierte Arbeit sage, meine ich ununterbrochenes Programmieren.

Das aktuelle JIRA-Ticket, an dem Sie arbeiten

Vorausgesetzt, das Jira-Ticket wurde bereits vom Produktbesitzer priorisiert und hat den Story-Time- und Sprint-Planungsprozess durchlaufen, kann es nie schaden, es noch einmal zu überprüfen und zu prüfen, ob Sie seine Wirkung steigern können. Lassen Sie es anhand unserer drei Fragen überprüfen:

1. Wie kann ich diese Aktivität in kürzerer Zeit abschließen?

Können wir bereits vorhandene Bibliotheken nutzen? Ich weiß, dass es für Ingenieure verlockend sein kann, etwas von Grund auf neu zu schreiben.

2. Wie kann ich den durch diese Aktivität erzeugten Wert steigern?

Gibt es eine Möglichkeit, Teile unserer aktuellen Aufgabe zu automatisieren, damit wir es zukünftigen Entwicklern einfacher machen können? Können wir eine allgemeine Aufgabe in eine Funktion oder Klasse abstrahieren? Manchmal lohnt es sich, im Voraus ein wenig Zeit zu investieren, damit wir in Zukunft schneller iterieren können.

3. Gibt es etwas anderes, dem ich meine Zeit widmen könnte, das mehr Wert schafft?

Gibt es wichtigere Aufgaben, an denen gearbeitet werden muss, die für das aktuelle Ziel oder die Veröffentlichung relevanter sind? Denken Sie MVP (Minimum Viable Product) in dieser Situation: Brauchen wir diese ausgefallenen Optimierungen wirklich am Anfang, wenn wir nur versuchen, frühes Feedback zu sammeln? Was ist die kleinste lieferbare Portion, die wir veröffentlichen können? Wie hoch ist das 80-20-Verhältnis bei einer Veröffentlichung? Worauf können wir verzichten? Wie können wir den Umfang reduzieren, ohne den Wert zu verringern?

Ich weiß, dass man sich leicht in viel Arbeit verstricken kann. Ich habe jedoch gelernt, dass man durch das Stellen der richtigen Fragen effektiver und produktiver arbeiten kann.

Seien Sie gespannt auf Teil 2, in dem ich näher auf die Priorisierung eingehe.