Einführung von „20% Zeit“ an einem Arbeitsplatz [geschlossen]

20% der Zeit ist es die Kultur eines Arbeitgebers, die es seinen Mitarbeitern ermöglicht, 20% ihrer Zeit mit der Arbeit an Projekten zu verbringen, die sie interessant finden - es kann sein, dass sie eine neue App erfinden oder einen bestehenden Prozess verbessern. Einige Leute kennen das vielleicht als Stinktier Arbeit, aber dieser Begriff kann nichts (oder etwas völlig anderes) für Sie bedeuten.

Es gibt viele dokumentierte Fälle von großartigen Produkten, die aus 20% / Stinktierarbeit in einem Unternehmen entstehen. Es scheint eine Win / Win-Situation zu sein; Das Unternehmen erhält möglicherweise ein großartiges neues Produkt oder eine großartige Anwendung, und der Entwickler hat die Möglichkeit, seine kreativen Muskeln zu spielen und Innovationen zu entwickeln.

Ich habe mehrmals versucht, eine Form von 20% / Skunk bei meinem früheren Arbeitgeber einzuführen, ohne Erfolg.

Wie kann ich es dem Management besser rechtfertigen? Was ist die "richtige" Herangehensweise an diese Art von Arbeitsarrangement?

Der Hauptgrund für 20% Zeit ist, die Kapazitätsauslastung bei 80% anstatt bei 100% zu halten.

Sie können sich eine Softwareentwicklungsorganisation als ein System vorstellen, das Featureanforderungen in entwickelte Features umwandelt. Sie können sein Verhalten mithilfe der Warteschlangentheorie modellieren .

THEORIE

Wenn Anforderungen schneller eingehen, als das System sie bearbeiten kann, werden sie in die Warteschlange gestellt. Wenn die Ankunft langsamer ist, nimmt die Warteschlangengröße ab. Da die Ankunfts- und Serviceprozesse zufällig sind, ändert sich die Warteschlangengröße mit der Zeit zufällig.

Der Mathematiker kann nach dieser "Zufälligkeit" fragen: Es muss eine Wahrscheinlichkeitsverteilung geben. Wie groß wird also die Warteschlange im Durchschnitt sein? Math (Warteschlangentheorie) hat eine Antwort darauf: Wenn sowohl Ankunfts- als auch Dienstprozesse Markov sind, dann ist N = rho ^ 2 / (1-rho).

(Wo rho der Nutzungskoeffizient ist, der dem Verhältnis von Service- und Ankunftsrate entspricht. Wenn die Prozesse nicht Markov sind, ist die Mathematik komplizierter, ändert aber nichts an den Schlussfolgerungen.)

Wenn Sie diese Funktion zeichnen, können Sie feststellen, dass die durchschnittliche Warteschlangenlänge bei einer Auslastung von bis zu 0,8 niedrig bleibt , dann stark ansteigt und unendlich wird. Sie können dies intuitiv nachvollziehen, indem Sie an die CPU Ihres Computers denken: Wenn sich die Auslastung 100% nähert, reagiert der Computer nicht mehr.

TRAINIEREN

Die Wirtschaftlichkeit der Softwareentwicklung ist derart, dass Softwareunternehmen hohe Kosten verursachen, wenn sich ihre Warteschlangen in einem Zustand mit hoher Warteschlange befinden. Dies umfasst verpasste Marktchancen, veraltete Produkte, verspätete Projekte und Verschwendung, die durch Gebäudefunktionen in Erwartung der Nachfrage verursacht werden.

Die 20% -Zeit ist somit die wissenschaftliche Antwort auf das Problem der Optimierung wirtschaftlicher Ergebnisse: Vermeiden Sie Zustände mit hoher Warteschlange, indem Sie Auslastungsquoten vermeiden, die sie verursachen. Es ist im Wesentlichen das Spiel, das das System anspricht.

Es folgen sofort einige praktische Schlussfolgerungen:

