Jak najlepiej wykorzystać prezentację oprogramowania

 

Przeczytaj transkrypcję:

Testujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Prosimy o wyrozumiałość w przypadku literówek, ponieważ bot nie zawsze działa w 100% poprawnie.

Galen Low: Cóż, kolejna prezentacja oprogramowania dostawcy kończy się katastrofą. Dyrektor technologiczny i lider DevOps najwyraźniej grają w bingo słów-wytrych z każdym marketingowym żargonem, o którym wspomina prowadzący. Oczy dyrektora generalnego zaczynają się szklić, gdy tematy stają się zbyt techniczne. I mimo że osoba prowadząca naprawdę wydaje się znać na rzeczy, nikt nie porusza słonia w pokoju: faktu, że ta osoba jest kuzynem waszego dyrektora generalnego.

Czy nie da się lepiej wykorzystać czasu wszystkich uczestników?

Jeśli słabe prezentacje były przeszkodą w podjęciu świadomej decyzji dotyczącej nowego oprogramowania dla waszej organizacji, słuchajcie dalej.

Omówimy niektóre z najskuteczniejszych strategii, dzięki którym etap prezentacji w procesie wyboru oprogramowania będzie znacznie bardziej dopasowany do konkretnych potrzeb waszej organizacji.

Cześć wszystkim, dziękuję za dostrojenie się! Nazywam się Galen Low i reprezentuję Digital Project Manager. Jesteśmy społecznością specjalistów cyfrowych, której misją jest pomaganie sobie nawzajem w zdobywaniu umiejętności, pewności siebie i kontaktów, aby podnosić wartość zarządzania projektami w cyfrowym świecie. Jeśli chcecie dowiedzieć się więcej, odwiedźcie stronę thedigitalprojectmanager.com.

Dobrze. Dziś rozmawiamy o procesie wyboru nowego oprogramowania dla zespołów projektowych, a w szczególności o tym, jak przejść przez prezentację sprzedażową oprogramowania i upewnić się, że dane narzędzie jest nie tylko najlepszym narzędziem, ale także właściwym narzędziem dla sposobu pracy waszych zespołów. Jest ze mną Olivia Montgomery, Associate Principal Analyst w firmie Capterra i była liderka PMO IT, która obecnie doradza małym i średnim firmom w zakresie wyboru oprogramowania.

Cześć, Olivia!

Olivia Montgomery: Cześć, Galen! Dziękuję za zaproszenie.

Galen Low: Wspaniale, że ponownie jesteś w naszym programie. Jak się masz w Austin?

Olivia Montgomery: Jest naprawdę ekscytująco. Odbywa się South by Southwest i po raz pierwszy od 2020 roku wydarzenie wróciło w formule stacjonarnej. Miasto tętni życiem, jest mnóstwo wydarzeń, prelekcji i różnego rodzaju atrakcji. Ten tydzień jest naprawdę ekscytujący.

Galen Low: Wracamy do działania. South by Southwest bardzo mnie ekscytuje. Cały czas widzę to w mediach społecznościowych. Nigdy nie udało mi się dotrzeć do Austin, ale to tak prężna społeczność muzyczna. Tak wiele się dzieje, jest mnóstwo konferencji i okazji, by ludzie mogli się spotkać i dobrze bawić.

Wygląda więc na to, że nie mam już żadnych wymówek. Być może to będzie ten rok. Być może właśnie ten rok.

Olivia Montgomery: Jest naprawdę świetnie. Są też ścieżki tematyczne poświęcone technologii. Mogłam uczestniczyć w prelekcjach liderów łańcucha dostaw, dyrektora generalnego Amtrak, a także firmy John Deere, która mocno koncentruje się na technologii. Są doświadczenia VR skupiające się na opowiadaniu historii w nowy sposób — od bardzo poważnych tematów po lekką rozrywkę — i pokazujące, jak możemy inaczej wchodzić w interakcję z treściami i ze sobą nawzajem.

Galen Low: Bardzo ciekawe. Co do tej pory podobało ci się najbardziej?

Olivia Montgomery: Poza całą technologią i innowacjami, które oglądamy, miałam okazję zobaczyć na żywo nowego Batmobilu. Muszę powiedzieć, że to jeden z najważniejszych punktów programu. Jestem wielką fanką filmów. Właściwie nie oglądam zwiastunów, więc nie widziałam żadnego. Nie obejrzałam jeszcze Batmana z powodu South by Southwest, ale po raz pierwszy zobaczyłam Batmobil na żywo. To było naprawdę świetne.

Galen Low: Myślę, że to nawet lepsze niż zwiastun.

Olivia Montgomery: Też tak myślę. Pomyślałam: dobrze, już rozumiem, czuję ten klimat. Teraz naprawdę nie mogę się doczekać filmu.

Galen Low: Właśnie na to czekam, odkąd wszystko znów zaczęło się otwierać. Na niespodziewane sytuacje, na rzeczy, których nie planowaliśmy, a które znów pojawiają się przed nami.

Świetnie. Dobrze. Przejdźmy do tematu.

Porozmawiajmy o najbardziej stresującej i budzącej wątpliwości części procesu wyboru oprogramowania, czyli o prezentacji. Zacznijmy od zarysowania sytuacji.

Załóżmy, że powierzono ci znalezienie nowego narzędzia dla organizacji i jesteś albo jedyną osobą decyzyjną, albo przewodniczysz komisji wyboru. Spędziłeś niezliczone godziny na poszukiwaniu przypadków użycia. Zbierałeś wymagania od zespołu. Ustalałeś budżety z kierownictwem i prowadziłeś wiele badań w internecie. Wreszcie masz krótką listę narzędzi, które wydają się odpowiednie, i chcesz zobaczyć je w działaniu.

