Zlecenie i prowadzenie projektu IT

Krzysztof Kempiński
Apr 21 · 12 min read
Image for post
Image for post

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Karolem Majem o zleceniu i prowadzeniu projektu IT.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć, mój dzisiejszy gość to przedsiębiorca, bloger, analityk biznesowy w obszarze IT, CEO software house’u FrameCoders. Fascynują go komputery i informatyka. Swoją przygodę w IT rozpoczynał od roli administratora i programisty.

Jest prelegentem występującym na konferencjach IT. Prywatnie ojciec, mąż i miłośnik podróży. Moim i waszym gościem jest dzisiaj Karol Maj.

Cześć, Karol! Bardzo miło mi gościć cię w podcaście!

Cześć Krzysztof!

Z Karolem się trochę znamy, także bardziej cieszę się, że będziemy mieć dziś okazję porozmawiać. Muszę powiedzieć, że Karol ma bardzo duże doświadczenie w realizacji projektów dla małych i dużych firm, organizacji projektów wszelakiej maści, więc z tego doświadczenia Karola chcę dzisiaj skorzystać i wypytać go o różne aspekty związane ze zlecaniem i przeprowadzaniem projektów w IT.

Oczywiście, na początku, żeby standardowo wszystkie procedury związane z odpalaniem podcastu mogły się wykonać, to muszę cię Karol zapytać, czy słuchasz podcastów i jeśli tak, to jakich najczęściej?

Tak, oczywiście słucham podcastów. Sam akurat jestem słuchaczem, który nie słucha za każdym razem każdej serii, tylko wybieram sobie określone odcinki i wtedy je odsłuchuję. Może nie regularnie, ale wybieram różne.

I rzeczywiście, takie podcasty, które się trafiają to DevTalk, Porozmawiajmy o IT, to jest między innymi też ten podcast, którego słucham, a także Zaprojektuj swoje życie. Tych słucham częściej.

Oczywiście, również szereg takich podcastów zagranicznych, ale głównie ten obszar IT i biznesu.

Zacznijmy może od przygotowań do zlecenia projektu. Obydwoje już mamy trochę tych projektów na koncie i wiem, że nieraz zdarzają się takie firmy, tacy zleceniodawcy, którzy nie posiadają w swoim zespole osoby, która miałaby jakieś pojęcie o procesie wytwarzania oprogramowania. Nieraz te obszary, z których takie zlecenie do IT przychodzi, są zupełnie odległe.

Jakie są według ciebie przyczyny braku takiego, powiedziałbym, analityka biznesowego albo product ownera, po stronie zamawiającego?

Myślę, że głównie w większości przypadków to oczywiście jest oszczędność po stronie zamawiającego. Na samym, początkowym etapie zamawiający oszczędza na kosztach i z tego tytułu brakuje osób z doświadczeniem przy okazji realizacji tych projektów.

To również, co dostrzegam także przy dużych klientach, czy to urzędach nawet, czy firmach zamawiających, jest problem związany z tym, że niepoważnie też podchodzą do tematów związanych z IT.

Bardzo często takie osoby, które są na stanowiskach zarządczych, wszystkich dookoła nazywają informatykami. Mimo że długi czas ta dziedzina się rozwija i wiadomo, że te stanowiska są bardzo różne, to zauważam, że nadal jeden czy drugi informatyk jest w stanie sobie z danym tematem poradzić i bardzo często w takich firmach pojawia się taka sytuacja, że osoba, która obsługuje, serwisuje sieć, dodatkowo jest specjalistą w zakresie wdrażania oprogramowania czy też tworzenia jakiegoś oprogramowania dedykowanego. Wiadomo, że wtedy taka wiedza, takiej osoby jest bardzo mała.

Główny czynnik wtedy powoduje, że oczywiście taka osoba jest zaufaną, bo zna organizację, natomiast nie ma zupełnie doświadczenia w zakresie wytwarzania oprogramowania. Ma bardzo małe pojęcie na ten temat. Te elementy po stronie zamawiającego decydują, że brakuje tej osoby doświadczonej na samym początku projektu.