• Wenn Sie 20% Zeit in Betracht ziehen und die Kostenrechnung durchführen (die Zeit der Entwickler kostet X, aber / und das Unternehmen kann / kann es sich nicht leisten), machen Sie es falsch.
• Wenn Sie wöchentlich 20% auf einen Freitag verteilen, machen Sie es falsch
• Wenn Sie ein 20-prozentiges System zur Einreichung / Überprüfung / Genehmigung von Projektvorschlägen einrichten, machen Sie es falsch
• Wenn Sie Stundenzettel ausfüllen, machen Sie es falsch
• Wenn Sie Innovation zu 20% als Motivator verwenden, machen Sie es falsch. Während neue Produkte aus 20% Projekten hervorgegangen sind, waren sie nicht der Punkt. Wenn Ihr Unternehmen während seiner Kernstunden keine Innovationen durchführen kann, ist das ein Problem!
• In 20% der Zeit geht es nicht um Kreativität. Sagen Sie nicht, dass Sie Ihre Kreativität mit 20% der Zeit entfesseln werden, sondern fragen Sie, warum Sie bereits während Ihrer Kernstunden nicht kreativ genug sind.

ANTWORTEN AUF FRAGEN IN DEN KOMMENTAREN

Dan , du hast das richtig verstanden und den Fehler, den viele gemacht haben, genau beschrieben. Sie können den Auslastungsgrad nicht auswählen, da es sich um eine Ausgabevariable handelt. Es ist ein Verhältnis der Eigenschaften zweier Prozesse, also ist es das, was es ist, weil die Prozesse so sind, wie sie sind. Eine Organisation hat Einfluss auf beide Prozesse. Anpassungsfähigkeit und -nachfrage sind eines der größten Probleme, mit denen sich die Wissensbasis der Lean-Software-Entwicklung befasst. Die Auslastung ist einer der Indikatoren dafür, wie gut dieses Problem in einer Organisation gelöst wurde. Mit fortschreitender Lean-Initiative entsteht ein Mangel, und Sie entfernen Abfall aus dem Wertstrom. Wenn Sie jedoch 20% Zeit einplanen, landen Sie in derselben Auslastungsfalle mit weniger verfügbarer Kapazität.

Kim , es ist teilweise immer noch eine Kultursache. Der nächste kulturelle Bezugspunkt, den ich mir vorstellen kann, ist die synergetische Ebene des sogenannten Marshall-Modells des organisatorischen Wandels. Es entsteht am Ende erfolgreicher Lean-Transformationen oder ist in Organisationen vorhanden, die von Anfang an schlank aufgebaut wurden. ( Hier ist ein Link zu Bob Marshalls Whitepaper (PDF) .)

VERWEISE

Die obige Logik wird in der Literatur zur Softwaretechnik gut unterstützt. Mary und Tom Poppendieck haben dies in ihrem 2006 erschienenen Buch Implementing Lean Software Development angedeutet . Donald Reinertsen behandelt in seinem 2009 erschienenen Buch Principles of Product Development Flow (Kapitel 3) dieses Thema gründlich mit Formeln und Grafiken.

Vierzehn Monate, nachdem ich diese Antwort geschrieben hatte, hatte ich eine viel bessere .

Ich habe nicht an einem Ort gearbeitet, an dem solche Arbeiten offiziell anerkannt wurden. Aber aus meinen Gesprächen und Versuchen, etwas über diese Praxis zu lernen, habe ich folgendes herausgefunden:

• Es ist in der Tat eine Kultur und keine Politik
• Es kann nicht von der Geschäftsleitung verordnet werden
• es kann nicht von einem Komitee von Entwicklern eingerichtet werden
• es sind nicht 32 stunden auf dieser und 8 stunden auf der

" Skunkworks " entspricht nicht 20% der Zeit. 20% Zeit ist, wie Sie sagten - Zeit, an der der Entwickler selbst entscheidet, woran er arbeitet. Skunkworks ist ganz anders. Ein Skunkworks-Projekt ist ein hochwertiges, kostenintensives Projekt, an dem ein Team (häufig ein Splitterteam von Gurus) arbeitet, das nicht dem oberen Management gemeldet wird, und das Team entscheidet selbst, wie das Projekt ohne die Anweisung des Managements weitergehen soll . Diese Projekte werden oft durch ein taktisches oder geschäftliches Bedürfnis motiviert, etwas zu erledigen, aber im Budget ist kein Platz dafür. Wenn etwas erledigt werden muss , wird es erledigt - Budgets müssen verdammt sein.

