W tym odcinku omawiam pięć kwestii, które warto poruszyć przed rozpoczęciem współpracy z dostawcą usług IT.

Transkrypcja odcinka

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

Jako firma dostarczająca oprogramowanie często mamy do czynienia z klientami, którzy nie do końca wiedzą, jak wygląda proces tworzenia oprogramowania, nie mówiąc już o kwestii tego, jak wygląda ofertowanie, wyceny, jak się komunikuje w takich projektach i jak przebiega wiele czynności towarzyszących realizacji projektu informatycznego, które nierzadko potrafią stanowić o sukcesie nawet w większym stopniu niż udana faza samego developmentu, implementacji takiego rozwiązania. Ten temat nie dotyczy tylko tworzenia oprogramowania. Nie da się ukryć, że jak zawsze najbliżej mi do tego świata z racji prowadzenia właśnie firmy typu software house, natomiast w ogóle przy realizacji projektów z szeroko pojętej branży IT kwestia tego, że klienci nie orientują się w różnego rodzaju realiach, biorąc pod uwagę, jak dynamicznie zmieniają się uwarunkowania branży IT, wydaje mi się, że to jest coś wspólnego, niezależnie czy mówimy o realizacji właśnie oprogramowania dedykowanego, czy o wdrażaniu oprogramowania gotowego, czy o jakichś projektach związanych z wdrażaniem infrastruktury, czy usług chmurowych, myślę, że sytuacja jest tu podobna.

Nie da się ukryć, że dobry dostawca tego rodzaju usług powinien rzetelnie przeprowadzić klienta przez cały proces analizy, przygotowania, potem realizacji i wdrożenia projektu informatycznego, natomiast pewna taka samoświadomość, można powiedzieć, pewne zorientowanie się w realiach branży, w której klient chce przeprowadzić projekt, może tylko pomóc nie tylko w czasie realizacji projektu, ale przede wszystkim na etapie przygotowania czy też wyboru dostawcy. Oczywistą rzeczą jest to, że ważne są dla klientów wyceny, całkowita wartość kontraktu czy projektu, natomiast czasami też klienci orientują się, że są jakieś stawki godzinowe, zwłaszcza przy projektach związanych z tworzeniem oprogramowania. Natomiast mało kto jest zorientowany na tyle, zakładając oczywiście wcześniejszy brak doświadczenia, bo zdarzają się klienci, którzy już wcześniej projekty informatyczne realizowali, uczestniczyli w nich, natomiast jeżeli ktoś nie ma tego doświadczenia, to brakuje tej wiedzy, żeby wiedzieć w ogóle, o co pytać. I chociaż teoretycznie klient ma zawsze rację, jak to mówi staropolskie określenie, zresztą nie tylko w Polsce obowiązuje, lepiej jednak od razu wiedzieć, co warto wiedzieć przed rozpoczęciem realizacji projektu IT, bo mimo posiadania tej racji, lepiej nie odwoływać się do tego argumentu, tylko po prostu wiedzieć, w jaki sposób najlepiej porozumieć się z potencjalnym dostawcą usług IT. W związku z tym zadamy sobie w tym odcinku takich 5 pytań, 5 kwestii do poruszenia z potencjalnym dostawcą, które warto poruszyć przed rozpoczęciem realizacji projektu informatycznego.

