To jest 62. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o zlecaniu i prowadzeniu projektu IT. Przypominam, że w poprzednim odcinku rozmawiałem o technologii blockchain. 
Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/62 
Jeśli jeszcze tego nie zrobiłeś, to wystaw ocenę lub recenzję podcastowi w aplikacji, w której tego słuchasz, abym wiedział, że jesteś. 
Chcemy poszerzać horyzonty ludzi z branży IT i wierzę, że poprzez wywiady takie jak ten, publikowane jako podcasty, będę to robił z sukcesem. 
Nazywam się Krzysztof Kempiński i życzę ci miłego słuchania.

Odpalamy!

 

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. 

 

Chciałem zapytać jeszcze o poziom szczegółowości. Wyobraźmy sobie coś prostego — ekran logowania. Oczywiście, możemy powiedzieć, że ekran logowania jest dość standardowy, posiada pole do wpisania jakiegoś loginu i hasła, natomiast idąc dalej, możemy też w takim opisie uwzględnić to, że ma być określona walidacja po stronie backhandu, albo określone komunikaty wyświetlane i tak dalej, i tak dalej. Chodzi mi o to, że nigdy nie jest tak, że mamy wystarczająco wyczerpująco opisany dany proces czy widok. 

 

Jak z twojego doświadczenia wynika — na jaki poziom szczegółowości warto się pisać, żeby nie zajmowało to zbyt wiele czasu, jeśli chodzi o przygotowanie, a jednocześnie dawało też programistom, którzy będą później wykonywali taki kod obsługujący dany widok — wyczerpujące informacje do tego, jakie funkcjonalności powinni zrealizować, żeby nie pozostawało to w gestii interpretacji, domysłu po stronie programistów. 

 

Ten przykład wylogowania przedstawiłbym w ten sposób, że jest oczywiście jeden widok takiego logowania, a następnie w procesie bym przedstawił, że taka autoryzacja, weryfikacja następuje — żeby programista miał świadomość, że jakieś określone weryfikacje, autoryzacje muszą zostać podjęte, aby właśnie takie logowanie wykonać i dodatkowo w opisie — tak, żebym ewentualnie zawarł informacje na temat procesu autoryzacji, jak on powinien przebiegać. Natomiast myślę, że tu też jest istotne, że jeżeli ma się tę wiedzę, czy też ma się doświadczenie w pracy z deweloperami, albo się jeszcze dodatkowo zna ten zespół deweloperski, który pracuje, to bardzo często pewne elementy jesteśmy w stanie hasłowo uwzględnić, jesteśmy w stanie dość krótko opisać, z uwagi na to, że ta osoba dokładnie będzie wiedziała, co mamy na celu osiągnąć. 

 

Możemy używać też technicznych określeń danej autoryzacji, wtedy programista na pewno nas dobrze zrozumie. 

 

Wobec tego, kiedy specyfikacja jest już przygotowana — przynajmniej jakaś pierwsza wersja, która mniej-więcej składa się w takie jednorodne rozwiązania problemu, no to chcemy się zgłosić do wykonawców. Chcemy ogłosić przetarg bądź też inne formy, które pasują do naszej organizacji. Chcemy po prostu zebrać oferty.

 

Ze swojego doświadczenia i pewnie z twojego też tak wynika, że najczęściej te oferty są nieraz bardzo różne — nieraz skrajnie różne. Oczywiście też mogą być tego różne przyczyny. Natomiast chciałem cię zapytać, z czego wynikają takie różnice, z czego wynika fakt, że zakres prac, który jest nieraz bardzo dobrze i szczegółowo opisany, potrafi być zinterpretowany w ten sposób, że w efekcie dostajemy oferty różniące się o naprawdę duży procent — i czasowy, jeśli chodzi o wykonanie, i finansowy. 

 

Na blogu zrobiłem osobny wpis na temat wyceniania projektów IT. Sam tę wycenę dzielę na dwa elementy: bottom up i top down. Bottom up to jest wycen wynikająca z naszych kosztów w zakresie organizacji i wiadomo, że każda organizacja może mieć różne koszty jej prowadzenia — inne koszty pośrednie, zarządów, biur, wszelakich takich struktur organizacyjnych. Dodatkowo może mieć też różny poziom wynagrodzeń dla deweloperów i inne osoby, które wspierają tych deweloperów. Z tego wynika koszt bottom up i na to oczywiście jest nałożona marża według strategii danego przedsiębiorstwa i z tego wynika ten koszt, który powstaje jako pierwszy — ta pierwsza tego typu wycena. 

 

