Dzień Pracy Własnej

6

Niedawno na fejsie zaprzyjaźniona białostocka firma DevCore.NET pochwaliła się, że u nich pracownicy mają DPW – Dzień Pracy Własnej. Zapachniało Guglem.

Chciałem tą informację po prostu zignorować i wyrzucić z głowy, jako że kwestia ta nie dotyczy mnie nawet w 1%. Ale jak to czasami bywa, w środku mi to utknęło i mózg sam zaczął ten temat mielić. Zastanowienie przyszło samo, zabierając cenne cykle mojego wewnętrznego procesora. Aby więc cykle te nie poszły kompletnie w piach, spiszę je sobie i opublikuję, jak to mam niekiedy w zwyczaju.

Wypada zastanowić się przez chwilę po co taki DPW w ogóle istnieje. Celem jest prawdopodobnie to, żeby pracownicy się nie wypalili i nie rzygali z nudy przekraczając próg biura. I dodatkowo: żeby po takim dniu byli lepsi niż przed takim dniem. Jeśli ktoś pracuje nad jednym projektem non stop, w kółko, przez X czasu, babrając się cały czas w tym samym, to może w końcu z tej stagnacji powiedzieć sobie “dość”. I wewnętrznie “pęc”. A nawet jeśli nie, to siłą rzeczy raczej stoi w zawodowym miejscu, rozwijając się ewentualnie po godzinach. Ale ilu programistów tak naprawdę to robi?

I tak oto dostając od pracodawcy dzień “gratis” może sobie dev jeden z drugim wziąć coś nowego, pobawić się, poznać alternatywy, zobaczyć co w trawie piszczy.

Tylko… co z tym dniem zrobić? Można puścić sobie wszystkich całkiem wolno, samopas, i powiedzieć “róbta co chceta”. Moim zdaniem warto jednak przykazać dodatkowo: “ale najpierw pomyślta”. Nie sztuka usiąść do komputera i, nawet opierając się pokusie spędzenia całego dnia w rozrywkowych internetach, czas ten kompletnie zmarnować i nic z niego nie wynieść. A byłoby szkoda. Jeśli ktoś faktycznie ma tylko jeden dzień na parę tygodni, aby się w którymś kierunku rozwinąć, to warto wykorzystać go w 100%.

Po pierwsze – ja bym taki dzień w jakiś sposób rozliczał. Przydałoby się, aby każdy zrobił małe podsumowanie tego, czego się nauczył. Może krótka, nawet 15-minutowa prezentacja przed zespołem, żeby wiedza się w firmie rozprzestrzeniała?

Po drugie – fajnie byłoby takie dni sensownie zaplanować. Tak, aby układały się w spójną ścieżkę. Skakanie każdego takiego dnia na całkowicie różne tematy raczej nie przyniesie wielkich korzyści, bo tego czasu jest zwyczajnie za mało.

Wątpię, aby taki dzień był przydzielany raz w tygodniu, to w końcu aż 20% czasu pracy. W tym przypadku DPW ma miejsce raz w miesiącu. Pierwsza moja myśl była: “to strasznie mało, co można zrobić przez jeden dzień w miesiącu?”. Ale teraz wydaje mi się, że to może wystarczyć. O ile zrobi się to z głową.

Ja widziałbym taki dzień w sposób następujący:

Unikamy sytuacji, w której każdy osobno coś sam sobie skrobie, w oderwaniu od reszty. Z powodu wymienionego wcześniej: w ciągu jednego dnia ciężko jest coś w pojedynkę zrobić. Mi, mimo tego, że na co dzień pracuję praktycznie sam, więc jestem do tego przyzwyczajony i mi z tym dobrze, napisanie nawet durnego serwisu który robi “redirect” pod wskazany URL zajęło tydzień. Dodatkowo jeśli kilka osób będzie coś robiło wspólnie to zmniejszamy pokusę spędzenia paru godzin na fejsie, twitterze, czy w poszukiwaniu nowych słitaśnych kaloszków na allegro (bo przecież muszę mieć w czym pójść na grzyby i dalej wyglądać sexi!). Taki wewnętrzny, firmowy hackaton!

