Pytanie:
Jak firma może wdrożyć program „20% czasu”, taki jak Google?
Reinstate Monica - Goodbye SE
2012-04-13 02:03:46 UTC
view on stackexchange narkive permalink

Czytałem, że zasada Google 20% dotyczy zachęcania do zabawy i innowacji.

W jaki sposób moja firma może wdrożyć taki program i zarządzać nim?

Dobra odpowiedź na to pytanie powinna również obejmować następujące pytania podrzędne:

  • Jakie są granice dla tych 20% czasu?
  • Co się dzieje jeśli muszę przepracować 40 godzin, aby zakończyć projekt na czas?
    Czy w takim razie spodziewałbym się, że przeznaczyłbym dodatkowe 10 godzin na „zabawę”?
    Czy mogę po prostu spędzić 16 godzin w następnym tygodniu? Jeśli opuszczę tydzień, czy po prostu stracę 20% godzin?
Bardzo powiązane: [Today is Goof off at work day] (http://www.codinghorror.com/blog/2012/08/today-is-goof-off-at-work-day.html), artykuł na blogu 20% czasu autorstwa Jeffa Atwooda.
Właściwie Google odchodzi od 20%. Jeśli czytasz ich oficjalne propozycje, nie rozmawiają już o tym i nie jest to tak zachęcające, jak było.
Być może dlatego nie wydają się tak innowacyjne jak kiedyś?
Siedem odpowiedzi:
#1
+38
Hrafn
2012-04-21 03:28:37 UTC
view on stackexchange narkive permalink

Mogę podać trochę informacji na ten temat, opierając się na tym, w jaki sposób moja firma wdrożyła to rozwiązanie i jak sobie radziliśmy.

W mojej firmie wdrożyliśmy to jako narzędzie rekrutacyjne i sposób na utrzymanie umiejętności inżynierów ostry. Istnieją również potencjalnie interesujące powody, aby nie dopuścić do zbytniego wzrostu wykorzystania, aby ułatwić przełączanie kontekstów. Ta odpowiedź zawiera również kilka dobrych wskazówek dotyczących około 20% czasu i kilka dodatkowych odniesień, które dodatkowo potwierdzają jego punkt widzenia.

Nie opieramy tego, co robimy, na wymienionych tam punktach, ale myślę, że warto się nad tym zastanowić, jeśli próbujesz wdrożyć swój własny 20% czas w firmie.

Mamy kilka podstawowych wskazówek dotyczących tego, na co można przeznaczyć 20% czasu ludzi. Powinno to być coś, co generalnie przyczynia się do rozwoju firmy (w tym do kultury, którą staramy się budować) lub do własnego rozwoju zawodowego. Więc spędzanie czasu na nauce nowego języka programowania jest niesamowite, a poświęcanie czasu na naukę gry na gitarze już nie.

Prowadzimy również regularne prezentacje, a jeśli nie masz czasu, musisz również przedstawić prezentację dotyczącą tego, nad czym pracujesz. Dzięki temu 20% czasu jest wydajne. Niektóre rzeczy, które okazały się szczególnie przydatne w 20% czasu:

  • Prototypowanie pomysłów lub zabawa z technologiami, których nie jesteśmy jeszcze gotowi do wprowadzenia do produkcji.
  • Doskonalenie umiejętności.
  • Rekrutacja wspaniałych ludzi.
  • Daj inżynierom możliwość stworzenia skutecznych dowodów koncepcji, które mogą uzyskać wsparcie na poziomie produktu.

Jeśli chodzi o alokację, próbowaliśmy kilku różnych rzeczy.

Czas w tygodniu

Pomysł jest taki, że 1 dzień w tygodniu jest przeznaczony na projekty poboczne. Zasadniczo podejście do problemu „jeśli przeznaczasz 20% na piątek w każdym tygodniu”. Najpierw wypróbowaliśmy tę implementację i napotkaliśmy kilka bezpośrednich problemów:

  • Wiele ciekawych wyzwań nie sprzyja jednodniowej pracy. Samo zapoznanie się z tym, co robisz, zajmuje tyle czasu.
  • Jeśli wykonałeś jakieś zadanie z niewielkim opóźnieniem, nie wziąłeś tego… co często oznaczało, że nigdy nie zajmowałeś 20% czasu . Przewracanie się było problematyczne, ponieważ szczerze mówiąc, jeśli śledzisz go za pomocą arkusza czasu na tym poziomie, coś poszło nie tak.
  • Niezbyt przewidywalne z punktu widzenia planowania, ponieważ chociaż piątki były powszechne, nie były one uniwersalne i nie wiedziałeś, kto będzie je przyjmował, ani czy faktycznie to przyjmą.
  • Pomogło to bardziej w planowaniu, ponieważ pomogło ludziom zapobiec nadmiernemu zwiększaniu szybkości osobistej, jeśli włączyli automatyczny 20-procentowy bufor.
  • W większości nigdy nie był używany.

Jedna iteracja na pięć

Przez długi czas pracowaliśmy poza dwutygodniowymi iteracjami. Tak więc następną realizacją pomysłu było wydanie jednej iteracji na pięć pracując nad dowolnymi projektami pobocznymi. Działało to dość dobrze - znacznie lepiej niż poprzednia wersja. Kilka uwag:

  • Dzięki temu rzeczy były bardzo przewidywalne z punktu widzenia produktu. Wiedziałeś dokładnie, jakie tygodnie stracisz, i mogłeś odpowiednio to zaplanować.
  • Z drugiej strony konflikty w harmonogramie były częste, ponieważ zespół miał zaplanowane wydanie tydzień później i musiał uzyskać próbne wdrożenia lub Przeprowadzono testy w ostatniej chwili. Dlatego często poruszaliby się w swoim harmonogramie i mogli łatwo zakłócić czyjś 20% czas z powodu potrzeby ich doświadczenia w zakresie wdrażania lub kodu.
  • To naprawdę nie pomogło w wykorzystaniu problem.
  • Zespoły, które nie miały idealnie zsynchronizowanych iteracji (żaden z nas tego nie robił), nie mogły tak naprawdę efektywnie współpracować przy większych lub bardziej interesujących projektach.

Jeden Tydzień z pięciu

Następnie zaczęliśmy przechodzić na system Kanban i myśleliśmy w tygodniach zamiast iteracji, więc przeszliśmy od 1 iteracji na pięć do jednego tygodnia na pięć.

  • Konflikty z wdrożeniami występowały częściej (częstotliwość), ale generalnie generowały mniejszy wpływ, ponieważ łatwiej było zablokować tydzień niż zablokować dwa tygodnie.
  • Ponieważ wszyscy pracowali tydzień po tygodniu, łatwiej było zsynchronizować się z innymi zespołami.

Poza tym było bardzo podobne do jednej iteracji na pięć.

Bloki czasowe na kwartał

To jest obecny system, który próbujemy. Pomysł polega na tym, że na tablicach Kanban konfigurujesz zadania dla siebie z ilością czasu przeznaczonego na nie, którą otrzymujesz za kwartał. Czas nie płynie między ćwiartkami, ale możesz wziąć to wszystko z góry lub na koniec lub w mniejszych fragmentach, jak uznasz za stosowne. Pozwala to poszczególnym osobom i zespołom dowiedzieć się, co będzie dla nich najlepsze na podstawie ich harmonogramu wydań, a także poświęcić czas w odstępach mniej więcej tygodniowych w zależności od ich harmonogramu, tego, co próbują zrobić itp. >

To rozwiązuje wiele problemów, które napotkaliśmy wcześniej, ale ma tę wadę, że czas musi być ściślej zarządzany i trudniej jest go precyzyjnie przewidzieć. Z drugiej strony może mieć mniejszy poziom zakłóceń.

#2
+21
jcmeloni
2012-04-21 20:28:06 UTC
view on stackexchange narkive permalink

Mam doświadczenie w pracy w organizacjach, które wdrożyły coś w rodzaju „20% czasu” (nawet jeśli było to tylko „10% czasu”) i zamierzam to wdrożyć w firmie, do której właśnie dołączyłem.

Odpowiedź na pytanie, jak brzmi „ostrożnie”. Nie ma to być złośliwa odpowiedź, ale raczej prawdziwa odpowiedź na szerokie pytanie, w którym nie znamy szczegółów Twojej firmy. Przez „ostrożnie” mam na myśli:

  • przy wsparciu przełożonych lub przynajmniej milczącym zrozumieniu tego, co się dzieje
  • konsekwentnie (nie wdrażaj programu, a następnie zabierz to natychmiast)
  • udzielając wsparcia tym, którzy tego próbują (nie oczerniaj produktu pracy i celebruj wynik)
  • ze zrozumieniem, że na początku możesz zobaczyć mniej bezpośrednich korzyści (lub wyników) dla projektów, do których ludzie są oficjalnie przypisani

Prowadzi to do pytania, którego tak naprawdę nie zadałeś, a mianowicie, dlaczego po co to robić w pierwszej miejsce ? Zrozumienie „dlaczego” kryje się za tym, dzięki czemu poniższe odpowiedzi na pytania podrzędne będą miały więcej sensu.

Jakie są granice dla tych 20% czasu?

Cokolwiek chcesz, to w jakiś sposób ulepsza produkty firmy lub jej zasoby (np. Ty).

Co się stanie, jeśli będę musiał pracować 40 godzin, aby zakończyć projekt na czas? (itp)

Jeśli nie masz czasu na spędzenie czegoś dodatkowego, nie rób tego.

Jeśli spojrzysz na pierwszą linię Artykuł w NY Times, do którego masz link, mówi: „Inżynierowie są zachęcani , aby poświęcali 20 procent swojego czasu na pracę nad czymś związanym z firmą, co ich osobiście interesuje”. Podkreśl moje.

Zachęcam. Nie wymuszony. „20% czasu” nie dotyczy „obowiązkowej zabawy” ani „dodatkowej pracy wykraczającej poza Twoje rzeczywiste zadanie”. Jest dobrowolne i polega na odkrywaniu i zachęcaniu do motywacji w miejscu pracy.

Warto zauważyć, że nie jest to coś, co wymyślił Google - karteczka powstała na początku lat 70., ponieważ pracownik firmy 3M wykorzystał swój „15% czasu” na wymyślenie tego.

Daniel Pink, autor Drive: The Surprising Truth About What Motivates Us , koncentruje dyskusję na temat motywacji pracowników na trzech czynnikach: potrzebie autonomii (chęć kierowania naszymi własne życie), mistrzostwo (chęć doskonalenia się w czymś, co ma znaczenie) i wiele przykładów „20% czasu” lub dni FedEx firmy Atlassian, które są 1,5-dniowymi wydarzeniami mającymi na celu wspieranie kreatywności, drapanie , czerpać przyczepność z radykalnych pomysłów i (w końcu) dobrze się bawić, u ich podstaw leży chęć uczynienia szczęśliwszych, bardziej zmotywowanych i zaangażowanych pracowników, mając świadomość, że inwestycja przyniesie lepsze efekty w pozostałych 80 czas, jeśli to są rzeczy, które Ci odpowiadają .

Wracając do pierwotnego pytania „jak firma to robi”? Wracam do mojej odpowiedzi „ostrożnie”, ale dodałbym też „z zapałem!”

To świetna odpowiedź!
#3
+8
Jim In Texas
2012-04-16 21:09:05 UTC
view on stackexchange narkive permalink

Pracuję w firmie, która uważa się za „miejsce pracy zorientowane na wyniki”, czasami nazywane „ środowiskiem zorientowanym na wyniki”.

Zespół ROW odrzuca fabryczny model zatrudnienia w którym menadżerom i brygadzistom płaci się za jeżdżenie stadem po hali fabrycznej owiec jak dzieci, którym nie można ufać.

[Na marginesie: w USA kontrahenci zbrojeniowi są w dużej mierze zmuszani do tayloryzmu przez wymagania kontraktów rządowych. Może to odpowiadać za typowe, ogromne przekroczenia kosztów i częste spóźnione terminy dostaw.]

Środowisko pracy modelu fabrycznego jest czasami nazywane „taylorizmem”, na cześć Fredrick W Taylor.

Zespół oprogramowania pracujący w strukturze typu Taylora nie byłby w stanie wdrożyć koncepcji Google 20%, samo śledzenie czasu byłoby bardzo kosztowne i rozpraszające. Ponieważ wiele, prawdopodobnie większość, z 20% projektów nigdy nie przynosi krótkoterminowych zysków, firma w stylu Taylora nie kontynuowałaby eksperymentu zbyt długo.

Nigdy nie pracowałem w Google, ale podejrzewam, że są Organizacja typu ROW. Podejrzewam, że programiści Google współpracują z liderami swoich zespołów, aby opracować harmonogram oczekiwanych rezultatów, który uwzględnia 20% projektów deweloperów. Podejrzewam, że dopóki programista dostarcza wyniki mniej więcej zgodnie z ustalonym (nie narzuconym) planem, nie ma obawy o to, ile czasu ktoś zajął na lunch lub czy spędził w zeszłym tygodniu 9 godzin nad swoim 20% projektem .

Czad - zredagowałem oryginalne pytanie, aby umożliwić spekulacje, ponieważ w przeciwnym razie tylko kierownictwo Google mogło na nie odpowiedzieć. Mam nadzieję, że wydaje się to uzasadnionymi spekulacjami, ponieważ moja organizacja, choć nie ma formalnej polityki 20%, daje pracownikom dużą swobodę osobistą eksperymentowania i uczenia się w czasie pracy.
W porządku, Chad, ale jak napisano, nikt inny niż menedżer Google nie ma na to odpowiedzi. Pytanie powinno być sformułowane w taki sposób, aby pracownicy spoza Google mogli w jakiś sposób odpowiedzieć. Oznacza to, że odpowiedzi będą wymagały „spekulacji”, niezależnie od tego, czy lubimy to słowo, czy nie.
„Jak można to skutecznie wdrożyć”, gdy taki plan * najwyraźniej został * nie powinien odpowiadać „Nie, nie możesz tego zrobić”.
Cieszę się, że wspomniałeś o taylorizmie. Na YouTube jest o tym świetny dokument, spróbuję go znaleźć dziś wieczorem.
#4
+3
HLGEM
2012-04-16 23:54:40 UTC
view on stackexchange narkive permalink

Spróbuję odpowiedzieć na to pytanie:

Albo jak organizacja programistyczna mogłaby wdrożyć podobną koncepcję „projektu 20%”, która byłaby do przyjęcia dla kierownictwa, klientów i pracowników.

Jak widzę, wdrożenie takiej rzeczy w miejscu pracy wymagałoby pokonania kilku przeszkód. Musisz zdać sobie sprawę, że jest to decyzja biznesowa, a zatem musi być czymś, co można sprzedać kierownictwu wyższego szczebla pod względem biznesowym.

Po pierwsze, w jaki sposób płaca się obecnie dewelopera? Jeśli, tak jak w miejscu, w którym pracuję, większość czasu dewelopera jest obciążona projektami klienta, 20% czasu spędzonego na pracy niepodlegającej rozliczeniu będzie trudną sprzedażą. Pieniądze na wypłatę tych pensji muszą skądś pochodzić, a każda propozycja, aby to zrobić, będzie musiała określać skąd. Widzę trzy podstawowe wybory: firma pobiera to z bieżących zysków, firma podnosi stawkę godzinową naliczaną klientom, aby móc za nią zapłacić lub firma zapisuje zmienione godziny klientowi o 20% (co może lub nie być legalne). Jeśli nie wykonujesz pracy płatnej przez klienta, pierwszy wybór jest jedynym wyborem. Jeśli to zrobisz, druga strona może być opłacalna, jeśli (i jest to duże jeśli) jest mało prawdopodobne, że stracisz klientów, gdy podniesiesz stawki. Wydaje mi się, że trzecia opcja nie jest do końca wykonalna i nie sugerowałbym jej, chyba że wiedziałbym, że jest legalny.

Jednak aby sprzedać propozycję, musisz pokazać, co dostaną za te pieniądze. Jest podobny do R&D w firmie farmaceutycznej. To duże ryzyko i duży koszt z potencjalnie ogromną korzyścią. Ale jak ustalić, czy przyniosło to korzyści? Cóż, tam musisz śledzić osobiste projekty. Jeśli więc proponujesz coś takiego, upewnij się, że opracowałeś system dla osobistych projektów, które są wdrażane, aby można je było śledzić i śledzić oszczędności lub nowe zyski z nich.

Będziesz musiał oszacować potencjalne korzyści w kategoriach biznesowych. Porozmawiaj o zdolności do przyciągania najlepszych talentów, niższych kosztach dzięki wyższemu zatrzymaniu pracowników i oczywiście o potencjalnych zyskach omówionych powyżej.

Następnie musisz pokazać, w jaki sposób godziny zostaną wykorzystane i jak planowanie projektu będzie musiało zostać dostosowane, aby uwzględnić czas. Oznacza to, że terminy odejdą, co znowu nie jest łatwą sprzedażą. Sugerowałbym, że najbardziej sensowne byłoby użycie do 20% godzin naliczanych w miesiącu, a tydzień w tygodniu. I tak, gdybyś tego nie zrobił w tym miesiącu, straciłbyś go, chyba że w nadzwyczajnych okolicznościach, o których decyduje pojedynczo kierownictwo. Możesz również rozważyć umieszczenie części lub całego czasu jako okresu odpoczynku między dużymi projektami. Nieco łatwiej jest powiedzieć klientom zewnętrznym, że żaden z nich nie będzie dostępny do 1 czerwca, a projekt zajmie 40 dni roboczych, niż powiedzieć im, że rozpocznie się 15 maja i zajmie 48 dni roboczych. Część tego wymagałaby rozważenia sposobu, w jaki obecnie prowadzisz interesy. Zespoły przeważnie pracujące w trybie konserwacji nie miałyby tak łatwego do zdefiniowania czasu przestoju, ale przy krótszych projektach prawdopodobnie łatwiej jest znaleźć godziny w trybie tygodniowym.

Musisz również odpowiedzieć na pytanie: Czy my kup więcej osób lub przesuń terminy, aby uwzględnić dodatkowe 20%.

#5
+2
mhoran_psprep
2012-04-16 17:11:41 UTC
view on stackexchange narkive permalink

Najlepszą odpowiedzią na to pytanie jest firma, która stosuje te zasady, ale pracowałem z niektórymi organizacjami, które próbowały z nich korzystać, ale ich nie udało się.

  • W ciągu 40 godzin w tygodniu roboczym, 8 godzin nie zostanie wykorzystanych na wygłupy, ale na produktywne wygłupywanie się. W jednej organizacji ilość dokumentacji wymaganej dla tych 20% oznaczała, że ​​4 godziny z tego zostały stracone na papierkową robotę.

  • Jedna grupa oczekiwała od pracowników, że poświęcą 60 godzin tygodniowo, dlatego nikt nie wiedział, czy ma to być 48 godzin pracy i 12 godzin eksperymentowania; lub 60 godzin pracy, a następnie eksperymentowanie pod koniec tygodnia.

Pomysł, że firma lub pracownik ma śledzić godziny pracy, aby można go było wykorzystać do wyrównania obciążenia, brzmi jak koszmar administracyjny. Oznacza to również, że pracownik wie, że kierownictwo śledzi czas i decyduje, w jakie projekty warto się bawić.

Jeśli nie brzmiało to zabawnie lub przynajmniej mniej stresująco w porównaniu z innymi projekty, nie byłbym tym zainteresowany.

Jakoś wątpię, że Google faktycznie zabija połowę 20% czasu z papierkową robotą. Która firma wymagała takiego poziomu dokumentacji i dlaczego miałaby ona być wymagana?
Wymagała tego grupa, która przeczytała artykuł o polityce Google, ale tak naprawdę byli mikro-menedżerami.
Micromanage! = Google. Nie odebrałbym tego jako znaku wbrew zasadzie 20%, tylko niekompetentna firma.
Jeśli celem firmy jest maksymalizacja kwartalnych zysków poprzez minimalizację kosztów pracy, to oczywiście 20-procentowa głupota byłaby niezrozumiała dla kierownictwa lub pracowników. Z drugiej strony, gdyby firma miała politykę projektowania środowiska pracy, najlepszych pracowników na świecie, aby wprowadzić długoterminową dominację w ich branży, wtedy 20% „głupoty” wydawałoby się niewielką ceną do zapłacenia.
@JimInTexas Powiedziałbym, że to bardziej złożone, 100% czasu pracy nie oznacza 100% czasu produktywności. Projekty Google „Goof off” również czasami zamieniają się w prawdziwe produkty (obecny projekt Google Play to czas „Goof Off”). Myślę, że wiele osób tutaj nie rozumie zasad Google i tego, co tak naprawdę się dzieje.
-1, ponieważ wyjaśniasz, jak niekompetentna firma mogłaby to zrobić, a nie jak właściwie to wdrożyć.
Muszę -1 to z tych samych powodów, dla których zrobił to Rarity.
#6
+1
Thaddeus Howze
2012-04-20 03:29:53 UTC
view on stackexchange narkive permalink

Wszystkie pomysły, które pojawiły się przed tym, sprawiają, że odkładanie czasu na bok jest o wiele bardziej skomplikowane, niż powinno. 20% to jeden dzień dowolnego tygodnia. W ten sposób cztery dni spędzamy pracując nad „normalnymi” projektami. Jeden dzień w tygodniu przez cztery tygodnie poświęcamy na „inną”, bardziej inspirującą pracę. Wypróbuj ten proces dla rozmiaru.

  1. Wygląda na to, że pomysł został sprzedany przełożonym. Jeśli tak, nie ma tam pracy do wykonania.
  2. Jeśli chcesz wdrożyć projekt, rób to na zasadzie 20% jednego dnia w tygodniu.
  3. Piątego dnia okresu (4 piątki z rzędu, w 5. piątek) Przedstaw pracę.
  4. Szósty piątek, wybierz najbardziej niesamowity projekt. Dodaj go do kolejki dopracowywania.
  5. Następne cztery piątki pracuj nad rozwojem projektu i zdecyduj, czy projekt ma prawdziwą wartość.
  6. Jeśli tak, dodaj go do podstawowego harmonogramu pracy jako projektu i pracuj nad wersją alfa.
  7. Zademonstruj wersję alfa i zdecyduj, czy chcesz pójść dalej. Zachowaj listę innych mniej wartościowych projektów do rozważenia. Prawdopodobnie drugie miejsce w wybranym projekcie może otrzymać taką samą uwagę.
  8. Jeśli projekt zostanie wybrany do dalszego rozwoju, dodaj go do kolejki rozwoju. Poczekaj miesiąc, aż projekt się ustabilizuje, przepłucz i powtórz.
  9. Powinieneś być w stanie to zrobić co najmniej cztery razy w roku.
  10. „Niepowodzenia” oznacza projekty poza pierwszymi wybranymi 8 zawsze można przejrzeć i poprawić później.
#7
+1
Scott Stevens
2013-01-11 05:47:31 UTC
view on stackexchange narkive permalink

Zgadzam się z innymi uwagami, że należy to zrobić bardzo ostrożnie. Myślę, że powinieneś dążyć do następujących:

1) zrównoważonych celów . Chcesz, aby Twoi pracownicy pracowali nad projektami, które mogą przynieść korzyści Twojej firmie, jednak niekoniecznie chcesz przejmować zbyt dużą kontrolę nad tym, co zdecydują zrobić w tym czasie. Jeśli powiesz im, nad czym mogą pracować, zobaczą, że nie różni się to niczym od dodania kolejnego projektu na talerzu.