Natomiast myślę, że bardzo często jak mamy do czynienia w przypadku realizacji przetargowych — ta cena, którą widzimy w przetargach, w dużym stopniu wynika z tej analizy top down. Czyli analizujemy rynek, wiemy jakie wyceny mniej więcej się wcześniej pojawiały na tego typu podobnych zapytaniach. Wiemy, jakie są gwarancje potrzebne do danego zapytania, jakie są gwarancje po stronie wykonawcy potrzebne, żeby móc swoją ofertę przedstawić. 

 

Na tej podstawie wyliczamy pewną kwotę, tak żeby ewentualnie być na dobrej pozycji wśród konkurentów, żeby nasza ocena nie została zakwalifikowana jako rażąco niska cena. Żeby nie była też najwyższą ofertą — wiadomo, że wtedy nasze prawdopodobieństwo zwycięstwa się odpowiednio zmniejsza. Bardzo często te kluczowe elementy biorą udział przy tej wycenie i bardzo często ten rozstrzał może być ogromny — i rzeczywiście, jest ogromny. Różnego typu organizacje startują do realizacji określonych zamówień i często w tych wycenach, na przykład, w których sam brałem udział, to nawet wyceny sięgały od 500 000 do 10 000 000. Czyli jest po prostu ogromny rozstrzał cenowy. 

 

Różnego typu organizacje w tym startujące, różny też poziom doświadczenia — bo wiadomo, że jeżeli organizacje mają większe doświadczenie w tego typu ofertowaniu, tego typu przetargów w określonej dziedzinie dla określonego zamawiającego, to mają większe też doświadczenie. Wiedzą, jaki pułap cenowy ewentualnie powinien być zachowany. Siłą rzeczy jednak pojawiają się również mniej doświadczeni i oni trochę zaburzają tę wycenę. Pojawiają się wtedy bardzo niskie wyceny w takich przetargach. 

 

Wobec tego, na co zwrócić uwagę, gdy wybieramy wykonawcę? Powiedziałeś już, że może te skrajne ceny nie są najlepsze, bo mogą świadczyć o tym, że możemy się zderzyć z potencjalnymi problemami w jedną albo w drugą stronę. Jakie są, według ciebie, kluczowe czynniki, które powinniśmy ocenić, wybierając wykonawcę dla naszego projektu? 

 

Myślę, że najważniejszy czynnik, według którego powinniśmy wybierać wykonawcę, jest z jednej strony element rekomendacji. To jest bardzo istotne. Wiadomo, że przy przetargach trudno to uzyskać, bo nie ma takiej formy rekomendacji. Jedynie możemy oceniać doświadczenie danego wykonawcy. To też pozwala w jakiś sposób ocenić czy realizował podobnego typu realizacje — bo to jest istotne, że nie powinniśmy robić tak, że wybieramy firmę, która posiada najlepszą ofertę, tylko wybierajmy firmę, która już podobnego typu realizacje zrobiła, ma doświadczenie — ale doświadczenie w konkretnej dziedzinie. Jest w stanie określony sklep uruchomić, określony ERP. Jest w stanie wdrożyć jakąś określoną platformę, na przykład e-learningową, bo już tego typu realizacje przeprowadzała. 

 

Myślę, że najważniejszy czynnik, według którego powinniśmy wybierać wykonawcę, jest z jednej strony element rekomendacji

 

Szereg doświadczeń zebrała w takich konkretnych dziedzinach, mało tego — może jeszcze dodatkowo powiedzieć: we wcześniejszych realizacjach robiliśmy takie i takie rozwiązania, może warto, zamiast rozwiązania X zastosować rozwiązanie Y, bo uważamy, że takie rozwiązanie się lepiej sprawdzi. Mamy już doświadczenie ze wcześniejszych wdrożeń. 

 

Taki właśnie partner dziedzinowy jest najlepszy. Natomiast tutaj też jest ważny element doświadczenia i rekomendacji danego wykonawcy. My również w przypadku przetargów mieliśmy takie sytuacje, w których zamawiający rozpisywał przetarg po raz drugi, z uwagi, że ta pierwsza realizacja okazała się fiaskiem. 

 

