Zatrudniasz się jako programista. Dostajesz powolny komputer. Nie ma na nim oprogramowania, które pozwala na wydajną pracę. Sporo stron w internecie jest zablokowanych. Nie możesz wybrać sobie klawiatury ani myszy, krzesła też wszyscy mają takie same. Brzmi znajomo?
5S
Japonia posiada interesującą kulturę. Estetyka, porządek, pracowitość – to bez wątpienia ciekawy kraj. Jednym z jego wielkich sukcesów jest motoryzacja. Amerykański przemysł samochodowy – z legendarnym Detroit, z linią produkcyjną w fabrykach Forda – był dumą Stanów Zjednoczonych. Mimo wygranej wojny i lat doświadczeń, w latach 80 przegrał z Japońską motoryzacją, a System Produkcyjny Toyoty wszedł do podręczników organizacji i zarządzania.
Jednym z elementów Japońskiej kultury w tym obszarze jest 5S. Nie wchodząc w szczegóły, jest to organizacja miejsca pracy polegająca m.in. na:
- usunięciu zbędnych przedmiotów
- ograniczeniu zbędnego ruchu i wysiłku pracowników
- utrzymaniu stanowisk pracy w czystości
Wdrożenie tych zasad pomaga stworzyć bezpieczne i efektywne miejsce pracy. Nie trzeba mówić, że pomaga to całej organizacji w utrzymaniu wydajności – co istotne, bez zwiększania wysiłku pracowników.
Alcoa
Alcoa to jeden z największych producentów aluminium na świecie. Ciekawą historię o firmie opisał Charles Duhigg w Sile nawyku. Otóż swego czasu pojawił się w Alcoa nowy CEO – Paul O’Neill. Po nominacji na stanowisko prezesa zaskoczył udziałowców, bo w swoim przemówieniu inauguracyjnym skupił się nie na wynikach, opłacalności biznesu, planach rozwoju, ale… na bezpieczeństwie pracowników. Było to jedyne, co poruszył. Zmniejszenie liczby wypadków przy pracy.
O’Neill zarządzał firmą od 1987 do 1999 roku. W tym czasie wartość rynkowa firmy wzrosła z 3 do ponad 27 miliardów dolarów, a dochód netto wzrósł z 200 milionów do prawie półtora miliarda.
Czy te pieniądze Alcoa traciła na wypadkach przy pracy?
Oczywiście, że nie. Traciła je z powodu złej, niedbałej, niechlujnej organizacji stanowisk pracy. Na tym, że były nieprzemyślane, nieergonomiczne i były takie od lat z powodu złych procesów oraz komunikacji. O’Neill wprowadził presję na ulepszenie organizacji produkcji, bezpieczeństwo stanowiska pracy było metryką doskonałości. Jak widać – skuteczną.
Ciągle im mało
Tak, wiem, jesteśmy roszczeniowi. Mamy game roomy, podnoszone biurka, dwa monitory i owocowe czwartki, ale ciągle nam mało – snujemy się po kolejnych firmach w poszukiwaniu Bóg jeden wie czego, ale pewnie pieniędzy, których ciągle nam mało.
Może tak jest.
Co jednak, jeśli nie?
Co jeśli jest jakaś głębsza przyczyna migracji koderów?
Stanowisko pracy programisty
W programowaniu duży nacisk kładzie się na optymalizację. Motywem przewodnim tej branży od lat jest efektywność. Nowe frameworki, które pozwolą zrobić to samo szybciej. Szybsze procesory, więcej pamięci, potężniejsze dyski. Algorytmy, które liczą sprawniej, lepiej niż starsze. Karty graficzne, które generują więcej klatek na sekundę. Branża technologiczna oparta jest o wiarę w to, że da się lepiej i szybciej, taniej i sprawniej.
Programista, kiedy siada do pracy, próbuje ją sobie zoptymalizować. Jeśli musi wykonywać powtarzalną czynność – napisze skrypt. Jeśli coś zajmuje dużo czasu – pomyśli jak zrobić to szybciej, innym sposobem.
Co więc może być bardziej irytującego dla programisty od sytuacji, w której coś spowalnia jego pracę, a jednocześnie nie da się obejść, usunąć, poprawić?
Tych mniejszych lub większych przeszkód na drodze do wydajności, w wielu miejscach pracy, jest zaskakująco dużo. Oto kilka przykładów:
- komputer, na którym programujemy ma za mało pamięci / za wolny procesor / za mały dysk
- internet w firmie działa powoli, np. przez proxy
- oprogramowanie antywirusowe dramatycznie spowalnia komputer (choćby od czasu do czasu)
- polityka firmy blokuje pewne strony (np. youtube, gdzie możemy znaleźć tutorial do rozwiązania problemu)
- przyznanie praw dostępu przeciąga się w nieskończoność (np. by wykonać zadanie potrzebujemy dostępu do systemu x, ale musi je zaakceptować trzech managerów, a to trwa trzy tygodnie)
- firma nie kupuje pewnych narzędzi albo robi to bardzo powoli (np. potrzeba jakiegoś narzędzia na za tydzień, ale akceptacja i zamówienie zajmuje trzy miesiące)
- naprawa zepsutego sprzętu trwa bardzo długo (osobiście raz czekałem dwa tygodnie na naprawę mojego firmowego komputera)
Pamiętam pewnego managera, który dziwił się, jak to jest możliwe, że startupy są wydajniejsze? – przecież mają nieraz mniejsze budżety, czyli teoretycznie gorszych pracowników, a jednak dostarczają szybciej. Z mojej praktyki wynika, że to właśnie narzut organizacyjny zabija efektywność…
Skupienie
Poza czysto technicznym aspektem, jakim jest wydajność sprzętu i dostępność narzędzi warto jednak pamiętać również o ergonomii miejsca pracy programisty. W jej skład wchodzą zarówno wygodne, dostosowane do konkretnej osoby krzesło, czy klawiatura, jak i otoczenie.
W wielu firmach kupuje się kilkaset takich samych krzeseł, biurek, monitorów, klawiatur i przydziela każdemu nowemu programiście. To zrozumiałe. Stan tych narzędzi jest zresztą zazwyczaj bardzo dobry. Jest jednak część osób – może niskich, może otyłych, może wysokich albo czułych w jakimś sensie – którym taki standard będzie utrudniał życie. Będzie ich bolał kark albo nadgarstki, będą ich bolały oczy. Trudno wtedy o najważniejszą rzecz w pracy programisty – skupienie.
Programista, jeśli nie może się skupić, trwoni pieniądze firmy. Skupienie zaś nie jest tak łatwe jak przyjście do biura. Rozmowni koledzy, liczne spotkania w trakcie dnia, niewygodne krzesło, zapach ryby atakujący nas z biurowej kuchni… wszystko to może zburzyć delikatną materię flow.
DX
User experience stało się głośną ideą. Na tyle głośną, że specjaliści projektujący interfejsy wygodne dla użytkownika zagościli w wielu firmach tworzących oprogramowanie. Każdy dziś wie już, że ergonomia aplikacji jest ważna.
Analogicznie, należałoby stworzyć ideę DX – developer experience. Im gorszy, tym więcej pieniędzy utonie w projekcie, a to co powstanie może okazać się niewarte wysiłku. Im lepszy tym mniejsza rotacja w zespole, wydajność i motywacja programistów, mniej błędów, a więcej zysku.
Za zalążek DX uznać można słynny test Joela – listę punktów, jakie spełnia proces rozwoju oprogramowania. Im więcej, tym on dojrzalszy, ale również przyjemniejszy dla programistów uczestniczących w projekcie…
Starając się „dopieścić” koderów warto wyjść poza standardy. Nie muszą to być duże koszty. Zyski zaś i owszem.
Na koniec przypomnijmy, że i Microsoft nigdy nie był obojętny na developerów…
