Zarządzanie projektem i firmą IT w obliczu pracy zdalnej

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Piotrem Januszko o zarządzaniu projektem i firmą IT w obliczu pracy zdalnej.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Mój dzisiejszy gość jest zaangażowany w IT od 2005 roku, zresztą tak samo jak ja. Pracował dla firm o różnej wielkości i z różnych branż, skupiając się na zarządzaniu zespołami, projektami, leadershipie oraz programowaniu. Obecnie rozwija szczeciński oddział firmy Unikie. Sam o sobie mówi, że jest ojcem, szefem, podwładnym, rzeźbiarzem, poetą, śpiewakiem, tancerzem, pisarzem, twórcą i odbiorcą. Moim i Waszym gościem jest Piotr Januszko.

Cześć, Piotr! Bardzo miło mi gościć Cię w podcaście.

Cześć, Krzyśku! Dzięki za zaproszenie i witam też słuchaczy.

Bardzo się cieszę, że będę miał okazję porozmawiać z tak barwną osobą. [śmiech] Tematem naszej dzisiejszej rozmowy będzie zarządzanie projektem i firmą IT w obliczu pracy zdalnej, czyli temat jak najbardziej na czasie. Zacznę jednak od stałego punktu programu, czyli pytania do Ciebie, Piotr. Czy słuchasz podcastów? Jeśli tak, to może masz jakieś swoje ulubione, którymi chciałbyś tutaj się podzielić.

Tak, trochę słucham i jest ich chyba kilka. Pierwszy, o którym chciałbym wspomnieć, to jest Joe Rogan — dosyć znany podcast. Zanim opowiem o samym podcaście, to wyjaśnię dlaczego. W podcastach — i ogólnie — bardzo interesuje mnie to, kim dany człowiek jest, co sobą reprezentuje, jakie ma doświadczenia. Jeśli chodzi o Joe Rogana, to jest komik, to jest zawodnik i komentator MMA, właściciel allegedly, jak to się mówi, największego podcastu na świecie, więc postać bardzo ciekawa i też skromna, a przynajmniej sądząc po tym, w jaki sposób rozmawia z innymi. Cóż jeszcze?

Może dwie takie mniej znane osobistości. Pierwsza to Eric Weinstein, naukowiec Harvardu, fizyk, ekonomista, ale zajmuje się też muzyką, sztuką, socjologią. Dosyć trudny w odbiorze czasami, natomiast ciekawy i jego podcasty oraz jego teoria, nad którą pracował wiele lat, związana z fizyką kwantową, też gdzieś na przecięciu socjologii, jakby to dziwnie nie brzmiało, jest dosyć interesująca.

Druga osoba — Lex Fridman, to jest też naukowiec z MIT. Zajmuje się wieloma rzeczami: IT, robotyką, AI-em, samochodami autonomicznymi, ale oprócz tego też muzyką, jest również zawodnikiem Brazilian jiu-jitsu bodajże. O! i dodam może jeszcze jedną osobę, aczkolwiek to nie jest stricte podcaster, natomiast wiele, wiele godzin poświęciłem słuchając jego wykładów i to jest Jordan Peterson. To jest taki psycholog kliniczny z University of Toronto. W ostatnich latach dosyć popularny, można powiedzieć, że stał się osobą publiczną.

Tak, bardzo fajne podcasty. Faktycznie każdy z nich również mogę polecić, bo to jest naprawdę kopalnia wiedzy, doświadczenia i warto po prostu ich słuchać bez dwóch zdań. Dobrze, Piotr, chciałbym na początku zapytać Cię o takie podstawowe rozróżnienie, ponieważ będziemy się dzisiaj obracać wokół zarządzania. Natomiast często mylonymi pojęciami są zarządzanie i przywództwo czy też leadership. Więc żeby tak osadzić się tutaj twardo, to chciałbym Cię poprosić, żebyś zdefiniował te dwa pojęcia, czym się różnią od siebie.

