Od pomysłu do backlogu
Jak rodzi się funkcjonalność z Bartkiem Lesnerem
Opis
W dzisiejszym odcinku rozmawiam z Bartkiem Lesnerem, Product Ownerem w IamIP, o tym, jak z luźnego pomysłu powstaje funkcjonalność, która trafia do backlogu i staje się częścią produktu.
Osoby
Transkrypcja
Transkrypcja jest generowana automatycznie
Bartosz (00:05) Ale jeżeli chodzi o samo przekazywanie idei zespołu IT, to wydaje mi się, że trzeba w bardzo dokładny, precyzyjny sposób rozpisywać tematy, którymi się przychodzi, tak żeby nie było żadnych wątpliwości. Jeżeli podczas procesu faktycznie te wątpliwości się pojawiają, to
tworzą się problemy.
Wojtek (00:54) Witajcie, zapraszam na 17 odcinek podcastu hospoda.tech. Dla tych, co widzą kolejny odcinek już z pełnym wideo. W dzisiejszym odcinku z Bartkiem Lesnerem porozmawiamy o tym, jak z luźnego pomysłu powstaje konkretny opis funkcjonalności, a potem jak to się dzieje, że ten pomysł czy ten opis funkcjonalności już wtedy ląduje w procesie wytwarzania oprogramowania.
Transkrypcję, linki i wszelkie materiały do tego odcinka znajdziecie na hospoda.tech. łamane na 17. Zachęcam do subskrybowania podcastu, dzięki czemu nie przegapisz kolejnego odcinka. A teraz już zapraszam na dzisiaj i życzę miłego
Wojtek (01:40) Dzisiaj mam przyjemność gościć po raz kolejny w podcaście Bartka Lesnera, product ownera w firmie IMIP Sferi GAB. Porozmawiamy sobie dzisiaj o temacie, tak jak temat odcinka, od pomysłu do backlogu, jak rodzi się funkcjonalność. Główne pytanie, które będziemy starali sobie odpowiedzieć, to jest, jak z gmlistych pomysłów od klientów, zarządu czy zespołu powstaje realny backlog produktu. Cześć Bartek.
Bartosz (02:05) Cześć, wektork.
Wojtek (02:07) To pierwsze pytanie, które już trochę zawierało się w tym tym pytaniu głównym. Skąd biorą się pomysły?
Bartosz (02:17) Wydaje mi się, generalnie pomysły biorą się z potrzeb. Różni ludzie, czy to klienci zgłaszają się z tymi potrzebami, czy to pracownicy firmy te potrzeby identyfikują i na bazie tych potrzeb powstają pomysły jak te potrzeby rozwiązać, jak te problemy, które się…
pojawiają podczas pracy, jak w ich rozwiązaniu można klientom pomóc.
Wojtek (02:51) No dobra, a z takim pierwszym pomysłem w ogóle na biznes nazwijmy to kiedy nie mamy jeszcze aplikacji to jak rozumiem podobnie.
Bartosz (03:01) Wydaje mi się, tak, że te produkty, które osiągają sukces na rynku to są takie, które te potrzeby rozwiązują. Oczywiście jest kilka, czy nawet nie kilka, pewnie całkiem duża grupa produktów, które wymyślają te potrzeby i później je rozwiązują, ale wydaje mi się, uogólniając to produkt jest odpowiedzią na potrzeby.
Wojtek (03:29) OK, to tutaj dopytam co to znaczy wymyślić problem czy wymyślić potrzebę.
Bartosz (03:35) Wydaje mi się, że całe social media to jest wymyślanie czy może trochę przerobienie potrzeby kontaktu między ludźmi i rozwiązanie tego w taki, jaki sposób to było rozwiązane.
Wojtek (03:54) Rozumiem. dobra. Zakładam, że są pewne fazy tutaj w drodze do backlogu. Następną fazą będzie pewnie jakaś weryfikacja pomysłu. Czy to potrzeba, która istnieje, czy stworzona przez nas. Jak odróżnić, nie wiem czy tutaj już nie wybiegnę trochę do przodu za bardzo.
ale jak to zweryfikować, czy pomysł jest po prostu fajny, czy jest wartościowy, czy ten problem, który chcemy rozwiązać, to rozwiązanie ma sens, czy jest tylko jakimś takim, nie wiem jak to określić, ale to już pytanie do Ciebie.
Bartosz (04:43) Pracą product ownera, też ogólnie firm, które np. w przypadku AMIP dostarczają produkt jest znanie i świadomość tego, co klienci nasi potrzebują. od tego wychodzimy. To jest to pierwsze sito, które pomysły
nasze przechodzą, jesteśmy w stanie zweryfikować pomysły, są, mówiąc może trochę brzydko, totalnie odczapę, które się zupełnie nie nadają, niczego nie rozwiązują albo nie rozwiązują w taki sposób, który będzie odpowiedni dla naszych klientów. Po takiej pierwszej weryfikacji oczywiście bardzo wartościowa jest analiza tego pomysłu z członkami zespołu.
czy to z ludźmi ściśle zajmującymi się stroną techniczną, czy to z zespołami customer service, customer success, czy też sprzedażą. Bo co bym nie powiedzieć, oni mają kontakt z klientem, mają go często i też trochę z innej strony niż zespoły techniczne. I oczywiście, jeżeli jest taka możliwość, warto jest
czy to bezpośrednio, czy to poprzez ankietę klientów, ten pomysł ma sens, bo mimo, że… znaczy nie zdarzyło się to może wielokrotnie, ale jestem w stanie na palcach jednej ręki przypomnieć sobie przykłady, którym wszyscy myśleli, że pomysł jest genialny, a klient powiedział, że mimo wszystko nie albo w drugą stronę na przykład.
Więc ta ostateczna weryfikacja przez klienta, jeżeli jest możliwa, naprawdę może zaoszczędzić czasu, pieniędzy i wysiłku.
Wojtek (06:53) No dobra, to tutaj teraz takie może dodatkowo trochę podchwytliwe pytanie, bo w przypadku jeżeli mamy, jesteśmy wykonawcą dla jednego klienta, tak budujemy komuś jakiś produkt, no to zakładamy, że ta osoba, ten klient jednostkowy w tym momencie wie, czego chce, umie, zna się na swojej domenie, wie jak rozwiązać problemy swoich klientów, co jest mu do tego potrzebne, więc w tym momencie powiedzmy sobie, no nie dyskutowałbym. W przypadku, kiedy mamy…
swój produkt, czyli tych klientów mamy wielu, no to teraz takie trudne pytanie, na ile można klientom tak naprawdę ufać, na ile powinniśmy być przez klientów my jak gdyby prowadzeni troszeczkę do przodu w tym, co im dostarczamy, a na ile my powinniśmy szukać, nazwijmy to, lepszych rozwiązań tych problemów, o których klienci sami by nie pomyśleli, no bo…
Jednak za tobą stoi duże doświadczenie w samych produktach IT, tak? A klienci korzystający z naszego produktu nie zawsze wiedzą, że coś można byłoby zrobić lepiej, To jak to jest z tym właśnie zaufaniem do tego, czy klient wie lepiej?
Bartosz (08:10) Z mojej perspektywy.
Z mojej perspektywy to wygląda troszkę inaczej, ponieważ oczywiście nie można, nie może być tak, że klient, który mówiąc brzydko najgłośniej krzyczy, dyktuje w jaką stronę idzie organizacja, ale ten feedback od klientów jest bardzo ważny. Ja nie mówię, że ostateczne, bo jeżeli jakaś grupa klientów nawet powie ci, że jest inaczej.
a ty masz świadomość tego, że to na pewno rozwiąże ten problem, to decyzja ostateczna jest jakby w organizacji, ale zamykanie się na klientów, tak naprawdę na jakikolwiek z tych etapów, których wcześniej rozmawialiśmy, no jest niebezpieczne. Mogłem powiedzieć tak chyba.
Wojtek (09:14) Znaczy koniec końców ja rozumiem, że produkt jest tworzony dla klienta i tutaj jak gdyby ja w ogóle z tym nie dyskutuję. Natomiast chciałbym się odnieść już chyba po raz kolejny w tym podcaście do tego klasycznego powiedzenia Henrygo Forda. Także gdybym zapytał co ludzie chcą to powiedzieliby że szybsze konie. I tutaj jest właśnie takie pytanie jak rozpoznać to że mamy.
już nie słuchać klienta, nie dawać mu szybszego konia, tylko w tym momencie zbudować coś nowego, zbudować ten samochód, bo zakładam, że chyba nie raz trafiłeś na coś takiego, że klient w zupełnie innym kierunku chciał rozwiązywać dla nas trywialny problem, bo patrzyliśmy z zupełnie innej perspektywy.
Bartosz (10:03) No to jest ciekawy temat, tylko wydaje mi się, to przekładanie takich pomysłów, których tutaj, znaczy pomysłów…
przykładów z Henrygo Forda, generalnie z pomysłów zmieniających totalnie świat, wywodzących się z genialnych umysłów. Nie można tutaj patrzeć na codzienną pracę przez pryzmat takich wydarzeń, bo mimo wszystko my nie wymyślamy
rewolucyjnych rozwiązań każdego dnia. Oczywiście zdarza nam się rozwiązywać problem w sposób inny niż ktokolwiek wcześniej rozwiązał i okazuje się, że odpowiada to potrzebom klientom, klientów i oni oczywiście nie zdawali sobie sprawę z tego w jaki sposób go rozwiązać, ale to jest jakby
kwestia ta, którą poruszyłeś. Ludzie pracujący w IT znają już pewne rozwiązania i są w stanie je zmienić, są w je zaadaptować, są w stanie je lekko skastomizować tak, żeby już może nie znane i lubiane, ale znane i sprawdzone rozwiązanie służyło klientom w nowych sytuacjach.
I stąd też się bierze, że to jest chyba nawet taki mem, że deweloper przychodzi do dewelopera i pytać, i mówi mu, że użyłem twojego kodu, a drugi deweloper odpowiada, nie, to nie mój kod. Także w IT wydaje mi się, że my mamy łatwość adaptowania czyichś pomysłów i niewymyślania koła na nowo.
Wojtek (12:17) Znaczy, tak, bardziej chodziło mi tu o to, ok, może z Henrym Fordem, może pojechałem trochę za daleko. Bardziej chodziło mi o to i może to też będzie przykład raczej odwrotny, bo sobie bardziej wyobrażałbym sytuację na odwrót, natomiast nie mogę znaleźć teraz konkretu żadnego, ale przychodzi klient do ciebie, opisuje ci jakiś bardzo skomplikowany proces, bo chce coś osiągnąć, nagle okazuje się, że trzeba byłoby przepisać pół systemu, żeby…
osiągnąć jakieś tam nie wiem, statystyki i nagle wy mówicie, no dobra, ale wiesz co, przecież w sumie tobie wystarczy export do Excela na przykład. Dlatego mówię, że przykład odwrotny, bo zwykle raczej klient by przyszedł, powiedział, słuchajcie, zróbcie mi export do Excela, bo ja chcę coś tam zrobić, a żeby budować feature’y, to się buduje je jednak w środku w systemie, ale to bardziej tego typu rzeczy, żeby klienta prowadzić za rękę tam, gdzie można.
Bartosz (13:16) No ale to też jest jakby kwestia ekspertyzy, tak, bo faktycznie to można by porównać w prosty sposób do do przewodnika, Człowiek nie mając przewodnika będzie kluczył trzy razy się zgubi i może faktycznie do celu nie dojdzie. Mając przewodnika pójdziemy najprostszą dostosowaną do nas drogą. i co by nie powiedzieć, to my tutaj jesteśmy.
Jeżeli oczywiście pracujemy z klientami jakby zewnętrznie i nie mamy cały czas całego klienta, no to my za tego przewodnika służymy. Dostajemy temat, dostajemy problem tak naprawdę do rozwiązania i na bazie jeżeli już ta aplikacja istnieje czy w przypadkach, w trzeba stworzyć nowe rozwiązania, na bazie doświadczenia i tej ekspertyzy dobieramy najlepsze rozwiązania.
Wojtek (14:17) Wydaje mi się, że to genialne podsumowanie tej części z tym byciem przewodnikiem. Wspomniałeś wcześniej już o rozmawianiu ze wszystkimi, również z deweloperami i teraz coś, co wydaje mi się chyba jedną z trudniejszych rzeczy może tak na sam początek. Jak rozmawiać z zespołem technicznym o nowych ideach, tak, oni je wiadomo zrozumieli, ale jeszcze bardziej, żeby…
żeby je zaakceptowali i chcieli wdrożyć.
Bartosz (14:50) A czy…
Ja mam trochę inne doświadczenia, bo nie widzę problemu z rozmową zespołem technicznym i sprzedawanie mi pomysłów. Ja czasami mam wrażenie, że przy tych rozmowach tych pomysłów pojawia się za wiele i rozchodzimy się w zbyt wielu kierunkach. Czyli nie staramy się…
rozwiązać tego konkretnego problemu, tylko też znajdujemy lekką problemy poboczne i nie próbujemy jakby pojawiają się tak naprawdę też nowe rzeczy i można by to tak określić, że przychodząc na takie spotkanie był jeden cel, a potem się pojawia tych celów kilka, tak albo może się przynajmniej pojawić, więc.
Wydaje mi się, że jeżeli pracuje się ze zmotywowanymi ludźmi, którzy chcą się rozwijać, to oni są skorzy do rozmowy. Później bardziej się pojawia problem, jeżeli oni mają na to pomysł z przekonaniem ich mimo wszystko do swojego. W taki sposób.
Wojtek (16:11) Znaczy no właśnie, bo tutaj to poruszyłaś chyba taki temat, gdzie kończy się załóżmy rola osób produktowych, gdzie zaczyna się rola zespołów technicznych, bo oczywiście zespół techniczny jak najbardziej może zasugerować jakieś polepszenie rozwiązania, tylko no chyba jednak tutaj powinniśmy się skupiać przede wszystkim na technicznym aspekcie rozwiązania.
a nie już tym, bo do tej pory raczej rozmawialiśmy tylko o takim czysto użytkownikowym poziomie tego jak powinno być coś rozwiązane, czyli przytoczony przeze mnie Excel export. To jest po prostu export do jakiegoś pliku, który jest uniwersalny. i teraz tak jasne, w jakichś przypadkach zespół techniczny może powiedzieć, a lepiej jednak byłoby, żebyście to zrobili może tutaj inaczej.
No ale chyba w większości przypadków ich rola powinna się może bardziej opierać o to, żeby powiedzieć jak najlepiej te dane wyeksportowe.
Bartosz (17:17) No to tu jeżeli chodzi o przekazywanie w takim razie i taką czystą komunikację co do już ustawionej funkcjonalności, czy może tak postanawionych funkcjonalności, jedną na pewno kwestią jest to, żeby używać język, a to czasami jest problematyczne, zwłaszcza jeżeli się współpracuje w różnych językach z ludźmi.
żeby tak samo nazywać rzeczy, bo tutaj komunikacja może być problemem. Nawet firmy, której teraz pracuję różne działy potrafią różnie nazywać tematy. Więc jeżeli przychodzą ludzie czy to z działu zajmującego się produktem, czy to na przykład customer service, to może być problem z komunikacją z IT, bo po prostu inaczej coś nazywamy.
Ale jeżeli chodzi o samo przekazywanie idei zespołu IT, to wydaje mi się, że trzeba w bardzo dokładny, precyzyjny sposób rozpisywać tematy, którymi się przychodzi, tak żeby nie było żadnych wątpliwości. Jeżeli podczas procesu faktycznie te wątpliwości się pojawiają, to
tworzą się problemy. Podejrzewam, że to się generalnie odnosi do wielu aspektów życia, ale czym lepiej jesteśmy przygotowani na początku, ten proces przeprowadzenia tego początku do końca idzie łatwiej, szybciej i sprawniej.
Wojtek (19:03) Znaczy tu teraz, żebyśmy może jeszcze też tak zacząłem sobie myśleć, nie popadli w taką pułapkę, bo mówisz o przygotowaniu pewnych rzeczy wcześniej, im lepiej przygotowane. Dla niektórych mogło tutaj zapachnieć trochę takim a la waterfallem, no nie, więc może omówmy sobie jakieś takie z grubsza, co powinno być właśnie dla tego zespołu przygotowane.
Bartosz (19:29) Przychodzimy z pomysłem, czyli musi być określona jasna wizja tego, chcemy osiągnąć. To jest angielska requirement z projektu. Musi być jasna, przynajmniej tak jak ja to robię i jak u nas to wygląda. Mamy już porozpisywane flow w jaki sposób, od początku do końca w jaki sposób chcemy te rzeczy osiągnąć.
I na tym etapie już z mojej perspektywy jeszcze tak naprawdę przed tą komunikacją bezpośrednio z zespołem jesteśmy w stanie wyłapywać pewne rzeczy, których nam brakowało jakieś potencjalne problemy, które teraz już wiemy, że jesteśmy w stanie rozwiązać. Jeżeli mamy jasne określone cele, mamy jasne określone w jaki sposób chcemy do tych celi doprowadzić.
no to potem już jesteśmy w stanie zanurzyć się w szczegóły i tutaj faktycznie zespół jeżeli chodzi o osiąganie tego celu już poprzez te szczegóły ma pewne pole do popisu.
Wojtek (20:41) OK, teraz czy tutaj było pytanie o estimację, Na tym etapie, bo następnym etapem będzie zapewne priorytetacja, o którą zaraz zapytam. Na tym etapie, jak wyglądała twoim zdaniem, czy powinna wyglądać, bo w sumie wiemy, wygląda, więc jak powinna wyglądać estimacja tego wszystkiego?
Bartosz (21:05) Znaczy, estimacje ogólnie z mojej perspektywy najlepiej rozbijać. To nie powinno być jakby jednej ostatecznej estimacji. Na samym początku, patrząc na złożoność projektu, mając już pewne doświadczenie, też w jakiś sposób się konsultując z innymi ludźmi, jesteśmy w stanie określić ogólną wielkość projektu i jego skomplikowanie. Czy to jest…
powiedzmy, że jesteśmy w stanie to przełożyć na takie t-shirt size w tym momencie i to potem faktycznie pomaga przy tej priorytyzacji, którą wspomniałaś. Jeżeli potem przechodzimy do szczegółu, no to wtedy jesteśmy już na bazie estymacji zespołu, na bazie tych danych, które są zbierane.
wyestymować ile faktycznie taki projekt, taka funkcjonalność zajmie czasu. Także w taki sposób.
Wojtek (22:14) Ok, czyli jak rozumiem, bo teraz już będę przechodził powoli do zagadnienia priorytazacji, czyli z tymi wstępnymi T-shirt size’ami, załóżmy tam Smart, Million, Large, to będzie input do dalszego etapu w procesie. Jeżeli powiedzmy sobie priorytazacja, której zaraz sobie porozmawiamy, wyrzuci nam takie, a nie inne priorytety, co zakładam, że w tym momencie łatwiej też jest wam się skupić na
tych rzeczach, które są pierwszym priorytetem, żeby je tamto określić. Czyli tak naprawdę jakaś taka roadmap, a jakiś plan deweloperski powstaje dopiero na samym końcu z połączenia tej priorytetacji. OK, dobra. No to co? To teraz sama priorytetacja. Jak wygląda ten proces? Kto powinien ostatecznie podejmować decyzje?
Bartosz (23:07) To tutaj podejrzewam, że to też się bardzo różni w zależności od miejsca, którym się siedzi, czyli firmy, które się pracuje. Ale ja generalnie jestem zwolennikiem tego, żeby za priorytyzację nie odpowiadała jedna osoba. Ja rozumiem, że pewna osoba z waga ich w priorytyzacji jest większa.
Ale co by nie powiedzieć, wtedy jest dużo łatwiej o pomyłkę, wtedy jest dużo łatwiej o to, żeby coś zostało pominięte. I oczywiście osoba, która zajmuje eksponowane stanowisko powiedzmy w większości przypadków ma ostateczne zdanie, ale czym więcej feedbacku, czym więcej komunikacji i rozmów podczas tej priorytyzacji,
Tym lepiej.
Wojtek (24:06) Znaczy, tu się z tobą też zgadzam, ja jestem fanem tego Priority Committee, jakiegoś komisji, jakiegoś ciała, no bo koniec końców jeżeli chodzi potem o to, to odpowiada za to cały management. Wydaje mi się tutaj, że dział sprzedaży musi to sprzedać, marketing musi to zareklamować, działy obsługi klienta, potem będą obsługiwały klienta na tym feature, no a…
a dział IT czy developmentu musi to dowieźć i też nigdy jakoś tak nie widziałem tej odpowiedzialności na jedną osobę, bo z drugiej strony, no co by się stało, tak? Jeżeli ta jedna osoba popełni błąd, to co? Zwolnimy ją i będziemy szukać następnego odważnego, który będzie nam palcem wskazywał?
Bartosz (24:56) czy
generalnie ta współodpowiedzialność za decyzję, czyli współodpowiedzialność za priorytyzację właśnie zmaga zaangażowanie, bo jeżeli człowiek jest w stanie na coś wpływać, to czuje się za to po prostu bardziej odpowiedzialny, jest to jego, a nie czyjeś, więc tutaj na pewno
Bardzo mocno wpływa to na zaangażowanie później.
Wojtek (25:29) Ok, czyli mamy tą wspólną priorytyzację, nie chcę użyć słowa demokratyczną, bo jeszcze nie wiem jak ona będzie wyglądała. I jak taki proces powinien dalej przebiegać według Ciebie? Czy z Twojego doświadczenia?
Bartosz (25:47) Znaczy, naprawdę, jeżeli ma się listę tematów, tak, powiedzmy już przeszliśmy przez te etapy, których rozmawialiśmy, mamy ostateczną listę tematów, wtedy faktycznie takiej komitji spotyka się. Jesteśmy w stanie te pomysły, potencjalne projekty przeanalizować, porozmawiać o nich. Czasami się zdarza, że jeszcze osoby, które
za tę priorytyzację odpowiadają, nie do końca rozumieją, na czym te projekty mają polegać. I na bazie i podczas takiego spotkania ustala się lista czy też road map. Więc tutaj akurat jest to dość mocno straightforward.
Wojtek (26:35) Czyli co jakieś takie subiektywne głosowania lub jakieś rankingi jakieś przydzielania?
Bartosz (26:41) Znaczy jeżeli
chodzi o metody, to metod jest wiele. Mamy tradycję z Moskou. Podejrzewam, tutaj w zależności od tego, jakie człowiek ma doświadczenia i gdzie widział największe sukcesy, to taka metoda jest używana, ale z mojej perspektywy
Rozpisywaliśmy to na nie przywołam się teraz z głowy na ile punktów robiliśmy sobie rankingi przypisywaliśmy faktycznie wagi i na bazie tego ustalana była ostateczna lista. To jest dość wcześniej powiedziałem że to jest straight forward bo to jest generalnie proste ale sam proces jako taki ilość tych zmiennych jest dość długa.
Wojtek (27:41) Jasne, bo tu chciałem dopytać w takim razie, tak metod na pewno jest bardzo dużo. Co ty polecasz, co według ciebie działa po prostu? Czy to właśnie to co wspomniałeś, czy…
Bartosz (27:55) Wydaje mi się, przynajmniej z mojego doświadczenia ustalenie tak naprawdę w tym gronie, którym te decyzje zapadają, co jest dla nas ważne i czym się kierujemy wracając jakby do tego, że współdecydowanie o tym sprawia, że te osoby w takiej priorytyzacji chętnie biorą udział, bo mają jakby na to wpływ od samego początku.
bardzo pomaga w samym procesie. Czym mimo wszystko jesteśmy w stanie porozpisywać te aspekty, których nam zależy bardziej szczegółowo tym lepiej. Tutaj na pewno najważniejszymi aspektami tego jest zadowolenie naszego klienta i generalnie to czy taki feature, taki projekt.
nam się zwróci. To są jakby rzeczy z mojej perspektywy, tematy, których czasami się zapomina, zwłaszcza to drugie, a mimo wszystko jest kluczowe.
Wojtek (29:07) Czyli co, żeby to odrzeć troszeczkę z jak takiej, nie wiem może, magii, tego, bo liczby liczbami oczywiście na liczby się patrzy, ale w takim razie w przypadku takiej priorytetacji koniec końców sprowadza się do subiektywnego zdania osób odpowiedzialnych za firmę i ich intuicji. Znaczy, bo intuicja to wiadomo, to już nie jeden ekspert mówił, tu nie chodzi o jakieś takie czary mary, że mi się wydaje, tylko intuicja lidera to jest jednak
możliwość wyciągania wniosku w oparciu o dane, jak widzą te dane, to po prostu pchają w tym kierunku.
Bartosz (29:39) To jest…
Tak,
tutaj nie możemy powiedzieć, że to jest intuicja, to są też dane, to są też analizy konkurencji, to są też analizy potrzeb, to też jest dokładnie waga, bo jeżeli mimo wszystko my wiemy z różnych źródeł, że nasi klienci się tego potrzebują, czy się tego domagają, to też jest…
rzecz, która bardzo mocno wpływa na prioritizację.
Wojtek (30:15) OK, ale nawet jeżeli są te dane, to nie te dane wprost wchodzą w ten algorytm priorytetacji, tylko decyzje menadżerów w oparciu po prostu chyba do tego jednego chcę tutaj jak gdyby dojść. Czy uważasz, że priorytetacja powinna być tak z automatu oparta o to, co jest zbierane, też bez ingerencji człowieka, załóżmy rzeczywiście suche dane, czy końc w końcu…
Bartosz (30:41) Nie wydaje mi
się, że powinna być to, że ta decyzja powinna zapadać jakby z algorytmu na bazie danych. Najlepszą sytuacją jest, jeżeli faktycznie człowiek, ludzie mają szansę z tymi idynymi się zapoznać, wyciągnąć wnioski i na bazie tych wniosków i faktycznie później się rozmowy podjąć decyzję.
nie skłaniałbym się tutaj w stronę automatyzacji tego procesu decyzyjnego, bo chyba jeszcze nie jesteśmy na tym etapie, żeby temu procesowi tak bardzo ufać. I mimo wszystko jeszcze właśnie ta intuicja w przypadku ludzkich decyzji w wielu przypadkach nam pomaga.
Wojtek (31:24) OK
czyli po prostu zespół, który potem odpowiada za wynik. To chciałem się tak tylko upewnić. No dobra, to teraz tak trochę o twoim doświadczeniu tutaj. Wiadomo, że to co ciekawsze, czyli tym negatywnym doświadczeniu, jakieś może przykłady z pierwszej albo drugiej ręki, błędów, które kosztowały czas nerwy, czego unikać.
Bartosz (32:07) To może skupię się na dwóch przykładach. Jednym generalnie negatywnym, który kosztował nas faktycznie bardzo dużo nerwów i drugim, który może nasze ego trochę nas zabolało, ale mimo wszystko z tego wyszło coś pozytywnego. Mówiąc o pierwszym. Tutaj jest to dość proste.
Rozmawialiśmy o analizie projektów, rozmawialiśmy o ich estimacji. I jakby jedna z gorszych doświadczeń moich wiąże się z projektem, który został po prostu źle wyestymowany i który został źle wyestymowany jakby od początku, ale mimo wszystko pozwoliliśmy sobie na rozrost jego w trakcie. Ten projekt
Przerósł nasze możliwości, powiedzmy, przerobowe i z tego powodu mocno się wydłużył i to nas kosztowało naprawdę dużo nerwów i stresu. Także jakby ucząc się też na tym, przykładamy teraz dużo większą wagę do analizy na właśnie tym wczesnym etapie, żeby sobie na takie sytuacje nie pozwolić. I drugi pozytywny, o tym ego,
To sytuacja, której, tak jak już sumie wspominałem, przedstawialiśmy rozwiązanie klientowi i klient nam powiedział, znaczy nie klientowi, tylko klientom i klient nam powiedział, że oni chcą zupełnie coś innego tak naprawdę.
My myśleliśmy, że może bez przesady ze złocym gralem i ostatnio z super rozwiązaniem, ale wydawało się bardzo dobry pomysł. Generalnie, podejrzewam, dalej uważamy, że jest to dobry pomysł, ale mimo wszystko jest on niepotrzebny.
Wojtek (34:18) Ale to było już po realizacji projektu? Czy udało się to przed?
Bartosz (34:22) To było,
to wyszło na etapie prototypy.
Wojtek (34:28) Rozumiem. No czyli jeszcze dosyć wcześniej jeszcze prawie że można to zaliczać jako nie błąd. Natomiast z ciekawości to były po prostu nie wiem błędy komunikacyjne. sensie już pytaliście wcześniej trochę klienta o to czego chcą i źle to zrozumieliście czy nazwijmy to ktoś zapomniał zapytać klienta o zdanie i.
Bartosz (34:57) Został nam przedstawiony obszar w pracy klienta, który jest dla nich jednym z bardziej problematycznych. Z naszej strony przeprowadziliśmy analizę w jaki sposób można by to rozwiązać, jakie mamy potencjalnie narzędzia, które możemy użyć.
Właśnie idąc z hypem AI próbowaliśmy użyć tam rozwiązania użyć używającego, użyć rozwiązania AI-owego. Okazało się, że będziemy w stanie to rozwiązać w sposób tradycyjny.
Wojtek (35:42) i taki teraz obecnie typowy błąd przy AI troszeczkę tak wrzućmy AI wszędzie gdzie się da a klient tak naprawdę potrzebował kosy a nie kombajnu tak no ok dobra
Bartosz (35:49) Z troską, tak.
Nie, nie, nie aż
tak źle, ale blisko.
Wojtek (35:59) Rozumiem, świetnie. Teraz tak, ciężko jest pytać o sukcesy, bo o sukcesach się aż tak dużo nie myśli i z tych sukcesów jest pewnie więcej, jak błędów popełnionych. Natomiast nie wiem, jeżeli przyszłoby ci coś do głowy, co udało ci się właśnie w całym tym procesie poprawić w ciągu ostatniego czasu.
Bartosz (36:26) Znaczy wydaje mi się, że zmiany, które udało nam się poczynić właśnie na pierwszych etapach pracy przy projektach są kluczowe, bo jesteśmy dużo lepiej przygotowani i przechodzimy przez proces dużo łatwiej i bez żadnych większych zgrzytów. Oczywiście tak jak powiedziałeś, to trochę wyglądało jak waterfall, ale mimo wszystko
Pracując nad czymś i odkrywając pewne rzeczy jesteśmy otwarci na to, żeby je poprawiać czy nawet zmieniać. Także to jakby wydaje mi się jedną z ważniejszych rzeczy, a drugą ważną rzeczą jest na pewno zmiana trochę procesu tak, żeby większa ilość osób była w to zaangażowana, w tym też klienci.
już od wczesnych etapów.
Wojtek (37:25) No OK. Tylko to tak to jest też takie ciekawe zagadnienie bo ja się też zawsze zastanawiam na ile ten klient jak jest za wcześnie i to jeszcze nie jest w stanie się odnieść i może troszeczkę namieszać. Widzisz tutaj jakieś zagrożenie.
Bartosz (37:41) Znaczy…
Nie spotkałem się tym osobiście, żeby takie zamieszanie straszne zostało wprowadzone. Oczywiście może to trochę popsuć szyki, ale wtedy wydaje mi się przy odpowiedniej komunikacji z klientem, nawet jeżeli będziemy szli w odpowiednią stronę, jeżeli się jemu to wytłumaczy, no to tutaj też nie rodzą się problemy.
a potencjalnie, tak jak mówię, pewne kierunki mogą być zmieniane, mogą się… Jesteśmy w stanie dużo szybciej zareagować na pewne rzeczy.
Wojtek (38:25) OK, dobra, świetnie. co, taką klamrą już zawsze na końcu musi być jakaś wisienka na torcie w stylu jakiś mit do obalenia, ale tu bym powiedział jakaś rada dla tych, którzy się borykają z zarządzaniem backlogiem czy właśnie tym…
Bartosz (38:47) Znaczy mi się wydaje, że to rada może nie tylko do zarządzania backlogiem, generalnie.
Nie należy się bać feedbacku. Tutaj oczywiście w dużej mierze się to łączy z ego, ale w niektórych sytuacjach nam tego pomaga, a w przypadku przyjmowania feedbacku może nam mocno zaszkodzić. Oczywiście jeżeli ten feedback jest konstruktywny.
Wojtek (39:00) OK
Rozumiem. Znaczy no tu masz rację. Tak, tu bardzo dobra rada w sumie tak z tym tym feedbackiem. Myślę, że też jeszcze trzeba o niego zapytać czasem na tych na tych wczesnych etapach, bo ludzie są różni. Natomiast tak nie ma się co bać feedbacku, bo tak jak sobie pomyślałem jak to powiedziałeś feedback do nas tak czy tak wróci tylko w formie może już nieformalnego feedbacku, a skarg klientów, że coś im nie działa.
to tak lub w spadku sprzedaży lub jakiegoś czarna. super. Dziękuję ci za rozmowę Bartek. I do usłyszenia.
Bartosz (39:57) Dzięki bardzo. Do
usłyszenia.
Wojtek (40:08) Mam nadzieję, że forma wideo, przynajmniej dla oglądających, przypadła wam troszeczkę bardziej do gustu. Mi osobiście wydaje się, że podcast nabiera troszeczkę takiej większej dynamiki. Oczywiście dla tych, którzy wolą słuchać podcastu tylko na słuchawkach, gdzieś w autobusie, pociągu, metrze czy na spacerze. Dalej te odcinki robione są w taki sposób, żeby był to przede wszystkim podcast głosowy i że na pewno niczego nie stracicie.
Przypominam, że transkrypcję do tego odcinka znajdziecie na HospodaTech łamane na 17. Jak również zachęcam do wejścia na stronę i zapisania się do newslettera. Jeżeli jesteście ciekawi tego, co będzie za tydzień, to sugeruję zasubskrybować podcast w aplikacji, w której mnie w tej chwili słuchacie albo oglądacie. Jeżeli jest taka możliwość, zostawcie jakiś komentarz, wystawcie ocenę, dajcie lajka.
Na pewno jest to duża motywacja do dalszego tworzenia podcastu. Przypominam również o tym, że hospoda.tek znajdziecie na Facebooku, iksie lub blue sky app. A za dzisiaj już dziękuję, do usłyszenia za tydzień.
- Category:
- Rozmowy