Dlaczego jest to tak stresujące i budzi tyle wątpliwości? Myślę, że głównie dlatego, iż jest to dosłowne podsumowanie wszystkich dotychczasowych wysiłków. Musisz koordynować wszystkich interesariuszy. Próbujesz skutecznie przekazać wszystkie wymagania dostawcom oprogramowania. Musisz przyswoić ogromną ilość informacji i reagować na bieżąco, a wszystko odbywa się w najbardziej stresującym środowisku ze wszystkich — podczas spotkania.

Pomyślałam więc, że skoro już o tym mówimy, zacznijmy od argumentów sceptyków. Czy zespół lub organizacja w ogóle powinni zawracać sobie głowę prezentacją? Czy to nie jest po prostu prezentacja sprzedażowa?

Olivia Montgomery: Róbcie prezentacje, proszę, naprawdę je róbcie. Rozumiem. Sama uczestniczyłam w wielu prezentacjach, które były bardzo mocno nastawione na sprzedaż. To właśnie wtedy zaczęłam rozwijać pomysły na to, jak je ulepszyć. Wierzę w proces prezentacji i uważam, że zwłaszcza kierownik projektu może wykonać wiele pracy przygotowawczej, aby prezentacje stały się jednym z najważniejszych elementów procesu wyboru.

Tak więc tak, róbcie prezentacje, ale nie są one tak proste, jak podążanie za wskazówkami dostawcy. Myślę, że właśnie tutaj niektórzy popełniają błąd. Naprawdę chcecie kierować prezentacją i ustalać wymagania dotyczące tego, co chcecie zobaczyć.

Galen Low: Myślę, że to wszystko ma sens. Te narzędzia są przecież bardzo rozbudowane. W wielu przypadkach wybieramy narzędzie, które ma robić wiele różnych rzeczy i odpowiadać różnym osobom. Czy w ramach prezentacji w ogóle da się omówić tak szeroki zakres, zamiast tylko pobieżnie przejrzeć podstawowe funkcje oprogramowania? Jakie strategie powinna rozważyć organizacja, aby uzyskać potrzebne odpowiedzi?

Olivia Montgomery: Tak. To świetne pytania.

Przede wszystkim nie, nie da się omówić wszystkiego podczas prezentacji oprogramowania. Właśnie tutaj przydadzą się wcześniejsze badania w internecie. Jeśli przeprowadzacie proces RFP albo ograniczyliście wybór do dwóch lub trzech dostawców, poproście ich o przesłanie wszystkich informacji w dokumencie. Prezentacja nie jest najlepszym miejscem do omawiania całej potrzebnej funkcjonalności.

Powinniście skupić się przede wszystkim na wyglądzie interfejsu użytkownika oraz na kilku kluczowych historiach użytkownika, które zespół musi przejść. Jakie procesy biznesowe ma wspierać to narzędzie? I szczerze mówiąc, czy użytkownikom podoba się jego wygląd i sposób działania? Dla nich może to być pierwszy kontakt z narzędziem i jego interfejsem.

Dlatego wygląd i sposób działania są tutaj kluczowe. Lista rzeczywistej funkcjonalności powinna być zapisana przed podpisaniem umowy.

Galen Low: To bardzo ważne. Dziękuję, bo wcześniej przedstawiłem prezentację jako kulminację całego procesu, jako punkt, do którego prowadzą wszystkie drogi, ale w rzeczywistości prezentacja tylko uzupełnia pewne luki.

Jest częścią procesu badawczego. Są rzeczy, które trzeba zobaczyć w działaniu, aby wyrobić sobie zdanie — tak jak powiedziałaś, chodzi o interfejs użytkownika i konkretne przypadki użycia. Nie chodzi o to, że przeprowadziłem całe badanie, wiem, że narzędzie potrafi robić wiele rzeczy, przejrzałem tabelę porównawczą, a teraz pokażcie mi każdą funkcję w ciągu dwóch godzin. To prawdopodobnie nie skończyłoby się dobrze.

Chodzi raczej o sytuację: świetnie, wiemy już to wszystko, widzieliśmy te informacje na papierze, przesłaliście mi dodatkowe szczegóły, a teraz zaplanujmy prezentację, podczas której zagłębimy się w kilka istotnych kwestii.

Olivia Montgomery: Dokładnie. Właściwie zdecydowanie zalecam zaplanowanie dwóch prezentacji.

Lubię prezentację skierowaną do biznesu, a następnie prezentację techniczną. Połączenie ich w jedno spotkanie stworzyłoby bardzo długie i skomplikowane wydarzenie. Połowa interesariuszy nie byłaby zainteresowana częścią techniczną, a druga połowa częścią biznesową. Zalecam więc ich rozdzielenie, aby uszanować czas interesariuszy.

Potrzebni są też inni uczestnicy. Nie będą to te same osoby. Dlatego uważam, że jest to kolejny etap weryfikacji, ale także dalsze zbieranie wymagań od dostawcy. Niezależnie od tego, czy chodzi o narzędzie do zarządzania projektami, narzędzie księgowe, nowy system ERP czy inne oprogramowanie, lubię stosować podobną strukturę prezentacji.

Pierwsza prezentacja powinna być skierowana do biznesu. Powinien wziąć w niej udział właściciel biznesowy. To prawdopodobnie oczywiste, ale warto też zaprosić zaawansowanego użytkownika. Często jest to przełożony, lider albo osoba, która korzysta z narzędzia codziennie. Dzięki temu można spojrzeć na narzędzie zarówno z perspektywy strategicznej i długoterminowej, jak i z perspektywy codziennego użytkownika.