Ale też raczej szkoda by było zespołowi z góry narzucać co ma robić, bo wtedy to już nie będzie praca “własna”. Moim zdaniem zespół wspólnie powinien zdecydować co chce danego dnia razem poznać, dojść do jakiegoś konsensusu. Najlepiej pod warunkiem: używamy jak najmniej narzędzi, z którymi mamy już doświadczenie. Czyli widziałbym na przykład takie zadanie postawione przed teamem: napiszcie w ciągu jednego dnia szkielet czata, którego będziemy wewnętrznie w firmie używali do komunikacji. Podczas kolejnych miesięcy będzie on doszlifowywany, aż w końcu wyjdzie z tego skończony projekt zrealizowany w nowych technologiach. W typowo “microsoftowym” software-housie technologiami/narzędziami mogłyby być: Git/Mercurial (zamiast TfuFS), Nancy/Fubu/Simple.Web (zamiast MVC/WebAPI), Simple.Data/Dapper/NH (zamiast Entity Framework), Postgre/MySQL (zamiast SQL Server), xUnit (zamiast MSTest). Do tego szczypta Angulara/Knockouta/Embera (którykolwiek nie jest jeszcze używany). I warto poznać też SignalR, jeśli jeszcze nie został w żadnym firmowym projekcie zastosowany.

To jest zdecydowanie do ogarnięcia w ciągu jednego dnia. Oczywiście nie w wielkich szczegółach, ale wspólnymi siłami można każdy komponent liznąć na tyle, żeby mieć choć jako-takie porównanie z softem używanym na co dzień.

Jeśli każdego miesiąca działałoby się z takim rozmachem, to raptem po paru miesiącach zabrakłoby narzędzi do poznawania! I wtedy można każde z nich dodatkowo pogłębiać, dodając ficzery do rozpoczętych projektów.

Co za tym idzie? Wzrost kompetencji firmy jako organizacji – bo teraz programiści byliby w stanie świadomie wybrać odpowiednie narzędzie pod dany projekt, bez trzymania się kurczowo tego czy tamtego “bo wszystko w tym piszemy”. Satysfakcja z pracy powinna również wystrzelić w górę, i wspólne oczekiwanie na te “własne” dni byłoby moim zdaniem czuć sporo przed ich nadejściem. Dyskusje przy korycie nabrałyby rumieńców – bo wreszcie każdy może pogadać o czymś nowym, a nie ciągle o klepaniu tego samego. Dodatkowo nawet w “prawdziwych” projektach być może udałoby się znaleźć zastosowanie dla nowej wiedzy, tym bardziej że każdy w jakiś sposób jest w stanie się swoimi wrażeniami podzielić.

Nawet więcej: czyż nie byłoby świetnym pomysłem założenie firmowego bloga, na którym zostałyby opisane takie przygody? Już widzę pierwsze akapity postów… “Na co dzień pracujemy z ASP MVC, a oto nasza opinia o Nancy”. “Tyle słyszy się o Angularze, poniżej poczytacie czego udało się nam, użytkownikom Knockouta, nauczyć w jeden dzień”. Albo: “Do tej pory pisaliśmy testy jednostkowe tylko na serwerze, a ostatnio poświęciliśmy cały dzień na zgłębienie tematu testowania Javascript z Jasmine, poniżej nasze wnioski”. Czy też, maj fejwrit: “W ostatni DPW daliśmy szansę Gitowi i Procent naprawdę ma rację, w porównaniu TfuFS to ścierwo i będziemy go od dziś bojkotować w codziennej pracy!”;).

Albo jeszcze lepiej: wszystkie te eksperymenty opublikować na GitHubie, i do nich z bloga linkować! No po prostu wypas, aż sam się napaliłem.

Wszystko miło, wszystko fajnie, ale zostaje jeszcze jedna dość przykra kwestia: a co z terminami, klientami, prawdziwymi projektami? Wprowadzanie takiego dnia na zabawy z technologią ma sens, jeśli faktycznie ów dzień będzie się regularnie odbywał. Znam przypadki, gdzie takie coś przetrwało parę miesięcy, a potem dostało trądu i padło. Bo przecież trzeba się zająć normalną robotą, wdrożenie czeka, klient się niecierpliwi, a my tu się sobie bawimy. Z tego powodu inicjatywa ta, o ile jak najbardziej godna pochwały, może być nieco kłopotliwa w realizacji. Jak można spędzić cały dzień na dev-igraszkach, skoro robota czeka i się nawarstwia? Nie można przecież oczekiwać, że z powodu tego jednego dnia wszyscy będą harować w weekend – wtedy już lepiej zorganizować takie coś w sobotę i liczyć na ochotników. Ja osobiście gdybym został zmuszony do uczestniczenia w DPW po to, żeby potem nocami nadrabiać, położyłbym na takim dniu różne rzeczy i po prostu zajął się pracą. Nie są to proste problemy. Dobra strona tych dylematów jest taka: nie ja muszę je rozwiązywać. Zła: ktoś musi.