Ich leitete ein Entwicklungsteam, in dem ich 20% Zeit implementierte. Oder zumindest versucht. Ich hatte die Zustimmung meiner Vorgesetzten, also war das kein Problem. Das Problem war, dass das Team zu klein und zu spezialisiert war. Wann immer Probleme auftauchten, die ein sofortiges Eingreifen erforderten, wurde die 20% -Zeit überschritten. Dies geschah letztendlich sehr oft.

Ich stellte auch fest, dass einige meiner Entwickler meine Richtungslosigkeit als beunruhigend empfanden. Obwohl ich sagte "Arbeite an allem, was du willst, solange es programmierbezogen ist", fiel es ihnen immer noch schwer, den "irgendetwas" -Teil zu akzeptieren. Sie dachten, dass einige Projekte besser wären als andere, und arbeiteten daher unweigerlich an einfachen Implementierungsanforderungen für das Hauptprodukt. Ich wollte, dass sie sich verzweigen und wachsen, aber stattdessen vertieften sie sich in ihre Hauptkompetenz.

Ich würde es wieder tun, aber ich würde ausdrücklich verbieten, am Hauptprodukt zu arbeiten, und ich könnte sie mit einigen Ideen beginnen, aus denen ich auswählen kann, um loszulegen.

Ich arbeite für ein Start-up, das die 20% -Richtlinie umgesetzt hat. Dies ist mein erster Arbeitgeber, der dies tut, und als er es beim Vorstellungsgespräch ansprach, war ich wirklich überrascht, da die meisten anderen Arbeitgeber versuchten, keine einzige Stunde zu "verschwenden".

Ich trat dem Start-up bei, als es gegründet wurde, und war fast ein Jahr lang der einzige Entwickler. Ich habe meine 20% mit ein paar Dingen verbracht:

• Fehler in zufälligen Open-Source-Projekten melden / beheben - das kann so klein sein, als würde man ein interessantes Projekt auf Github veröffentlichen und ein paar Tippfehler in den Dokumenten korrigieren.
• Open Source "Zeug" schreiben - Dinge wie Programmierherausforderungen, nur zum Spaß.
• Zu Konferenzen und Sprints gehen - alle paar Monate würde ich zu einem Sprint gehen, wo ich an Projekten arbeiten kann (von denen einige möglicherweise von der Haupt-App verwendet werden, andere nicht) und etwas Erfahrung sammeln kann. Es gibt einige Bibliotheken, die von unserer App und von Apps anderer Unternehmen verwendet werden, die Entwickler zu Konferenzen schicken, sodass dies als direkter Vorteil für unser Unternehmen angesehen werden kann.
• Neue Technologien lernen - so habe ich Go gelernt , auch wenn wir es nicht im Unternehmen einsetzen. Dies wird von meinem Arbeitgeber besonders gefördert. In letzter Zeit habe ich einige der kostenlosen Online-Kurse von Stanford verfolgt.

Die Zeiten werden nicht genau gemessen, es sind definitiv keine 32 + 8 Stunden, manchmal gibt es dringende Dinge zu tun, wenn nicht genug Zeit vorhanden ist, um diese 20% abzuschneiden, manchmal habe ich mehr Zeit.

Ich arbeite aus der Ferne, und wir verwenden den Campfire-Chat von 37signal, um zu kommunizieren und die Präsenz des jeweils anderen zu verfolgen. Diese Stunden werden als "Arbeitsstunden" aufgezeichnet. Ich bin im Chat angemeldet und für Kollegen verfügbar, obwohl ich sie erstelle es ist klar, dass ich gerade nicht an unserem Projekt arbeite.

Nach meiner kleinen Erfahrung haben viele unserer Projekte tatsächlich auf diese Weise begonnen. Wir hatten freie Zeit und Bandbreite, um neue Projekte anzunehmen. Wir haben uns zusammengetan und mögliche coole / zukunftsorientierte Ideen für unsere Abteilung entwickelt. In unserer Freizeit haben wir einen Prototypen entwickelt und sobald dieser ziemlich poliert war, wurde er der oberen Ebene präsentiert und in der Regel sehen sie den Nutzen.

Es scheint mir, dass die obere Ebene weiß, was sie wollen, wenn sie es sehen, aber nicht weiß, dass sie es brauchen / wollen, bis sie es sehen. Durch Prototyping konnten wir unsere eigenen Projekte erstellen, diese vorschlagen und dann, sobald dies genehmigt wurde, mehr Zeit für die Fertigstellung aufwenden.