W tym odcinku zajmuję się odniesieniem popularnych 7 nawyków skutecznego działania w kontekście prowadzenia i uczestnictwa w projektach IT.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 40 - 7 nawyków skutecznego działania w wersji IT.

W tym odcinku kontynuuję temat rozpoczęty w odcinku 39., gdzie omówiłem znane z książki Stevena Covey’a „7 nawyków skutecznego działania”. Jeśli nie miałeś do czynienia z tą książką, to oczywiście zachęcam do odsłuchania tego odcinka. Można powiedzieć, że pauza minęła, to teraz możemy przejść już do tej drugiej, dzisiejszej części. Także cóż, ad rem.

Bądź proaktywny. Jeżeli uczestniczysz w projekcie, jeżeli prowadzisz projekt, tutaj można spojrzeć na to z różnych perspektyw - od programisty aż po całego klienta, z punktu widzenia organizacji, jeżeli projekt, w którym uczestniczysz, a zwłaszcza jeżeli go prowadzisz, to już jakby wyjątkowo jest wtedy istotne - zmierza w złą stronę, jeżeli widzisz, że coś się toczy nie tak, nie przechodź nad tym do porządku dziennego, zgłaszaj to co widzisz. Jeżeli jest to okej praktyką, którą stosuje się w twojej organizacji, to może nawet podejmij się naprawy, choć tutaj to oczywiście zależy od przyjętych procedur. Natomiast na pewno użyj jakiegoś wirtualnego, bądź nawet rzeczywistego dzwoneczka, aby poinformować innych: słuchajcie, jest tu problem, trzeba się nim zająć.

W najgorszym razie, jeżeli ten problem został już zauważony, to po prostu dostaniesz taki feedback, to raczej nie zajmie dużo czasu, a w najlepszym razie zwrócisz uwagę na jakiś istotny problem, który dzięki temu prawdopodobnie zostanie rozwiązany dużo szybciej niż gdyby takie zgłoszenie nie zostało zrobione.

W Makimo ująłem to kiedyś w formie takiej dewizy: drążyć temat i już, zamiast „po co drążyć temat”. To było parę lat temu i ta dewiza mogła być bardziej taka, powiedziałbym, dosłownie i mocno powiedziana, ale sens jest ten sam.

Kwestia druga, podejmuj działania z myślą o celu. No właśnie, jeżeli w danym projekcie realizujesz czy planujesz wykonanie jakiejś funkcji, czy w ogóle nawet realizację całego projektu i dodajesz zadania, zadanie do backlogu projektowego, do jakiejś listy wymagań, to niekoniecznie musi być przecież Agile, to najpierw się zastanów, w jaki sposób to, co właśnie dodajesz, realizuje zasadniczy cel klienta? Jeżeli, powiedzmy, że trudno jest znaleźć powiązanie z tym głównym celem, to cel powinien być rozpisany na jakieś takie cele częściowe czy zasadnicze wymagania, ograniczenia też biznesowe i czy chociaż w taki sposób wpasowuje się to co robisz, właśnie w ten kontekst?

Na przykład, jeżeli klient chce zainstalować sobie jakieś rozszerzenie, jakąś wtyczkę, jakiś mechanizm, który zwiększy konwersję na platformie ecommerce,  to to, co dodajemy, tworzymy, rozwiązanie, które tworzymy, wdrażamy, powinno w pewnym stopniu chociaż przyczynić się ostatecznie do wzrostu konwersji. Albo taki przykład na gorąco, modny temat chatboty, fajnie mieć chatbota, tylko że nie chodzi o to żeby po prostu wrzucić sobie chatbota, może pomoże, tylko zastanowić się, w jaki sposób chatbot może zwiększyć konwersję, pomóc naszym klientom, a koniec końców spowodować zwiększenie przychodu z kanału ecommerce’owego.

Jasne, można na siłę uprzeć się, że posiadanie fajnego chatbota po prostu przykuje uwagę ludzi i zwiększy szum medialny, też jest to coś, ale mimo wszystko, jeżeli już wchodzimy w taki temat, powinniśmy mieć jakieś konkretne cele, które chcemy spełnić.