W takich przetargach braliśmy również udział. Rzeczywiście, okazywało się, że taki wykonawca, który był wcześniej wybrany, najczęściej nie miał doświadczenia w danym projekcie. Nie realizował go zgodnie ze sztuką i to powodowało, że problemy w przypadku realizacji były coraz większe. Taka realizacja musiała zostać przerwana i zamówienie musiało zostać ponowione. 

 

To, że otrzymujemy jakąś konkretną wycenę, konkretną kwotę, to nie znaczy, że musimy się na to godzić i to akceptować. Możemy jako zlecający również podjąć się jakiejś negocjacji. 

 

Czy według ciebie, dążenie do takiej minimalizacji ceny — myślę tutaj o stronie zlecającego, który w jakiś sposób chce jeszcze coś ugrać i cenę zmniejszyć. Czy to jest najlepsza strategia — zupełna, zupełna minimalizacja ceny. Jakie ryzyko takiego podejścia widzisz i czy w inny sposób możemy albo coś innego możemy negocjować, niż tylko cenę? 

 

Z mojego doświadczenia najlepiej negocjować elementy związane z elementami przedmiotu zamówienia. To jest istotne — czyli równie związane z jakością, z SLA, czyli utrzymaniem ewentualnie tego rozwiązania, które tworzymy, żeby na przykład poziom wsparcia był wyższy — na wyższym poziomie. Dodatkowo myślę, że warto jest ewentualnie, uzbroić się w określoną gwarancję, w określone elementy dostarczania realizacji, rezultatów projektu. 

 

Myślę, że te elementy są kluczowe dla zamawiającego, niż element związany z negocjowaniem i obniżaniem ceny. Wiadomo, że musimy zawsze brać ten element z drugiej strony — jeżeli my obniżamy ceny w przypadku projektu Fixed Price, gdzie cena jest ustalana za całość realizacji projektu, no to w tym momencie wykonawca będzie musiał zaoszczędzić na jakiś środkach, działaniach — czy to po stronie zespołu, czy po stronie oczekiwań, które będzie realizował, żeby ewentualnie zrealizować poziom marży. 

 

W mojej ocenie zdecydowanie lepiej negocjować te elementy jakościowe, związane z realizacją projektu. 

 

Jeśli mamy już wybranego wykonawcę, który będzie w stanie zrealizować nasze zapotrzebowanie, nasze zlecenie, no to przystępujemy do podpisania umowy. Tak jak powiedziałeś, nawet w momencie, kiedy mamy bardzo agilowe podejście, to warto jest mieć umowę, ponieważ nigdy nie wiemy, w jaki sposób ta współpraca będzie przebiegała i nigdy nie wiadomo, czy nie będziemy musieli skorzystać z tej umowy, z różnych jej zapisów. Dlatego, przynajmniej z mojego doświadczenia tak wynika, nawet na mniejsze prace, warto jest taką umowę podpisywać. 

 

We wcześniejszych odcinkach podcastu rozmawiałem z prawnikiem o umowach, ale to pod kątem prawnym. Chciałbym cię zapytać, jak od strony biznesowej, od strony IT wygląda kwestia tego, co powinno znaleźć się w takiej umowie, żeby dobrze zabezpieczyć obydwie strony. 

 

W mojej ocenie właśnie tego elementu, którego zauważam, że brakuje w umowach, to dobrze określony przedmiot wraz ze specyfikacją zamówienia. Bo rzeczywiście, tutaj, jeżeli tego po stronie zamawiającego nie określimy w prawidłowy sposób, to rzeczywiście tracimy bardzo dużo w zakresie ewentualnej możliwości dochodzenia swoich praw. 

 

Takie podstawowe elementy, które w mojej ocenie powinny się w umowie znaleźć, to też prawa autorskie — przekazanie praw autorskich wraz z polami eksploatacji, harmonogram z jakimiś terminami realizacji, z podziałem na etapy, które wynikają jednoznacznie z realizacji umowy i to też można powiązać z wynagrodzeniem — że etapowo po prostu to wynagrodzenie rozliczać i ewentualnie częściowymi protokołami odbioru, że jesteśmy w stanie stopniowo ten projekt zgodnie z harmonogramem realizować. 

 

Ważny też punk kar umownych — które także powinniśmy zawrzeć w umowie, żeby ewentualnie móc takiego wykonawcę dyscyplinować, czy też, żeby on miał rzeczywiście tę konieczność realizacji określonych elementów umowy. 

 