Pierwsze pytanie brzmi: co właściwie zawiera wycena? Wydaje się, że w przypadku projektów IT to w ogóle nie powinien być jakiś skomplikowany temat, no bo sprawa jest prosta. Jeżeli prosimy o wycenę jakiejś aplikacji, no to oczekujemy, że ktoś wyceni po prostu realizację takiej aplikacji. Jeżeli chcemy wdrożyć jakiś gotowy system, no to interesuje nas całkowita wycena takiego procesu wdrożenia. Ale właśnie, czy na pewno? Nawet jeżeli założymy dobrą wolę dostawcy, czyli że dostawca tutaj nie próbuje w jakiś sposób ukryć pewnych kosztów, tylko po prostu chce być takim frontem do klienta, jak to się mówi, chce naprawdę szczerze przedstawić wszystkie koszty, to mimo to pewne koszty takiemu dostawcy mogą wydawać się oczywiste, że są do poniesienia przez klienta, a z drugiej strony klient wcale może nie być świadom, że te koszty będzie musiał ponieść. Nie jest to po prostu taką kwestią oczywistą. Zresztą do tego słowa jeszcze powrócimy w kolejnych pytaniach. W związku z tym powiedzmy sobie, które koszty mogą być tymi kosztami nieoczywistymi. Przede wszystkim wszelkie koszty związane z infrastrukturą. Tutaj oczywiście mówimy o sytuacji bardziej związanej z oprogramowaniem, bo jeżeli realizujemy projekt polegający na wdrożeniu infrastruktury, to akurat staje się kosztem oczywistym. Ale jeżeli mówimy o np. wytworzeniu aplikacji internetowej i wdrożeniu jej, jeżeli mówimy o wdrożeniu jakiegoś gotowego rozwiązania, to to oprogramowanie nie funkcjonuje w próżni. Konieczne jest posiadanie dostępu do pewnych zasobów, czy to fizycznie umiejscowionych serwerów w jakiejś firmie, w jakiejś serwerowni, czy serwerów zlokalizowanych w jakiejś serwerowni u dostawcy, czy w takiej klasycznej chmurze. Możliwości jest wiele, ale to są koszty, które trzeba ponosić. Czasami pojawiają się też koszty licencyjne związane np. z licencją na chociażby systemy serwerowe Windows. Jeżeli używamy Linuxów, czyli darmowych, otwartych systemów operacyjnych z rodziny Linux, mówiąc dokładniej, no to to nie jest problem. Natomiast jeżeli mamy Windows, to też jakieś te koszty licencyjne mogą się pojawić. Mogą być też koszty licencyjne oprogramowania, które funkcjonuje w takim systemie, chociażby bazy danych Microsoft SQL Server. Nie będę wchodził w duże szczegóły, ale tylko wspomnę o kosztach środowisk chmurowych, jeżeli wdrażamy jakieś oprogramowanie np. w chmurze AWS. Tu warto pamiętać, że zwłaszcza na wczesnym etapie estymowanie dokładnego kosztu chmury, takiego co do grosza czy tam centa, jest niezwykle trudnym zadaniem, bo nie zawsze jesteśmy w stanie bardzo dokładnie określić, jaka to będzie infrastruktura. A nawet jeżeli jesteśmy na wczesnym etapie, to też trudno do końca oszacować, jaki będzie faktyczny koszt zasobów. Więc jeżeli, powiedzmy, dostawca mówi wam, że będzie to np. koszt +/- taki a taki, te widełki są na poziomie kilkunastu procent, to nie traktujcie, proszę, tego jako takiego kręcenia czy celowego zaciemniania obrazu. Koszty wdrożeń chmurowych aplikacji naprawdę nie są takie oczywiste jak np. wynajęcie pojedynczego serwera gdzieś w jakieś serwerowni. No dobrze, nawet jeżeli infrastrukturalnie jesteśmy już dogadani, to coraz więcej aplikacji, coraz więcej systemów również gotowych swoje działanie opiera na pewnych usługach, które się integruje, chociażby integracjach z jakimiś usługami SAS-owymi. No i wtedy takie usługi też najczęściej kosztują. I tutaj może pojawić się kwestia nawet kosztu per użytkownik – jeżeli integrujemy i chcemy, żeby nasi użytkownicy korzystali jeszcze z jakiejś licencji oprogramowania zewnętrznego, które będzie integrowane, to może się pojawić kwestia tego, że to oprogramowanie też będzie licencjonowane, np. per użytkownik. I to nie są kwoty, które trafią do kieszeni dostawcy, więc on może nawet nieświadomie nie powiedzieć, że taki koszt się pojawi, no bo to nie są pieniądze, które nawet przejdą przez jego kieszeń. Natomiast koniec końców ty jako klient taki koszt poniesiesz, więc ciebie to niestety zaboli. Żeby tutaj podać jakiś przykład, ja pamiętam, jak na początku pandemii było bardzo dużo zapytań o tworzenie różnych usług, w dużej mierze też związanych z e-learningiem. Więc tam ważne było to, że chciano z reguły tworzyć rozwiązania e-learningowe, w których byłaby funkcja komunikacji audiowideo w czasie rzeczywistym. I koszty np. zintegrowania usług zewnętrznych, no bo samodzielna realizacja streamingu audiowideo nie jest tanią kwestią, znacznie łatwiej zapłacić za dostarczenie takiego komponentu i przede wszystkim też zasobów sprzętowych potrzebnych do przetworzenia tego rodzaju danych, ale właśnie to był dodatkowy koszt, który trzeba było wliczyć. I to w skali całego rozwiązania potrafiło być naprawdę istotne procentowo, rzędu kilkudziesięciu procent koszty funkcjonowania. No i wreszcie jak nawet takie typowo zewnętrzne koszty mamy, można powiedzieć, omówione, to zawsze pozostaje kwestia zakresu odpowiedzialności po stronie dostawcy. Musimy zadać więc pytanie, czy wycena zawiera tylko prace programistyczne, czy też wszystkie inne, które w danym projekcie mogą być istotne. Czyli chociażby kwestie związane z prowadzeniem projektu, czyli project management, kierowanie projektem, user experience, quality assurance, czyli kontrola jakości, doświadczenie użytkownika, czyli UX, kwestie związane z operacjami, z developer operation, devops, czyli zapewnieniem płynnego wdrażania projektu i ciągłej integracji. Z jednej strony obecnie wiele firm już w wycenach to uwzględnia, ale mimo wszystko lepiej dopytać. Osobną kwestią jest, kiedy projekt zostanie zrealizowany, kwestia utrzymania i opieki, wsparcia takiego wdrożonego projektu. Ale o tym jeszcze wspomnę pod koniec odcinka. Ostatnia kwestią tak naprawdę cały czas do pierwszego pytania, ale ono jest zdecydowanie najdłuższe, to jest to, na jakiej zasadzie się rozliczamy z dostawcą. Czy mówimy o tym, że projekt jest realizowany według stałej wyceny, tzw. fixed price, gdzie określamy po prostu dla zadanego zestawu rzeczy do zrobienia w projekcie, jaka ma być wycena, czy rozliczamy się na zasadzie time and material, czyli rozliczeń godzinowych. Ma to istotne znaczenie z reguły pod kątem egzekwowania wyników prac, formalnego trybu zgłaszania różnych poprawek. Prawda jest taka, że temat jest dość złożony, więc tutaj mogę odwołać ciebie do innych odcinków, do odcinka 11., skądinąd o najtrudniejszych frazach przy tworzeniu software, które się pojawiają, a także do odcinka 18. Na temat zasad opracowania dokładnych estymat projektowych. Na tym kończymy to pierwsze tak naprawdę pytanie, pozostałe będą już trochę krótsze.