Można by tu oczywiście znaleźć taki przykład, przykłady, gdzie trzeba zrealizować pewne zadania, które nie będą pozornie związane z tymi celami, czy z tymi wymaganiami, chociażby jak był rok 2018 i wszędzie wdrażano RODO, to znaczy teraz wdrażanie RODO jest czymś oczywistym, kiedy na przykład tworzy się nowa organizacja. Natomiast wtedy trzeba było wdrożyć RODO po prostu we wszystkich istniejących, praktycznie wszystkich istniejących firmach. Ogólnie RODO jest tutaj przykładem dostosowania się do ciągle zmieniających się przepisów prawnych. Ostatnio znacznie bliżej historycznie to była dyrektywa Omnibus, też taki ważny punkt. I można oczywiście powiedzieć, że to nie zwiększy nam przychodu, że będziemy mieli baner z RODO, ale tutaj trzeba na to spojrzeć z innej strony, bo żeby w ogóle móc mówić o przychodzie, o osiąganiu podstawowych celów biznesowych, musimy spełniać pewne konkretne wymogi, jakie stawia na nas ustawodawca, jakie stawia na nas otoczenie biznesowe, gospodarcze. I po prostu, żeby w ogóle mówić o jakimkolwiek przychodzie i realizowaniu go, musimy po prostu spełnić, odhaczyć pewne punkty i w ten sposób też przyczyniamy się do realizacji celu.

Punkt trzeci, czyli ustalanie rozsądnych priorytetów. No tutaj to w zasadzie chyba nie muszę nikogo przekonywać, że w projektach IT dużo częściej zdarza się, że jest zdecydowanie za dużo do zrobienia niż sytuacja, że nie ma co robić, zwłaszcza w kontekście oczywiście budżetu i dostępnych mocy przerobowych. Priorytetyzacja jest więc absolutnie kluczowa, bo z jednej strony chcemy osiągać kolejne cele klienta, tak jak to mówiłem przed chwilą. W przypadku zwłaszcza startupów to jest też taka sytuacja, że bardzo często na wczoraj potrzebna jest przykład nowa funkcja, bo przyszedł nowy duży klient, który może zmienić całkowicie sytuację startupu, ale potrzebuje dopisać do oprogramowania jakąś tam nową funkcję. No a z drugiej strony trzeba też zadbać o długoterminową jakość produktu, na przykład wdrażać refaktoryzację, czyli po prostu usprawniać jakość oprogramowania, zmniejszać też dług technologiczny. Oczywiście, no nie mam na to jakiejś takiej złotej rady, sentencji czy odpowiedzi na taki problem. Natomiast to co warto mieć na względzie to to żeby mieć na podorędziu, mieć w projekcie dobrze zdefiniowane i wartościowe grono interesariuszy, które pozwoli nam podjąć odpowiednią właściwą decyzję w danej sytuacji. Nam się na przykład, ten przykład ze startupami tutaj jeszcze pociągnę, że mamy sytuację, że trzeba zrobić jakąś tam funkcję, czasami udawało się rozwiązać w ten sposób, że gdy podrążyliśmy temat, popytaliśmy faktycznie wszystkie osoby zaangażowane to się okazywało, że na przykład  jednak klient się rozmyślił i nie chcę kupić, to ta funkcja nie jest nam już w tym momencie potrzebna, po jakichś kilku dniach od tego, jak po raz pierwszy wypłynęła. Albo udało się przekonać klienta, że może poczekać na tę funkcję, więc nie ma ciśnienia i gdybyśmy cały czas tkwili tylko w zespole projektowym, no to byśmy tej wiedzy nie mieli, a tak jedno proste zdanie ratuje sytuację.