Właściciel biznesowy może zdecydować, czy narzędzie będzie wspierać rozwój organizacji i jej kierunek, ale potrzebny jest także zaawansowany użytkownik, który oceni konkretną historię użytkownika. Chce on wiedzieć, czy kluczowa funkcja, którą musi wykonywać, jest możliwa do zrealizowania oraz jak wygląda i działa w praktyce.

Czasami kierownicy projektów mówią mi, że nie zawsze mogą uzyskać zgodę na udział zaawansowanego użytkownika w którejś z prezentacji. Bywa, że jest za wcześnie albo pojawiają się różne wymówki. Jednak zaawansowany użytkownik będzie uczestniczyć w dalszej części projektu. Prawdopodobnie stanie się osobą odpowiedzialną za zapewnienie jakości podczas wdrożenia.

To główne źródło wymagań użytkowników. To zespół, który będzie korzystał z narzędzia. Użytkownicy muszą być zadowoleni z jego wyglądu i sposobu działania, a prezentacja jest właśnie weryfikacją tych elementów. Dlatego trzeba zadbać o obecność obu tych osób.

Kolejnym sposobem przygotowania prezentacji jest zebranie historii użytkownika od zespołu, w tym co najmniej jednej lub dwóch od zaawansowanego użytkownika, i przesłanie ich dostawcy z dużym wyprzedzeniem. Najlepiej zrobić to kilka dni przed zaplanowanymi prezentacjami, aby dostawca mógł skonfigurować system i przeprowadzić was dokładnie przez daną historię użytkownika. Powinniście móc powiedzieć: jako księgowy muszę wygenerować raport zamknięcia miesiąca w ciągu 24 godzin, aby zamknąć miesiąc księgowy. Musicie zobaczyć, jak ta czynność jest wykonywana w narzędziu.

Historia użytkownika nie powinna dokładnie definiować: chcę zobaczyć tę konkretną funkcję w narzędziu. Pozostawia to przestrzeń na to, że dane narzędzie opracowało innowacyjny sposób osiągnięcia celu lub wykonania funkcji, którego wcześniej nie znaliście. Nie należy więc ograniczać dostawcy, mówiąc: pokażcie mi tylko to. Trzeba pozostać otwartym.

Ogólnie rzecz biorąc, zaawansowany użytkownik musi móc zobaczyć swoją kluczową funkcję. Właściciel biznesowy również będzie mieć wymagania, które chce zobaczyć, zazwyczaj panel kierowniczy. Jak on wygląda?

Jak wygląda narzędzie po zalogowaniu się jako menedżer, lider lub dyrektor generalny? Jak wyświetlić raporty na panelu? To kolejny element, którego wygląd i sposób działania trzeba zobaczyć. Warto poprosić dostawcę o wprowadzenie przykładowych danych. Zazwyczaj dostawca przygotuje środowisko testowe na potrzeby prezentacji. Niech załaduje przykładowe dane, aby można było ocenić strukturę raportowania.

Galen Low: To bardzo ciekawe. Podoba mi się pomysł rozdzielenia grupy. Czasami wydaje się to sprzeczne z intuicją w procesie podejmowania decyzji, ale podoba mi się idea dwóch różnych prezentacji, ponieważ w przypadku tego narzędzia trzeba przeprowadzić dwie różne rozmowy.

Ostatecznie chodzi o najlepsze wykorzystanie czasu ludzi. Czasami spotykamy się z oporem: nie chcemy na tym etapie angażować naszego zaawansowanego użytkownika z księgowości, bo jest za wcześnie i tak dalej. W rzeczywistości jest to jednak część oceny długoterminowego wykorzystania narzędzia oraz głębokości jego zastosowania.

Chodzi także o weryfikację i uczynienie z tej osoby ambasadora procesu wyboru, ponieważ uczestniczyła w nim i była obecna. Jeśli jej zabraknie, może stać się najgłośniejszym głosem w pomieszczeniu twierdzącym, że podjęto złą decyzję.

Podoba mi się też to, co powiedziałaś o środowisku testowym. W przypadku niektórych osób proces wyboru oprogramowania wygląda tak: najpierw wykonujemy pracę, potem odbywa się prezentacja, a uczestnicy siedzą i oglądają. Później chcielibyśmy otrzymać środowisko praktyczne, w którym można samodzielnie wypróbować rzeczy pokazane podczas prezentacji.

Czy możliwa jest sytuacja, w której uczestnicy testują narzędzie samodzielnie w środowisku testowym podczas prezentacji, czyli biorą udział w prezentacji praktycznej?

Olivia Montgomery: Jestem pewna, że zaawansowani użytkownicy bardzo chcieliby mieć taką możliwość. Jednym z problemów jest to, że chcecie wybrać narzędzie odpowiednie zarówno dla obecnych, jak i przyszłych procesów. Czasami prezentacja koncentruje się wyłącznie na stanie przyszłym.

Czasami zakłada się, że po wdrożeniu narzędzia nasze procesy radykalnie się zmienią i automatycznie dojrzeją dzięki automatyzacji. Nie zawsze jest to jednak rzeczywistość. Zaawansowany użytkownik będzie w stanie ocenić, czy od pierwszego dnia narzędzie sprawdzi się w pracy, czy spełni obecne potrzeby i jednocześnie wesprze przyszły stan.

Wejście do środowiska testowego przed prezentacją mogłoby pomóc zaawansowanemu użytkownikowi stwierdzić: tak, mogę używać tego już dziś, a moja praca nadal będzie wykonana. Nie włączymy narzędzia i nie stracimy całej funkcjonalności.