Czyli głównie oszczędność.

Co może taki analityk biznesowy wnieść do firmy, do całego procesu wytwarzania czy też obsługi projektu IT. Jakie kompetencje, jaką wartość dodaną wnosi od siebie?

Moim zdaniem najważniejsze jest to, że — jeszcze jeden element zaznaczę na samym początku — w mojej ocenie bardzo istotne jest to, żeby taki analityk lub osoba, która przygotowuje projekt IT, a ewentualnie później go odbiera, żeby to była osoba zarówno niezależna od zamawiającego, jak i również niezależna od wykonawcy. Można powiedzieć, że taka osoba pośrodku, która jednocześnie na samym początku jest w stanie przygotować ten projekt do realizacji. Przede wszystkim pierwszy etap, pierwszy krok to jest zrozumienie potrzeb. Taka osoba jest w stanie właśnie zrozumieć potrzeby, problemy danej organizacji.

Przede wszystkim pierwszy etap, pierwszy krok to jest zrozumienie potrzeb. Taka osoba jest w stanie właśnie zrozumieć potrzeby, problemy danej organizacji.

Kolejnym krokiem jest przeanalizowanie tych problemów poprzez wywiady z pracownikami, poznaniu tych problemów również na niższych szczeblach organizacji.

Następnie, takim krokiem, myślę, że istotnym, jest także przedstawienie tych wszystkich zebranych wywiadów, zebranej wiedzy w formie raportu jak ta sytuacja wygląda at time, że tak powiem — czyli jak to wygląda dzisiaj. Następnie przeanalizowanie tych wszystkich zebranych elementów. Optymalizacja ewentualnie procesów, które mają miejsce w przedsiębiorstwie i ułożenie z tego także takiej rekomendacji to be. Czyli jak jego zdaniem, powinny te rozwiązania różne wyglądać, ale to co jest najważniejsze, to że analityk, który jest niezależny od wykonawcy bardzo często — sam mam taką sytuację — że bardzo często rozwiązuje określone problemy, nie wykorzystując oprogramowania.

Czyli nie ma konieczności tworzenia dedykowanego oprogramowania, tylko jestem w stanie wykorzystywać narzędzia, które już istnieją na rynku — w ten sposób zdecydowanie ograniczam koszty danego zamawiającego. W ten sposób chronię jego interesy i jestem pośrodku, czyli nie chronię też interesów wykonawcy, bo nie reprezentuję go. W tym momencie jestem w stanie zaproponować takie rozwiązanie, które już na samym starcie zdecydowanie obniża koszty, a ewentualnie piszemy jakieś konieczne integrację, konieczne rozwiązania, które muszą być zrealizowane w sposób dedykowany.

Myślę, że na początku zamawiający nie zdaje sobie sprawy, jak dużo taka osoba może dać oszczędności dla realizacji całego projektu. W mojej ocenie daje bardzo dużo. Rzeczywiście unika, może spokojnie obciąć konieczność realizacji jakichś dedykowanych rozwiązań nawet o 40, 50%.

Faktycznie bardzo dużo. Załóżmy taki optymistyczny scenariusz, że taki analityk występuje w procesie zlecania, w procesie realizacji projektu IT.

Wspomniałeś trochę o wywiadach, które taka osoba może przeprowadzić, żeby zrozumieć cały zakres pracy, najlepiej tymi pracami później pokierować. Chciałbym zapytać bardziej szczegółowo: od czego taka osoba zaczyna swoją pracę i jakich metod używa do określenia tego zakresu prac, później też do pokierowania pracami?

