Przedstawiamy „20% czasu” w miejscu pracy [zamknięte]

20% czasu to kultura pracodawcy, która pozwala pracownikom spędzać 20% czasu na pracach nad projektami, które uznają za interesujące - może to być wynalezienie nowej aplikacji lub ulepszenie istniejącego procesu itp. Niektóre osoby mogą to wiedzieć jako skunks pracować, jednak ten termin nie może oznaczać dla ciebie nic (lub czegoś zupełnie innego).

Istnieje wiele udokumentowanych przypadków, w których wspaniałe produkty rodzą się z 20% / pracy skunksa w firmie. Wydaje się, że sytuacja jest wygrana / wygrana; firma potencjalnie zyska świetny nowy produkt lub aplikację, a programista ma okazję napiąć swoje kreatywne mięśnie i wprowadzić innowacje.

Wielokrotnie próbowałem wprowadzić jakąś formę 20% / Skunk pracującą u mojego poprzedniego pracodawcy bez powodzenia.

Jak lepiej uzasadnić to kierownictwu? Jaki jest „właściwy” sposób podejścia do tego rodzaju pracy?

Głównym powodem 20% czasu jest utrzymanie wykorzystania mocy na poziomie 80%, a nie 100%.

Można myśleć o organizacji opracowującej oprogramowanie jako o systemie, który przekształca żądania funkcji w funkcje rozwinięte. Możesz modelować jego zachowanie za pomocą teorii kolejkowania .

TEORIA

Jeśli żądania przychodzą szybciej niż system może je obsłużyć, ustawiają się w kolejce. Gdy przyjazdy są wolniejsze, rozmiar kolejki zmniejsza się. Ponieważ procesy nadejścia i obsługi są losowe, rozmiar kolejki zmienia się losowo z czasem.

Skłonni matematycznie mogą zapytać o tę „losowość”: musi istnieć pewien rozkład prawdopodobieństwa, więc jaki będzie średni rozmiar kolejki? Matematyka (teoria kolejkowania) ma na to odpowiedź: jeśli zarówno procesami przybycia, jak i usługami są Markow, to N = rho ^ 2 / (1-rho).

(Gdzie rho jest współczynnikiem wykorzystania równym stosunkowi usług i stawek przybycia. Jeśli procesy nie są Markowskie, matematyka jest bardziej skomplikowana, ale nie zmienia wniosków.)

Jeśli wykreślisz tę funkcję, zobaczysz, że średnia długość kolejki pozostaje niska, podczas gdy wykorzystanie wynosi do 0,8 , a następnie gwałtownie wzrasta i przechodzi w nieskończoność. Możesz to zrozumieć intuicyjnie, myśląc o procesorze komputera: gdy jego wykorzystanie zbliży się do 100%, komputer przestaje reagować.

ĆWICZYĆ

Ekonomika tworzenia oprogramowania jest taka, że ​​firmy produkujące oprogramowanie ponoszą duże koszty, gdy ich kolejki znajdują się w stanach wysokiej kolejki. Obejmuje to utracone możliwości rynkowe, przestarzałe produkty, spóźnione projekty i marnotrawstwo spowodowane przez tworzenie funkcji w oczekiwaniu na popyt.

Czas 20% jest zatem naukową odpowiedzią na problem optymalizacji wyników ekonomicznych: unikaj stanów stojących w kolejce, unikając powodujących je wskaźników wykorzystania. Zasadniczo to luz powoduje, że system reaguje.

Natychmiast wyciągnięto kilka praktycznych wniosków:

• jeśli bierzesz pod uwagę 20% czasu i rozliczasz koszty (czas programistów kosztuje X, ale / a firma nie może sobie na to pozwolić), robisz to źle.
• jeśli przeznaczasz 20% na piątek co tydzień, robisz to źle
• jeśli tworzysz system składania / oceny / zatwierdzania propozycji projektu w czasie 20%, robisz to źle
• jeśli wypełniasz karty czasu pracy, robisz to źle
• jeśli używasz innowacji jako motywatora przez 20% czasu, robisz to źle. Chociaż nowe produkty powstały z 20% projektów, nie o to chodziło. Jeśli Twoja firma nie może wprowadzać innowacji w godzinach pracy, to jest problem!
• 20% czasu to nie kreatywność. Nie mów, że uwolnisz swoją kreatywność z czasem 20%, zapytaj, dlaczego nie jesteś wystarczająco kreatywny już w swoich podstawowych godzinach.

ODPOWIEDZI NA PYTANIA W KOMENTARZACH

Dan , masz rację i dokładnie opisałeś błąd popełniony przez wielu. Nie możesz wybrać procentu wykorzystania, ponieważ jest to zmienna wyjściowa. Jest to stosunek cech dwóch procesów, więc jest taki, ponieważ procesy są takie, jakie są. Organizacja ma wpływ na oba procesy; dopasowanie możliwości i popytu jest jednym z trudnych problemów, z którymi boryka się szczupły zespół programistów. Wykorzystanie jest jednym ze wskaźników, jak dobrze ten problem rozwiązano w organizacji. Slack pojawia się wraz z postępem inicjatywy lean i usuwasz odpady ze strumienia wartości. Ale jeśli zlecisz 20% czasu, skończysz w tej samej pułapce wykorzystania z mniejszą dostępną pojemnością.

Kim , nadal jest to po części kwestia kultury. Najbliższe odniesienie kulturowe, jakie mogę wymyślić, to synergiczny poziom tak zwanego modelu zmian organizacyjnych Marshalla . Pojawia się pod koniec udanych transformacji Lean lub jest obecny w organizacjach zbudowanych Lean od samego początku. ( Oto link do białej księgi Boba Marshalla (PDF) .)

REFERENCJE