Drugie pytanie, które warto zadać czy poruszyć, to jest bardziej kwestia, która wiąże się z takim słowem, które padło przy pierwszym pytaniu. To jest słowo, którego bardzo nie lubię, kiedy pada w rozmowach z klientami. Ale kiedy ono pada, to najczęściej niestety kontekst nie jest zbyt dobry. Mogę powiedzieć, że na szczęście w ostatnich latach już bardzo rzadko je słyszę. Jest to słowo: oczywisty, po angielsku obvious. Chciałoby się powiedzieć jak w memach, kapitan Obvious. To jest słowo bardzo bolesne, bardzo trudne dla dostawcy, bo jeżeli ono pada, to najczęściej pada w kontekście, że coś nie zostało zrobione, a powinni być. Jest oczywistym, że powinno się znaleźć w projekcie. Np. funkcja resetowania hasła przy jakiejś funkcji logowania czy rejestracji. No i z jednej strony jak podałem taki właśnie przykład, to faktycznie, kurcze, resetowanie hasła brzmi jak taka podstawowa, oczywista rzecz, to powinno się znaleźć. Tak samo jak kupujemy samochód, to chyba nie mówimy sprzedawcy, że samochód powinien mieć koła, kierownicę, silnik i parę innych ważnych elementów, hamulce na przykład by się przydały. Natomiast pamiętajmy, że jednak, choć bardzo lubię porównywać, to już chyba da się zaobserwować, tworzenie oprogramowania do właśnie tej branży motoryzacyjnej, to przy tworzeniu oprogramowania mamy do czynienia z dużo większą elastycznością. To nie jest tak jak w samochodach, że tak naprawdę to w zasadzie mamy wpływ na pewne4 dodatki, takie bajery w samochodzie, oczywiście też moc silnika, ale w gruncie rzeczy większość elementów w samochodzie myślę, że jest taka sama, niezależnie od konkretnego modelu. A teraz pytanie, czy słuchacze motoryzacyjni mnie za to nie zjedzą, ale trudno, zaryzykuję. Natomiast przy tworzeniu oprogramowania ta elastyczność jest jednak dużo większa i naprawdę mało co można uznać za rzecz oczywistą. I tu nawet nie chodzi o to, że system bez resetowania hasła ma większy sens. Pamiętajmy, że kiedy tworzymy oprogramowanie, to często robimy to iteracyjnie, czyli najpierw tworzymy jakąś pierwszą wersję, udostępniamy ją do testów, a potem tworzymy kolejne. Ale rozliczamy się, najpierw wyceniamy tę pierwszą. I może się okazać, że przy pierwszej wersji, zwłaszcza jeżeli tworzymy produkt dla start-upu, to tak naprawdę wcale to resetowanie hasła nie jest takie potrzebne. Bo będzie np. taki produkt używany tylko w zamkniętym gronie kilkunastu, kilkudziesięciu użytkowników, jak już od biedy ktoś to hasło będzie musiał mieć zresetowane, to zrobi się to ręcznie z poziomu bazy danych. Przy jakimkolwiek produkcyjnym działaniu na większą skalę, oczywiście coś takiego by nie przeszło. Ale w takiej pierwszej wersji w zasadzie czemu nie. Więc moim zdaniem jeżeli mówimy o zakresie projektu od strony tego, co zostanie w nim zrealizowane, to podstawową regułą powinna być jawność i dyskutowanie szczegółów aż do przesady. Kilka dodatkowych zdań wypowiedzianych właśnie w czasie takich rozmów, które prowadzimy z dostawcą naprawdę nie zakosztuje nas za dużo czasu, a może zmniejszyć znacząco ryzyko tego, że braknie jakiejś ważnej funkcji w naszym systemie.