Nie wiem, czy zespoły techniczne naprawdę chciałyby, mogłyby lub miałyby czas, aby to zrobić. Jestem jednak zdecydowaną zwolenniczką przejrzystości i otwartości. Porozmawiajcie z interesariuszami i dostawcą o swoich potrzebach oraz ich pomysłach. W ten sposób przechodzicie przez prezentację sprzedażową, nie pozwalając dostawcy całkowicie nią kierować, ale jednocześnie warto pozostać otwartym, ponieważ dostawca zna rozwiązanie.

Być może ma innowacyjne sposoby podejścia do problemu, o których wcześniej nie pomyśleliście. Na to również trzeba pozostać otwartym.

Galen Low: Bardzo mi się to podoba. Porozmawiajmy jeszcze o przygotowaniu do tych dwóch prezentacji. Czy masz jakieś ciekawe historie lub przykłady przypadków użycia, które zespół powinien poprosić o przeprowadzenie, aby upewnić się, że oprogramowanie działa tak, jak powinno? Albo o samym procesie zbierania historii użytkownika, tak aby nie ograniczać go zbyt mocno?

Nie chodzi o: pokażcie mi tylko jedną rzecz. Jeśli oprogramowanie podchodzi do problemu inaczej, zespół powinien móc to ocenić.

Olivia Montgomery: Oczywiście. Jeśli macie szczęście i dysponujecie analitykiem biznesowym IT, który może zebrać wszystkie wymagania, to świetnie. Nie jest to jednak częste. Nawet jeśli macie taką osobę, zaawansowany użytkownik mógł nigdy wcześniej nie przedstawiać historii użytkownika ani wymagań i będzie potrzebować pomocy.

W przeszłości wysyłałam ankietę do zespołu, zaawansowanego użytkownika i liderów działów, którzy będą korzystać z narzędzia. Nadawałam jej strukturę w stylu Mad Libs. Historia użytkownika brzmiała: jako [stanowisko] potrzebuję możliwości [czynność], aby [powód wykonania czynności].

Taka struktura pomaga szybko uzupełnić puste miejsca. Jest prosta i łatwa, a następnie można przesłać dokładnie tę historię użytkownika dostawcy, mówiąc: właśnie to chcemy zobaczyć.

Podoba mi się więc podejście oparte na schemacie Mad Libs.

Galen Low: Uwielbiam Mad Libs i historie użytkownika, a tutaj mamy połączenie obu tych rzeczy. To świetny sposób patrzenia na problem. Pozostawia dostawcy przestrzeń do przygotowania prezentacji pokazującej, jak oprogramowanie rozwiązuje dany problem, a jednocześnie pozwala zespołowi uzyskać potwierdzenie, że narzędzie wykona daną czynność i jak należy to zrobić. Bardzo ciekawe.

Olivia Montgomery: Zobaczenie narzędzia i upewnienie się, że podoba wam się jego wygląd oraz sposób działania, to główny cel prezentacji biznesowej. Wspominałam także o drugiej, technicznej prezentacji. Historie użytkownika mogą tutaj obejmować częstotliwość wykonywania zadań. Czy trzeba czekać? Czy można zaplanować zadania na pierwszą w nocy? Czy będą działać przez godzinę? Czy jest to akceptowalne dla biznesu? Czy potrzebujemy uruchamiać je częściej lub rzadziej? Czy narzędzie ma takie możliwości?

Właśnie dlatego na tej części prezentacji powinni być obecni lider techniczny zespołu oraz lider techniczny dostawcy.

Administrator systemu musi wiedzieć, jak działa narzędzie, podobnie jak osoba odpowiedzialna za architekturę IT i inżynier. Muszą wiedzieć, gdzie przechowywane są dane. Czy dostawca je hostuje? Czy to wam odpowiada? Czy hostujecie je sami? Gdzie dokładnie? Jest mnóstwo szczegółów technicznych, których omówienie dopiero przy podpisywaniu umowy może prowadzić do bardzo nieprzyjemnych niespodzianek.

Ta część musi należeć do procesu weryfikacji. Dwa zespoły techniczne powinny wspólnie odpowiadać na pytania, oglądać rozwiązanie i omawiać jego możliwości. Mogą zapytać: czy to będzie wymagać niestandardowego kodu? Czy ta funkcja jest dostępna od razu?

To pytania, na które właściciel biznesowy i zaawansowany użytkownik prawdopodobnie nie będą znać odpowiedzi. Czasami również kierownik projektu, chyba że jest kierownikiem projektu technicznego. Trzeba je więc zadawać. Warto też zapytać o integracje: czy któryś z obecnych klientów ma integrację z konkretnymi używanymi przez was narzędziami?

Nie bójcie się wymienić nazw narzędzi i zapytać, czy dostawca ma z nimi integracje. W przypadku większych firm może się to wydawać oczywiste, ale czasami trzeba zadawać bardziej dociekliwe pytania. W przypadku mniejszych firm również chcecie znać odpowiedź.

Jeśli dostawca nie ma istniejącej lub gotowej integracji, trzeba ustalić, czy jest to dla was przeszkoda nie do zaakceptowania. Czy trzeba stworzyć niestandardową integrację? Czy macie na to zasoby? Czy dostawca jest gotowy ją przygotować? Czy macie na to czas? Wszystkie te rozmowy powinny się odbyć.

Może się wydawać, że rozmowa stanie się zbyt obszerna, ale zapewniam, że tak nie będzie, jeśli dobrze się przygotujecie. Zespoły techniczne będą wiedzieć, o co zapytać. Oszczędzicie sobie wielu problemów, jeśli nie odłożycie tych kwestii na późniejszy etap procesu.

Galen Low: To bardzo ważny punkt. Jest wiele tematów do omówienia i rozmowa może stać się zbyt obszerna. Chcemy skupić się na konkretnych przypadkach użycia, ale oprogramowanie, takie jak CRM, ERP czy system zarządzania treścią, musi wykonywać wiele różnych czynności. Zademonstrowanie ich i omówienie wymaga czasu.