Jeżeli chodzi o same wywiady, to jak już ma oczywiście zarejestrowane problemy, opisane, jakie są do tego rozwiązania, to określa też stanowiska, które dotyczą tych konkretnych problemów, które ma dane przedsiębiorstwo i ewentualnie celów, które chce osiągnąć. W tym momencie łączy się z daną osobą, chce zobaczyć, w jaki sposób ona pracuje, w jaki sposób wykonuje swoją pracę na bieżącym, danym stanowisku plus przedstawia mi także dokumenty, które są tworzone w ramach danego stanowiska czy do wykonywania danego procesu biznesowego. Tutaj są wszelkie raporty, zestawienia, budżety, tego typu pliki, dokumenty są przestawiane. Sam na tej podstawie jestem w stanie zamapować cały proces, dokładnie jak on przebiega przez wszystkie stanowiska, wraz z dokumentami, które są wytwarzane na poszczególnych etapach realizacji.

Teraz, jak już mam zebrane informacje na temat tych procesów i dokumentów, które są wytwarzane w tym procesie biznesowym, to w tym momencie jestem w stanie te procesy zoptymalizować. Czyli teraz jestem w stanie albo zastosować jakieś rozwiązanie już dostępne na rynku do odpisu wewnątrz organizacji, do podpisywania dokumentów do obiegu. Następnie jestem w stanie zoptymalizować też te procesy, zaproponować optymalizację tych procesów po stronie organizacji. Nie tylko po stronie narzędzia, ale także organizacja może wprowadzić zmiany, które mogą w zdecydowany sposób ograniczyć kilkanaście kroków, które są niepotrzebne albo można wykonać w inny sposób.

I na tej podstawie prezentuję takie rekomendacje, omawiamy to z zarządem. Też jest ważny element związany z procesami, związany z rozpoczęciem projektu. Istotne jest umocowanie danego analityka — czyli, że on ma ten bezpośredni kontakt z zarządem. Że jest w stanie pewne propozycje przedstawiać i realizować pewne uzgodnienia, bo jeżeli takiej możliwości nie ma, to rzeczywiście bardzo trudno jest skorzystać z pełnego zakresu kompetencji i korzyści, jakie daje ten analityk w takiej realizacji. Tu więc to umocowanie analityka jest bardzo ważne, żeby był jak najbliżej zarządu i żeby przynajmniej w tej początkowej fazie, ale w późniejszych również, konsultować jak najwięcej elementów z zarządem, który ma największy wpływ na późniejsze wdrażanie, czy oprogramowanie tych procesów.

To jest istotne, jeżeli się wprowadza takie oprogramowanie do przedsiębiorstwa, żeby zarząd brał również aktywny udział we wdrażaniu oprogramowania, a nie na zasadzie: daję tej osobie projekt, zróbcie go, ja w ogóle nie chcę o tym słyszeć. Tego typu podejście jest bardzo szkodliwe dla wdrażania takiego projektu IT w przedsiębiorstwie.

To jest istotne, jeżeli się wprowadza takie oprogramowanie do przedsiębiorstwa, żeby zarząd brał również aktywny udział we wdrażaniu oprogramowania, a nie na zasadzie: daję tej osobie projekt, zróbcie go, ja w ogóle nie chcę o tym słyszeć. Tego typu podejście jest bardzo szkodliwe dla wdrażania takiego projektu IT w przedsiębiorstwie.

Chciałbym jeszcze chwilkę pociągnąć ten wątek umocowania, bo tak naprawdę potrafię sobie wyobrazić sytuację, w której osoba z zewnątrz tak de facto, musi w jakiś sposób zrozumieć najpierw wszystko to, co się dzieje, albo to jakie są potrzeby, plany na zbudowanie jakiegoś projektu informatycznego.

To zajmuje jakiś tam czas, oczywiście, żeby takie podstawowe procesy, mechanizmy, na których firma jest oparta, przetrawić, zrozumieć, pobawić się pewnie trochę w detektywa i dojść do tego, jak różne elementy całej tej układanki ze sobą współpracują. To zajmuje jakiś czas — w związku z tym, czy nie lepiej byłoby użyć na przykład osoby, która już w organizacji się znajduje, która być może wiele lat przepracowała w danej firmie i wiadomo, siłą rzeczy może lepiej rozumieć różne stanowiska, różne procesy, które w niej się dzieją. Może się okazać, że taka osoba po prostu lepiej zrozumie ten cały zakres prac do wykonania, niż zewnętrzny analityk.