Czwarty punkt, czyli sytuacje win-win to pozornie temat trudny, no bo tak z prostego punktu widzenia im więcej pracy i rzeczy do zrobienia w projekcie dla dostawcy, czyli taki nasz win, tym większy koszt i czas oczekiwania dla klienta. No to jednak win to to nie jest tylko raczej lose. No i można powiedzieć, że odwrotnie projekt szybki, zrealizowany w szybkim terminie, często może się wiązać z mniejszymi przychodami dla dostawcy, więc też nie jest to sytuacja win-win. No i tutaj po wielu niewątpliwie ciekawych, ale i trudnych doświadczeniach zauważyliśmy, że często w projektach jest tak, że kiedy okazuje się, że trzeba zrealizować nowy projekt albo nawet po prostu jakąś dodatkową funkcję dodać do tego projektu czy obsłużyć jakiś nowy proces biznesowy, nie wiem dodać obsługę jakiegoś działu w firmie, który nie korzystał z systemu to sytuacja dzieje się następująco. Jest jakieś spotkanie, pracownicy klienta czy inni interesariusze opowiadają, jak ten proces jest realizowany w tym momencie, analitycy czy starsi programiści,  różnie to bywa czasami jest to ta sama osoba dokładnie notują to, co ma być zrobione i potem starają się, aby zespół zaimplementował ten proces jak najbardziej idealnie po prostu w 100 %. Ale potem okazuje się, że kiedy mamy już tą analizę i przychodzi do implementacji, to jest to bardzo czasochłonne zadanie, bo czasem takie procesy w organizacjach mają dużo specyficznych, takich rzadko spotykanych, ale jednak ważnych przypadków brzegowych, jakichś warunków, które trzeba spełnić. Przełożenie procesu, do którego się wszyscy przyzwyczaili, który wydawałoby się, że jest prosty, okazuje się, że jest całkiem skomplikowane, a koniec końców oznacza to, że sam proces wcale nie jest taki łatwy.

I zamiast tutaj implementować, tracić czas i pieniądze, i też zamiast generować ryzyko, bo implementacja coraz to bardziej skomplikowanego procesu biznesowego powoduje, że będzie w nim sporo błędów popełnionych podczas implementacji. Można rozważyć, czy samo uproszczenie procesu nie na poziomie technicznym tylko, ale też na poziomie biznesowym czy po prostu zmiana tego, w jaki sposób funkcjonuje firma, nie będzie tutaj lepsza. Pomijam już fakt, że samo oprogramowanie wtedy może powstać szybciej i taniej, ale i pracownicy będą wtedy pracować po prostu efektywniej.

Krok piąty, czy też temat piąty. Zrozum, aby być zrozumianym. Gdy prowadzimy jakieś takie rozmowy wstępne, trochę sprzedażowe, trochę analityczne z klientami na temat nowych funkcji czy na temat nowych projektów, staramy się jak najbardziej wczuć w jego skórę. Jeżeli to jest przedsiębiorca, to wtedy też sami wiemy jak to jest, ale no często są to zupełnie obce dla nas branże, ale mimo wszystko staramy się zrozumieć punkt widzenia.  Podejście do tego, w jaki sposób problemy, które my mamy usprawnić oprogramowaniem, są rozwiązywane do tej pory, często na przykład opowiadając o tym, co klient chce zrobić własnymi słowami. I wtedy, gdy my podejmujemy takie wysiłki, klient to widzi to często też na przykład, gdy przedstawimy ofertę i nie wszystko jest jasne albo co częste wycena okazuje się być zbyt duża, klient też nie powie, okej dobra dzięki za drogo, na razie. Tylko będzie się zastanawiać, w jaki sposób może tą ofertę zmodyfikować, dlaczego właściwie ta oferta jest taka droga. Przyznam szczerze, że miałem kiedyś taki przypadek, że znajomy poprosił o wycenę. Był taki znajomy troszeczkę z kontekstów biznesowych, ale znaliśmy się dosyć krótko, natomiast poprosił mnie właśnie o wycenę oprogramowania, ono było poza budżetem, ale ja właśnie starałem się jak najlepiej z jednej strony zrozumieć to, czego on potrzebuje, a z drugiej wyjaśniłem oczywiście też, skąd wynika ta oferta i on podziękował oczywiście. Natomiast potem wiem, że polecał paru innym osobom, bo właśnie w tak nietypowy sposób dla niego, ale pozytywnie nietypowy, starałem się zrozumieć, o co mu chodzi. A nawet kiedy okazało się, że system nie był na jego możliwości finansowe, to starał się to też, nawet  nie tyle starał się, tylko po prostu zrozumiał skąd to wynika i też chciał nas polecić, żebyśmy mogli pomóc komuś, kto akurat budżetowo będzie do nas lepiej dopasowany.