Przechodzimy teraz do dalszych pytań, które już będą ciut krótsze, ale nie znaczy to, że mniej ważne. Trzecie pytanie, trzecia kwestia to kto będzie realizował dany projekt. Ma ono znaczenie zwłaszcza w przypadku tych projektów, które opierają się na pracy bardzo konkretnych zespołów zbudowanych z określonych osób, a nie dostarczeniu usługi przez po prostu firmę, gdzie czasem odpisze jedna osoba, czasem druga, czasem trzecia, ale w gruncie rzeczy nie jesteśmy związani z konkretnym zespołem. W naturalny sposób dotyczy to tej mojej działki, czyli software house’ów, ale nie tylko. Myślę, że tutaj też agencje marketingowe, czasami również na poziomie indywidualnym konsultanci czy jakieś takie małe zespoły konsultantów to również jest taka sytuacja. I typowym problemem pracy agencyjnej, bo tak naprawdę software house to jest taki właśnie typ pracy usługowy-agencyjny, jest to, aby mieć i klientów, i ręce do pracy. Najlepiej porównywalnie. I wiele firm stosuje bardzo intensywny, nawet może czasami agresywny marketing, po to żeby pozyskać jak najwięcej prospektów, czyli takich perspektywicznych, potencjalnych klientów, natomiast to się dzieje masowo i nie zawsze takie firmy zastanawiają się, czy mają w danej chwili ręce do pracy. Mają generować jak najwięcej tych prospektów. A co się stanie, jeżeli wejdzie więcej projektów niż jest rąk do pracy? Wtedy takie firmy odzywają się do innych firm i tworzą zespoły zbudowane, powiedzmy, na takiej patchworkowej zasadzie. Ktoś od nas, ktoś od kogoś innego, ktoś jeszcze z trzeciej firmy i jakoś to się toczy. I to nie jest samo w sobie złe zjawisko. Ono pozwala wyrównać pewne, powiedziałbym, przestoje. Jak ktoś ma za dużo osób niepracujących w danej chwili, bo się projekty skończyły, a ktoś ma za dużo tematów do realizacji, to się w naturalny sposób wyrównuje. Natomiast mimo wszystko warto jednak, aby klient był świadomy, że taki model się realizuje, że właśnie w taki sposób dostarcza się zespół. Jeżeli rozumiesz specyfikę pracy takiego zespołu, może się też zdarzyć, że faktycznie są to osoby dobrze dopasowane do siebie, to jest to okej, jeżeli w ten sposób np. projekt szybciej się zacznie. Natomiast jeżeli ci na tym, aby pracować z zespołem, który faktycznie składa się z osób pracujących w jednej firmie, no to warto to podkreślić. I tutaj pytanie o to, kto faktycznie będzie pracował w danym projekcie i w jakiej firmie docelowo taka osoba pracuje, może mieć istotne znaczenie. To pozwoli też ograniczyć ryzyko, które czasem pojawia się w takich projektach, gdzie mogą pojawić się jakieś nietypowe tarcia, brak zgrania w zespole, no bo są osoby z różnych firm. My niezwykle rzadko korzystamy z pomocy firm zewnętrznych, w zasadzie raz czy dwa na próbę korzystaliśmy. Czasami za to pomagamy w drugą stronę, co też pozwala zdobyć właśnie ciekawe doświadczenia, inne punkty widzenia, ale też różne rzeczy zdarzało nam się widzieć.

