Rozwój LLM powoli zaczyna przynosić działające rozwiązania. Pierwsze, które pokazały wartość dwa lata temu były copiloty wspierające programowanie.
Copilot działa w ten sposób, że w trakcie pisania tekstu przez człowieka analizuje treść i co jakiś czas podpowiada, co jeszcze człowiek mógłby chcieć napisać. W przypadku programowania ich efektywność jest olbrzymia i sam korzystam z produktu oferowanego przez Github.
Pomyślałem, że mając bazę wiedzy z plikami firmowymi we Wroolo (wroolo.com), mając model RAG, czyli taki, który semantycznie wyszukuje treści i generuje z nich nowe teksty, mogę uzupełnić go o funkcję copilot. Testowałem copilot, stosując „goły” model GPT-4, ale podpowiedzi były bardzo słabe, oderwane od mojego kontekstu.
Wszystko uległo zmianie rewolucyjnej, gdy podstawą do generowania podpowiedzi były moje własne pliki.
Poniżej wrzuciłem przykład, w którym dokumentami wejściowymi były SIWZ z urzędu miasta. Zadanie natomiast polegało na napisaniu kolejnych fragmentów nowego SIWZ. Jak widać w przypadku formułek prawnych, adresów, typowych paragrafów działa to naprawdę nieźle.
Tutaj można sobie zobaczyć przykład dla generowania oferty na szkolenie. Na wejściu wrzuciłem trzy pliki z ofertami na Massawę i zacząłem chwilę później pisać ofertę. Jak widać w wielu fragmentach algorytm trafnie wybierał treści ze źródłowych dokumentów i mi je podpowiadał. Przyjrzyjcie się, jak komponuje akapit na temat mojej osoby i mojego wspólnika Pawła.
Niesamowite jest to, że wystarczyły mi 3-5 plików źródłowych, aby podpowiedzi stały się naprawdę wartościowe. Problemów jest kilka:
Wydajność – na każdą podpowiedź trzeba czekać około 2-5 sekund. Rozwiązanie tutaj może być postawienie LLM lokalnie, albo poczekanie aż GPT stanie się szybszy.
Koszt – to jest chyba największy problem. Za każdym razem, gdy generowana jest podpowiedź, do GPT wysyłany jest bardzo długi prompt. Przygotowanie powyższych tekstów kosztowało około 1 dolara. To dużo, gdyby chcieć to wykorzystywać na codzień. Ale… ceny LLM spadają drastycznie, albo może postawić go lokalnie i mieć za darmo.
Poufność – wpisywane treści, jak i dokumenty wysyłane są do GPT i do chmury Google. To niekiedy może być przeszkodą, jednak rozwiązaniem znowu może być postawienie takiego rozwiązania lokalnie.
Jakość – około 10-20% podpowiedzi jest bez sensu. Ewidentnie wydłużenie prompta poprawia jakość, ale wpływa to na koszty i wydajność. Rozwiązaniem może być tutaj poczekanie na lepsze modele lub postawienie LLM lokalnie.
Podsumowując, moim zdaniem, gdziekolwiek w pracy pojawia się potrzeba pisania tekstów podobnych do już kiedyś napisanych tekstów, copiloty zawojują rynek. Przy programowaniu przyśpiesza mi to pracę już dzisiaj o około 20%. A pomyślmy, jak może to pomóc przy pisaniu pism do klientów, umów, prezentacji, notatek ze spotkań, dokumentacji wymagań, specyfikacji stanowisk, instrukcji, odpowiedzi na reklamacje itd.
Mam też wizję stworzenia copilota do rysowania diagramów procesowych. Gdyby to dobrze działało, byłoby niesamowitym wsparcie dla analityków. Wyobraźcie sobie, że człowiek wgrywa dostępną dokumentację, zaczyna rysować i system sam proponuje mu co wstawić w kolejnym kroku, i robi to poprawnie na chociaż 80%.
Ps.
Ze względu na koszty copilot we Wroolo jest dostępny tylko dla niektórych użytkowników.
(ten artykuł jest częścią książki Bardziej niż Agile, która ukaże się w 2023 roku)
Pierwszy hackathon został zorganizowany w 1999 roku w ramach konferencji OpenBSD. Dzisiaj Hackathon to krótki, zwykle dwudniowy, maraton, w trakcie którego zespoły rywalizują przy tworzeniu różnych rozwiązań technicznych. Najczęściej hackathony dotyczą technologii programistycznych, choć można spotkać również takie, które skupiają się na tworzeniu prototypów urządzeń. Największy w Polsce, a według organizatorów również w Europie to Hackyeah, które miałem okazję być uczestnikiem w 2022 roku jako mentor.
Istnieją hackathony otwarte, w których mogą wziąć udział wszyscy chętni i hackathony zamknięte, organizowane w ramach wybranej korporacji (takie na przykład organizuje ING). Są hackathony zdalne i stacjonarne, te ostatnie w opinii większości moich rozmówców mają gigantyczną przewagę zaangażowania i atmosfery zabawy oraz rywalizacji.
Hackathony to oprócz zabawy dla uczestników, świetne narzędzie budowania profesjonalnego wizerunku dla patronów fundujących nagrody oraz dla pracodawców osób startujących w nich. Przez duże organizacje te konkursy są również tanią metodą wytestowania różnych ryzykownych koncepcji. Wystarczy zgłosić swoją potrzebę na konkurs, zafundować nagrodę i liczyć na to, że zgłosi się kilka zespołów, które spróbują zmierzyć się z wyzwaniem.
Mały zespół
Typowy zespół na hackathonie ma trzy do siedmiu osób. Ważne jest, aby pokryć kompetencjami wszystkie krytyczne obszary. Na przykład w przypadku hackathonów programistycznych takie obszary to:
Przygotowanie prezentacji
Grafika i interfejs użytkownika
Technologie frontendowe
Technologie backendowe
Obsługa urządzeń, jeżeli takowe jest konieczne
Przygotowanie danych, na przykład w przypadku rozwiązań z zakresu sztucznej inteligencji
Koordynacja całości
Zdobywanie wiedzy od mentorów i jury
Jeżeli zespół się nie zna za dobrze, to może wypisać na tablicy, co każdy potrafi, w jaki sposób może pomóc w projekcie.
Jeżeli masz luki kompetencyjne w zespole. Jasno to zapisz na samym początku projektu i przedyskutuj, jak je wypełnić. Naturalnym adresem będą mentorzy krążący po sali. Warto ich eksploatować maksymalnie, jak się da.
Pewnie temu tematowi warto by poświęcić osobny rozdział, ale efektywność zdobywania wiedzy bardzo podnosi aktywne zadawanie pytań i głośne przyznawanie się do swojej ignorancji. Dopóki otoczenie nie wie, że potrzebujesz pomocy, nie będzie wiedziało, że powinno ci pomóc. Rzadko zdarza się, aby ktoś podszedł i zagadnął: “czy przypadkiem nie jesteś zagubiony i nie trzeba ci pomóc?”. Po prostu pytaj. W najgorszym przypadku ktoś powie, że nie wie, albo nie ma czasu.
Product owner
To, co różni zespoły zmierzające ku klęsce od tych z potencjałem na zwycięstwo był brak lub obecność kogoś, kto pilnowałby wizji produktu.
Product owner dba o to, aby zespół zajmował się właściwymi zadaniami i nie odpłynął zabawy z technologią. Pilnuje też czasu i reaguje, gdy trzeba ciąć zakres, bo inaczej zespół nie zdąży z demonstracją.
Rekrutuj dla motywacji
Ciężko przecenić wagę zgranego zespołu. Motywacja wewnętrzna jest krytyczna dla innowacyjność. Niemal wszyscy rozmówcy podkreślali jej wagę i wskazują na to dziesiątki badań.
Źródeł wewnętrznej motywacji jest kilka:
Nauka i poznawanie nieznanego – “Fajne jest wzięcie maczety i pójście przez dżunglę na przełaj”.
Atmosfera zabawy i rywalizacji – najlepiej zilustrują tą tezę cytaty uczestników hackathonów: “będzie co opowiadać wnukom”, “można poznać ciekawych ludzi”, “na hackathonach zawsze dają darmową pizzę, a człowiekowi najlepiej się pracuje na darmowej pizzy!”, “spędzić czas razem”, “ znamy i się lubimy, i mamy zajawkę na punkcie robienia hackathonów”.
Misyjność, poczucie wpływu na świat – misji poświęciłem następny akapit, ale podsumowując ludzie lubią odnajdywać głębszy sens w tym, co robią. Dotyczy to w większym stopniu aktywności, które nie są wynagradzane czynnikami zewnętrznymi takimi, jak płaca.
Jednak po wielu rozmowach doszedłem do wniosku, że nie istnieją proste i szybkie metody zbudowania motywacji wewnętrznej. Albo ktoś ją ma na starcie, albo jej nie zbuduje w sobie w trakcie hackathonu i tyle. Z tego między innymi powodu taką przewagę mają zespoły, które wcześniej się poznały i miały szansę współpracować.
Znajdź misję
Dużo przyjemniej buduje się system, który ma zredukować ilość śmieci w środowisku niż system oceny wiarygodności kredytowej klientów. Oba to duże wyzwanie intelektualne, ale ten pierwszy ma dodatkowo misję.
Rozpoznaj kryteria i preferencje jury
Niuanse zapisane są czasem między wierszami. Szczególnie na początku, na etapie analizy wymagań i wymyślania koncepcji, koniecznie zaangażuj członków jury. Gdy porozmawiasz z nimi, dowiesz się więcej niż to, co zostało zapisane w oficjalnych kryteriach konkursowych.
Warto zrozumieć też intencje, które stały za zleceniem danego tematu konkursowego. Skąd on się wziął? Z drugiej strony opłaca się poznać członków jury i zrozumieć ich osobiste preferencje. Czy prezentacja koncepcji jest ważniejsza, czy może proof of concept?
Wracam też do tezy, że pytając, można uzyskać dużo więcej wiedzy, niż pasywnie czekając na pomoc.
Spotkaj się w tym samym miejscu
“Człowiek przejdzie kółko wokół laptopów, popatrzy w cudzy monitor i powie “hej, ja też miałem taki problem.” – potwierdził jeden z wielokrotnych zwycięzców hackathonów programistycznych. “Praca zdalna obniża motywację do siedzenia po nocy.”
Moi rozmówcy podkreślali, że nawet gdy hackathon organizowany był w formule zdalnej to i tak zespół spotykał się w biurze lub w jednym mieszkaniu.
Duża intensywność prac w połączeniu ze zmęczeniem i innowacyjnością rozwiązań i tak stanowią spore wyzwanie. Nie warto dokładać do tego ograniczeń komunikacyjnych.
Poza tym włącza się jeszcze efekt facylitacyjny, albo syndrom “jechania na jednym wózku”. Gdy widzę, jak inni dookoła intensywnie pracują, to samemu mi głupio odstawać. W projekcie Arystoteles Google’a dowiedziono, że był to jeden z najważniejszych czynników efektywności zespołów IT.
Cykl życia projektu
Analiza wymagań konkursowych
Burza mózgów na temat koncepcji – przez około godzinę do dwóch ludzie rzucają pomysły na projekt. “Trzeba wymyślić, coś czego nie ma i bardzo wielu ludzi boli ten brak”. Następnie trzeba zagłosować na najlepszy. Niektóre zespoły przygotowują prosty lean canvas, aby pokazać wszystkie aspekty pomysłu.
Szukanie źródeł wiedzy – jedną z dużych przewag jest ustalenie, czy ktoś, czegoś podobnego już kiedyś nie zrobił. Znalezienie analogii drastycznie redukuje ryzyko projektu. Źródłem może być internet, na przykład serwisy o startupach, poprzednie hackathony, serwisy z fragmentami kodów. Szczególnym źródłem są też mentorzy krążący po sali, bo z reguły mają sporą wiedzę dziedzinową.
Strukturalizacja pomysłu – od jednej do dwóch godzin trwa podzielenie wybranego pomysłu na części problemowe. Kryterium może być podział na eksperymenty do przeprowadzenia, albo główne zadania, albo różne technologie do użycia w rozwiązaniu. Efektem strukturalizacji jest przypisanie zadań do ludzi. Nie chodzi o to, aby mieć plan projektu do końca, tylko chodzi o to, aby zacząć jak najszybciej od najważniejszych rzeczy. Później ten plan będzie co godzinę ulegał zmianie, albo wręcz wyląduje w koszu, gdy pojawi się nowy pomysł.
Produkcja – w kolejnym akapicie bardziej szczegółowo opisują jak zorganizować ten etap. Należy tylko wspomnieć, że w każdej chwili projekt może zostać zatrzymany i postawiony na głowie. Szczególnie, gdy okaże się, że pomysł jest niewykonalny albo zabraknie czasu.
Przygotowanie prezentacji – jedni mówią, że prezentacja powinna powstawać od samego początku hackathonu, inni, że od połowy prac, jeszcze inni, że poświęcają na nią ostatnie dwie godziny. Tak, czy siak to prezentacja w dużej mierze decyduje o zwycięstwie i nie można o niej zapomnieć.
Schematyczna prezentacja przebiegu projektu w trakcie hackathonu.
To co chciałem pokazać to, że pierwsza część projektu nie jest wcale poświęcana na prace. Niektórzy rozmówcy wręcz wskazywali, że nawet połowę czasu zajmuje wymyślanie i strukturalizacja koncepcji. Po drugie prace produkcyjne przebiegają równolegle w zmiennym rytmie. Jedne wątki toczą się w rytmie częstych wydań i krótkich zadań, bo taka jest ich natura. Inne są zupełnie nieprzewidywalne. Czasem przetwarzanie danych może zająć kwadrans, a czasem trzy godziny. To oznacza w konsekwencji, że niemożliwe jest zastosowanie wspólnych sprintów o stałej długości.
Co godzinę przegląd
Zespół co godzinę odkłada zadania dosłownie na pięć minut i omawia stan prac. Jak jest tablica kanban, to przestawia zadania na niej, jak jest Slack to wpisuje ustalenia, a jak nie ma nic, to po prostu dyskutuje. Główny problem przed zespołem to ten, czy zdąży przygotować rozwiązania na czas. I upewnienie się, że tak będzie jest głównym celem przeglądu projektu. “Czy z tym, co macie zrobić zdążycie do końca? Jeżeli nie, to dyskusja o redukcji zakresu i ewentualnie zmianie koncepcji.”.
Jeżeli zidentyfikowano problem techniczny, to dedykowani członkowie zespołu omawiają go, a reszta wraca do roboty. Jeden z rozmówców podrzucił następujący pomysł na podział każdej godziny produkcyjnej: około czterdziestu minut pracy w słuchawkach, wtedy sobie nie przeszkadzamy, a potem wszyscy je zdejmuje i trwa dalsza praca połączona z dyskusją.
Skup się na prezentacji
Daj sobie czas przed końcem hackathonu na doprowadzenie rozwiązania do poziomu, na którym można cokolwiek pokazać. Wielokrotnie zdarzało się, że zespoły najbardziej zaawansowane w obszarze technologicznym nie zdążały na koniec dopiąć rozwiązania i doprowadzić go do stanu, w którym można by cokolwiek zademonstrować.
“Kręcenie filmów jako elementu końcowej prezentacji mocno działa na korzyść.” – podkreślił mój rozmówca. – “Widzieliśmy dużo słabych prezentacji, na przykład gdy ludzie skupiają się na technikaliach (nikogo to nie interesuje), lub pokazują powerpointa z dziesięcioma tysiącami punktów (nie sprzedażowa), albo brakuje treści a jest tylko sama prezentacja, lub prezenter nie potrafi przekazać wartości pomysłu, niekiedy zespół nawet zrobi fajną prezentację, ale nie pokaże głównej idei i korzyści z pomysłu, zakładając, że jury domyśli się szczegółów (tzw. klątwa wiedzy).”
“Prezentacje trzeba robić od początku hackathonu. Nieważne, ile się zrobi przez 24h i tak cała robota sprowadza się do trzech minut prezentacji.”
“Ważne jest też, aby zrobić próby prezentacji.” Sama forma pokazania jest istotna w kontekście oceny rozwiązania przez jury.
Zarządzaj snem i frustracją
Hackathon to przede wszystkim zabawa. Bez dobrej atmosfery nic się nie będzie kleić.
“Gdy raz nie spałem, to prezentacja, którą wówczas przygotowałem była jedną z najgorszych. Trzeba spać w trakcie hackathonu.” “Na początku jest euforia, potem jest dołek, bo nie wychodzi, wszystko leży. Warto mieć świadomość istnienia takiego cyklu emocjonalnego.” “Nie spanie jest największym błędem.”
Warto z góry zaplanować, ile czasu członkowie zespołu poświęcą na sen i wyznaczyć szychty. Ktoś, kto przygotowuje prezentację powinien być wypoczęty na koniec, ktoś kto testuje koncepcję musi od razu być aktywny. Jednak każdy musi w pewnym momencie odpocząć. Im umysł jest bardziej zmęczony, to staje się mniej elastyczny i otwarty na nowe informacje. To prowadzi do konfliktów.
Poniżej hackathon o drugiej w nocy, ja idę spać, oni walczą. 🙂
Żaden Scrum, Kanban!
“Scrum nie nadaje się, bo to jest za krótki projekt!” Bo nie ma czasu na sprinty – hackathon trwa od jednego dnia do dwóch zwykle. Sprint musiałby trwać dwie godziny. A organizowanie w jego trakcie planningów, review i retrospektyw stałoby się obciążającą biurokracją.
Bo prace trwają różnych rytmie – jeden obszar składa się z zadań po kwadrans, a w innym przez pół dnia opracowuje się koncepcję.
Bo nie ma inkrementu – jest tylko pomysł, lub kulawe rozwiązanie, które ma błędy, albo jedynie koncepcja w powerpoint. Jakość w hackathon schodzi na dalszy plan, celem jest zademonstrowanie fajnego prototypu.
Bo nie da się estymować – ludzie co najwyżej mówią “zdążę z tym, a z tym to chyba nie zdążę”. Jakakolwiek próba oszacowania wydajności zespołu i pracochłonności zadań mijałaby się ze zdrowym rozsądkiem. Po prostu trzeba zacząć robić i zobaczyć, jak nam wychodzi.
Natomiast pomaga pokazanie zadań na wspólnej tablicy. Ustalenie, które z nich są priorytetowe, bo mają największy wpływ na końcową ocenę rozwiązania, albo bo są najbardziej żmudne lub niepewne i wymagają eksperymentów. Pomaga też przydzielenie najbliższych zadań konkretnym członkom zespołu, aby maksymalnie wykorzystać ich produktywność.
Przywództwo zwinno – autokratyczne
Kiedy nagle ktoś z zespołu, nikomu nic nie mówiąc, wybiera się spać, potrzebna jest osoba z charyzmą, która utrzyma zespół w ryzach. Ten i wiele innych czynników występujących w takim projekcie powoduje, że samo przywództwo zwinne to za mało:
Gigantyczna presja czasu
Zmęczenie
Częste pivoty
Niska jakość
Braki wiedzy technicznej
Na druga rękę potrzebny jest przyjazny dyktator z wizją całości.
Upraszczając, mamy dwa style liderskie i dwie sytuacje z perspektywy menedżerskiej w trakcie hackathonu:
Wszystko idzie zgodnie z planem – zespół wie, co ma robić, zadania zostały jasno podzielone, wizja rozwiązania jest wykonalna i atrakcyjna, atmosfera pozytywna i nikt stanął pod ścianą braku kompetencji. W takiej sytuacji działa servant leader. Przygląda się, pyta, czy może pomóc, usuwa przeszkody sprzed drogi projektu, upewnia się, że zespół jest zsynchronizowany, ale działa raczej w trybie coachingowym niż dyrektywnym. Na przykład “co sądzicie o takim pomyśle, czy coś jeszcze można tu poprawić?”, a nie “to nie zadziała, ty musisz jeszcze raz na to spojrzeć”.
Projekt stoi na rozdrożu – koncepcja okazała się niewykonalna, albo istnieje więcej niż jedna koncepcja na stole i trzeba wybrać, zespołowi siadło zaangażowanie, ludzie są zmęczeni, pojawiły się konflikty personalne. Wtedy wkracza przyjazny dyktator. Wysłuchuje opinii i przekonuje zespół do jednej koncepcji. Rozprawia się z konfliktami w zespole. Wywiera presję na tych, którym wszystko opadło. Kluczem jest czas reakcji. Zespół musi mieć szybko nową wizję. Jeden z rozmówców wprost mówił o “leciutkiej dyktaturze”: “Jedna osoba powinna mieć wizję i wymuszać ją na zespole do końca. Autokrata, który ma mapę w głowie i pilnuje, aby nie odpłynąć w pomysłach.”
Tu należy tylko uważać, aby ręcznym sterowaniem projektem nie zabić zaangażowania zespołu. Idealnie, gdy zespół jednomyślnie zagłosuje za decyzję o porzuceniu starej koncepcji na rzecz nowej. Jeżeli jednak nie ma zgody, to lider przynajmniej powinien wyczerpująco uzasadnić swoją decyzję. A najlepiej jeżeli dysponuje takim autorytetem, że przekona wszystkich do swojej perspektywy.
Z reguły lider zespołu, ów zwinno – autokratyczny przywódca, jest też odpowiedzialny za komunikację z mentorami i jury oraz przygotowanie prezentacji. Zatem idealnie, gdy lider rozumie technologię, ale i biznes. Wie, jakie wymagania będą krytyczne z perspektywy oceny pomysłu, a jakie mimo technologicznej atrakcyjności, można odłożyć.
Wędrując jako mentor po sali Hackyeah, gdzie kilka tysięcy inżynierów tworzyło rozwiązania, rzucił mi się w oczy jeden brak. Nigdzie nie było białej tablicy. Ludzie przywozili komputery, wielkie monitory, słuchawki, maskotki jak na przykład średniowieczny szyszak, czy mandolina, ale nikt nie przywiózł tablicy, na której zespół mógłby notować, omawiać i rozbijać problemy na małe części. Uważam, że w trakcie fazy tworzenia koncepcji mogłaby szalenie pomóc skupić uwagę na właściwych zagadnieniach.
Przydatne narzędzia
Tablica Kanban – to może być po prostu tablica, jeżeli zespół siedzi w biurze lub narzędzie typu Trello, Jira.
Lista dyskusyjna – mimo, że ludzie zwykle siedzą koło siebie, to i tak używają oprogramowania do rozmowy, jak Slack, Messenger, Whatsapp, czy Discord. Przewaga polega na tym, że na zadane pytanie mogę odpowiedzieć za dwie minuty, gdy uporam się z jakimś problemem, więc mniej mnie to rozprasza. Poza tym na liście dyskusyjnej zostają zapiski poprzednich ustaleń i można do nich wrócić bez angażowania członków zespołu. Można tam też wrzucać linki, kawałki kodu, obrazki, próbki prezentacji itd. Wszystko w jednym miejscu.
Wspólne repozytorium – w przypadku hackathonów programistycznych dobrze jest trzymać kod w jednym miejscu (Github) i zarządzać wersjami, szczególnie gdy rozwiązanie ma wiele powiązanych modułów. Choć pojawiły się też głosy, że za mało czasu jest na stosowanie repozytorium. Kod po prostu łatwiej jest przesłać na czasie.
Burza mózgów – jedni stosują mapy myśli (np. XMind), inni affinity diagram (np. biała tablica lub kartka), jeszcze inni rysują makiety ekranów (np. Figma) i procesy (np. Draw.io). Ważne, aby dane narzędzie “przykleiło się” do zespołu i faktycznie było użyteczne w danym wyzwaniu.
Typowe błędy
Za duże rozwiązanie
Jeden z uczestników hackathonów napisał, że obowiązuje tu zasada Pi razy oko – wszystkie estymacje musisz pomnożyć razy trzy. To oznacza, że trzeba brać do realizacji koncepcje trzy razy mniejsze niż by się nam wydawało, że damy radę. Lepiej zrobić coś małego niż nie zrobić nic. Na Hackyeah 2022 około dziesięciu procent zespołów nie oddało nic. Absolutnie nic, nawet nie zrobiło prezentacji.
Wystarczy, że zrobisz cokolwiek a już przeskakujesz tych dziesięć procent rywali.
Dla ominięcia tej pułapki kluczowa jest rola product ownera.
Brak czasu na przygotowanie prezentację i jej przetestowanie
Czasem zespół tak mocno wkręci się w produkcję, że albo nie zdąży przemyśleć prezentacji, albo nie przygotuje się do niej.
Tu trzeba sprzedać rozwiązanie. Pierwszym etapem oceny jest zwykle głosowanie jury lub mentorów na podstawie prezentacji w PDF, filmików lub slajdów. A drugim demonstrowanie osobiste rozwiązania.
Juror ma tylko kilka minut na rzucenie okiem na projekt, bo projektów może być nawet sto. Więc prezentację trzeba tak przygotować, aby w kilkanaście sekund człowiek dał radę zrozumieć, o co chodzi, jaka jest wartość, jak to działa i na jakim etapie jest produkcja rozwiązania.
Szczególnie do drugiego etapu oceny trzeba się przygotować osobiście, bo to jest trochę taki teatr. Ważna jest nie tylko treść, ale i sposób przekazania zamysłu stojącego za rozwiązaniem.
Nie przedstawienie w prezentacji, co chodzi w rozwiązaniu
Klątwa wiedzy objawia się tym, że zespół tak dobrze jest zaznajomiony ze swoim rozwiązaniem, że zapomina opowiedzieć o nim jurorom. Zakłada, że wszystko jest oczywiste. Nie jest, szczególnie, jeżeli juror ma tylko dwie minuty na ocenę pojedynczego projektu.
Przy niektórych projektach musiałem zdrowo się nagłówkować, jaką koncepcję miał zespół. Jedyne, co wyczytałem z prezentacji, to że Ziemia jest zaśmiecona, ludziom się to nie podoba i zobaczyłem kilka klimatycznych zdjęć ze stocka.
Zaprezentowanie tylko slajdów bez rozwiązania
Wcześniej wspomniałem o konieczności przygotowania się do prezentowania przed jury. Na drugim końcu osi pułapek jest zrobienie samej prezentacji bez rozwiązania. Około dwudziestu procent projektów nie pokazało samego projektu. Mogliśmy tylko poczytać o tym, jak to zespół wyobraża sobie rozwiązanie w przyszłości i jakie mógłby mieć zamierzenia. To nie buduje wiarygodności.
Skupienie się na drobiazgach
Wiecie, jaka była najczęściej implementowana funkcjonalność aplikacji na Hackyeah? Ekran logowania! Coś, co nie zmienia wartości pomysłu, nie wyróżnia i jest całkowicie oczywiste. Inny przykład to formularz rejestracyjny. Po co do oceny koncepcji prototypu produkować stronę z rejestracją użytkownika? Wystarczy przecież jeden testowy użytkownik do zademonstrowania rozwiązania. Jeszcze brakuje tylko funkcji “przypomnij hasło”.
Z przyjemnością informujemy, że dołączyliśmy do grona partnerów konferencji Management 360, która odbędzie się w dniach 24-25 października we Wrocławiu! Przesyłamy krótką informację o tym wydarzeniu od organizatora:
„Dzięki udziałowi w interaktywnych warsztatach zdobędziesz umiejętności w zakresie wykorzystania Visual Thinking w środowisku biznesowym, nauczysz się posługiwać się prostymi i zarazem potężnymi narzędziami Product Ownera: (Impact Mapping i Story Mapping, poznasz techniki i narzędzia monitorowania projektów w organizacji, a dzięki serii sprawdzonych i unikalnych ćwiczeń poczujesz na własnej skórze czym jest agile!
Drugi dzień to prelekcje ekspertów!
jak budować skuteczny zespół projektowy realizujący najtrudniejsze wyzwania,
jaka jest rola PMO w projektach agile,
jakie są pułapki zwinnych transformacji,
czym Project Manager różni się od producenta,
kto ponosi odpowiedzialność za jakość User Experience w projektach,
Pierwsze ze szkoleń odbędzie się w Poznaniu 4-8 lutego. Będzie to przygotowanie do PMP po polsku. Edycja wyjątkowa, bo trwająca aż 5 dni, więc będzie czas, aby dogłębnie omówić nie tylko aspekty kaskadowe prowadzenia projektów, ale i zwinne. Po raz pierwszy też wykorzystamy w pełni nasz najnowszy symulator prowadzenia zwinnego projektu.
Drugie ze szkoleń to kolejna edycja Szkoły Project Managera. Pierwszy zjazd będzie miał miejsce 19-20 stycznia we Wrocławiu. To już VII edycja naszych studiów podyplomowych.
Mamy już minimalne grupy, więc terminy są finalnie potwierdzone. Zapraszamy do zapisywania się.
Przez lata miałem szansę poczuć, jak bardzo racjonalne i sensowne mogą być zachowania ludzi w biznesie. Jak bardzo potrafią kierować się rozumem i profesjonalizmem. Jednak niekiedy sytuacja wymykała się spod kontroli i robiło się, to chyba najwłaściwsze słowo, dziwnie. Osobliwość niektórych sytuacji była tak bardzo unikalna, że nawet nie istniały precyzyjne terminy, aby je nazwać. Postanowiłem je przywołać z pamięci i nadać im profesjonalny sznyt, czyli stworzyć fachowe terminy. Terminów tych można by potem używać przy okazji tworzenia wybujałych prezentacji biznesowych, czyli dawać upust rokokofilii.
Wyobraźmy sobie firmę, która startuje w przetargach, wszystko jedno, czy publicznych, czy prywatnych. Schemat przygotowania oferty wyglądać może mniej więcej tak. Pojawia się zapytanie od potencjalnego klienta. Firma ustala zakres zlecenia, a następnie szacuje koszty. Uzyskuje tym samym koszty bezpośrednie projektu, czyli koszty, które bezpośrednio można przypisać do elementów zakresu. Następnie dodaje marżę na ogół w postaci procentów. Te procenty marży wynikają, albo z przyjętej polityki cenowej, np. u nas zawsze bierzemy 30%. Albo ze znajomości konkretnego klienta, np. klient może szeptem podpowiedzieć, że w tym projekcie konkurencja dała cenę 100 tysięcy złotych, co przy naszych kosztach da nam 15% marży. Klient też wprost może oznajmić – chcę wydać na ten kontrakt maksymalnie 120 tysięcy.
Załóżmy, że firma policzyła, że wytworzenie wszystkich elementów WBS będzie kosztowało 100 tysięcy. W tym znajduje się praca ludzka, materiały, narzędzia, które trzeba zakupić do projektu.
Przyjmijmy także, że firma oczekuje od swoich projektów marży na poziomie 50%. W niektórych branżach to dość wysoki poziom zysków. Zatem podaje klientowi cenę 150 tysięcy złotych. Handlowiec zaciera ręce, naczelne kierownictwo się cieszy. Klient też się ucieszył i podpisał kontrakt typu fixed price na kwotę 150 tysięcy.
Tą marże nazwałbym marżą teoretyczną, bezpośrednią. Ponieważ uwzględnia ona tylko bezpośrednie koszty i wstępne założenia projektowe.
Marża druga
Nasza firma zapomniała, że koszty bezpośrednie to nie jest całość wydatków na projekt. Są jeszcze takie rzeczy, jak: praca kierownika projektu, dyrektora produkcji, marketingu, premia handlowca i całego zespołu, szkolenia związane z projektem, raty za maszyny używane w projekcie i wiele innych. Założmy, że w naszej firmie kierownik projektu ma 4 zlecenia naraz i na ten konkretny planuje poświęcić 20 dni po 300 zł. za dzień, handlowiec otrzyma 2% ceny, zespół zaś 3% planowanego budżetu bezpośredniego. Zatem koszty pośrednie wynoszą 12 tysięcy złotych.
W firmie są też koszty ogólne takie, jak marketing, księgowość, kadry, administracja, których nie można wprost przypisać do projektu, ale bez których firma nie mogłaby istnieć. Dobrą praktyką jest zrzucanie się projektów na te koszty. Załóżmy, że w przykładowej firmie nie ma jawnej zasady zrzucania się na projekt. Jednak w ciągu roku firma realizuje przychód na projektach na poziomi 10 miliona, zatem nasz projekt stanowi 1,5% w przychodach. Koszty ogólne niech wyniosą 200 tysięcy, 15% z tej kwoty to 3 tysiące.
W efekcie marża całkowita, teoretyczna wynosi juz tylko 1 – 150 / 115 = 30%. Tyle naprawdę firma spodziewa się otrzymać za ten projekt.
Marża trzecia
Projekt ruszył. W trakcie projektu okazuje się, że pewne prace były niepewnie wycenione. W jednych zadaniach rośnie pracochłonność, w innych więcej materiału się zużyło, w jeszcze innych z powodu opóźnień trzeba było wynająć dodatkowych ludzi. W końcu sam klient zgłasza drobne uwagi, drobne, czyli nie kosztujące nic a nic pracy. Sporo firm nie prowadzi regularnych przeglądów projektów, nie zbiera co miesiąc lub częściej danych o kosztach wykonania. Nikomu to nie przeszkadza. Wszak ludzie są na etacie, więc swoją pensję otrzymują, zewnętrzni kontraktorzy mogą się jedynie cieszyć z dodatkowych zleceń, a dodatkowo zużytym materiałom już nic nie przeszkadza.
W rzeczywistości jednak zmianę widać w tempie prac firmy. Otóż nasze przedsiębiorstwo wciąż wydaje tyle samo, tylko niestety kolejny projekt, który mogłaby rozpocząć w niewidoczny jeszcze sposób opóźnia się. A to oznacza opóźnienie przychodów. Pierwsze dodatkowe koszty uwidocznią się w firmie, gdy minie termin płatności faktury dla zewnętrznych podwykonawców. A także, gdy trzeba będzie uzupełnić magazyn materiałów, jednak przy większych zapasach to może nastąpić za kilka tygodni dopiero.
Przyjmijmy, że w niewidzialny narazie sposób w projekcie wydano doatkowo 40 dni po 300 zł. za dzień oraz 2000 zł. na materiały. Zatem koszty rosną do 114 tysięcy złotych, a marża spada do 24%.
Tą marże nazwałbym marżą praktyczną, bezpośrednią. Marża praktyczna ma to do siebie, że cały czas się zmienia. Z każdym dniem wydaje złotówki nieco inaczej niż zaplanowaliśmy. Dodatkowe spotkanie? Ciach – 1000 zł. Ekstra wyjazd do klienta? Trach – 2000 zł. Zepsuty prototyp? Bam – 3000 zł. Regularne raportowanie daje nam wgląd, jak zmienia się marża praktyczna w naszym przedsięwzięciu. Dlaczego to jest istotne? Ano dlatego, że jedną z typowych patologii w projektach jest tzw. pełzanie zakresu, które powoduje powolne zjadanie marży. Dzięki raportowaniu wiemy, kiedy przerwać prace i albo skasować projekt, albo całkowicie przebudować formułę pracy nad nim. W przeciwnym wypadku zmierzamy ku klęsce.
Marża czwarta
Jak się pewnie domyślacie, będzie to marża praktyczna, całkowita. Jeżeli po drodze zaangażowanie kierownika projektu będzie jednak większe (np. 30 dni), i okaże się, że więcej czasu trzeba spędzić na określonej maszynie (przeliczony dodatkowy koszt 1 tysiąc), albo firma w ciągu roku zrealizuje przychód nie na poziomie 10 milionów tylko 8 milionów złotych, to marża praktyczna, całkowita spadnie znacząco.
W naszym przykładzie dodatkowe koszty wyniosą. Udział w przychodach 200 tysięcy / 8 milionów = 2,5%, czyli 5 tysięcy złotych. Koszt kierownika projektu to ekstra 3 tysiące a maszyny 1 tysiąc. W efekcie razem daje to koszt faktyczny 114 tysięcy + 9 tysięcy = 123 tysiące. I marże na poziomie 1 – 150 / 123 = 22%.
Marża piąta
Ale to nie koniec przygody z projektem. Przyjmijmy optymistycznie, że projekt się skończył i finalnie koszty całkowite wyniosły 123 tysiące, jak to podano powyżej. Jednak dwa miesiące po oddaniu projektu klient zgłosił drobną reklamację. Banał, wystarczy pojechać na krótkie spotkanie, wysłuchać uwag, naprawić i dostarczyć poprawkę, łącznie 5 dni pracy plus koszty wyjazdu, łącznie 13 tysięcy. Klient jeszcze chciał zamówić dwie modyfikacje, tym razem płatne. Zespół pojechał na wycenę, przedstawił ofertę. Jednak finalnie klient się wycofał. Koszt analizy i stworzenia oferty to tylko 4 dni i dwa wyjazdy, czyli około 12 tysięcy. Po drodze jeszcze zrobiono kilka drobnych modyfikacji za darmo, aby utrzymać dobre relacje. Tych dwadzieścia drobnych zmian kosztowało łącznie 6 dni, czyli 14 400 zł. W rezultacie mamy dodaktowych kosztów przy braku rzeczywistych przychodów na ok. 40 tysięcy złotych.
I jeszcze jedna drobna sprawa. Nasz projekt rozrósł się od 100 tysięcy do 163 tysięcy, czyli o 60%. Oprócz dodatkowych kosztów oznacza to, że prace w innych projektach były opóźniane. Jeżeli całkowita, praktyczna marża wynosi 22%, to właśnie utracono niemal 63 tysiące * 22% = 14 tysięcy złotych. To są tzw. utracone korzyści.
Zatem marża piąta, nazwijmy ją marżą post mortem, wynosi 1 – 150 / 177 = -15%. Mamy stratę!
Podsumowanie
Co robi nasze przedsiębiorstwo w takiej sytuacji? Bierze kolejny projekt do realizacji, w ten sposób może pokryć owe 27 tysięcy straty. Często ten kolejny projekt podąża podobnym scenariuszem. W sytuacji, gdy mamy koniunkturę na rynku, przychody firmy mogą rosnąć. Coraz większa ilość projektów pokrywa coraz większe straty z poprzednich. Jednak kiedyś ta piramida finansowa musi się skończyć. I to może skończyć się tragicznie. Sektor budowlany przeżył w naszym kraju takie fale bankructw. Serie upadłości zdarzały się też w sektorze IT.
Co mogłoby zrobić przedsiębiorstwo, gdyby chciało ucieć od widma bankructwa? Mogłoby, albo znaleźć przychody gdzie indziej. Niektóre firmy na przykład chwilowo wolne środki inwestują w nieruchomości. Inne próbują wypuścić własne produkty, aby zapewnić sobie stałe źródło dochodu. Firma mogłaby też uzdrowić marżę, czyli spróbować zrównać wszystkie pięć marż i tak ustawić ceny, aby projekty mimo wszystko się opłacały.
Rozwój LLM powoli zaczyna przynosić działające rozwiązania. Pierwsze, które pokazały wartość dwa lata temu były copiloty wspierające programowanie.