Takie elementy, które także powinny się znaleźć to SLA, czyli forma utrzymania danego oprogramowania i także reakcje na interwencje określone — czyli na określone incydenty, które mogą się zadziać podczas utrzymania danego oprogramowania. 

 

Czas reakcji, na przykład powinien być bardzo precyzyjnie określony, tak żeby mieć kontrolę nad elementem utrzymania. Elementy komunikacji — czyli w jaki sposób się komunikujemy, w jaki sposób zatwierdzamy poszczególne etapy, w jaki sposób zatwierdzamy protokoły — wszelakie komunikacje. One mogą być ustalone w pełni elektronicznie, ale powinniśmy mieć tę strukturę również ze sobą ustaloną.

 

I ostatnie takie elementy, myślę, że konieczne: warunki gwarancji i zapisy RODO. To są takie elementy formalne, które także powinny się w takiej umowie znaleźć. 

 

Nawet jeśli mamy bardzo precyzyjnie taką umowę określoną, jest szczegółowa i zawiera te wszystkie elementy, o których powiedziałeś i mamy bardzo dokładną wycenę, to i tak nie jest w żadnym stopniu gwarancja tego, że realizacja projektu będzie przebiegała bez żadnych problemów. Powiedziałbym, wręcz odwrotnie — prawie na pewno będą jakieś problemy do rozwiązania w trakcie. 

 

Chciałbym cię zapytać, z jakim ryzykiem, potencjalnymi problemami może się spotkać zamawiający, w momencie, kiedy takie prace zleca na zewnątrz? 

 

Tutaj w tym momencie najważniejsze zagrożenie ryzyka, z jakimi może spotkać się zamawiający, to oczywiście wadliwe działanie oprogramowania. Może się takie pojawić i rzeczywiście w tym momencie trzeba reagować w taki sposób: albo uzgodnić z danym wykonawcą w protokole, ewentualnie określić te elementy, albo zdecydować wtedy o najgorszej sytuacji — ewentualnie na przerwaniu i wybraniu ewentualnie innego wykonawcy do realizacji tego zamówienia. 

 

Z jednej strony mogą być takie wady, które na bieżąco się pojawiają, kiedy wykonawca pracuje nad rozwiązaniem, ale jakieś wady pojawiają się na bieżąco w oprogramowaniu i w tych modułach, które zostały już odebrane — wtedy rzeczywiście na bieżąco trzeba szybko reagować. Natomiast może być tak, że oprogramowanie po realizacji projektu także mieć wady ukryte, które nie zostały wykryte podczas realizacji zamówienia.

 

Wtedy w ramach gwarancji trzeba się także z wykonawcą kontaktować, żeby w ramach gwarancji zostały one zrealizowane. Natomiast myślę, że na początku podczas realizacji projektu są takie elementy, które się pojawiają, czyli brak wyników dostarczanych prac przez wykonawcę. 

 

W mojej ocenie tutaj też jest bardzo istotna rzecz, którą bardzo często podczas projektów zaznaczam — bardzo ważny jest element monitorowania prac wykonywanych przez wykonawcę, tak aby części tego ryzyka uniknąć. To jest też część, która powinna znajdować się w umowie, a mówię tutaj dokładnie o przekazywaniu, udostępnianiu właśnie dla takiej osoby, która monitoruje, odbiera projekt, udostępnieniu repozytorium. Także, aby taka osoba mogła wykonywać tzw. kod review realizacji tego konkretnego projektu, żeby miała taki bieżący wgląd na to, w jaki sposób wykonawca wykonuje dany projekt, bo wtedy bardzo szybko jesteśmy w stanie dostrzec, czy realizacja idzie w określonym celu, czy te prace postępują względem tego zespołu wykonawczego i też najważniejszy punkt. Jeżeli osoba odbierająca projekt pilnuje, aby była robiona odpowiednia dokumentacja i też odpowiednio kod był zgodnie ze sztuką tworzony, to nawet w najgorszej sytuacji, kiedy dojdzie do przerwania realizacji projektu, to mając kod, mając te elementy z określonych standardów z dokumentacji, możemy ten projekt przekazać innemu wykonawcy. 

 