Kolejne, czwarte już pytanie, to jak wygląda proces akceptacji prac. Jest to ważne kwestia w metodykach zwinnych, agile’owych, pojawia się nawet takie określenie jak definitione of done. Natomiast nie jest to właśnie prosta rzecz, co uznać za skończoną pracę, skończone zadanie, skończony projekt. Zadbajmy więc o to, aby precyzyjnie z dostawcą określić to, w jaki sposób prace są akceptowane, odbierane, które przypadki, scenariusze użycia będą analizowane, sprawdzane. Ale warto także zadbać o aspekty niefunkcjonalne, czyli np. jaka będzie wydajność rozwiązania, ilu użytkowników utrzyma takie rozwiązanie, czy będzie się skalować, czy będzie odpowiednio zabezpieczone. Tutaj nie chodzi o to, że każdy projekt, który realizujesz, chcesz zrealizować, musi mieć te same wymagania. Bo umówmy się, jeżeli robimy proof of concept czy LVP dla start-upu, czyli taki minimalny projekt, żeby po prostu cokolwiek pokazać, on nie musi być z reguły super zabezpieczony, super wydajny. Ważne, żeby był zrobiony szybko i realizował jakiś określony cel. Natomiast inaczej to wygląda, kiedy z założenia budujemy jakiś kluczowy system, strategiczny system dla funkcjonowania dużej organizacji czy korporacji.