To jest trudne i jednocześnie rozmawiamy w takim okresie w moim życiu. Może rok, dwa lata wcześniej, mógłbym odpowiedzieć na takie pytanie zgoła inaczej. Natomiast dzisiaj wydaje mi się, że podstawowa różnica, jeśli chodzi o menedżment i leadership wynika po prostu z potrzeby. I też częstą, przeze mnie przynajmniej obserwowaną tendencją jest to, żeby hejtować menedżment. Leadership to jest to, menedżment jest mniej szanowany albo mniej jest tego glamour dookoła niego. Z tym glamour na pewno się zgodzę. Natomiast moim zdaniem, jeśli chodzi o potrzeby, to przynajmniej w kontekście menedżmentu są one chyba dużo bardziej namacalne. I z biegiem lat też mogę powiedzieć, że osobiście bardzo chciałbym mieć menedżera. Może: co ja rozumiem przez menedżment. Gdyby tak się zastanowić, co robi menedżer, to ja bym to może rozdzielił na takie dwie rzeczy. To jest w pewien sposób sprzątanie tego, co się rozlało w zespołach, w organizacji, a z drugiej strony też organizowanie rzeczy, które się wydarzyć powinny, de facto trochę organizowanie czasu być może innym, oprócz siebie.

Może rok, dwa lata wcześniej, mógłbym odpowiedzieć na takie pytanie zgoła inaczej. Natomiast dzisiaj wydaje mi się, że podstawowa różnica, jeśli chodzi o menedżment i leadership wynika po prostu z potrzeby. I też częstą, przeze mnie przynajmniej obserwowaną tendencją jest to, żeby hejtować menedżment. Leadership to jest to, menedżment jest mniej szanowany albo mniej jest tego glamour dookoła niego.

Nie chciałbym, żeby to zostało źle odebrane, ale dla mnie to jest połączenie pracy i sprzątaczki, i asystentki. Wydaje mi się, że bardzo korzystnym byłoby, gdyby w ten sposób do menedżmentu podchodzić i żeby tutaj też było jasne: w żaden sposób nie chciałbym umniejszać znaczenia pracy kogoś, kto sprząta czy asystentki. Ja osobiście zaczynałem swoją karierę zawodową od „sprzątaczki”, pracując też trochę fizycznie lata temu z moim wujkiem i to jest podstawa, to jest po prostu podstawa. Natomiast jeśli chodzi o pracę asystentki, asystenta, to jest nieprawdopodobnie wymagająca rola, żeby godzić różne priorytety. To jest bardzo operacyjne i nie wiem, czy byłbym w stanie być asystentem czyimkolwiek, ponieważ to jednak wymaga zdolności organizacyjnych na ponadprzeciętnym poziomie, żeby to robić oczywiście dobrze.

Leadership, tutaj z drugiej strony. Potrzeby, na jakie odpowiada leadership w mojej ocenie, to jest dawanie ludziom celu, zbieranie ich wokół celu i umożliwienie ludziom osiągania tego celu, realizację. Szczerze powiedziawszy, wydaje mi się, że rodzi to, oprócz dużego potencjału do robienia rzeczy dobrych, obiektywnie dobrych, też duże pole do nadużyć. Myślę, że w historii można znaleźć wystarczająco wiele przykładów, kiedy różni ludzie ze swoją wizją byli w stanie pociągnąć niekoniecznie w dobrym kierunku. Natomiast byli to liderzy, to trzeba sobie powiedzieć. Co tutaj według mnie można jeszcze dorzucić do leadershipu? Coś, co moim zdaniem jest dużo mniej patogenne [śmiech] i to jest dawanie ludziom przestrzeni do rozwoju, do wzrostu. To bym wrzucił do tej grupy rzeczy wokół leadershipu i tutaj nie mam pytań. Wydaje mi się, że to jest to, gdzie najwięcej dobra można uczynić.

Czyli tak konkludując, zarówno menedżer, jak i lider są potrzebni, przynajmniej w mojej ocenie, i szczerze powiedziawszy wydaje mi się, że dużo więcej dobrego day-to-day można zrobić jako menedżer niż jako lider. Może to kłócić się z jakimiś popularnymi osądami, natomiast to też we mnie się klarowało przez długi czas. Jedno i drugie jest potrzebne.

Cieszę się, że postawiłeś ten akcent, że jedno i drugie jest potrzebne. Żeby firmy w branży IT — ale nie tylko w branży IT, myślę że w prawie każdej branży — mogły odnosić sukces, to potrzebne jest tam trochę pierwiastka takiej wizji, ale też jest potrzebne całkiem dużo realnej pracy wykonawczej, związanej z zarządzaniem, prowadzeniem, sprzątaniem, naprawianiem różnych problemów i tak dalej. To tutaj niezbędne. A będziemy mówić dzisiaj o zarządzaniu, czyli takim obszarze, który wymaga konkretnych umiejętności, twardych nierzadko, ale też mimo wszystko pracy z ludźmi, bo ostatecznie do tego to się sprowadza. Przeżywamy w branży IT od kilku, może nawet kilkunastu lat pewną zmianę, mocno przyspieszoną przez pandemię, pod tytułem: praca zdalna, czy też taki większy shift w kierunku pracy zdalnej.