To jest połączone z zapisami umowy, które dają nam takie możliwości, natomiast na takim etapie jesteśmy w stanie to wykonać. W wielu projektach, w których dowiadywałem się, że jest jakiś problem od klientów, to pojawiała się taka sytuacja, że całość kodu i całość realizacji, łącznie z uruchomionymi aplikacjami, serwerami, wszystko znajdowało się po stronie wykonawcy i tak naprawdę wykonawca teraz — jeżeli był konflikt pomiędzy zamawiającym a wykonawcą, to wykonawca troszeczkę szantażował zamawiającego, że może po prostu mu wyłączyć wszystkie elementy i zabrać kod, który wytworzył. 

 

To jest więc bardzo istotne, żeby od samego początku zwrócić na to uwagę i jak gdyby stopniowo odbierać te prace, ale przede wszystkim kontrolować kod, który jest wytwarzany poprzez repozytorium.

 

Bardzo ważne elementy. Czy wykonawca też czymś ryzykuje? Może się spotkać z jakimiś problemami?

 

W mojej ocenie, z doświadczenia wiem, że największy problem, który sam też dostrzegam we własnych realizacjach, to jest element związany z brakiem zaangażowania zamawiającego w realizację. Czyli jest jakaś osoba wydelegowana, zarząd może nie tak bardzo interesuje się realizacją konkretnego projektu, natomiast kiedy już dochodzi do jakiegoś etapu, w którym projekt powinien zostać wdrożony, uruchomiony, następuje oczywiście zapoznanie się zarządu z realizacją takiego projektu i może nastąpić pewien problem, z uwagi na to, że zarząd wyobrażał sobie inaczej. Inne rozwiązanie. 

 

Mimo tego, że dotychczas nie brał aktywnego udziału w realizacji projektu, bo nie miał po prostu czasu, był szereg innych, ważniejszych tematów, to w końcowej fazie realizacji ma szereg uwag dotyczących danego rozwiązania. Mimo tego, że pracownicy wydelegowani są zgodni, że wszystko jest prawidłowo. Zarząd ewentualnie zawsze może mieć wątpliwości. Pojawiają się takie wątpliwości bardzo często. 

 

Są również projekty, w których praktycznie nie ma wydelegowanych osób. Nie ma bieżącego kontaktu z zamawiającym. To się pojawia w przypadku projektów rządowych, przetargowych, gdzie rzeczywiście w danej organizacji nie ma jasnej, jednoznacznej struktury projektowej związanej z realizacją danego projektu.

 

Bardzo często zadaniem wykonawcy na samym początku, w mojej ocenie jest bardzo ważne, żeby ustalić interesantów po stronie zamawiającego. Dokładnie z kim musimy się kontaktować, w jakim temacie, ustalić samemu wręcz tę strukturę organizacyjną, mimo tego, że zamawiający nie do końca mają ją ustaloną — to my musimy wziąć to na swoje barki. 

 

Podobnie, jeśli chodzi o rozwiązania w przypadku braku zaangażowania ze strony zamawiającego, to ja też reaguję w taki sposób, że rzeczywiście tworzę raport związany z bieżącymi pracami i celowo angażuję tutaj najwyższe kierownictwo do tego, aby oni właśnie z takim podsumowaniem się zapoznali, żeby zapoznali się ewentualnie z tym, jak przebiega realizacja tego projektu, z komentarzami odnoszącymi się do problemów, do specyfikacji i myślę, że w taki sposób nawet sam próbuję angażować najwyższe kierownictwo do tego, żeby brali aktywny udział realizacji takiego projektu. To rzeczywiście oni wtedy widząc, że taka komunikacja z nimi występuje, są bardziej chętni do tego, żeby brać udział właśnie w jakichś spotkaniach naszych, żeby ewentualnie co drugie, co trzecie spotkanie wziąć udział, żeby mieć większą wiedzę na temat tego, co się dzieje. 

 

Także myślę, że to są takie podstawowe elementy.

 

Niezależnie od tego, jaką metodologię wytwarzania oprogramowania sobie przyjmiemy, z jakiego frameworka skorzystamy, to i tak ważne jest to, co powiedziałeś — takie bieżące monitorowanie postępu prac. 

 

Na co tutaj warto zwrócić uwagę, ewentualnie z jakich narzędzi skorzystać? 

 