2) Normalne godziny . Jeśli twoje zasady 20% są prawidłowo wdrożone, są szanse, że Twoi pracownicy będą pracować nad nimi poza godzinami pracy. Jednak nie wymagałbym tego. W pewnym stopniu zbiega się to z posiadaniem „zrównoważonych celów”. Jeśli powiesz swoim pracownikom, nad czym mają pracować w ciągu 20% czasu, oprócz ich obecnego czasu, zobaczą, że minął fantazyjny żargon i zobaczą, że jest to przymusowa praca w nadgodzinach. Należy to zrobić jasne jest jednak, że ich zwykłe obowiązki zawodowe mają pierwszeństwo. Będziesz musiał ciężko pracować, aby upewnić się, że ich normalna praca jest dławiona w taki sposób, że nie narusza ich 20% czasu tak bardzo, jak jest to realistyczne. Dodałbym ponadto, że jeśli masz problemy z zatrudnianiem pracowników tylko przez swój związek zawodowy 40, kiedy jest jeszcze dużo pracy do wykonania, istnieje duża szansa, że ​​masz problem z morale. Zadowoleni pracownicy poświęcą czas na wykonanie pracy.

3) uznanie . Musisz rozpoznać pracę włożoną przez twoich pracowników. Upewnij się, że rozpoznajesz sukces, ciężką pracę, a także innowacje. Nie każdy pomysł, jaki mają, będzie domem. Ale musisz zachęcić do udziału. Muszą zobaczyć, że cenisz ich pomysły i wkład.