Pod rozwagę zostawiam. I opinie, jak zwykle, chętnie poznam.

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

6 Comments

  1. Idea jak najbardziej słuszna, jednak jak to z ideami bywa sprawdzają się tylko w utopii;)

    Moim, zdaniem każdy programista ma listę TODO i jeśli firma decyduje się na wprowadzenie DPW to nie powinna nić narzucać. Ja osobisice wykorzystał bym taki dzień do poznania choćby z jednym tematem z mojej osobistej listy. To dałoby mi większą satysfakcje niż pisanie np. wspomnianego czatu, który byłby narzucony przez firmę, wkońcu poczułbym wolność;). Dobrym pomysłem jest, na koniec takiego dnia, aby każdy z zespołu powiedział czym się zajmował i morze zaprezentował małego sampla. Tym sposobem może np. team leader również zobaczył by coś nowego i zdecydował się nowo prezentowaną bibliotekę w kolejnym projekcie.

    Jednak, taki dzień może też przynieść odwrotny skutek. Programista może się dowiedzieć że tyle ciekawych frameworków jest na świecie a my tu ciągle .Net 2.0 i WinForms ;)

  2. To może kilka słów w imieniu “zaprzyjaźnionej firmy” :)
    Na naszym DPW pracownicy robią to, na co mają ochotę (musi to być jedynie związane z programowaniem i musi się to odbywać na miejscu w firmie) – tak więc mają szerokie pole do popisu. DPW jest planowane jak urlop – przykładowo do 5. dnia października, każdy określa w jaki dzień listopada chciałby mieć DPW, to jest akceptowane przez kierownika projektu / kierownika działu. W takim podejściu eliminujemy przypadki, że nagle nie ma komu projekt robić, albo ktoś sobie wziął DPW na deadline. I dodatkowo po zakończeniu DPW każdy pracownik jest zobowiązany podzielić się swoimi efektami pracy tworząc krótki wpis na Sharepoint.
    Podoba mi się idea pracy zbiorowej (nie narzuconej) oraz krótkich prezentacji 15-minutowych. Dzięki Procent, przemyślimy to :)

    Dodatkowo kryptoreklama :) Ta “zaprzyjaźniona firma” aktualnie poszukuje kolejnych programistów do naszego (już sporego) zespołu :)

    • Marcin,
      A z takim planowaniem to ciekawy pomysł, cool, faktycznie wtedy sporo problemów odpada.

  3. Zawsze mi się koncepcja 20% podobała. Google niestety od niej odchodzi. Inne firmy za to wdrażaja z sukcesami: http://www.fastcompany.com/3015963/google-took-its-20-back-but-other-companies-are-making-employee-side-projects-work-for-them
    W mojej obecnej firmie praktykujemy to na podobnej zasadzie do opisanej przez ciebie. Na koniec każdego sprintu mamy dzien w którym możemy zglosić chęć pobawienia się różnymi technologiami, koncepcjami, czy nawet procesami zespołu. Wyniki należy zawsze udokumentować na blogu zespołu. lub w innej formie, jeżeli w danym przypadku blog nie ma sensu.

  4. Dobrym pomysłem na wykorzystanie takiego dani pracy jest udział w projektach OpenSource. Przykladowo korzystamy z jakiejś tam biblioteki, brakuje nam czegoś / cos działa nie tak jak chcemy, więc można zkodować i wysłać Pull Request’a. Dodatkowa korzyść to satysfakcja w udziale w projekcie Open Source, poznanie kodu innych ludzi, reklama dla firmy że wspiera Open Source no i nowa funkcjonalność:)

  5. A u mnie w firmie niestety nie ma co liczyć na DPW. Kiedyś szef wspomniał coś na ten temat ale od tego momentu minął już prawie rok i nic się takiego nie miało miejsca. Aby zrekompensować sobie tą stratę wstaję wcześniej i przed pracą robię sobie godzinną wersję DPW. Po pracy też ale już znacznie rzadziej. Możliwość zabłyśnięcia w firmie nową wiedzą w ten sposób zdobytą, albo jakimś skryptem, który robi jakieś zadanie za mnie jest bezcenna ;)

Newsletter: devstyle weekly!
Dołącz do 1000 programistów!
  Zero spamu. Tylko ciekawe treści.
Dzięki za zaufanie!
Do przeczytania w najbliższy piątek!
Niech DEV będzie z Tobą!