Tak.

Właśnie, chciałbym Cię zapytać, jak z Twojego doświadczenia wynika, czy są jakieś różnice, a jeśli tak, to jakie, w zarządzaniu takim zespołem, czy takim projektem, który jest realizowany w klasycznej wersji stacjonarnie versus z zespołem, który jest rozproszony i jak te różnice wyglądają od strony na przykład takiej osoby jak Ty, która jest zaangażowana w zarządzanie, i od strony wykonawców projektu?

Zacznę może od tej drugiej części. Jeśli chodzi o wykonawstwo projektu i to, w jaki sposób praca zdalna na to wpływa, i też na zarządzanie takim projektem, to w pewien sposób wydaje mi się, że nie zmieniło się nic. Natomiast to, co się na pewno wydarza, to jest obnażanie błędów, takie bardzo bezlitosne i bardzo szybkie, w zarządzaniu, ponieważ o tyle, o ile będąc w ciągłym kontakcie z ludźmi, co jest oczywiście bardzo dobre i to jest też mój ulubiony sposób pracy, kiedy tego nie ma, wszystkie niedopatrzenia mają dużo krótsze nogi, jeśli tak mogę sparafrazować to powiedzenie. Czy to problemy z komunikacją, czy z rozwiązywaniem konfliktów, czy zarządzanie efektywne pracą, worklogiem, praca właśnie z worklogiem, to błędy tam popełnione dużo szybciej stają się widoczne i też samonapędzają się w przypadku pracy zdalnej.

Są też takie czysto operacyjne mierniki. Jakbym miał porównać, jak wygląda praca mniej więcej w tej samej jakości w projekcie, gdzie mamy bezpośredni kontakt z ludźmi, pracujemy w jednym pomieszczeniu, w jednym budynku versus praca zdalna, to śmiało mogę powiedzieć, że żeby zachować tę samą jakość, to trzeba gdzieś ze 30% czasu więcej poświęcać na to. Oczywiście na spotkania, na wdzwanianie się, na przekazywanie informacji na komunikatorach wszelkiego rodzaju, którymi akurat się posługujemy — coś, co normalnie dzieje się po odwróceniu się w jedną stronę czy w drugą i szybkim powiedzeniu ludziom, tutaj musi być w jakiś sposób przetworzone, skwantyfikowane do tego, co przekazujemy właśnie w formie tekstowej. Myślę, że to jest takie dość mierzalne.

Jeśli chodzi o takie wyzwania, z którymi mierzy się firma w ogóle, to pewnie nie odkryję w jakiś sposób Ameryki, mówiąc że przede wszystkim identyfikacja z firmą to jest to, nad czym trzeba w organizacji pomyśleć, przemyśleć to i zastanowić się, w jaki sposób utrzymać to na takim poziomie, jakim się chce, żeby to było. Swoją drogą, nie pamiętam dokładnie nazwy tego badania, ale to jest gdzieś do wyszperania w Internecie. W zeszłym roku były zrobione badania a propos wpływu na pracę, na to, jak ludzie pracują zdalnie, przy okazji oczywiście pandemii. Wnioski były takie, w sumie ciekawe, ale jak się zastanowić, może nawet oczywiste, że efektywność rośnie, zasadniczo efektywność rośnie.

Jesteśmy sobie w domu, tak jak ja teraz chociażby — chociaż muszę powiedzieć, że już bywam w biurze częściej — ale jesteśmy sobie w domu, mamy ten komfort, że możemy sobie zrobić coś do jedzenia, nie musimy nigdzie wychodzić. Można po prostu wziąć tego taska i z nim jechać, rąbać go, aż go zrobimy, nawet do wieczora, co się często wydarza. Natomiast kreatywność spada. Efektywność rośnie, kreatywność spada — taki był wniosek tego badania. I to też jest bardzo ciekawe, ponieważ to pokazuje, czego kreatywność potrzebuje. Można taką hipotezę postawić, że kreatywność w takim razie potrzebuje kontaktu z ludźmi i zderzania się z innymi pomysłami, pewnie też stąd idea brainstormingu chociażby. Generalnie, żeby ten punkt odniesienia, który sobie każdy sam w domu buduje, czy wymyśla, był w innych i wtedy najwidoczniej ta kreatywność ma lepsze pole do rozwoju.