Jak wybrać i ustalić priorytety przypadków użycia oraz pytań, na które dostawca powinien odpowiedzieć, aby rozmowa nie stała się zbyt obszerna?

Olivia Montgomery: To bardzo ważne pytanie. Trzeba polegać na liderach zespołów, liderach biznesowych i zaawansowanym użytkowniku. Przed prezentacją należy z nimi porozmawiać i zapytać: jakie są wasze główne obawy? Co koniecznie musimy omówić?

Niech powiedzą, co jest najważniejsze. Jeśli jesteście bardzo technicznym kierownikiem projektu, możecie prowadzić te rozmowy, ale wiele osób nim nie jest. Polegajcie na innych, pytajcie: jakie dwie lub trzy rzeczy musicie zobaczyć?

Następnie dopilnujcie, aby zostały omówione podczas prezentacji i aby rozmowa nie zboczyła z tematu. Kierownik projektu powinien również moderować prezentację. Jeśli ktoś zbyt szczegółowo zagłębia się w jeden temat, można powiedzieć: chcę dopilnować, abyśmy omówili te trzy kwestie. Dostawcy zazwyczaj dobrze zarządzają czasem, ponieważ przeprowadzili wiele prezentacji swoich produktów, ale nie bójcie się włączyć do rozmowy.

Aby to zadziałało, trzeba wcześniej porozmawiać z osobami uczestniczącymi w prezentacji i powiedzieć: oto trzy kwestie, które omówimy. Dzięki temu nie będą zaskoczone i nie poczują, że je przerywasz lub ignorujesz. Będą wiedzieć, że uzgodniliście plan i można do niego wrócić.

Galen Low: To bardzo ważne. W roli kierownika projektu są obszary, nad którymi mamy kontrolę i za które odpowiadamy, w tym za przygotowanie procesu.

Niektóre decyzje należą jednak do sponsorów i osób decyzyjnych, nawet w projekcie wyboru oprogramowania. Musimy polegać na procesie decyzyjnym i na zespole kierowniczym, który ustala priorytety oraz określa, co chcemy osiągnąć podczas prezentacji. Jednocześnie musimy zebrać opinie różnych zespołów, które będą korzystać z narzędzia.

W ten sposób uzupełniają oni swoje historie użytkownika, rejestrują i dokumentują przypadki użycia, a ostatecznie mają swój głos w procesie.

Olivia Montgomery: Zgadza się. Można też przypominać wszystkim, że podczas prezentacji staracie się omówić trzy, najwyżej cztery konkretne historie użytkownika, które wcześniej przekazaliście dostawcy. Dzięki temu dostawca zna temat i jest przygotowany.

Wszystko poza tym można poprosić o przedstawienie w formie pisemnej w ramach RFP albo innego dokumentu. Można powiedzieć: potrzebujemy dokumentacji dotyczącej tej kwestii. Jaki będzie koszt? Po prezentacji warto uzyskać od dostawcy zestawienie: ta konkretna funkcja wymaga niestandardowego kodu i będzie kosztować określoną kwotę; dostawca ją zbuduje albo trzeba będzie zrobić to samodzielnie.

Oprogramowanie ogólnie zmierza w kierunku rozwiązań wymagających niewielkiej ilości kodu, dzięki czemu administrator, programista interfejsu, a nawet zespół biznesowy lub zaawansowany użytkownik mogą konfigurować wiele przepływów pracy. Trzeba jednak wiedzieć, kto będzie musiał je tworzyć — dostawca czy wy. To samo dotyczy integracji.

Aby podczas prezentacji nie zagłębiać się zbyt mocno w szczegóły, przypominajcie wszystkim: te kwestie umieścimy w dokumentacji, a teraz przejdźmy dalej i zobaczmy działanie oprogramowania.

Galen Low: Bardzo mi się to podoba. Wróćmy do pomysłu rozdzielenia grupy. Ustaliliśmy, że należy przygotować dwie prezentacje: biznesową, z udziałem zaawansowanego użytkownika i oceną interfejsu, oraz techniczną, dotyczącą infrastruktury, integracji, zadań harmonogramowanych i procesów działających w tle.

W pewnym momencie te elementy muszą jednak znów się połączyć. Różne grupy prowadzą rozmowy i dokonują oceny na podstawie różnych informacji. Czy cała komisja wyboru powinna stworzyć kartę oceny, aby porównywać produkty z krótkiej listy na równych zasadach i dokumentować swoje przemyślenia, tak by po ponownym spotkaniu móc określić i ocenić opinie dotyczące oprogramowania?

Czy może jest to przestarzałe podejście, ponieważ produkty i oprogramowanie są obecnie tak różne, że niektórych z nich nie da się porównać za pomocą jednej skali?

Olivia Montgomery: Cieszę się, że wspomniałeś o kartach oceny dostawców. Jestem ich wielką zwolenniczką. Nadal zdecydowanie mają swoje miejsce i wcale nie są przestarzałe. Za każdym razem, gdy można ograniczyć reakcje emocjonalne, które są częstym problemem podczas mocno sprzedażowych prezentacji, warto to zrobić. Trzeba pamiętać, dlaczego w ogóle kupujecie oprogramowanie.

Karta pomaga zapisać problem, który rozwiązujecie, a następnie porównać, jak każdy dostawca sobie z nim radzi. Można pomyśleć: ten dostawca był bardzo interesujący, ale karta zawiera pytania takie jak: czy narzędzie spełnia nasze wymagania funkcjonalne? Obejmuje stronę biznesową i techniczną, ponieważ jeśli narzędzie nie spełnia obu rodzajów wymagań, nie jest dobrym rozwiązaniem.