4) Zabawa . Chcesz, aby Twoi pracownicy dobrze się przy tym bawili. Jest to dla nich sposób na uwolnienie intelektualnej pary, rozmowę z innymi działami i grupami, z którymi normalnie nie mogą wchodzić w interakcje, i odkrycie problemów lub pomysłów, o których istnieniu nie zdawali sobie sprawy. To ćwiczenie nie tylko dla inżynierów oprogramowania, ale także dla ludzi biznesu. Często zdarza się, że brakuje komunikacji między stroną oprogramowania a stroną biznesową. Ludzie zajmujący się oprogramowaniem tworzą rozwiązania, których biznes nie potrzebuje, a potrzeby biznesowe nie mają pojęcia, że ​​istnieją rozwiązania programowe dla problemów, z którymi borykają się każdego dnia. Daj szansę obu stronom na komunikację ze sobą, a koła zębate w ich głowach zaczną zgrzytać.

5) informacja zwrotna . Generalnie Twój przebieg może się różnić. Myślę, że ostatecznie najważniejszym zasobem dla Ciebie są sami pracownicy. Nie tylko zbieraj opinie online ze stosu. Poproś pracowników o opinie. Docenią, że ich poprosisz, i docenią szansę znalezienia sposobu na robienie rzeczy, które będą z nimi działać. Ostatecznie reguła 20% to moim zdaniem maszyna do podnoszenia morale, generowania pomysłów i spłaszczania organizacji. Myślę, że pomaga to wyeliminować biurokrację, z którą zmaga się wiele kultur korporacyjnych. Jeśli istnieją wyzwania, przed którymi stoi Twoja firma, prawdopodobnie jest ktoś, kto mógłby je rozwiązać. Może nie być osobą, której oczekujesz. Posłuchaj swoich pracowników i znajdź to, co działa dla Ciebie.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...