 Witam was wszystkich. Tak, może ja przyjdę do konkretów od razu na jednym z ostatnich WorldCampów. Mówiłem tak długo, że dziwiłem się, że teraz mnie zaakceptowano, także spróbuję się pospieszyć. Dobrze, o, to dobrze. Dobra, ja mam dzisiaj taki temat troszkę o szacowaniu. Szacowaniem jest po prostu jak ze strzelaniem do celu z zamkniętymi oczami. Czasem trafimy w cel, tak jak chcieliśmy, czasem po prostu w siebie. Ja osobiście przeżyłem to na własnej skórze i to nie raz, szczególnie na początkach kariery, a potem oglądałem, widziałem, jak po prostu inni robią to za mnie. Generalnie klienci, deweloperzy, każdy, kto podejmował się czegoś bardziej ambitnego, miało z tym problem. Ja osobiście wierzę, że większość problemów, które są związane z niedoworzeniem projektów jest właśnie związane z problemem na samym początku, odpowiednią oceną tego, co możemy zrobić w jakim czasie i za ile. Według artykułu pana Franka Fejta ok. 66% przebadanych projektów z 50 tysięcy w 2020 roku skończyło się po prostu, doznało jakieś porażki albo skończyło się całkowitą porażką. Porażkę możemy rozumieć różnie, ale generalnie ja myślę, że możemy wszyscy się zgodzić, że związana jest z czasem i z naszymi pieniędzmi. Chciałbym przedstawić pięć kroków, które u nas w Koditywie, pozwoliły nam zbudować trochę więcej spokoju, które przekłada się i na jakość komunikacji, i na zwiększenie zadowolenia ze strony klientów, co znowu się przekłada na więcej pieniędzy dla firmy. Po pierwsze, musimy się upewnić, że zawsze mamy przynajmniej podstawowy pomysł na osiągnięcie wymaganych rezultatów. Jeśli nie mamy pomysłu, tak naprawdę estimujemy w ciemno. Jeśli estimujemy w ciemno, no to prosimy się o naprawdę poważne problemy. Ja osobiście byłem świadkiem wielu takich sytuacji. Kto pier... Kto z nas nie przeżył chociażby jednej sytuacji, takiej, gdzie musiał pracować tak naprawdę za darmo ze względu na to, że troszkę namieszał na samym początku, no niech pierwszy rzuci kamieniem. Szacowanie kosztów w stylu strzelania, wysyłania oferty, akceptacja tej oferty, no i praca z nadzieją, że jakość to będzie jak już... że coś tam wymyślimy, jak już zaczniemy ten development. No różnie to bywało. Można powiedzieć, że to jest klasyka w gatunku, że tak powiem, w jakiejś... w naszej branży szczególnie. No ja bym powiedział, że to nie jest dobra ścieżka. Żeby uniknąć problemów związanych z estimowaniem, no musimy przed wysłaniem oferty do naszego klienta mieć przynajmniej jakiś podstawowy pomysł, jakiś wstępny zarys tego, co chcemy osiągnąć. Tutaj w tym bardziej racjonalnym przykładzie, klient przychodzi do nas z jakąś informacją z pytaniem, ile czasu zajmie implementacja danego rozwiązania. No i my już na etapie taka jakby przekazywania informacji przedstawiamy mu to, że zajmie nam to tyle i tyle, wykorzystując takie i takie rozwiązanie. To oczywiste jest to, że nie będziemy w stanie znaleźć wszystkich potencjalnych problemów i opisać wszystkich najmniejszych szczegółów na etapie przesyłania oferty, no ale jakiś podstawowy plan to jest coś, co musi być. Ja spotkałem się z wieloma sytuacjami, gdzie po prostu developer estimował jakieś zadanko i ja się dziwiłem, że wow, szybko potrafisz to zrobić. No i pytanie, jak to zrobić, w jaki sposób to zrobić, no to było takie w sumie, no nie wiem, coś tam wymyśle. No i bardzo często to prowadziło do dużych problemów i sytuacji, w których trzeba dopłacać do projektów. Tak że jeśli chcemy poczuć się spokojnie podczas szacowania, no to zawsze przynajmniej ten podstawowy plan musimy mieć. A jeśli nie jesteśmy w stanie go jakoś wymyślić, bo na przykład coś wykracza poza zakres naszych umiejętności, albo po prostu naprawdę nie wiemy, to dla własnego bezpieczeństwa no nie staramy się wysyłać oferty, no bo się możemy na tym przejechać. No chyba, że lubimy ryzyko. Kolejny bardzo ważny temat też z doświadczenia ważnym jest to, aby być przewodnikiem klienta, a nie jego niewolnikiem. Jeśli klient by się nas zapyt poprosił, by nas o wskoczenie w ogień, no to raczej nikt by nie wskoczył, no bo to po prostu ryzykowne. No uważam, że takie samo podejście możemy wykorzystać również na etapie estymowania, no w generalnie w biznesie. Klienci przychodzą do nas, bo mamy wiedzę, aby rozwiązywać jakieś problemy, które oni mają. Dlatego wykorzystajmy tą wiedzę, wykorzystajmy nasze eksperckie podejście do tego, aby mu doradzić, a nie ślepo podążyć za tym, co mówi. Przykładzie z życia, klient przychodzi do nas i ma już jakieś gotowe rozwiązanie, no i wykorzystujemy tutaj podejście jakiegoś oczywiście znanego przez chyba każdego syna koleżanki, który robi podobne rzeczy, ale nie ma czasu, dlatego odesłam nas do nas i już prezentuje jakieś tam powiedzmy rozwiązanie, które powinno zatekować problem np. plaginami. No i w takim podejściu trochę bardzo ryzykownym, developer po prostu mówi, klientowi, ok idziemy w to, do mnie zajmie 20 godzin i tyle. I nie zastanawia się nad potencjalnymi konsekwencjami, nad czymkolwiek, no po prostu robi to, co klient powiedział. No i z czasem po jakimś czasie, no, dzieją się złe rzeczy np. system pada, bo dołożył za dużo plaginów albo plaginy, no ze względu na te rozwiązanie, które wybrali po prostu wszystko siadło. No i w takiej sytuacji, developer często obwinia po prostu klienta, no przecież ma to, co chciał, powiedział, że chce plaginy, no to mu zrobiłem plaginy. No i to też jest normalne, w miarę normalne, każdy z nas tak robi. Ja też, to zdarza mi się bardzo często, ostatnio robiłem, remont syna w pokoju, elektrykiem nie jestem, no ale zabrałem się za zmianę gwiazdek, no to pozmieniałem wszystkie, idę odpalić bezpieczniki, i pff, wywaliło, nie? Wracam, rozmontowuję wszystko, podłączam jeszcze raz, włączam znowu, pff, wywaliło, no i pierwsza myśl, jaką miałem, nie to, że coś zrobiłem źle, tylko, że, no, jakieś zjebane gniazdka mi dali, nie? I od razu po prostu już nie, to ja na pewno zrobiłem dobrze, tylko ktoś inny. 30 sekund potem do chwili przerwy i mówię, dobra, sprawdzam. No i się okazało, że tak to zrobiłem, że dziwię się, że tu jestem jeszcze, nie, jak podłączałem. I no to jest klasyczne zachowanie, ale jeśli się skupimy na tym i weźmiemy pod uwagę to, że my też się możemy milić, no to może osiągnąć dużo lepsze rezultaty. I już trochę bardziej lepszym podejściu do klienta, na etapie, kiedy on przesyła nam już jakąś ofertę z jakimś tam pomysłem, my ekspercką podchodzimy do tematu i mówimy, no, okej, no, możemy to tak zrobić, to mi zajmie tyle czasu, ale musisz być świadomy, że to może spowodować problem taki, taki, taki. Aby go uniknąć, co jest, co może być dla ciebie bardzo opłacalne, możemy to zrobić w taki, w taki i w taki sposób. Zajmie to więcej czasu, ale jest trochę bezpieczniejsze na podstawie naszego doświadczenia i doświadczenia innych klientów. No i klient już na podstawie takiego feedbacku sam sobie decyduje. Wiadome jest to i nie ma w tym nic złego, że klient może się nie zgodzić z czymś takim powie. Dobra, i tak robimy tam, bo tam to jest tańsze, ja chcę tanie. No to okej, no, możemy to zrobić, ale w przypadku problemów związanych z takim rozwiązaniem jesteśmy trochę bardziej bezpieczni, bo już na etapie przed wysłaniem oferty przekazaliśmy klientowe nasze obawy. No i jeśli coś się zesra po prostu przez takie rozwiązanie, no to my będziemy mieli podkładkę, no, słuchaj, nie posłuchałeś nas, my zaprezentowaliśmy ci taką opcję, więc no, musisz teraz trochę więcej zapłacić, żeby to odkręcić. Dlatego jeśli chcemy poczuć się pewnie i zbudować zaufanie do naszych estymacji, do naszych szacunków jakichkolwiek, czasowych, pieniężnych, no to bądźmy przewodnikiem klienta, a nie jego niewolnikiem. Kolejny punkt szczerość, bądź szczery wobec siebie i wobec ludzi wokół ciebie po prostu. Często możemy mieć taką sytuację, że to też przykład z życia. Klient przychodzi do nas z jakimś tam pomysłem, no, słyszałem, że tam AWS jest super, zróbmy to na AWS'ie, ale kurde, mam tylko budżet na 4 godziny. To aktualnie... Trochę liczby wymyślone, ale jakbym trochę dodał więcej to sytuacja realna. No i developer mówi, o, super, klient we mnie wierzy, trochę mnie to podbudowało, to działamy, a wmyśli sobie w głowie, że w sumie z AWS'em to nigdy nie działałem, no, ale próbujemy. No i to nie jest też dobre podejście. Co my tu mamy? Tak, to nie jest dobre podejście. Nie starajmy się pokazywać, że wiemy coś, żeby dać po prostu fałszywe rezultaty, bo się na tym przejedziemy i zapłacimy tak naprawdę czasem i naszym pieniędzmi. Bądźmy szczerzy, jeśli widzimy, że jakiś budżet, jakiegoś budżetu nie da się do... jakiejś funkcji nie da się dowieść w tym zakładanym przez klienta terminie, no to poinformujmy od razu o tym. Jeśli mamy jakiekolwiek wątpliwości dotyczące rozumienia wymagań biznesowych klientach tego, co chcę osiągnąć, żeby się zapytać, bądźmy z nim szczerzy i powiedzmy, że słuchaj, niekumen w ogóle o co ci chodzi, jakbyś mógł wyjaśnić trochę więcej. No i sobie rozmawiamy i trochę więcej się nam już klaruje. Bycie szczerym wobec siebie i innych ludzi, nie tylko klienta, ale w zespole, no jest taką podstawą, która naprawdę da nam duże bezpieczeństwo, przynajmniej mi osobiście dała. Bardzo często walczy z tym, żeby być szczerym, bo niektóre rzeczy potem ustawiają mnie na przykład w związaniu z świetle, typu, że po prostu coś zjebałem na przykład, ale ostatnio miałem taką sytuację, że faktycznie pierdoła fest, że aż wstyd się przyznać i szukałem na siłę jakiś tam argumentów, że co się mogło stać, żeby po prostu pokazać klientowi, że to nie do końca moja wina. No w końcu stwierdziłem, dobra, nie ma sensu, powiedziałem, przyznałem się, że coś zwaliłem, nawet jeśli chodzi o estymację. No i w sumie, aż się zdziwiłem jego reakcji, no bo powiedział ok, takie rzeczy się zdarzają i dziękuję, że tam wskoczyłeś za jakiś, od razu, jak zgłosiłem jakiś problem z tym zadaniem. Oczywiście tak jakby zmieniło to mój pogląd. Pogląd na sytuacja. O wiele lepiej sprawdza mi się bycie szczerym pokazywanie swoich prawdziwych uczuć czy problemów, bo no sprawia, że jestem bezpieczniejszy, szczególniejsi mówimy tutaj o czasie i pieniądzach, które mogę zarezykować. Kolejny temat, wykorzystanie potęgi prostoty. Chyba każdy z nas raczej nie byłby zainteresowany z korzystaniem z oferty, kogokolwiek, kto prezentuje rozwiązania bardzo trudno. Prze mnie ma broszury, w których jest 10 stron i wszystko jest napisane trudnym technicznym językiem, z którego większość jest niezrozumiała dla nas. Raczej skorzystalibyśmy tego w momencie z takiego rozwiązania, w momencie, kiedy dostaniemy broszurę i będzie napisane, ej, ja robię dokładnie to, co chcesz, więc mi kup. I ty się nie zastanawasz wtedy, o czy na pewno, tylko jak obiecujesz, to dobra, to idę w to, nie? No i to jest właśnie potęga prostoty. Możemy to zrobić na kilka sposobów, możemy to usprawnić. Pierwszy przykład to jest spróbujmy zrozumieć swojego słuchacza. Czasem możemy starać się pokazać klientowi, że mamy wiedzę, umiejętności, za które on płaci, nie w taki sposób, jaki powinniśmy. Czyli wykorzystujemy dużo technicznych słów, jakieś super techniczne pytania, żeby pokazać, że naprawdę jesteśmy kozacy, nie? A z drugiej strony jest klient i on tak patrzy na nas i mówi, w sumie nie wiem o co ci chodzi, nie? I w wielu przypadkach może być tak, że on uzna kurde, jestem chyba za głupi na to, to ja się nie piszę, nie? Ja sobie zrobię nie wiem, stronkę sam i to jeszcze na jakichś narzędziach, na których na przykład nikt z nas nie lubi, nie? Bo tu jakieś trudne rzeczy, nie? Rozwiązanie jest proste, no. Spróbujmy wykorzystać potęgę prostoty. Zamiast wykorzystywać te trudne techniczne pytania, których nikt nie rozumie tylko my, zadajmy pytania w taki sposób, żeby każdy mógł na nie odpowiedzieć. Czyli jeśli się zastanawiamy nad infrastrukturą na przykład, no to nie pytajmy się czy chce do kera, czy szert hosting, no bo mu to może nic nie mówić, ale zapytajmy, czy właśnie o liczbę użytkowników, jaką chcą ogarnąć na przykład miesięcznie, jakie mają planę na przyszłość. Może się okazać, że robią MVP i w zasadzie ja nie wiem, będą potrzebować właśnie 25 użytkowników, no do tego doker nie jest potrzebny. Nie musi klient wtedy inwestować w jakieś dodatkowe zespoły, które by nam to ogarnęły. Kolejny przykład to jest wykorzystywanie słów, których nie znamy, czyli jej też strzelamy, mówimy, że no doker jest no też przykład właśnie z infrastrukturą o, i w takiej sytuacji mówimy, pytamy się klienta czy chce do kera czy szert hosting, no i tu już mamy klienta, który się zna i mówi, znam obie dobrze, ale powiedz mi co możesz tutaj doradzić. No i deweloper mówi no, szert hosting jest łatwy w zarządzaniu i ja ci to ogarnę, a doker jest słyszałem, że jest modny i tyle. No to jeśli tyle wiesz, no to po co się pytasz i proponujesz? Jak no naprawdę, no, możesz mieć problem z ogarnięciem tego. Wykorzystaj potęgę prostoty i zadaj pytania tylko te, które będziesz w stanie wyjaśnić, tak jakby jeśli klient do ciebie wróci, jeśli ty nie znasz do kera, no to nie pytaj się czy chce do kera, no bo wiadomo to jest to, że jak powie, że chcę, no to ty masz dodatkowy problem i musisz znaleźć kogoś, kto ci to ogarnie. Zadaj prosty pytania, bo to ci pozwoli tak naprawdę znaleźć to, co klient potrzebuje. Może on tak naprawdę właśnie tego do karania potrzebuje i ten szert hosting wystarczy, czyli od razu optymalizujemy mu koszty, jego implementację, jego funkcji jest mała i to dzięki, i wszystko dzięki prostocie. Tak, że tu jest, a dokładnie, tu jest właśnie przykład już na etapie wysłania, tak jakby efekty do klienta, piszemy mu jakie są, zadajmy pytanie i od razu odpowiadamy jakie są możliwości, jakiej konsekwencje niosę, niosie ze sobą dana opcja, no i od razu dajemy feedback, którą my byśmy mu zalecili. Znacznie usprawnia to pracę, szacowania czegokolwiek, dogadywania się z klientem, bo on dostaje taką wiadomość, widzi wszystko, co ty proponujesz, od razu sobie czyta wadę zalety, co masz, a dzięki temu mieć i ma jedną, po prostu odpowiedź wykorzystamy to i komunikacja w tym temacie się kończy. Kolejny ważny temat, to już nawet nie tyle właśnie rozmowy z klientem, no kimkolwiek, nawet w zespole, no coś ja uważam i wierzę w to bardzo, widzę po sobie, że coś jest lepsze niż nic, dlatego zawsze postarajmy się dawać jakąkolwiek wartość, nawet na najmniejszą, to jest coś. I powiedzmy, jesteś ważniejszą osobą w firmie, tym tak naprawdę masz mniej czasu, więc sytuacja bardzo, bardzo często manager przychodzi do dewelopera i się pyta ile czasu ci zejdzie na daną funkcję no i deweloper mówi nie robiłem tego, nie wiem, i koniec rozmowy, nie? No i musisz się, aby usprawnić proces, gdzieś tam właśnie szacowania czasu, musisz wziąć pod uwagę to, że taka odpowiedź, no jest bardzo szczera, no trudno, bardziej szczerą odpowiedź, no bo możemy czegoś nie wiedzieć, no ale starajmy się, im szybciej się przekonamy, że taka odpowiedź nic nie zmienia, a nic tak naprawdę nie daje w konwersacji z drugim osobą, no to tym będzie dla nas łatwiej, będziemy w stanie osiągać lepsze rezultaty. Tutaj już mamy drugi przykład. Nie ma nic złego w tym, że czegoś nie wiemy, no wielu z nas, nie wie wielu rzeczy, ale właśnie spróbujmy dać jakąkolwiek wartość, możemy nie wiedzieć ile zajmie dana funkcja, bo faktycznie jej nie robiliśmy, ale wiemy ile zajęła podobna funkcja, albo przynajmniej w pewnym stopniu podobna w innym projekcie. Wiemy, że aktualny projekt jest problematyczny i na przykład 70% czasów, w jaki sposób zawsze było przekraczanych, budżet. Możemy wiemy, że klient zawsze na końcu coś tam zmienia, bo jest marudny i zawsze jakiś tam czas jest potrzebny, no to wiemy coś, tak naprawdę, tak, że zamiast mówić nie wiem, wykorzystajmy potęgę tego, co wiemy, co nie jest tym bezpośrednim rozwiązaniem, ale wykorzystajmy potęgę tego, żeby zniwelować pływ rzeczy, których faktycznie nie wiemy. I w tym przypadku, nawet jeśli dajemy tutaj widelki, a nie konkretną estymację, konkretne szacunki, no to dajemy jakąś wartość i taki klient, manager już w tym momencie jest w stanie ocenić, czy idziemy w tym kierunku, czy nie idziemy w tym kierunku. Lider zespołu jest w stanie ocenić, czy developer, który mówi mu, ile to zajmie, ma jakiś fajny pomysł na to, czy nie, w wielu przypadkach, jak otrzymywałem taką informację, no to już widziałem, że, kurde, chat GPT w 20 godzin od zera, no to fajnie, dość bardzo optymistycznie, jak byś to zrobił, bo ja na przykład nie wiem, jestem ciekawy, no i wtedy otrzymuję informację, że w sumie nie wiem. No i już jako lider mamy informację o tym, że coś tu jest nie tak, że to jest to, co jest to, co jest to do klienta, no to możemy mieć problem. Tak, że naprawdę z doświadczenia powiem, że starajmy się dawać jakąś wartość, nawet najmniejszym, nawet jeśli ona nie jest precyzyjna, bo to znacznie usprawni nam cały proces szacowania i workflow. I to by było tyle. Tak, te 5 punktów to trzeba zaznaczyć, że dla wielu z was mogą być punkty bardzo proste i jak można tak nie robić, no ale my w Coditi już przerobiliśmy bardzo dużo klientów, bardzo dużo deweloperów, bardzo dużo razy się przejechaliśmy i te 5, tak jakby prostych, naprawdę prostych sposobów już na etapie komunikacji znacznie sprawiła, że czujemy się bezpiecznie jako deweloper, jako właściciel biznesu, że możemy i bardziej zaufać swoim pracownikom i bardziej po prostu dawać większą wartość klientom. No to myślę, że jest istotne szczególnie właśnie tak bardzo natężonym, nie natężonym, tylko tak bardzo zmieniającym się świecie IT, gdzie ten przemiał deweloperów jest ogromny. Także naprawdę spróbujcie skorzystać z tych zasad, jeśli nie korzystacie to polecam, nam się to przełożyło na naprawdę fajne rezultaty i tyle. Jeśli byście mieli więcej pytań, to mamy 2 stoiska Coditiw i Astratik, jesteśmy dostępni, a jak by ktoś chciał więcej informacji o WordPressie, to zapraszam na Twittera i stronę ten typ Dev, tam staram się prezentować fajne treści i będę wdzięczny za feedback, tak że dziękuję bardzo. Dzięki.