Jak to wynika z twojego doświadczenia?

Stosuję taką metodę, że jeżeli jestem w danej organizacji, to pojawia się również taka osoba, która jest odpowiedzialna za rozwój w obszarze IT czy też ma największą wiedzę równie o organizacji, ale też ma wiedzę na temat rozwiązań IT, jakie są na rynku. Rzeczywiście bardzo często z takiej osoby korzystam i bardzo ściśle z nią współpracuję.

Problemem takich osób natomiast — oczywiście, tutaj doświadczenie jest ich bardzo dużą zaletą, trzeba na nich polegać i z nimi bardzo ściśle współpracować. Natomiast minusem tych osób jest brak doświadczenia w realizacji projektów IT i takiej komunikacji z deweloperami.

Często też takie osoby mogą proponować pewne rozwiązania na wyrost — żeby jeszcze mocniej rozwijać tę przestrzeń IT, natomiast analityk bardzo często bardziej realistycznie podchodzi do tematów związanych z realizacją. Mówi — okej, w moje ocenie takie rozwiązanie jest zbyt duże względem potrzeb, może ograniczmy funkcjonalność tak, żeby w pierwszej kolejności rozwiązać najpoważniejszy problem i później, iteracyjnie wdrażać kolejne rozwiązania, kiedy już na przykład pracownicy będą pracować na tej podstawowej wersji, która rozwiązuje ich największe problemy.

To jest jak gdyby jeden element, drugi — analityk jest w stanie bardzo sprawnie komunikować się z programistami, jest w stanie im te wymagania dobrze przekazywać, a tutaj się też pojawia problem w przypadku osoby wewnątrz organizacji — to jest dobry ekspert dziedzinowy, ale uważam, że nie jest dobrą osobą do późniejszego prowadzenia projektu.

Opowiadałeś trochę o tym, jak wygląda taka praca, w jaki sposób ty podchodzisz do rozwiązywania tego typu projektów, to pojawiło mi się w głowie dwa takie trochę skrajne obszary. Pierwszy, taki trochę może waterfallowy, kiedy podchodzimy do problemu w ten sposób, że przygotowujemy dokumentację, specyfikację, opis problemu. Już na początku staramy się określić, co będzie potrzebne, komu i w jaki sposób będziemy chcieli pomóc i później będziemy to realizować — czyli takie standardowe podejście z obszaru waterfall.

Z drugiej strony, powiedziałeś, że może ma to sens, jeśli na początku pracownicy będą pracować na jakimś rozwiązaniu takim minimalnym, które w jakiś sposób już im pomaga, aczkolwiek jeszcze nie realizuje kompleksowo wszystkich potrzeb. Czyli skłaniamy się tutaj bardziej w kierunku metodyk zwinnych, Agilowych i tego, co obecnie w IT króluje, w podejściu do rozwiązywania problemów.

W związku z tym chciałbym cię zapytać, co myślisz na temat metodyk zwinnych? Czy to jest coś, co z twojego doświadczenia wynika, sprawdza się przy większych projektach czy też może lepiej jest postawić na dobrze sprawdzone już, klasyczne rozwiązania właśnie?

Myślę, że akurat tu jest ważny temat, ponieważ często właśnie nawet nie podczas konferencji ten temat poruszam. Chodzi o to, że jest taki problem, wynikający nie tyle z metodyk zwinnych, co ich interpretacji przez osoby, które pracują w tych metodykach.

Powiem, jak wygląda — zacytuję ten manifest związany z Agile, czyli tak:

Ludzie i interakcje ponad procesami narzędziami.

Działające oprogramowanie ponad szczegółową dokumentację.

Współpraca z klientem ponad negocjację umów.

Reagowanie na zmiany ponad realizację założonego planu.

Ten manifest jest jak najbardziej w porządku i sam się z nim bardzo identyfikuję, natomiast mam wrażenie, że ludzie troszeczkę inaczej interpretują ten manifest. Moim zdaniem osoby, które bardzo często pracują z metodyką zwinną nie zauważają, że interpretują go w ten sposób:

Ludzie i interakcje z pominięciem procesów i narzędzi.

Działające oprogramowanie z pominięciem szczegółowej dokumentacji.

Współpraca z klientem z pominięciem negocjacji umów.

Reagowanie na zmiany z pominięciem realizacji założonego planu.

Mam wrażenie, że wykluczają tę drugą część, zostawiając tylko tę pierwszą, a nawet w manifeście też jest na samym dole takie podsumowanie, być może też nie jest często przytaczane — po tym przewodnim haśle, po manifeście jest zapis: oznacza to, że elementy wypisane po prawej stronie są wartościowe, ale większą wartość mają dla nas wypisane po lewej.

Czyli nie powinniśmy nawet w tych metodykach zwinnych, nie powinniśmy rezygnować z dokumentacji. Nie powinniśmy z procesów, narzędzi rezygnować, także ewentualnie z zapisów umowy i jak gdyby określenia przedmiotu umowy, czy też jakiegoś planu, który powinniśmy mieć właśnie na realizację tego projektu. Z tych rzeczy nie powinniśmy rezygnować. Mimo tego, że realizujemy to w sposób zwinny, w sposób iteracyjny, to i tak właśnie ważne jest to, abyśmy te elementy posiadali, bo bardzo często te projekty — sam pojawiam się też w takich, w których są problemy. Już problem się pojawił i ten problem jest na zasadzie takiej, że właśnie wykonawca bardzo często nie może, albo jest jakiś konflikt pomiędzy zamawiającym i wykonawcą. Jak sięgam to umowy, to przedmiot realizacji tej umowy to często są trzy, cztery punkty czy jedna strona A4 zapisana, która jest do realizacji i wręcz bardzo trudno się do tego odnosić, bo wykonawca na tej podstawie zrealizował. Bardzo często literalnie jest w stanie się odnieść do każdego punktu i każdy punkt jest prowadzony, mimo tego, że to nie jest takie, jakie oczekiwał zamawiający.

Dlatego to jest istotne — żeby także zwracać uwagę na specyfikację, także mieć jasną wizję tego, co chcemy stworzyć. Dodatkowo mieć oczywiście te elementy wpięte jako załącznik do umowy, do tego przedmiotu umowy, żeby później móc sprawnie, iteracyjnie realizować po prostu ten projekt, ale móc się odnieść do twardych dokumentów w razie problemów. Myślę, że taka wizja jest bardzo istotna, nawet jeżeli będą jakieś istotne zmiany, na przykład w realizacji projektu — co jest naturalne — może na przykład przy jednej iteracji zamawiający dojść do wniosku, że przy kolejnej iteracji pewien moduł nie jest mu potrzebny, albo chce dokonać jakichś zmian. To jest jak najbardziej w porządku. Mogły zmienić się potrzeby biznesowe, bo widzi, jak to działa już w życiu. Żaden problem jest napisać aneks do umowy, zmienić jakieś elementy założeń, które były w umowie. Strony są w stanie na bieżąco się dogadywać, więc myślę, że bardzo często tego w tych projektach, w których ja biorę funkcję ratunkową, bardzo często tego typu problemy w nich występują.

Wiemy już, że skrajne podejścia w każdym przypadku są złe i podejście agilowe nie oznacza, że mamy teraz zupełnie odpuszczać jakiekolwiek procesy, jakiekolwiek kwestie formalne, iść na przysłowiowy żywioł.

Chciałem zapytać, ale już odpowiedziałeś — czy warto robić specyfikację. Może w związku z tym podpytam cię jeszcze, po co ją robić? W jakiej sytuacji może być przydatna? Czy jest tylko wyznacznikiem dla wykonawcy tego, co musi zrobić czy też może mimo wszystko służyć do czegoś zamawiającemu, który w jakiś sposób może chce udokumentować po swojej stronie, jak coś ma być wykonane?

Jak według ciebie specyfikacja może służyć dwóm stronom? Oraz kwestia, którą trochę poruszyłeś: czy ona może się zmieniać podczas wykonywania zlecenia?

