Dzień Pracy Własnej

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.