Nawet jeśli właściciel biznesowy uwielbia jedno konkretne narzędzie z powodów emocjonalnych, bez karty oceny lub ustandaryzowanej skali nie ma śladu pokazującego, jak podjęliście decyzję. Karty są przydatne podczas rozmów decyzyjnych. Jako kierownik projektu zdecydowanie zalecam ich przechowywanie, ponieważ nigdy nie wiadomo, kiedy projekt zostanie poddany audytowi.

Nie wiadomo też, kiedy ktoś zacznie zadawać pytania albo kiedy za kilka lat pojawi się potrzeba wymiany oprogramowania. Wtedy można sprawdzić, dlaczego pierwotnie nie wybrano konkretnego dostawcy. Być może otrzymał jeden punkt w kategorii integracji.

Kiedy wrócicie do rozmów z tym dostawcą, będziecie mogli sprawdzić, czy integracje są już dostępne. W ten sposób proces podejmowania decyzji będzie świadomy i oparty na informacjach. W pełni popieram i polecam karty oceny dostawców. Pozwalają zebrać różne informacje i połączyć je w całość. Wszyscy mogą zobaczyć swoje oceny — można użyć jednej wspólnej karty albo pozwolić każdemu kluczowemu interesariuszowi przygotować własną, a następnie połączyć je razem.

Zależy to od wielkości firmy oraz rozmiaru i złożoności systemu. W przypadku narzędzia do zarządzania projektami prawdopodobnie wielu liderów wypełni własne karty, a kierownik projektu połączy je w całość. Trzeba je także zachować, ponieważ nigdy nie wiadomo, kiedy będą potrzebne.

Galen Low: Chcę wyodrębnić trzy kwestie. Po pierwsze, karta oceny dostawcy nie musi być całkowicie ogólna. Można określić, co chcecie osiągnąć i dlaczego kupujecie nowe oprogramowanie. To właśnie jest skala oceny.

Olivia Montgomery: W rzeczywistości wolę, gdy karty są mniej szczegółowe. Skala od 1 do 10 może być zbyt szeroka. Zwykle zalecam ograniczenie jej do skali od 1 do 5 i zdefiniowanie znaczenia każdej oceny. Jedynka może oznaczać niespełnienie oczekiwań, piątka ich przekroczenie, a zero — brak danej funkcji.

Galen Low: Nieistniejąca funkcja. Tak.

Olivia Montgomery: Właśnie. Skala od 1 do 5 jest bardziej przejrzysta i zmusza ludzi do udzielania bardziej jednoznacznych odpowiedzi. Ułatwia także obliczenia, szczególnie przy przypisywaniu wag poszczególnym kryteriom. Warto jasno wyjaśnić, co oznacza każda ocena: spełnia oczekiwania, nie spełnia oczekiwań, przekracza oczekiwania albo nie ma funkcji.

Galen Low: Podoba mi się to. Druga kwestia dotyczy rozdzielenia grupy i różnych rozmów. Wiele osób uważa, że wszyscy powinni stosować dokładnie te same kryteria, ale może nie każdy powinien oceniać wszystkie obszary. Zespół techniczny może oceniać integracje i bezpieczeństwo, a zespół biznesowy funkcje związane z działalnością.

Jeśli każda grupa stosuje spójne kryteria wobec wszystkich narzędzi, po powrocie do wspólnego stołu można porównać wyniki, bez oceniania kwestii, które wykraczają poza kompetencje danej grupy.

Olivia Montgomery: Zasadniczo zalecam jedną kartę, która zawiera wymagania techniczne i biznesowe, a następnie jasne wskazanie, kto jest odpowiedzialny za poszczególne kolumny i wiersze. Zespół techniczny powinien oceniać integracje, wymagania dotyczące cyberbezpieczeństwa i inne kwestie techniczne, a kierownictwo może oceniać panel raportowania.

Chcę jednak, aby wszystkie informacje były udostępniane wszystkim uczestnikom. Można ukryć niektóre kolumny w wersjach wysyłanych konkretnym osobom, ale powinny one wiedzieć, że te obszary istnieją.

Wspólna karta pomaga zrozumieć, że istnieją także inne perspektywy. Czasami pojawiają się ciekawe rozbieżności. Szef IT może powiedzieć, że dostawca nie ma obecnie klientów korzystających z danej integracji i dlatego nie spełnia oczekiwań. Właściciel biznesowy może natomiast twierdzić, że przedstawiciel handlowy zapewnił go, iż integracja jest możliwa.

Karta pomaga rozpocząć rozmowę: co dokładnie oznacza, że jest to możliwe? Dyrektor IT może powiedzieć, że tak, jest to możliwe, ale będzie wymagać niestandardowej integracji, nie jest dostępne od razu, nie zostało przetestowane i żaden obecny klient z niego nie korzysta. Pojawia się więc wiele ryzyk i trzeba ustalić, czy organizacja jest gotowa je podjąć.

Wspólna karta pomaga wszystkim znaleźć się na tej samej stronie, poczuć się zaangażowanymi i wysłuchanymi oraz przeprowadzić ważne rozmowy przed podpisaniem umowy.

Galen Low: To ogromnie ważny punkt. Karta oceny nie powinna być traktowana jak narzędzie, które automatycznie wskaże najlepsze oprogramowanie. Jej rolą jest napędzanie rozmowy: pokazanie, w których miejscach występują rozbieżności i gdzie trzeba dokładniej przyjrzeć się znaczeniu poszczególnych ocen.

Olivia Montgomery: Dokładnie. To podstawa rozmowy i sposób na to, aby nie stała się ona emocjonalna. Możecie przedstawić informacje, oprzeć się na liczbach i uniknąć dyskusji typu „on powiedział” albo „ona powiedziała”.