Efektywność rośnie, kreatywność spada — taki był wniosek tego badania. I to też jest bardzo ciekawe, ponieważ to pokazuje, czego kreatywność potrzebuje. Można taką hipotezę postawić, że kreatywność w takim razie potrzebuje kontaktu z ludźmi i zderzania się z innymi pomysłami, pewnie też stąd idea brainstormingu chociażby. Generalnie, żeby ten punkt odniesienia, który sobie każdy sam w domu buduje, czy wymyśla, był w innych i wtedy najwidoczniej ta kreatywność ma lepsze pole do rozwoju.

Inna sprawa, że z takich wpływów na rynek IT czy na rozwój firmy, który ma praca zdalna, też ma wymiar czysto biznesowy i tu mówimy chociażby o wzroście zarobków pośród inżynierów: programistów, testerów, designerów, ponieważ ludzie po prostu odkrywają, że mogą pracować nie tylko w Polsce, będąc w Polsce. I firmy też odkrywają, że nie muszą zatrudniać tylko ludzi z ich krajów, ponieważ nagle wszyscy zostaliśmy przymuszeni do odkrycia innych sposobów pracy. Co swoją drogą jest w tym momencie, mówię tutaj o wzrostach zarobków w IT — znowu może powiem coś niepopularnego, ale wydaje mi się, że jesteśmy świadkami pewnej bańki. Przykład: w Polsce jest niezerowa i nieniska grupa inżynierów, którzy zarabiają w zasadzie tyle samo, co ludzie w Finlandii chociażby, przy kosztach, myślę, dużo, dużo niższych. I tego rodzaju dysproporcje rynki zazwyczaj w jakiś sposób weryfikują. Spodziewałbym się, czy to bańka czy nie bańka, ja to nazywam bańką, że ona jeszcze pewnie potrwa rok albo dwa, natomiast to nie może dziać się w nieskończoność, ponieważ po prostu rynek na to nie pozwoli.

No właśnie, rynki mają taką tendencję, żeby jednak wypłaszczać pewne rzeczy, zwłaszcza w jakimś dłuższym okresie, więc to jest faktycznie ciekawy czas. I też, myślę, nałożenie pandemii, większe zauważenie pracy zdalnej, wpływa na to, że — no nie wiem, czy się ze mną zgodzisz, czy nie, ale obserwujemy taką zmianę, jeśli chodzi o ten paradygmat pracy, że to już nie musi być te przysłowiowe 8 godzin od 9 do 5, że jednak ludzie mogą pracować wtedy, kiedy czują, że są najbardziej kreatywni, że mają najwięcej przestrzeni do zrobienia czegoś, że mogą pracować dla wielu różnych firm, bo jest też taki trend, który jest coraz bardziej zauważalny.

Coraz bardziej, mam wrażenie, ta praca będzie musiała być zwinna, żebyśmy byli w stanie jakoś się w nią wpasować, a jednocześnie, żeby ona wpasowała się w nasze życie. I ta zwinność to jest coś, co IT lubi, coś, co pokochało od początku lat 2000. Branża IT ciągle pracuje nad tym, żeby tak naprawdę zrozumieć i zdefiniować, czym ta zwinność jest. Ale z racji tego, że realizujemy projekty, które często są mocno nieprzewidywalne, w stosunku do których nie jesteśmy w stanie powiedzieć, jaki będzie finalny koszt, jaki będzie finalny deadline i tak dalej, to jest to jakoś atrakcyjne dla ludzi, którzy w IT się poruszają. Chciałbym Cię zapytać, czy z Twojego bogatego doświadczenia wynika, że branża rozumie zwinność? Rozumie, czym jest Agile?

