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

30

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?

dannywartnaby
quelle
11
Stinktierarbeit? Hier raucht jeder starkes Cannabis und schreibt echten Funky-Code?
Dan Diplo
@Dan theregister.co.uk/1999/10/27/what_the_hell ;) Mit diesem Begriff wird "nicht geplante, vom Entwickler initiierte Arbeit" in einem Unternehmen bezeichnet. In der Regel in Teilzeit. Einige Unternehmen gestatten ihren Mitarbeitern, einen bestimmten Prozentsatz ihrer Zeit damit zu verbringen, an etwas zu arbeiten, das sie möchten.
Dannywartnaby
2
@danny So verstehe ich den Begriff überhaupt nicht: Sie beschreiben Googles "20% Zeit". Ich bezweifle eher, dass Lockheeds Skunk Works irgendetwas Ungeplantes tun. Vielmehr handelt es sich um "eine Gruppe innerhalb einer Organisation mit einem hohen Maß an Autonomie und ohne bürokratische Hemmnisse, die mit der Arbeit an fortgeschrittenen oder geheimen Projekten beauftragt ist". (Zitat von der WP Skunk Works Seite)
Frank Shearar
1
@SteveBennett: Das äußerste logische Gegenteil von 20% Zeit ist 100% Auslastung, Arbeiten in funktionalen Silos, hoher Spezialisierungsgrad, Berücksichtigung der Zeit, die für jede Funktion aufgewendet wurde, und viele, viele, viele Abfälle.
Azheglov
1
Dies ist eher eine Frage für den Arbeitsplatz, aber sie wurde dort bereits gestellt - Workplace.stackexchange.com/questions/468/…
ChrisF

Antworten:

45

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.

Azheglov
quelle
Woah, nette Antwort. Ich hatte das nie in Betracht gezogen - es immer als eine kulturelle Sache angesehen. +1
Kim Burgess
SEHR interessant ... Eine Sache, die ich jedoch nicht befürchte: Warum die Warteschlange bis zu 80% klein bleibt, liegt daran, dass bis zu diesem Punkt freie Kapazität vorhanden ist. Wenn 20% Ihrer Kapazität mit nicht in der Warteschlange befindlichen Artikeln gefüllt werden sollen, haben Sie Ihre Kapazität nur auf 80% reduziert, und 80% sind Ihre neuen 100%. Recht?
Dan Ray
@KimBurgess: Ich habe am Ende der Antwort einen Kommentar zu Ihrem Kommentar zum Q & A hinzugefügt.
Azheglov
@ DanRay: Das hast du richtig verstanden! Ich habe am Ende der Antwort Fragen und Antworten hinzugefügt.
Azheglov
3
Ich wünschte, ich könnte zehnmal stimmen.
Daniel Daranas
12

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
Azheglov
quelle
Vielen Dank für Ihre Antwort. Ich denke, es muss eine Kultur sein - man kann Mitarbeiter nicht zwingen, Dinge zu erfinden. Ich war mir auch einig, dass es nicht von einem Komitee von Entwicklern eingerichtet werden kann - meine Erfahrungen stimmen sicherlich damit überein, also denke ich, die Frage wird, woher diese Kultur kommt. Atlassian hat dies ausprobiert, es muss also eine Managemententscheidung gewesen sein. Denken Sie, dass dies nur funktionieren kann, wenn es von Anfang an im Zentrum der Unternehmenskultur steht?
dannywartnaby
Im Falle von Atlassian kam die Entscheidung von oben, aber ich denke, sie hatten die richtigen Mitarbeiter, die Entwickler, die bereit dafür waren. Dennoch berichtet dieser Blogeintrag: blogs.atlassian.com/developer/2009/02/… über einige Probleme bei der Implementierung und obwohl sie sagten, dass sie ihr Experiment fortsetzen würden, haben sie die Öffentlichkeit in mehr als einem Jahr nicht auf den neuesten Stand gebracht Ein Jahr und ein Halbes. Ich bleibe dran.
Azheglov
6

" 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.

John Dibling
quelle
1
Warum war es ein Problem, dass sie sich mehr mit ihrer Hauptkompetenz befassten? Es hört sich so an, als wären sie froh, Dinge zu implementieren, die (vermutlich) erledigt werden mussten, aber nicht. Nicht jeder wird leidenschaftlich gerne ständig neue und innovative Dinge ausprobieren, und ich denke, es wäre ein Fehler, diese Einstellung durchzusetzen.
Matt Olenik
Ich würde nicht sagen, dass es genau ein Problem war. Ich denke nur, dass sie an dem Produkt gearbeitet haben, weil sie sich zurückgehalten haben, etwas Außergewöhnliches herauszusuchen. Dies lag zum Teil daran, dass ich nicht ausreichend erklärte, dass die in Frage kommende Problemdomäne alles war.
John Dibling
Wirklich nützliche Antwort John, danke. Es ist interessant, dass Sie festgestellt haben, dass der Mangel an Anleitung und die relative Freiheit, Arbeit zu erfinden, einen Faktor dafür darstellten, dass einige Entwickler 20% der Zeit nicht arbeiteten, da dies das Herzstück des Konzepts darstellt. Ich denke, einige Entwickler müssen nur ein klares Ziel haben, um das Beste aus ihnen herauszuholen. Ich denke, die Kultur könnte lauten "20% Ihrer Zeit damit verbringen, etwas zu erschaffen, aber wenn Sie es nicht können, ist das in Ordnung, vielleicht nutzen Sie die Zeit, um etwas besser zu machen - es muss nicht Ihr aktuelles Projekt sein".
Dannywartnaby
Das ist seltsam, ich bin zum ersten Mal in einem Buch auf den Begriff "Skunk Works" gestoßen, das ein hochwertiges, aber kostengünstiges Projekt beschrieb, das als geheimes Haustierprojekt für einen Entwickler begann und später die Richtung der Organisation komplett änderte.
Spoike
4

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.

Attila O.
quelle
3

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.

Chris
quelle
Ich denke, dass dies für die meisten Unternehmen zutrifft - ich habe in der Vergangenheit sicherlich erlebt, dass das Zeigen von coolen Dingen für das Management / Marketing bestimmte Möglichkeiten eröffnet und neue Projekte schafft -, aber jeder Versuch, diese Zeit "offiziell" für das Streben nach Neuem und Weiterem verfügbar zu machen Denkideen fallen sehr flach, sehr schnell. Sie haben "Freizeit" erwähnt - liegt diese Zeit außerhalb Ihrer Arbeit oder innerhalb unserer? Darf ich auch fragen, wie groß Ihre Abteilung ist? (Wie viele Entwickler und wie viele engagieren sich dafür?)
dannywartnaby
Diese Projekte werden normalerweise zwischen gecharterten Projekten gestartet. Unser Team ist ein kleines Team (3-7 Entwickler). Und es kommt auf das Projekt an, das sich daran beteiligt. Manchmal mache ich diese Dinge zu Hause zum Spaß, wenn ich eine neue Technologie erlernen möchte, manchmal, wenn es etwas ist, das ich ziemlich schnell prototypisieren kann, ohne die meisten Details herauszuarbeiten, werde ich genau das tun.
Chris