Galen Low: Skoro mowa o szczegółach, porozmawiajmy o procesie zbierania i łączenia ocen. Wspomniałaś o ważonych wynikach. Wszyscy wypełniają karty, a następnie trzeba przechować informacje, obliczyć wyniki i ustalić, gdzie potrzebne są dalsze rozmowy oraz kto powinien w nich uczestniczyć.

Olivia Montgomery: To ogromne pytanie. Istnieje wiele możliwości, dlatego zawsze wierzę w ustandaryzowane, ale jednocześnie dopasowane podejście. Każdy interesariusz i każda firma są inni. Różnią się dojrzałością środowiska, procesów biznesowych, budżetem i dostępnym czasem. Czy system jest potrzebny od razu, czy jest to wymiana planowana na sześć miesięcy?

Kierownik projektu musi mieć wiele narzędzi w swoim zestawie, aby elastycznie reagować na sytuację. Najpierw trzeba poznać oczekiwania. Jeszcze przed zaplanowaniem prezentacji, gdy ktoś prosi was o kierowanie projektem wdrożenia nowego narzędzia, warto ustalić, kto jest ostateczną osobą decyzyjną.

W większej firmie może to być komitet sterujący albo komitet sterujący IT, któremu trzeba przedstawić wyniki. W mniejszej firmie lub w przypadku mniej widocznego narzędzia może wystarczyć uzgodnienie stanowisk przez dyrektora IT i dyrektora jednostki biznesowej. Trzeba znać te informacje przed zaplanowaniem prezentacji, a najlepiej jeszcze przed rozmową z dostawcami.

Galen Low: Myślę, że najważniejszą kwestią jest przygotowanie. Kierownik projektu powinien mieć plan, korzystać ze swoich umiejętności i radzić sobie ze złożonymi rozmowami politycznymi. Trzeba wiedzieć, gdzie będą przechowywane karty, jak przygotować sesje, co powiedzieć dostawcom i co poprosić ich o pokazanie na podstawie historii użytkownika oraz ustalonych priorytetów.

Po prezentacjach należy zebrać wszystkie dane, przedstawić je w sposób umożliwiający rozmowę i zaprosić odpowiednie osoby. Ostatecznie osoby decyzyjne, właściciele biznesowi i liderzy techniczni muszą wspólnie podjąć decyzję, pozostawiając audytowalny ślad całego procesu.

Olivia Montgomery: Jeśli trudno uzyskać zgodę na kartę oceny albo organizacja nie jest jeszcze gotowa na bardziej dojrzały, ustrukturyzowany proces, można wypełnić kartę wspólnie. Po prezentacjach warto zaplanować 45-minutowe spotkanie i uzupełnić ją razem.

Wtedy karta rzeczywiście staje się narzędziem rozmowy i podejmowania decyzji. Można wspólnie ocenić wszystkich dostawców, których widzieliście, i spróbować osiągnąć konsensus pod koniec spotkania.

Galen Low: Podoba mi się to. To nie jest quiz ani konkurs sędziowski. Możemy podejść do tego wspólnie. To rozmowa.

Skoro wszystko zostało już powiedziane, niektórzy mogą stwierdzić, że podczas wyboru oprogramowania nie da się zadowolić wszystkich. Jak zarządzać oczekiwaniami osób w firmie, które przekazały opinie i mają udział w decyzji, aby nie były rozczarowane ostatecznym wyborem?

Olivia Montgomery: To kolejny powód, dla którego lubię karty oceny dostawców, szczególnie gdy kryteria mają przypisane wagi. Trzeba pamiętać, dlaczego potrzebujecie narzędzia, a nie tylko jakie narzędzie kupujecie. Nie nazywajcie projektu nazwą konkretnego dostawcy. To projekt wyboru oprogramowania.

Zawsze pytajcie, czy propozycja dostawcy, umowa, prezentacja i wszystkie zebrane informacje rzeczywiście rozwiązują problem biznesowy. Karta oceny może służyć jako ustandaryzowane, pozbawione emocji narzędzie pomagające utrzymać ten kierunek.

Nie chodzi o to, że dane narzędzie ma kilka świetnych funkcji, jeśli nie potrafi integrować się z systemem poczty elektronicznej, a integracja jest koniecznością. Trzeba wracać do karty i pytać: czy to rozwiązuje problem biznesowy? Nie: czy ma efektowne nowe funkcje?

Galen Low: Podoba mi się myśl, że karta oceny oznacza przejrzystość. Nie automatycznie, ale właśnie takie powinno być jej zastosowanie. Zapewnia jasność i rygor, pokazuje, co próbujemy osiągnąć, i pomaga wszystkim zrozumieć, dlaczego podejmujemy konkretną decyzję.

Na końcu trzeba przekazać wszystkim uczestnikom informację o decyzji, jej uzasadnieniu i sposobie oceny. Czy to sprawi, że wszyscy będą zadowoleni? Prawdopodobnie nie. Niektórzy nadal będą żałować funkcji, którą oferowało inne narzędzie. Będziecie jednak mieć uzasadnienie i dowód właściwego zaangażowania uczestników w proces.

Olivia Montgomery: Chcecie szacunku dla decyzji. Nie musicie sprawić, aby wszyscy byli z niej zadowoleni, ale powinni ją szanować. Jest to możliwe tylko wtedy, gdy prowadzi się uczciwe i przejrzyste rozmowy. Wszyscy powinni widzieć, że nie wybraliście narzędzia tylko dlatego, że pracuje tam krewny kogoś z firmy.

To może być realny problem w wielu organizacjach. Decyzja nie musi być uwielbiana, ale musi być szanowana.