Tak, jak najbardziej — odpowiadając od końca, specyfikacja jak najbardziej może ulegać zmianom i tutaj nawet analityk pełni taką funkcję, żeby zarządzać tymi zmianami w ramach specyfikacji. Żeby cały czas mieć kontrolę nad tymi wymaganiami i zarządzać nimi.

Myślę, że specyfikacja jest dobrym dokumentem, który pozwala nam w krytycznych sytuacjach osiągać założenia konkretnego projektu. Natomiast w bieżącej realizacji specyfikacja również jest nam pomocna — w przypadku opracowania historii do danego sprintu, w przypadku ułożenia pracy w danym sprincie. Możemy na podstawie tej specyfikacji monitorować realizację całego projektu, czyli jakie wymagania udało się zrealizować, jakie odkładamy na później, bo mają niższy priorytet — jesteśmy w stanie je zrealizować na dalszym etapie projektu. Na tej podstawie jesteśmy w stanie cały czas monitorować projekt, jego realizację i zarządzać wymaganiami, czyli na przykład usuwać określone wymagania, zmniejszać ich priorytet, ewentualnie przekładać w czasie.

Myślę, że specyfikacja jest dobrym dokumentem, który pozwala nam w krytycznych sytuacjach osiągać założenia konkretnego projektu.

Wobec tego, co powinna taka dobra specyfikacja zawierać, z jakich elementów się składać? W jakiej formie ją budować, żeby później zarządzanie taką specyfikacją, właśnie wyrzucanie rzeczy niepotrzebnych, dokładanie nowych, było w jakiś sposób ułatwione?

Jeśli chodzi o moje doświadczenie, to staram się tę specyfikację budować w sposób nie dokumentów. Znaczy się — dokument generuję w rezultacie, natomiast cała specyfikacja i jej poszczególne punkty są prowadzone w Jirze albo w OpenProject, gdzie mam cały rejestr wymagań. Mogę oczywiście przedstawić je w formie raportu, natomiast specyfikacja cały czas żyje. To jest istotne, że komentujemy określone rzeczy, układamy w całym planie realizacji. Tutaj mamy pełną możliwość zarządzania tymi wymaganiami. Wiadomo, że jeżeli stworzymy kilkuset stronicowy dokument z tego, to prawdopodobnie nikt nie będzie go w stanie przeczytać.

Tu jest więc istotny podział wymagań na określone sekcje, zaangażowanie ekspertów dziedzinowych w określonych obszarach, żeby oni byli w stanie w swoim obszarze wypowiedzieć się na temat swoich wymagań określonych, które mają być dostarczone. Myślę jednak, że to, co jest w specyfikacji istotne, przynajmniej dla mnie najważniejsze, z całego opisu, to są widoki danego oprogramowania.

W moich projektach bardzo dużą wagę przykładam do projektowania UX, w zakresie widoków oprogramowania, bo myślę, że widoki UX najlepiej przemawiają zarówno do zamawiającego, jak i również są bardzo pomocne dla deweloperów. Można bardzo szybko, dokładnie wyjaśnić poszczególne widoki systemu, w jaki sposób one będą działać. W jaki sposób ten proces będzie wykonywany w oprogramowaniu, a z drugiej strony deweloper później dokładniej wie jakie opcje mają się znajdować na konkretnym widoku w oprogramowaniu, więc to jest bardzo pomocna sprawa. Dodatkowo ten element modelowania procesów — każdy proces jest zamodelowany, rozpisany w notacji BPMN, a następnie jest to sprzęgnięte z opisem i sprzęgnięte z widokiem. Można powiedzieć, zawsze są trzy elementy: opis, model biznesowy — chodzi o proces biznesowy, opisany w notacji BPMN — i widok przedstawiony w UX. Myślę, że te trzy elementy powodują, że później realizacja jest bardzo, bardzo sprawna.

Czytaj dalej na:

kkempin’s dev blog

Dev and life blog.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface.

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox.

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store