Dzięki, że moje doświadczenie nazwałeś bogatym. Jednocześnie mogę mówić tylko za siebie. Trochę faktycznie widziałem, kilka projektów miałem okazję poprowadzić i kilka, kilkanaście zespołów stworzyć, czy być przy ich tworzeniu. Natomiast czy branża rozumie Agile? Znowu — mogę mówić tylko za siebie. Myślę, że świadomość podstaw przeważnie jest. Lubię mówić, że Agile jest prosty, natomiast nie jest łatwy i tutaj raczej pewnie kogo byś nie zapytał, to 9 na 10 osób coś Ci powie na temat Agile’a, chociaż pewnie prędzej na temat Scruma. Ta wiedza gdzieś tam jest. Natomiast czy jest świadomość tego, co to faktycznie robi, po co są te mechaniki, jaki mają też długofalowy wpływ? Na podstawie mojego doświadczenia powiedziałbym, że z tym jest dużo gorzej. Nie chcę uważać się za jakiegoś wielkiego specjalistę, nie mam zbyt wielu certyfikatów, jeśli chodzi chociażby o tę metodykę, natomiast przechodząc kiedyś szkolenie na Scrum Mastera, siłą rzeczy dużo inaczej, pewnie dużo węziej rozumiałem w ogóle to, czym jest Agile, teraz to wygląda trochę inaczej. Więc może tak — moim zdaniem ta świadomość jest niska.

Opowiem może takie 2–3 anegdoty, [śmiech] one dadzą obraz tego, jak to postrzegam. Kilka lat temu był taki artykuł na LinkedInie, już nie pamiętam niestety autora, natomiast on szerokim, szczególnie jak na LinkedIna, echem się odbił, tam było tysiące komentarzy pod tym, ponieważ tytuł był taki bodajże Agile Is Dead czy Scrum Is Dead. Tam pan, głęboko rozczarowany tym, jak praca w Scrumie wygląda, punktował tę metodologię, swoją drogą bardzo sensownie, celnie. Moje rozczarowanie było takie, że kontrargumentów sensownych było naprawdę niewiele w komentarzach. Oczywiście tych wszytkich tysięcy komentarzy nie przejrzałem, natomiast kto się tą metodologią interesuje, to myślę, że jest duża szansa, że skojarzy ten artykuł.

Wracając do tego, jak specjaliści albo użytkownicy Agile’a, ale bardzo pozytywnie do niego nastawieni, komentowali, to miało to trochę znamiona takiego fanatyzmu i ja mam duże uczulenie na takie podejście, ponieważ Agile jest narzędziem. To jest tylko i wyłącznie narzędzie, nic poza tym. To nie jest jakiś niesamowity paradygmat, to nie jest religia, to jest jedno z narzędzi, które, notabene, nie udziela odpowiedzi na niektóre bardzo podstawowe pytania, szczególnie jeśli chodzi o realizację projektu w domenie finansów chociażby. Ma też takie, powiedzmy, śmierdzące lekko miejsca, typu rola Scrum Mastera, typu rola Product Ownera, która w zasadzie w większości projektów, czego zresztą chyba całe stowarzyszenie, bodajże któreś ze Scruma, też ma świadomość, że tutaj jest dużo problemów wokół tego. Ponieważ to, co jest w Scrum Guidzie oficjalnie wyznaczone jako rola Product Ownera, Scrum Mastera to jest jedno, natomiast to, jak to jest później implementowane, to jest zupełnie drugie.

I trzeba postawić pytanie, czy to jest problem w ludziach, czy to jest problem w metodologii. Myślę, że jeżeli powie się, że problem jest w ludziach, to w takim razie po co jest ta metodologia? Metodologia generalnie powinna współdziałać z tym, jak działają ludzie i nie ma tutaj jakiejś super dobrej odpowiedzi na pytanie, dlaczego ten Scrum Master zazwyczaj jest albo Project Managerem, albo jest taki bardzo pasywny, nie podejmuje żadnych decyzji. Oczywiście wiem o servant leadershipie, to jest trochę osobny temat. Ale jeśli chodzi o Product Ownera, dlaczego ten Product Owner zazwyczaj materializuje się w przypadku software house’ów po stronie software house’u, a nie po stronie klienta? Te pytania często pozostają bez jakiejś sensownej odpowiedzi albo odpowiedź brzmi tak, że to jest po prostu źle. No to halo! Czy chcemy mieć rację, czy chcemy rozwiązać problem? To też na to w ten sposób trzeba popatrzeć.