Jeżeli chodzi o narzędzia, to myślę, że tutaj ja akurat najczęściej korzystam z Jir’y , ewentualnie takim oprogramowaniem, które również stosuję, jest OpenProject. To jest open sourcowe oprogramowanie, nie ma tam limitów, jeżeli prowadzi się szerszy, większy projekt z większą ilością użytkowników — po stronie klienta, po stronie naszej, dodatkowo jest jeszcze szereg instytucji, które także biorą udział w tym projekcie, bo takie projekty też występują z uczelniami, gdzie szereg jest użytkowników, to w takich projektach stosuję rozwiązania OpenProject. Ma możliwość z jednej strony prowadzenia zadań, a z drugiej wiązania tych zadań z repozytorium — tak, żeby programiści mogli jednoznacznie te swoje zmiany łączyć z zadaniami, które są w systemie. 

 

I podobnie działa Jira w powiązaniu z Bitbucket’em. Tam mamy także możliwość powiązania zadań deweloperskich, stricte zmian nawet, których dokonują z określonymi zadaniami, które wystąpiły w backlogu. Tak więc te dwa narzędzia stosuję najczęściej. 

 

Jeżeli chodzi o te elementy, na które też trzeba zwrócić uwagę i które trzeba monitorować, to właśnie to repozytorium, o którym wspomniałem. To jest bardzo kluczowy element, który nadal w mojej ocenie jest w bardzo małym procencie projektów udostępnianych przez wykonawcę dla zamawiającego. Z mojego doświadczenia to jest 5% projektów, które rzeczywiście takie repozytorium udostępniają. Tak transparentne, na bieżąco jest dla zamawiającego przekazywana, więc myślę, że tutaj ten element jest bardzo ważny. 

 

Z tego, co powiedziałeś, wynika, że zaufanie jest bardzo ważne, ale z drugiej strony nie powinniśmy tak zupełnie na słowo, tylko i wyłącznie sobie wierzyć i lepiej jest dokonywać tych odbiorów częściowych i później odbioru końcowego, kiedy cały projekt jest już zrealizowany i zakończony. 

 

Na co według ciebie warto zwrócić uwagę przy odbiorach? Co jest istotne dla obydwóch stron? 

 

Przy odbiorach bardzo ważne jest to, by — też i po stronie zamawiającego to jest istotne — dla wykonawcy odbiory częściowe są bardzo ważne, i warto jest je uwzględniać w umowie. Po stronie wykonawcy to jest plus, ponieważ obliguje zamawiającego do tego, aby przetestować dane rozwiązania, żeby się z nimi dokładnie zapoznać, żeby móc przedstawić ewentualne problemy albo jakieś niedociągnięcia związane ze specyfikacją. To jest właśnie to miejsce, żeby zamawiający mógł ocenić, jakie elementy jego zdaniem są nieprawidłowo wykonane, żeby zapisać to w protokole, bo bardzo ważne jest — protokoły częściowe i protokoły odbioru są tak naprawdę zdecydowanie istotniejszym narzędziem dla wykonawcy, niż dla zamawiającego. Ponieważ wykonawca, na podstawie protokołów wie, jakie są ewentualne rozbieżności, może je poprawić, może je w szybki sposób odpowiednio zrealizować i nie ma tak zwanego niekończącego się projektu. 

 

Po stronie zamawiającego może być taka sytuacja, że te nadmiarowe wymagania się pojawiają, pewne elementy dodatkowe się pojawiają i to jest naturalna sytuacja, że zamawiający dąży troszeczkę do zwiększenia tego zakresu, bo widzi potrzeby, więc do tego będzie dążył w naturalny sposób. Natomiast takim właśnie elementem pilnującym tę dyscyplinę realizacji projektu, są właśnie te protokoły odbioru wraz z tymi uwagami. Jeżeli wykonawca zrealizuje te uwagi, to nieprawidłowy w związku z realizacją takiej umowy jest to, że zamawiający może kolejne rzeczy znów wymyślić, znów dokładać, więc tutaj ograniczamy taką dowolność, zamykamy pewien etap. Robimy ewentualnie jakieś uwagi i przechodzimy do następnego etapu. Kolejne, kolejne realizujemy, zamykamy poszczególne etapy, pilnując w ten sposób tego, że nie rozszerza się nam zakres projektów. Myślę, że wykonawcy powinni bardzo tego pilnować — oczywiście mówimy tutaj o modelach FixPrice, gdzie jest ta cena ustalona, to trzeba bardzo dokładnie pilnować tego zakresu projektu, żeby on nie wzrastał, bo wtedy siłą rzeczy wykonawca traci. 

 

