• Praca,  Zarządzanie

    Jak dobrze wyjść z pełnej zdalności?

    W wielu dziedzinach życia ludzie próbują właśnie powrócić do „normalności”, a więc tego co było przed marcem 2020. Na tej fali niektórzy menedżerowie ogłosili już powrót do biur. Wydawać by się mogło, że wszyscy tylko czekają, aż będzie można i ochoczo do biur powrócą. Tymczasem dzieje się zupełnie odwrotnie.

    W jednej znanej mi firmie kiedy poszła informacja, że od 1 lipca koniec zdalnej pracy i wszyscy mają być w biurze od 9 do 17 jak dawniej… posypały się wypowiedzenia. Ich skala wśród pracowników związanych z szeroko pojętym rozwojem produktów cyfrowych sięgnęła ~30%. Dzieje się to ku zaskoczeniu menedżerów, którzy zupełnie się tego nie spodziewali – co z kolei dla mnie jest zaskakujące.

    W maju ukazało się badanie firmy EY pt. „EY 2021 Work Reimagined Employee Survey„. Czytamy tam, że 54% pracowników zadeklarowało chęć zmiany pracy w przypadku braku możliwości pracy „elastycznej”, przy czym 40% badanych woli pracę zdalną. Początkowo myślałem, że te liczby są trochę przesadzone – ostatecznie deklaracja w ankiecie nic nie kosztuje; to jednak coś innego niż podjęcie działania. Ale pod koniec czerwca zaczęły się opisane przeze mnie wyżej kłopoty firm, które próbowały po prostu wrócić do biur. Przekonałem się wtedy, że wskaźnik klasy jednej trzeciej pracowników, którzy prędzej odejdą niż wrócą do codziennej pracy w biurze jest jak najbardziej realny.

    Dodatkowo, zainspirowany rozmową z kimś, u kogo w firmie taki problem się pojawił, napisałem krótki wpis na LinkedIn. Reakcja na niego przeszła moje najśmielsze oczekiwania, bo w końcu nie jestem jakąś znaną osobą: w chwili gdy piszę te słowa ma on 2546 polubienia oraz 291 komentarzy, w większości od osób potwierdzających istnienie zjawiska lub potwierdzających, że nie zamierzają wracać do codziennego pobytu w biurze. Można to potraktować jako swego rodzaju mikro-sondaż, który potwierdza w całej rozciągłości wnioski z badania EY, które przytoczyłem powyżej.

    Zanim przejdę do tego jak w takim razie zarządzający powinni podejść do problemu „wyjścia ze zdalności” myślę, że warto zrozumieć z czego wynika niechęć pracowników do powrotu do biur.

    Przede wszystkim dojazdy. Wielu osobom dojazd do i z pracy pożerał od 2 do nawet 4 godzin dziennie. Po miesiącu pracy to od dwóch do czterech pełnych dni, po roku to miesiąc spędzony w samochodzie czy komunikacji miejskiej. Przez ostatni rok ludzie ten czas odzyskali, a więc odzyskali po prostu ogromny kawał swojego życia – a mimo to nic się nie zawaliło. Okazało się, że można być skutecznym pracownikiem i żyć bez dojazdów! Czy można się dziwić, że ludzie nie chcą z tego rezygnować?

    Trzeba to zrozumieć i przyjąć. Cierpkie uwagi klasy „jak ktoś sobie zbudował dom 30 km od Warszawy to sam jest sobie winien” (jeden z autentycznych komentarzy) nic nie zmienią. Będąc menedżerem lepiej zachować je dla siebie, bo ów ktoś włożył w ten dom ogromne pieniądze i wysiłek. Prędzej więc zmieni pracę niż wyprowadzi się z niego lub powróci do spędzania 3h dziennie w samochodzie.

    Po drugie, przy pracy – zwłaszcza intelektualnej – trzeba się czasem po prostu skupić. Biuro, w którym zawsze wokół są inni ludzie, którzy gadają, rozmawiają i się przemieszczają niektórym utrudnia skupienie, wręcz obniża ich efektywność. Że nie jest to bynajmniej zjawisko rzadkie dowodzi popularność w biurach słuchawek odcinających przeszkadzające dźwięki. Przynajmniej dla mnie możliwość przebywania samemu w mojej pracowni jest niezwykle cenna.

    Kolejny ważny aspekt pracy zdalnej to elastyczność – pracując zdalnie można lepiej wykorzystać czas w ciągu dnia, lepiej dostosowując go zarówno do swojego rytmu biologicznego jak i życia swojej rodziny.

    No właśnie! Po czwarte: rodzina! Ludzie dzięki pracy zdalnej mogli dużo więcej czasu poświęcić swojej rodzinie. Dla jednych nie było to fajne, ale dla innych wprost przeciwnie. O ile tych pierwszych łatwiej będzie przekonać do powrotu do biur, z tymi drugimi sprawa będzie trudniejsza.

    Ale to, co zmienił ostatni rok to nie tylko to, że ludzie zasmakowali w korzyściach z pracy zdalnej oraz nauczyli się jej – poznali narzędzia, nauczyli się ich używać, lepiej lub gorzej poradzili sobie z kwestią samodyscypliny, kontaktów w zespole i tak dalej. Zmienił się też rynek pracy.

    Wiele firm przyjęło pracę zdalną z entuzjazmem i zamierzają przy niej w dużym stopniu pozostać. W efekcie pracownicy mają obecnie dużo większy niż kiedyś wybór firm oferujących im możliwość utrzymania pracy zdalnej. Innymi słowy, przynajmniej, jeśli idzie o dużą część pracowników umysłowych – a już na pewno jeśli idzie o programistów, UX-ów, testerów itp. specjalistów z szeroko rozumianego IT – oni naprawdę nie muszą wracać do biura. Jeśli ich obecna firma nie umożliwi im pracy zdalnej bez trudu znajdą taką, która to zrobi. Tym bardziej, że mogą jej szukać niekoniecznie w pobliżu miejsca zamieszkania, ale praktycznie na całym świecie.

    Wszystko to nie przekreśla tego, że wiele osób chciałoby się ponownie spotykać z innymi członkami swoich zespołów. Wiemy, że kontakt osobisty ma walory, których żadna telekonferencja nie zastąpi. Ale nie trzeba spotykać się codziennie.

    Dlatego optymalny wydaje mi się – przynajmniej dla naszej branży – model hybrydowy, w którym ci, którym na pracy w biurze zależy pracują w biurze, a pozostali pracują zdalnie, ale regularnie spotykają się w biurze. Dotyczy to szczególnie zespołów zwinnych, które powinny regularnie się widywać – jeśli spojrzeć na Scruma dobrze by było chociaż „przełom sprintów” czyli przegląd, retrospekcję i planowanie kolejnego sprintu robić osobiście.

    Co z tego wynika?

    Po pierwsze menedżerowie powinni porzucić myśl, że będzie jak dawniej i wystarczy do tego powrócić. Próbując wszystkich „zagonić” na powrót do biura można stracić wartościowych pracowników, a najpewniej na dzisiejszym rynku i tak trzeba będzie się pogodzić z pracą zdalną by pozyskać innych na ich miejsce. Lepiej więc od razu działać w taki sposób, by do fali wypowiedzeń nie doszło. Innymi słowy, zamiast bezrefleksyjnie próbować wrócić do tego co było należy tym „przejściem” (zmianą sytuacji) zarządzać.

    Po drugie nie należy zapominać o korzyściach. Poza bardziej zadowolonymi pracownikami (bo firma daje im wybór i nie daje motywacji do szukania innej) mniej pracowników w biurze daje firmie też konkretne oszczędności w postaci możliwości redukcji drogiej powierzchni biurowej. Można również rozważyć rezygnację z części floty samochodowej, parkingów itp.

    Jak zatem dobrze wyjść z całkowitej zdalności?

    Zacząć należy od podstawowego rozeznania jak się rzecz ma w waszym przypadku, a więc krótkiego sondażu wśród pracowników by poznać ich preferencje. Warto przy okazji zakomunikować, że ich deklaracje będą podstawą do dalszych decyzji co do sposobu dalszej pracy już po ogłoszeniu końca Straszliwej Pandemii™. Jeśli zarządzasz większym zespołem są duże szanse, że wśród pracowników znajdą się i gorący zwolennicy powrotu do „dniówek” 9-17 i gorący zwolennicy pracy z domu oraz duża grupa o mniej zdecydowanych przekonaniach. Najlepsze co możesz zrobić, to już zapowiadając ankietę zapewnić, że wszyscy otrzymają – w granicach wynikających ze specjalności i stanowiska – możliwość wyboru.

    Jeśli masz zespoły zwinne to należy pozwolić im ustalić, jak zamierzają pracować. Możliwości, które zespoły mają do wyboru jest kilka:

    • całkiem „po staremu”, stacjonarnie w biurze,
    • określone dni w biurze (np. poniedziałek i wtorek w biurze), hybrydowo,
    • całkowicie zdalnie, ale biorąc udział w okresowych spotkaniach (np. jak wspomniałem wyżej na „granicach” sprintów).

    Przy takich zasadach działania zespołów w większych organizacjach możecie mieć sytuację, w której część zespołów powraca na stałe do biura, a inne pracują zdalnie w różnym stopniu.

    Organizując się w ten sposób należy unikać sytuacji, w której w zespole Scrum lub podobnym część pracowników zawsze jest w biurze a część zawsze jest zdalnie. Dany, konkretny zespół Scrum powinien trzymać się konkretnego sposobu pracy czy to całkowicie zdalnego czy to całkowicie stacjonarnego. A jeśli jest to tryb hybrydowy to wszyscy członkowie zespołu powinni być w biurze w ustalone dni „biurowe”. W przeciwnym razie wytworzy się w zespole podział na „nas” siedzących w biurze i „ich” w domach, a więc efektywnie i tak powstaną dwa zespoły. Lepiej przeprowadzić to w sposób kontrolowany.

    Przy takim podejściu – cały zespół pracuje razem zdalnie lub nie – należy dać pracownikom możliwość zmiany zespołu, gdyby z modelem pracy, który ustalił ich obecny zespół było im skrajnie nie po drodze. Pamiętajmy, że alternatywą dla pewnego zamieszania organizacyjnego jakie to wytworzy jest potencjalne odejście owych niezadowolonych z pracy, a więc zamieszanie jeszcze większe. Lepiej, jeśli zamiast tego zmienią tylko zespół pozostając w firmie.

    Należy również zadbać o to, żeby nawet zespoły zdalne regularnie spotykały się. Dobre relacje międzyludzkie wymagają, żebyśmy wiedzieli o współpracownikach coś więcej, niż to co można wyczytać z ich profilu na LinkedIn. Dopiero wtedy stają się dla nas „pełnowymiarowi”. Takie więzi zdecydowanie łatwiej powstają przy spotkaniu osobistym, które nawet jeśli poświęcone jest pracy ma także różne momenty nieformalne jak choćby wspólny obiad. Można więc przyjąć jako zasadę, że wszystkie zespoły powinny spotykać się nie rzadziej niż raz na miesiąc. Istotne jest nie tylko zakomunikowanie zespołowi takiego oczekiwania, ale również wyjaśnienie z czego ono wynika.

    Wyzwaniem organizacyjnym będzie na pewno jak zrobić to tak, by móc jednocześnie ograniczyć powierzchnię biurową. Oczywiste rozwiązanie to takie planowanie spotkań zespołów, aby równolegle odbywało się tylko tyle, ile może obsłużyć mniejsze biuro oraz posiłkowanie się wynajmem sal w razie „spiętrzeń”. W większych organizacjach może to nawet wymagać ponownej aranżacji powierzchni biurowej pod kątem jej rotacyjnego wykorzystania przez różne zespoły.  

    Potrzebne będą także narzędzia, aplikacje, które wspomogą funkcjonowanie firmy w taki sposobie pracy. Chodzi to nie tylko o zarządzanie korzystaniem z biura z „overbookingiem”, ale także np. możliwość prostego ustalenia kto akurat jest danego dnia w biurze i gdzie można go znaleźć. Dobrym pomysłem może być zaangażowanie w to pracowników, bo takie aplikacje czy narzędzia to wdzięczny temat dla hackathonu.

    Zadbać należy również, żeby spotykali się też ludzie, którzy nie pracują w jednym zespole. Jeden lub – lepiej – dwa zjazdy cały firmy lub – w większych firmach – działów to świetny sposób na to, by pracownicy z różnych zespołów mogli się spotkać i pogadać na stopie bardziej towarzyskiej. Oczywiście, również to, że takie zjazdy będą się odbywać dobrze będzie ogłosić wśród pracowników, najlepiej od razu z planowanymi datami.

    Wreszcie, poza kwestią zadbania o spotkania należy zadbać o jakość pracy zdalnej. Jak każda forma pracy i współpracy może ona być mniej lub bardziej efektywna, są tu pewne dobre praktyki (jak choćby używanie kamer na każdym spotkaniu, co powinno być bezwzględnie narzucone z góry i twardo egzekwowane) i pomocne narzędzia. Temat to jednak na osobny tekst, zresztą, na wiosnę 2020 napisaliśmy o tym książkę „Praca Zdalna – Poradnik”.

    Jako „nowa normalność pracy” wyłania nam się obecnie obraz pracy hybrydowej – zasadniczo z domu, z regularnymi wizytami w biurze dla spotkania najbliższych współpracowników i rzadszymi zjazdami, podczas których spotyka się szersze grono. Model ten ma więcej zalet zarówno od modelu tradycyjnego jak i całkowicie zdalnego. Umożliwia pracownikom nawiązanie ludzkiego, bezpośredniego kontaktu, jednocześnie dając im oszczędność ogromnej ilości czasu (dojazd do biura 4 razy w miesiącu to nie to samo co 21 razy) i inne korzyści pracy zwinnej. Firmie daje to bardziej zadowolonych pracowników – a także oszczędności na powierzchni biurowej.

    To, na co z pewnością nie można sobie pozwolić, to próba bezrefleksyjnego powrotu do tego, co było przed Straszliwą Pandemią™ lub bierne czekanie na to, co będzie. Trzeba przyjąć, że każda firma będzie musiała wypracować nowy sposób pracy w rzeczywistości, w której praca zdalna jest normą a nie wyjątkiem – i zabrać się za zarządzanie tym procesem.

  • Agile,  Zarządzanie

    Gdy masz tylko młotek….

    Pracując jako doradca i ekspert od metod zwinnych nieustannie spotykam się pewnym nieporozumieniem, które najkrócej streścić można w jednym zdaniu: „Agile to Scrum”. Innymi słowy polega ono na z gruntu błednym przekonaniu, że tak zwana „transformacja Agile” (czyli zmiana organizacji w nowoczesną, zwinną, sprawnie zarządzaną) polega na… wdrożeniu Scruma. Sprowadza to duży temat jakim jest Agile i w ogóle nowoczesne zarządzanie do jednej tylko metodyki pracy zespołowej, która choć bardzo dobra nie jest ani jedyną metodą Agile ani nie załatwia wszystkich problemów (zwłaszcza na skalę organizacji).

    Nieporozumienie to wydaje się dość niewinne – ot, typowe niezrozumienie tematu przez osoby, dla których jest nowy. Niestety, przekonanie, że „Agile == Scrum” jest na tyle powszechne, że prowadzi do dwóch niepożądanych zjawisk, które do tego wzajemnie się napędzają.

    Pierwszym są „wdrożenia Agile” polegające na odgórnym zadekretowaniu Scruma jako metodyki czy procesu, który ma obowiązywać wszystkie zespoły. Zazwyczaj początkiem takiej sytuacji jest kiedy ktoś mający władzę – menedżer działu IT, czasem prezes – zostaje „zainfekowany” fałszywym uproszczeniem, że „Agile to Scrum” czy to przez niekompetentnego konsultanta czy to wskutek lektury jakiegoś powierzchownego artykułu.

    Dlaczego takie odgórne narzucenie Scruma jest złe? Scrum jest tylko jedną z wielu metod i praktyk Agile. Nie jest z pewnością metodą dla wszystkich zespołów, bo wymaga spełnienia pewnych warunków by w ogóle działać a co dopiero działać dobrze. Są to m.in. takie rzeczy jak wspólnota pracy (członkowie zespołu nie wykonują indywiudalnie od A do Z osobnych prac ale tworzą wspólnie produkt, dla którego potrzebne są kompetencje ich wszystkich razem i na raz) czy wyraźne cele (sprintu i produktu). Generalizując Scrum jest najlepszy dla tworzenia nowych produktów, przechodzących fazę szybkiego rozwoju funkcjonalnego, przy pomocy zaangażowanych zespołów profesjonalistów, w firmach, których kultura zbudowana jest wokół pięciu wspierających Scrum wartości. Niestety, w wielu organizacjach tej szerzej wiedzy o Scrumie brak. Brak także wiedzy o innych metodach Agile, czasem nawet wręcz brak świadomości ich istnienia.

    Zatem zamiast narzucać dekretem Scruma należy raczej ustalić cele wprowadzania metod zwinnych, zapoznać się z ich teorią i różnymi dostępnymi opcjami po czym wybierać dla każdego zespołu te metody, które pasują do niego – i tego co robi. A także spojrzeć na organizację szerzej, zająć się takimi rzeczami jak cele, metryki, kultura itp.

    Drugi problem często występujący razem z pierwszym jest tzw. „mechanistyczny Scrum”, a więc „wdrożenie Scruma” polegające li tylko na przemianowaniu ról (np. z Project Managera na Product Ownera) i przymuszeniu zespołów do odbywania przepisanych w metodzie spotkań. Typowym (choć nie jedynym) symptomem takiej sytuacji jest uczynienie oficjalnym standardem organizacyjnym łączenia roli Scrum Mastera i developera w zespole oraz brak dbałości o odpowiednie przeszkolenie tych Scrum Masterów (że nie wspomnę o zespołach).

    W efekcie uzyskuje się niewiele korzyści z metody – jeśli w ogóle jakieś. Ponieważ nikt nie rozumie tak naprawdę po co są te spotkania i cała reszta, a rzecz została narzucona bez sprawdzenia czy dla danego zespołu ma sens to zamiast zwinnych wydajnych zespołów uzyskujemy ludzi, którzy bez przekonania – a potem z rosnącą niechęcią – odgrywają nakazany przez kierownictwo teatrzyk. „Mechanistyczny Scrum” nagminnie towarzyszy odgórnie zadekretowanym zuniformizowanym „wdrożeniom Scrum”, bo ma dokładnie taką samą przyczynę – brak głębszej wiedzy i zrozumienia choćby samej metody (a więc tego dlaczego Scrum jest taki, jaki jest, dlaczego składa sie z takich a nie innych elementów, czemu służy i gdzie działa najlepiej), że nie wspomnę o Agile jako szerzym zjawisku.

    Najgorsze jest w tym jest jednak nawet nie to, że efekty takiego wprowadzenia Scruma są mierne – dużo gorsze jest to, że nikt nie zdaje sobie sprawy z tego, że to, z czym mają do czynienia ma się nijak nie tylko do Agile ale nawet do Scruma. W efekcie organizacja produkuje całe zastępy ludzi, którzy są święcie przekonani, że pracują w Agile i świetnie wiedzą na czym polega Scrum bo przecież pracowali w nim (czasem kilka lat) – którzy tak na prawdę nie mają ani o Agile ani o Scrum pojęcia. Ta nieuświadomiona ignorancja jest niezwykle trudna do wyleczenia – najczęściej zdarza się to dopiero kiedy delikwent trafi wreszcie do miejsca, w którym Scrum czy jakaś inna metoda Agile jest naprawdę dobrze stosowana. Z tego powodu organizacja z mechanistycznym, zadekretowanym Scrumem jest czymś w rodzaju rozsadnika zarazy. Wychodzą z niej ludzie, którzy następnie w innych organizacjach opowiadają że „Scrum nie działa” lub co gorsza uważając się za doświadczonych reklamują się jako konsultanci od Scruma (bo nic innego nie znają – jak w tytułowym dowcipie o człowieku, który miał tylko młotek więc wszystko wyglądało mu jak gwóźdź), którzy w kolejnych organizacjach „wdrażają Scruma” w sposób, który znają z doświadczenia, co produkuje kolejnych zrażonych – i kolejnych zarażających.

    Walczyć z tym fenomenem można w jednyny sposób, a mianowicie przez rzetelną wiedzę nie tylko o Scrumie, nie tylko o Agile, ale w ogóle o nowoczesnym zarządzaniu. I to staram się robić m.in. w Code Sprinters, a także na tym blogu, w moich książkach i tak dalej. Metoda to żmudna, bo wiedza ta jest mniej „seksi” od uproszczeń w rodzaju „wdróżmy Scruma i będzie Agile”, ale za to skuteczna na dłuższą metę.

  • Agile,  Praca,  Zarządzanie

    Nigdy nie będzie dobrze

    Postanowiłem się dziś podzielić obserwacją tak oczywistą, ale najwyraźniej nie na tyle by była ona powszechnym rozumieniem. Otóż: nigdy nie będzie dość szybkich zespołów developerskich.

    Dlaczego? Ano dlatego, że wymyślanie potrzeb oraz funkcji w oprogramowaniu, które mogłyby je zaspokajać jest bardzo szybkie. Sam pomysł to krótki błysk w duszy i przebieg impulsów po neuronach – jest! Eureka! Zapisanie go, ew. przedyskutowanie to kwestia godzin. Ale realizacja może trwać dni, tygodnie, miesiące nawet. Jeśli dodamy do tego dość typową sytuację, kiedy wymyślających (zwanych elegancko „interesariuszami”) jest istotnie więcej od implementujących widać wyraźnie, że jest niemożliwością doprowadzenie do sytuacji, w której każdy pomysł („wymaganie”) jest realizowane bez oczekiwania. Z tego właśnie powodu praktycznie zawsze wymagania czekają a ich lista rośnie.

    [Opisując to językiem procesów tworzenie oprogramowania to – na wysokim poziomie ogólności –  etap, na którym jednostki pracy są wytwarzane bardzo szybko, po którym następuje etap przetwarzający je dużo wolniej.]

    Jeśli chwilę pomyśleć rzecz jest – jak to już napisałem wyżej – oczywista. Prosta logika mówi, że nie może być inaczej. A jednak mimo to w praktycznie wszystkich organizacjach, z którymi miałem do czynienia, jest ogromny nacisk na to, żeby zespoły działały szybciej. Tak jakby organizacje chciały osiągnąć to marzenie, idealny stan, w którym powiedzą sobie „mamy już wystarczająco szybki development”. Realizuje się to głównie przez odruch zatrudniania (stąd taka popularność tematu „skalowania Agile” – jak się już tych ludzi zatrudni jakoś trzeba ogarniać współpracę pomiędzy nimi).

    I w sumie nie ma w tym nic złego gdyby nie to, że nie widać by co najmniej taka sama energia i zaangażowanie były poświęcone na dobre wybieranie tego, co będzie realizowane. A to jest rzecz absolutnie najważniejsza. Mając ograniczony zasób jakim są możliwości i energia developmentu należy przede wszystkim zadbać o to, by nie marnować go na rzeczy o niskiej wartości. Każde wymaganie, każdy pomysł powinno się trzy razy obracać w palcach, oglądać pod światło i porównywać z innymi żeby mieć absolutną pewność, że w danej chwili nie ma naprawdę nic ważniejszego co developerzy mogliby zrobić.

    To jest kolejna oczywistość, dużo bardziej zresztą uniwersalna niż tworzenie oprogramowania – wszędzie ważna jest koncentracja. Niby wszyscy o tym wiedzą, ale w 9 przypadkach na 10 kiedy np. w ramach warsztatu zwizualizujemy kierownictwu ile mają otwartych inicjatyw i projektów to jest wielkie zdziwienie. Po czym oczywiście jedno z pierwszych pytań jest takie: co zrobić, żeby development szybciej pracował? Może zatrudnijmy więcej programistów?

    Myślę, że lekarstwem na to może być powtarzanie w kółko oczywistości, od której zacząłem ten wpis: „nigdy nie będzie wystarczająco szybkich zespołów”. I dodawanie „zatem zastanówmy się jak najlepiej wykorzystać to, co mamy”.

    Jak to konkretnie zrobić? Ano stosując empiryzm, nie pakując się w wielkie inicjatywy bez zweryfikowania małym (i tanim) eksperymentem, że warto, stosując biznesowe metryki (np. kwantyfikację celów biznesowych) i weryfikowanie na ile dana planowana funkcjonalność je poprawia – i tak dalej. Dużo narzędzi i praktyk wykraczających poza zakres tego artykuliku (o części z nich mówimy na szkoleniu dla Product Ownerów, o innych na różnych warsztatach). Czyli robiąc wszystko co się da, żeby właśnie jak najlepiej wybierać rzeczy, które trafią do realizacji.

    Ale to są narzędzia, a najważniejsza jest świadomość, że w ten sposób osiągniemy więcej niż koncentrując się na powiększaniu zespołów. Teraz już ją masz, więc do dzieła! Bo choć nigdy nie będzie dobrze, to jednak może być lepiej. 🙂