Na hasło wdrożenie systemu IT wiele osób czuje dreszcze, bo wie, że może się spodziewać wielu różnych niespodzianek, nie zawsze przyjemnych. Często praca z projektami IT i ich wdrażanie to przepychanki pomiędzy dostawcą a klientem, w jedną i drugą stronę. W dzisiejszym wpisie pokażę Wam kilka perspektyw, dzięki którym wdrażanie systemu IT oraz współpraca niekoniecznie musi przerodzić się w otwartą wojnę tylko może być dosyć fajną przygodą.
Jeśli nie wiesz jeszcze na czym polega zarządzanie projektami, na pewno warto odwiedzić artykuł – Zarządzanie Projektami – co to właściwie jest.
Jak współpracować w projekcie IT. Klient-dostawca.
Lata temu pracowałem Przez kilka lat w globalnym dziale IT. Do tej pory prowadząc projekty pracuję od czasu do czasu po obu stronach barykady. Po stronie firm, które zamawiają systemy IT, po stronie organizacji, które te systemy wdrażają, a czasem też pracując z działami wewnętrznymi IT. Przy każdym projekcie pułapki są podobne. I dziś poopowiadam o tych pułapkach, żeby łatwiej było te projekty prowadzić.
Zacznijmy od podstaw, od podejścia do wyszukiwania potrzeb i zrozumienia czego druga strona może chcieć. Moja propozycja jest taka, nie szukajcie potrzeb tylko zrozumcie problem, który chcecie rozwiązać. Projektach mamy naturalną barierę, że po jednej stronie mamy klienta, a po drugiej dostawcę. Jeżeli tak będziemy podchodzić przez dłuższy czas nie zbudujemy jakiegoś zaufania, to będzie ciężki projekt. My musimy udawać, że rozumiemy co klient ma do powiedzenia, bo przecież nas wybrali i liczą, że będziemy profesjonalni. Klient z kolei cały czas udaje, że rozumie co w ogóle robi, bo przecież mogą nas oszukać. W większości przypadków prawda jest taka, że jak będziesz pytać klienta o potrzeby, to nie jest w stanie ci tego do końca powiedzieć, bo ich wszystkich nie zna.
Natomiast można zrozumieć problem z jakim ktoś się mierzy. Dlaczego w ogóle wyszliście w to przedsięwzięcie, dlaczego oni chcą kupić od was jestem. Co wy faktycznie macie tam zrobić. W najgorszej sytuacji macie coś takiego, że z góry padła informacja chcemy mieć nowy system, który zapewnia fajne raportowanie i świetnie działa. Nikt po drodze nie zapytał, przeszło przez cały proces i dostaliście mamałygę, z której nic się zrobić nie da. Założenie, że klient nie wie czego chce jest dobrym założeniem. Klient wie natomiast co go boli.
Skupcie się na tym jaki problem naprawdę rozwiązujecie. Nie na zasadzie wizji, to nie ma aż takiego znaczenia, ma znaczenie jaki problem rozwiązujecie. Czy po prostu ma być nowy, czy ma być takie samo, czy ma pomóc ludziom pracować, gdzie naprawdę mamy coś zrobić. Może to jest projekt typu zamknij się i wiosłuj i macie to wdrożyć. Potrzeb klient wcale nie jest w stanie określić, ale ból i problem który potrzebuje rozwiązać jest wam w stanie o tym o powiedzieć. Z drugiej strony stawiając się po stronie kogoś kto coś zleca opisz jaki problem rozwiązujesz. Chciałbym na koniec uzyskać taki efekt, ale główny problem do rozwiązania jest następujący… Poznam, że projekt zakończył się sukcesem, jak ten problem zniknie. Podsumowując, klient nie wie czego chce, ale wie co go boli. Drążymy ból. Jesteś klientem skup się na bólu, jesteś dostawcą skup się na bólu, bo wtedy będzie łatwiej produkować rozwiązania które mają sens.
Klient nie rozumie procesu – i Ty też nie
Stawiam tezę, że do końca nie rozumiecie co się dzieje u klienta, bo firmy są specyficzne. Zawsze wyróżniam trzy warstwy, gdy pracuję z klientem. Proces – jak to jest poukładane, kultura – jak firma działa, osobowość – pracujemy z różnymi typami ludzi. Dużo rzeczy, które dzieje się firmie nie jest spisanych. Klient nie rozumie procesu, ale się nie przyzna, Ty udając że rozumiesz proces stawiasz się też w nienajlepszej sytuacji. Jeśli powstaje jakaś analiza, której nikt nie rozumie, to będzie długi projekt. Jak masz kogoś, kto potrafi dobrze negocjować i dorzucać więcej kwoty do kontraktu to z perspektywy dostawcy będzie super, chociaż to wcale nie jest komfortowa sytuacja dla większości osób z którymi ja pracowałem. Patrząc z perspektywy klienta raczej nie chcesz mieć długiego projektu. Jeżeli nie rozumiesz analizy, to po prostu pytaj. Warto myśleć w kategoriach czy wiemy na pewno, że ten proces tak działa – zielone. Najprawdopodobniej ten proces tak działa – żółte. Nie mamy pojęcia jak to działa musimy dopytać – czerwone. Nie bójcie się określać tych elementów procesu w taki sposób, bo wiecie na których elementach trzeba będzie popracować głębiej, a które można odpuścić.
Zakres, zakres, zakres
W projektach, z którymi miałem do czynienia największym problemem zawsze był zakres. Nie jest doprecyzowane wystarczająco, nie wiemy co robimy i nagle okazuje się, że robimy coś co jest proste miało trwać 2 h, a trwa drugi tydzień i końca nie widać. W zakresie najczęściej to co jest ważne jest opisane dosyć ogólnie. Tam natomiast, gdzie jest łatwo są szczegóły. Dlaczego tak się dzieje? Łatwo jest opisać łatwy proces. Zostawianie ogólnego opisu dla złożonych procesów nie jest dobre. Jak sprawdzić, czy masz dobrze zdefiniowany zakres? Sprawdzić czy przekłada się na działanie. Np. hasło „Przyjazny dla użytkownika”, po czym poznamy i to daje do myślenia. Na zakres naprawdę warto poświęcić czas.
Koszt wynika z zakresu i ryzyka
Stosunkowo prosta zależność. Masz pewne rzeczy do wykonania, które kosztują X, do tego rzeczy nieprzewidziane. Jak dodasz koszt bazowy i rezerwę na ryzyko, wychodzi koszt całego projektu. Problem jest już na etapie kontraktu. Zdarza się, że dajesz niską cenę, żeby wejść i wygrać kontrakt. Jak wygrasz, to klientowi trudno zrezygnować, ale można się odkuć na doprecyzowywanym zakresie. Mówię, to po to, żeby się zastanowić poważnie przy zlecaniu czegokolwiek i porównywaniu ceny czy porównujecie jabłka do jabłek.
Uświadom klienta, że samo się nie zrobi
Jak podejdziesz do klienta, że nie wie czego chce, my zrobimy, a on klepnie fakturę, to się skończy porażką. Opcja z którą się częściej spotykam, komuś zależy na tym, żeby zrobić dobrą robotę. Tylko często klient, który zamawia system znika, wiecie co macie robić, nie zawracajcie mi gitary, wróćcie jak będzie gotowe. Jeżeli pracujemy na rzeczach, które są złożone, pojawiają się w trakcie pytania, jeżeli nie zarezerwujesz czasu na odpowiedzi w trakcie, to się nie wydarzy. Zawsze będzie niedoprecyzowany zakres, musisz mieć zarezerwowany czas na współpracę z dostawcą IT. Jeżeli Ty zarządzasz takim projektem i nie uświadomisz klientowi, że będziesz potrzebować od niego czasu to skończy się tak sobie. Ustawcie dobry plan komunikacji.
Właściwy typ kontraktu
Od dawna istnieje podejście, że mamy kontrakt fixed-price, ustalony zakres i cenę, oraz różne podejścia i opcje łączone. Jeśli chcemy od dostawcy wymusić, że będzie kontrakt z określoną ceną, to dostawca postara się określić zakres w miarę ogólnie, żeby nie dało się doczepić do niektórych rzeczy i można było negocjować, wrzucić minimalną wartość. Człowiek musi zarządzić ryzykiem, z drugiej strony ktoś kto zamawia chce wiedzieć ile zapłaci, ryzyko przerzucić na dostawcę. Rozwiązanie jest takie, że jeżeli mamy tematy związane z analizą, to warto zrobić je na zasadzie zapłaćmy za wykorzystany czas. Jak już wiemy co chcemy zrobić to na to można zrobić fixed-price.
Zaangażuj IT klienta
Jeżeli IT nie zaangażujemy w miarę wcześnie, to się wysypie, jeżeli jesteś klientem i nie pogadasz z ludźmi z IT po swojej stronie to też się wysypie. Dużo osób sobie nie zdaje sprawy ze złożoności systemów, na których operujemy. Banał, ale warto pamiętać
Agile to nie metoda!
Jedną z lekcji, którą wyciągnąłem przy moich projektach jest to, że jeżeli nie zaciągniesz danych produkcyjnych na start, to się wpakujesz w problemy. Na danych testowych ludzie nie wyłapią błędów. Agile jest często wytrychem, że “będziemy mogli wprowadzać zmiany do ostatniej chwili”. To nie jest dobre podejście. Podpisywanie poszczególnych etapów, odbiory, to jest clue. Nie dajcie się nabrać, jeżeli ktoś wam mówi, że do ostatniej chwili będzie można wprowadzić zmiany i będzie fajnie. Zapytajcie jaka jest procedura, jak sprawdzamy, jak będziemy wyceniać, kiedy sprawdzamy poszczególne elementy zakresu.
VIDEO