Galen Low: Olivia, jak zawsze świetnie gościć cię w programie. Najważniejsza myśl, która ze mną zostanie, to koncepcja dwóch prezentacji. Intuicyjnie chcemy trzymać grupę razem, ponieważ podejmujemy wspólną decyzję, ale sama prezentacja nie musi być taka sama dla wszystkich.

Właściwie prawdopodobnie nie powinna taka być, ponieważ zakres jest zbyt szeroki, a rozmowy są różne. Można połączyć wszystko za pomocą karty oceny i wspólnej rozmowy po prezentacjach, angażując wszystkich, ale nie marnując ich czasu.

Olivia Montgomery: Zaawansowany użytkownik nie musi być obecny podczas rozmowy o częstotliwości uruchamiania zadań i dokładnym wyglądzie interfejsu API. Trzeba szanować czas wszystkich, nie pomijać żadnego obszaru i nie czekać z połączeniem perspektywy biznesowej i IT do etapu wdrożenia.

Nie powinno się to wydarzyć dopiero podczas wdrożenia.

Galen Low: Ostatnie pytanie. Podchwytliwe pytanie.

Olivia Montgomery: Jeszcze jedno?

Galen Low: Tak, jeszcze jedno, na zakończenie.

Załóżmy, że jesteś kierownikiem projektu i pracujesz w organizacji, w której proces wyboru oprogramowania nie jest prowadzony wystarczająco rzetelnie. Może ktoś mówi: to firma mojego brata, dostaniemy dobrą ofertę.

Co możesz zrobić? Co możesz powiedzieć, aby wprowadzić do procesu więcej rygoru i ograniczyć stronniczość? Jakie rozmowy trzeba przeprowadzić?

Olivia Montgomery: Trzeba mieć pełną szacunku relację z osobą, która wyraża taką opinię.

Należy sprawdzić, czy jest ona odpowiedzialna za ostateczną decyzję. Jeśli nie, trzeba zwrócić się do osoby decyzyjnej i powiedzieć: potrzebuję twojej pomocy i autorytetu. Jeśli to właśnie ta osoba podejmuje decyzję, wysłuchajcie jej, a następnie zaproponujcie wspólne przygotowanie karty oceny dostawców.

Powiedzcie, że chcecie upewnić się, iż uwzględniono wszystkie kwestie i że jesteście naprawdę zainteresowani narzędziem. Nie lekceważcie tej osoby i pracujcie nad relacją. Możecie współpracować przez długi czas.

Można wspólnie wypełnić kartę, stosując metodę sokratejską. Zapytajcie: czego dowiedzieliście się o integracjach? Jeśli odpowiedź brzmi: nie rozmawialiśmy o tym, możecie powiedzieć: dobrze, porozmawiajmy o tym z dostawcą.

W ten sposób wymagania są odkrywane krok po kroku. Może się okazać, że narzędzie nie jest najlepsze, a może właśnie nim jest. W każdym przypadku warto podziękować za informacje, ale jednocześnie zweryfikować rozwiązanie i porównać je przynajmniej z jedną inną opcją.

Zawsze wracam do tej samej zasady: bądźcie otwarci i przejrzyści. Powiedzcie, że rozwiązanie musi działać dla IT, jednostki biznesowej, obecnego stanu i przyszłego stanu. Zróbcie to wspólnie.

Galen Low: Świetnie. Bardzo mi się to podoba.

Olivia, wspaniale było cię gościć. Przeprowadziliśmy naprawdę szczegółową analizę procesu wyboru oprogramowania, zwłaszcza prezentacji i późniejszego podejmowania decyzji.

Mam nadzieję, że nasi słuchacze wynieśli z tej rozmowy wiele wartościowych informacji. Z przyjemnością zaproszę cię ponownie, ponieważ jest jeszcze wiele tematów, które możemy omówić, oraz wiele podchwytliwych pytań, które mogę ci zadać.

Olivia Montgomery: Dziękuję za zaproszenie. Mam nadzieję, że słuchacze czegoś się nauczyli i inaczej spojrzą na proces wyboru oraz prezentacje. Mam nadzieję, że nie będą ich już tak bardzo obawiać i nie pozwolą, aby decyzje zostały im narzucone. Mam nadzieję, że rozmowa była pomocna. Zawsze uwielbiam z tobą rozmawiać, Galen. Jesteś świetny. Bardzo dziękuję.

Dziękuję!

Galen Low: Jak myślisz, czy prezentacja oprogramowania jest warta czasu twojego zespołu? A może to tylko przedstawienie, które omija bardziej praktyczną, pogłębioną ocenę? Podziel się swoimi przemyśleniami i historiami w komentarzach poniżej.

Jeśli chcesz rozwijać swoje umiejętności jako strategiczny lider projektu, dołącz do naszej społeczności. Odwiedź stronę thedigitalprojectmanager.com/membership, aby uzyskać dostęp do wspierającej społeczności, która dzieli się wiedzą, rozwiązuje złożone problemy i wspólnie kształtuje przyszłość naszego zawodu.

Od rozbudowanych szablonów i comiesięcznych sesji szkoleniowych, które oszczędzają czas i energię, po wsparcie innych członków dostępne na forum dyskusyjnym, podczas wydarzeń społeczności i w grupach mastermind — członkostwo w naszej społeczności oznacza, że ponad tysiąc osób wspiera cię podczas rozwoju kariery w cyfrowym zarządzaniu realizacją projektów.

Jeśli podobało ci się to, co dziś usłyszałeś, zasubskrybuj nas i pozostań w kontakcie na stronie thedigitalprojectmanager.com.

Do usłyszenia następnym razem. Dziękuję za uwagę.