Powyższa logika jest dobrze poparta w literaturze inżynierii oprogramowania. Mary i Tom Poppendieck wspomnieli o tym w książce z 2006 roku Implementing Lean Software Development . Donald Reinertsen w swojej książce „Principles of Product Development Flow” (rozdział 3) z 2009 r. Szczegółowo omawia ten temat za pomocą wzorów i wykresów.

Czternaście miesięcy po napisaniu tej odpowiedzi wymyśliłem znacznie lepszą .

Nie pracowałem w miejscu, w którym takie prace zostały oficjalnie uznane. Ale z moich rozmów i prób zdobycia wiedzy na temat tej praktyki znalazłem to - cóż, głównie to, czym nie jest „czas 20%”:

• to rzeczywiście kultura, a nie polityka
• kierownictwo wyższego szczebla nie może tego zarządzić
• nie może być ustanowiony przez komitet programistów
• nie ma na to 32 godzin i 8 godzin

„ Skunkworks ” to nie to samo, co 20% czasu. 20% czasu to, jak powiedziałeś - czas, w którym deweloper sam decyduje, nad czym ma pracować. Skunkworks jest zupełnie inna. Projekt skunkworks to wysokowartościowy, kosztowny projekt, nad którym pracuje zespół (często zespół odłamków guru), który nie jest zgłaszany wyższemu kierownictwu, a zespół sam decyduje o tym, jak projekt powinien przebiegać bez kierownictwa . Projekty te są często motywowane potrzebą taktyczną lub biznesową, aby coś zrobić, ale nie ma na to miejsca w budżecie. Jeśli coś musi zostać zrobione , zostaje zrobione - budżety niech będą przeklęte.

Zarządzałem zespołem programistów, w którym wdrożyłem 20% czasu. A przynajmniej próbowałem. Miałem aprobatę moich przełożonych, więc to nie był problem. Problem polegał na tym, że zespół był zbyt mały i zbyt wyspecjalizowany. Ilekroć pojawiały się problemy, które wymagały natychmiastowej interwencji, 20% czas był przerywany. To się często zdarzało.

Odkryłem również, że niektórzy z moich programistów uważali mój brak kierunku za niepokojący. Mimo że powiedziałem „pracuj nad wszystkim, co chcesz, pod warunkiem, że jest to związane z programowaniem”, nadal mieli trudności z zaakceptowaniem części „cokolwiek”. Myśleli, że niektóre projekty będą lepsze od innych, więc nieuchronnie pracowali nad niskopoziomowymi wnioskami o wdrożenie w głównym produkcie, takie rzeczy. Chciałem, żeby się rozgałęziły i rozwijały, ale zamiast tego kopały głębiej w swoją główną wiedzę.

Zrobiłbym to jeszcze raz, ale wyraźnie zabroniłbym pracy nad głównym produktem i mógłbym zacząć od kilku pomysłów na początek.

Pracuję dla startupu, który wdrożył zasadę 20%. To mój pierwszy pracodawca, który to zrobił, a kiedy wspomniał o tym na rozmowie kwalifikacyjnej, byłem naprawdę zaskoczony, ponieważ większość innych pracodawców starała się nie „marnować” ani godziny.

Dołączyłem do start-upu, kiedy powstawał i przez prawie rok byłem jedynym programistą. Spędziłem moje 20% z kilkoma rzeczami:

• Zgłaszanie / naprawianie błędów w losowych projektach open source - może to być tak małe, jak rozwiązywanie interesującego projektu na Github i poprawianie kilku literówek w dokumentacji.
• Pisanie „rzeczy” typu open source - na przykład wyzwania programistyczne, dla zabawy.
• Idąc na konferencje i sprinty - co kilka miesięcy chodziłem na sprint, gdzie mogłem pracować nad projektami (niektóre z nich mogą być wykorzystywane przez główną aplikację, inne nie) i zdobywać doświadczenie. Istnieje kilka bibliotek używanych przez naszą aplikację i aplikacje opracowane przez inne firmy, które wysyłają programistów na konferencje, więc może to być postrzegane jako bezpośrednia korzyść dla naszej firmy.
• Uczenie się nowych technologii - tak nauczyłem się Go , mimo że nie używamy jej w firmie. Jest to szczególnie zalecane przez mojego pracodawcę. Ostatnio śledzę niektóre bezpłatne zajęcia on-line w Stanford.

Czasy nie są dokładnie mierzone, zdecydowanie nie są to 32 + 8 godzin, czasami są pilne rzeczy do zrobienia, gdy po prostu nie ma wystarczająco dużo czasu, aby odciąć te 20%, innym razem mam więcej czasu do stracenia.

Pracuję zdalnie i używamy czatu Ognisko 37signal do komunikacji i luźnego śledzenia wzajemnej obecności, a te godziny są śledzone jako „godziny pracy”, jestem zalogowany na czacie i dostępny dla współpracowników, chociaż jasne jest, że nie pracuję teraz nad naszym projektem.

Z mojego małego doświadczenia wynika, że ​​wiele naszych projektów rozpoczęło się właśnie w ten sposób. Mieliśmy wolny czas i przepustowość do podjęcia nowych projektów, spotkaliśmy się i wymyśliliśmy potencjalne fajne / przyszłościowe pomysły dla naszego działu. W wolnym czasie opracowaliśmy prototyp, który po pewnym czasie został dopracowany, zaprezentowany na wyższym poziomie i zazwyczaj widzą korzyści.

Wydaje mi się, że wyższy poziom wie, czego chcą, jeśli to widzą, ale nie wie, że potrzebują / chcą tego, dopóki tego nie zobaczą. Prototypowanie pozwoliło nam tworzyć własne projekty, proponować je, a po zatwierdzeniu poświęcać im więcej czasu na ich ukończenie.