Punkt numer sześć to synergia. No i tutaj w zasadzie przykładów można by mnożyć, bo od takiego najbardziej przyziemnego chciałoby się rzec jak pair programming, czyli programowanie w parach, projektach informatycznych, zdarza się, że dwie osoby pracują nad tym samym problemem w tym samym czasie, często przy jednym komputerze, teraz też zdarza się, że zdalnie. To z jednej strony oczywiście budzi obawy klientów, jak to dwie osoby na tym samym, to przecież naciągacie mnie na kasę. Ale ile może stała praca w taki sposób to faktycznie nie zawsze jest do obrony, jeśli chodzi o koszty na tyle, zwłaszcza w przypadku trudnych fragmentów czy rozwiązywania też błędów, naprawiania błędów, jest to bezcenne. I wtedy faktycznie, gdyby na przykład dać do analizy i rozwiązania problem jakiś błąd, bug jak to się mówi w programie najpierw jednej osobie, a potem drugiej, to każda z nich spojrzy ze swojej strony. Może ta druga skorzysta z jakiegoś feedbacku pierwszej i będzie miała pomysł lepszy, ale to nie jest gwarantowane.

Jak te dwie osoby będą siedziały razem, to no naprawdę znacznie łatwiej jest wtedy znaleźć błąd. Może się okazać, że na przykład z reguły jest, często bywa tak, że pierwsza osoba na przykład zaczęła pracę nad jakimś problemem utknęła prosi o pomoc drugą, siedzą razem, zaczynają pracować i ta druga wynosi taki powiew świeżości, ale nie tylko to. Mamy burzę mózgów, mamy sesję planning pokerowe do robienia wycen, warsztaty event stormingowe. Naprawdę chodzi mi o wszystkie spotkania, które nie polegają na tym, że jedna osoba mówi, a reszta słucha piąte przez dziesiąte, sprawdzając pocztę w tle. Są takie rodzaje spotkań, które naprawdę potrafią wnieść wiele do projektu i wtedy to, że te osoby pracują razem nad jednym problemem, nad wyceną, nad jakimś problemem do rozwiązania, burzą mózgów do przeprowadzenia. To daje możliwość wyciągnięcia faktycznej synergii, a nie jak to często bywa to słowo używane, taki bardzo mocny bass word, który niewiele wnosi.

No i na koniec tę ten siódmy punkt, ostrzenie piły. W kontekście projektów IT na pewno trzeba w sposób ciągły, nie cały czas, ale regularnie analizować, patrzeć na tyle na ile się da z boku, jak toczy się projekt, co w nim dzieje się, przede wszystkim złego, ale też dobrego, żeby móc docenić osoby czy zespoły, które pracują dobrze. Żeby to nie było po prostu sesję samokrytyki czy krytyki wzajemnej i zresztą metodykę zwinnych w Scrumie mamy na przykład retrospektywy, czyli takie właśnie spotkania poświęcone analizie tego, co się wydarzyło i co można usprawnić. Ale nawet jak nie realizujemy projektu zwinnie, warto rozważyć wdrożenie takich aktywności, bo to też jest takie spotkanie, które naprawdę z naszego doświadczenia wnosi znacznie więcej pożytku niż szkody.

No i tak dobrnęliśmy do końca tego dwuczęściowego odcinka, czyli już nie siedem a czternaście można powiedzieć punktów poruszonych.

Mogę już teraz powiedzieć, że 40 odcinków minęło jak jeden dzień, Ba Dum Tss! Natomiast to jest też taki moment, ja to nagrywam jeszcze w sierpniu, ale te odcinki pewnie gdzieś we wrześniu się pojawią, więc można powiedzieć, że zaczyna się kolejny sezon i rok akademicki przy okazji po wakacjach.

Życzę więc wszystkim słuchaczom i tym, którzy programują i tym, którzy prowadzą projekty i tym, którzy są z biznesu, powodzenia. Pamiętajcie też zawsze zachęcam do kontaktu ze mną, LinkedIn, Facebook, po nazwisku łatwo mnie znaleźć. Zachęcam do dzielenia się swoimi opiniami, jakimiś przemyśleniami czy sugestiami. Ja mam takie taki cel, z góry też przepraszam tych, którzy komentują na YouTube, bo to z jednej strony jest fajna forma, natomiast ja mam odwieczny problem jak to szewc bez butów chodzi sobie, skonfigurować powiadomienia wiec YouTube studio. Ja po prostu zerkam co jakiś czas, staram się te powiadomienia poprawić, ale cały czas to jakoś idzie jak po grudzie, mam nadzieję, że się wreszcie zbiorę w sobie i dobrze to powiadomienia skonfiguruje i będę w stanie szybciej reagować.

A na dziś to już Wszystko. Dziękuję za uwagę. Kłaniam się nisko i do usłyszenia.

KONIEC