Metodologia generalnie powinna współdziałać z tym, jak działają ludzie i nie ma tutaj jakiejś super dobrej odpowiedzi na pytanie, dlaczego ten Scrum Master zazwyczaj jest albo Project Managerem, albo jest taki bardzo pasywny, nie podejmuje żadnych decyzji. Oczywiście wiem o servant leadershipie, to jest trochę osobny temat. Ale jeśli chodzi o Product Ownera, dlaczego ten Product Owner zazwyczaj materializuje się w przypadku software house’ów po stronie software house’u, a nie po stronie klienta? Te pytania często pozostają bez jakiejś sensownej odpowiedzi.

Jeszcze a propos świadomości, to poleciłbym wszystkim sięgnięcie do korzeni i posłuchanie tych ojców założycieli Scruma. Ja, szkoląc ludzi — nie jest to dużo, ale myślę, że setkę spokojnie udało mi się przeszkolić właśnie z Agile’a, z takich podstaw Scruma również — potrzebuję naprawdę rozumieć, po co to jest. I na przykład pan Jeff Sutherland bodajże (to jest jeden z twórców Scruma) na konferencji dotyczącej z tego, co kojarzę skalowania Scruma powiedział, po co jest Scrum, przypomniał tak naprawdę, po co jest Scrum. Nie wiem, czy wiesz, czy może wszyscy słuchacze kojarzą Prawo Moore’a. Prawo Moore’a generalnie sprowadza się do tego, że patrząc na przykład na koszty tranzystorów na jednym chipie, to im więcej jest tranzystorów na jednym chipie, tym one są tańsze do pewnej granicy. Czyli generalnie miniaturyzacja sprawia, że rzeczy są tańsze.

Oczywiście jeżeli przegniemy, czyli będziemy chcieli zrobić je po prostu mniejsze, niż aktualnie technologia na to pozwala — to znaczy technologia musi na to pozwalać, ale nasza zdolność w operowaniu tą technologią nie jest jeszcze najlepsza — to jeżeli będziemy chcieli schodzić tak bardzo, bardzo nisko, to wtedy te koszty będą dużo wyższe. Natomiast do pewnego stopnia, do pewnego poziomu te koszty spadają. I dokładnie to samo prawo obowiązuje w pracy ze story pointami i z taskami czy user storiesami, gdzie można to sobie przyłożyć w taki sposób, że im więcej jednopunktowych storiesów, tasków, whatever, w jednym sprincie, tym one są tańsze (też do pewnej granicy) i to jest tylko po to, żeby zminimalizować koszty wytwórstwa oprogramowania. Ja wiem, że może tutaj brzmię bardzo mało romantycznie, natomiast trzeba mieć tego świadomość, że ostatecznie to jest właśnie po to.

Inna anegdota a propos świadomości czy takiego zrozumienia Agile’a i trochę też tego fanatyzmu, z którym niestety przyszło mi się zetknąć, który nie służy nigdy. Byłem kiedyś we Wrocławiu na takim Meetupie, też oczywiście a propos Agile’a, i to było chyba o servant leadershipie. Dyskusja jakoś się toczyła, ale to, co mnie zaczęło z minuty na minutę coraz bardziej uwierać, to to, że ja miałem wrażenie, że i prowadzący, i część wypowiadających się unosiła się w jakiejś kolorowej krainie misiów i baloników. Padały takie określenia jak „opiekowanie się problemem”, jak „przyglądanie się problemom”, jak „przytulanie problemów”.

Na litość boską, problemy się rozwiązuje. Jeżeli komukolwiek zależy na popularyzowaniu — nie wiem, czy teraz można mówić o popularyzowaniu Agile’a, bo każdy jakoś go tam zna — ale przynajmniej na prawidłowej jego adopcji czy wdrożeniu, to jeżeli jakiemuś „staremu” menedżerowi mówi się, że my się opiekujemy problemem, to nie jest dobry początek do rozmowy. Kiedy powiedziałem, co o tym sądzę, to może nie uwierzysz, Krzysiu, ale zostałem zlinczowany. Krzyczano do mnie z podium [śmiech], przepraszam za przytaczanie tego, że jestem z PIS-u, rozumiesz? To naprawdę nie pomaga, bardzo mnie to zniechęciło później w ogóle do pojawiania się na takich Meetupach. Co nie znaczy, że ja w Agile nie wierzę, wręcz powiem, że Agile mi kilkukrotnie uratował życie w cudzysłowie, projektowo, organizacyjnie.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-145-zarzadzanie-projektem-i-firma-it-w-obliczu-pracy-zdalnej/

--

--

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store