Ostatnie, piąte już pytanie, temat zapowiedziany na początku, czyli utrzymanie, wsparcie systemu to ponownie temat rzeka i tak naprawdę ja już o nim mówiłem więcej w odcinku 23. na temat SLA, service level agreement, czyli tego właśnie, czy realizowany przez ciebie projekt oprogramowania czy inny wymaga wsparcia, wymaga utrzymania i w jakim zakresie. Tutaj tylko takie może króciutkie podsumowanie, że warto ustalić na etapie nawet przygotowania do realizacji projektu, jakie są czasy reakcji np. w ramach gwarancji, jakie są w ogóle możliwości późniejszego wsparcia. Nawet jeżeli w danej chwili nie chce się negocjować samej umowy SLA, to warto w ogóle przedyskutować ten temat. Muszę przyznać, że klienci coraz częściej sami o to pytają, ale znowu jest to taka rzecz, że jedno drobne pytanie, kilka minut może dyskusji, a już będziesz wiedzieć, na czym stoisz. Tak naprawdę tego rodzaju umowy konstruuje się głównie dla ustalenia takich warunków brzegowych, można powiedzieć, czyli co się dzieje, jeżeli np. jest awaria systemu w czasie majówki, prawda. Bo systemy jednak na ogół działają, nie mają problemów, ale potrafią zepsuć się w najgorszym możliwym momencie, gdy np. jedna osoba jest na urlopie, druga jest chora. No i co wtedy? Czy system będzie działać, czy nie, w jakim czasie zostanie naprawiony w takim bardzo pesymistycznym przypadku? Takie przypadki dzieją się rzadko, ale się dzieją. I właśnie takie dyskusje na temat warunków powinny przede wszystkim opierać się na ustaleniu tych najbardziej, wydawałoby się może czasem, niemożliwych aż do zaistnienia, ale wbrew pozorom jednak pojawiających się sytuacji.

Na tym kończymy ten odcinek. Jeżeli po wysłuchaniu go chcesz dowiedzieć się więcej lub podyskutować na temat wyzwania, jakiegoś projektu, który stoi przed tobą, zachęcam do kontaktu, bo siłą rzeczy w takim krótkim odcinku nie sposób ująć wszystkich szczegółów. Mógłbym oczywiście mówić dłużej, przytoczyć więcej przykładów, ale jednak wiele zależy od bardzo konkretnego projektu. Projekty bywają bardzo różne. Dawno tego nie robiłem, więc zachęcę do subskrybowania, do oglądania – tutaj tak odruchowo powiedziałem, bo przypomniało mi się, że, co ciekawe, na YouTube również publikujemy ten podcast i właśnie tam bardzo dużo odwiedzin się pojawia. Przyznam szczerze, że przez długi czas skupiałem się głównie na przygotowywaniu tych materiałów, a w ostatnim czasie zacząłem bardziej intensywnie przeglądać statystyki przez serwis taki podcastowy Spreaker, ale właśnie też przez studio YouTube. I właśnie bardzo dużo odwiedzin jest przez YouTube, chociaż to jest tak naprawdę podcast. To nas jednak motywuje do tego, żeby też YouTube uruchomić do tego, do czego jest przeznaczony, czyli do firmy wideo. Już podejmujemy pewne działania, aby to faktycznie się ziściło. Tak że zachęcam do dalszego słuchania i mam nadzieję, oglądania nie tylko tych moich fajnych coverów, które są na YouTube, zdjęć z tytułem odcinka, ale także faktycznie rozmów, które niedługo będą się toczyć. Na tym już kończę dzisiejszy odcinek. Bardzo dziękuję za uwagę, kłaniam się nisko i do usłyszenia.

KONIEC