Wiadomo, że inną specyfikę mają material model, ponieważ wtedy wykonawca nie musi zwracać na to uwagi — po prostu dolicza kolejne godziny realizacji projektu. 

 

Dużo tutaj powiedzieliśmy o różnych takich mniej lub bardziej formalnych środkach do tego, żeby zabezpieczyć wykonanie projektu informatycznego z dwóch stron. Nie wiem, czy się ze mną zgodzisz, ale na końcu to jednak najważniejsze jest to, by być po prostu człowiekiem i uczciwe traktować druga stronę, bo to jest najlepszą przesłanką do tego, że po prostu z sukcesem realizujemy projekt informatyczny. 

 

Tak, oczywiście. Myślę, że to jest najważniejsze. Zaufanie jest tutaj kluczowe, w przypadku realizacji projektu. Natomiast myślę, że to zaufanie dobrze jest zbudować w ten sposób, jeżeli struktur też będzie odpowiednia. Czyli jest zamawiający, jest ewentualnie osoba, która zarówno jest po środku — w formie specjalisty, analityka, pomiędzy tymi stronami jest w stanie bardzo sprawnie się komunikować z wykonawcą jak i jednocześnie pilnować interesu zamawiającego. 

 

Wykonawca — jeżeli to jest sprawdzona osoba, sprawdzona firma, która ma doświadczenie w określonej dziedzinie, to w tym momencie też ta współpraca będzie w mojej ocenie bardzo dobrze się układać i spowoduje to zwiększenie zaufania w całym zespole. Dzięki temu wszyscy będą w stanie i sprawnie dostarczać rozwiązania po stronie wykonawcy, ale też zamawiający będzie działał także na korzyść wykonawcy. Oni w tym momencie znajdą wspólny język i te strony będą w stanie skutecznie się dogadywać, jeżeli chodzi o z jednej strony wymagania, z drugiej strony o te rezultaty, które są dostarczone. 

 

Dobrze powiedziane. Karol, bardzo dziękuję ci za bardzo ciekawą rozmowę, za podzielenie się doświadczeniami, wiedzą z tego obszaru, który nie do końca jest dla wszystkich jasny i oczywisty, czyli właśnie zlecania i wykonania według dobrych praktyk projektu informatycznego. Jeszcze raz wielkie dzięki i powiedz, proszę, gdzie cię można znaleźć w internecie. 

 

Można aktualnie znaleźć mnie na blogu, który prowadzę, czyli karolmaj.pl 

 

Tam oczywiście także dodać swojego maila do newslettera, w ten sposób na bieżąco będę informował o nowych wpisach, które się pojawią. Strona także ma swój fan page, ma swoją grupę na Facebooku, także można poprzez bloga przejść do tych linków — czy to strony na Facebooku, czy grupy, która już teraz ma ponad 800 osób. Także w tamtych miejscach można mnie znaleźć. 

 

Super, oczywiście linki dodam do notatek do tego odcinka. Zapraszam na bloga, zapraszam na grupę na Facebooku. 

 

Jeszcze raz wielkie dzięki, do usłyszenia, cześć!

 

 

To tyle z tego, co przygotowałem dla ciebie na dzisiaj. O prowadzeniu projektów IT powiedziano i napisano już bardzo wiele. Mam nadzieję, że po przesłuchaniu tego, co mówił Karol, masz teraz lepsze pojęcie o dobrych praktykach w zlecaniu i później w prowadzeniu projektów IT.

Jakiś czas temu ogłaszałem akcję Pomoc w IT. Jeśli masz pytanie związane z IT postaram, się w miarę możliwości pomóc i na nie odpowiedzieć. 

Pisz śmiało na krzysztof@porozmawiajmyoit.pl, by umówić się na rozmowę ze mną. 

Jeśli spodobał ci się ten odcinek i nie chcesz przegapić kolejnych epizodów podcastu, za subskrybuj go w swojej aplikacji podcastowej. Jeśli nie wiesz jak to zrobić, wejdź na stronę porozmawiajmyoit.pl/subskrybuj 

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o zlecaniu i prowadzeniu projektów IT. 

Zapraszam do kolejnego odcinka już za tydzień. 

Cześć!