IT w biznesie

IT w biznesie 2016-08-12

Jak układać współpracę z dostawcą oprogramowania dedykowanego? [cz. 2]

Dlaczego rola Właściciela Produktu jest tak ważna? Co daje transparentność we współpracy z firmą IT? Co robić, gdy projekt traci uzasadnienie biznesowe? Kolejne praktyczne rady daje Marcin Kaczmarek, CEO Consileon Polska.

Marcin Kaczmarek, CEO Consileon Polska /fot.: Consileon Polska / Marcin Kaczmarek, CEO Consileon Polska /fot.: Consileon Polska /

W poprzednim artykule wskazałem na specyficzną dynamikę wymagań związanych z realizacją projektów informatycznych oraz wymaganą (po stronie klienta) dozę elastyczności i zaangażowania. Poniżej kolejna porcja wskazówek i rad jak taką współpracę organizować.

Właściciel Produktu - najważniejsza osoba w projekcie

Z prowadzonych przez dziesiątki lat na rynku IT statystyk wynika, że brak zaangażowania klienta w projekt jest kluczową przyczyną niepowodzeń projektów budowania oprogramowania „szytego na miarę”.

To wyraźnie pokazuje, że do realizacji projektu, po stronie klienta, potrzebna jest osoba posiadająca nie tylko wiedzę, ale przede wszystkim czas, który może poświęcić na współpracę.

W zwinnych metodykach zarządzania projektem rolę taką pełni tzw. właściciel produktu (ang. Product Owner). Osoba ją pełniąca realizuje w imieniu klienta większość obowiązków związanych z zarządzaniem i przekazywaniem wiedzy dostawcy. Przede wszystkim jednak właściciel produktu ma osobistą odpowiedzialność za projekt i wynikającą z niej moc decyzyjną. Jego kluczowym obowiązkiem jest regularna ocena stanu realizacji projektu i budżetu, sterowanie kierunkiem rozwoju działań lub też decyzja o ich zakończeniu. To on dla projektu jest najważniejszą osobą w firmie i on podejmuje ostateczne decyzje.


Partnerzy cyklu IT w biznesie:

 
Skuteczność dostarczania informacji decyduje o efektywności działań dostawcy
 
Bez potrzebnej informacji od właściciela produktu dostawca będzie polegał jedynie na zakomunikowanych na etapie sprzedażowym wymaganiach i własnych wyobrażeniach o biznesie klienta. Stąd konieczność, by właściciel produktu miał czas na codzienną komunikację z zespołem wytwarzającym oprogramowanie tak, by na bieżąco doprecyzowywać zmieniające się wymagania projektu. Warunku tego nie można lekceważyć, gdyż opóźnienie w tym zakresie może być bardzo kosztowne. Wdrażanie zmian po implementacji projektu, czyli już po napisaniu kodu źródłowego, potrafi być nawet dziesiątki razy droższe niż ich wprowadzenie na etapie planowania.
 
Trudno jest reprezentować wszystkich interesariuszy projektu
 
Rolą właściciela produktu jest także pozyskiwanie, ujednolicenie i przekazywanie dostawcy wiedzy i decyzji od innych osób zaangażowanych w projekt. Z doświadczenia wynika, iż jest to bardzo trudne zajęcie, polegające na pozyskiwaniu wiążących informacji od przedstawicieli różnych działów firmy. W przypadku różnicy wymagań, od tej właśnie osoby oczekuje się podejmowania decyzji o priorytetach na poziomie całej firmy i z punktu widzenia jej strategii. Osoba ta dba także o skuteczność wdrożenia systemu poprzez takie projektowanie rozwiązania, by ilość zmian procesowych, często niezbędnych do wdrożenia nowego oprogramowania, była akceptowalna dla organizacji.
 
Nie wolno zapominać o użytkownikach końcowych aplikacji
 
Niestety właściciele produktu często zapominają o zapewnieniu udziału lub przynajmniej reprezentowaniu potrzeb najważniejszych osób dla tworzonych systemów, czyli o użytkownikach końcowych. Tymczasem, ich opinie powinny być traktowane jako kluczowe i analizowane np. na spotkaniach oceniających rezultaty prac dostawcy wykonane w danej iteracji. Tylko bowiem dzięki bezpośredniej informacji zwrotnej od grupy, która codziennie będzie korzystać z aplikacji, można oprogramowanie uczynić naprawdę przyjaznym dla jego użytkowników (ang. user friendly).
 
Właściciel Produktu musi mieć przede wszystkim czas...
 
Najczęstszym jednak problemem projektów jest to, iż wyznaczony właściciel produktu posiada wiedzę i chęci, ale nie dysponuje czasem na realizację swoich obowiązków. Istnieje zatem konieczność uświadomienia klientów (na etapie rozmów o kształcie przyszłej współpracy), że ta rola projektowa bywa zajęciem nawet na pełen etat i jest bezwzględnie potrzebna, krytyczna dla powodzenia podejmowanych działań.

Dlatego też dostawcy często oczekują zagwarantowania w kontrakcie dostępności właściciela produktu w określonym wymiarze godzin w tygodniu, tak by on wspólnie z dostawcą stanowił jeden zespół projektowy.

… i wcale nie musi być informatykiem

Czy właściciel produktu musi znać się na IT? Oczywiście lepiej by tak było, ale nie jest to warunek konieczny. Kluczowe są jego umiejętności komunikacyjne i zarządcze.

Natomiast, do sprawnego wykonania swojej pracy, dostawca usług IT potrzebuje rzetelnej informacji o poziomie wiedzy z zakresu technologii informacyjnych, jaką dysponuje klient, a w szczególności właściciel produktu. Ułatwi to dostawcy przystosowanie jego przekazu tak, by był on dla klienta zrozumiały i skuteczny, a informacje potrzebne klientowi w podejmowaniu ważnych decyzji projektowych będą dostarczone w przystępny dla niego sposób. Oczywistym jest, iż dostawca, którego angażujemy do projektu musi dysponować znacznie większą wiedzą informatyczną od swojego klienta - bez tego nie byłby ekspertem. Przy odpowiednim poziomie zaufania, a przez to wzajemnej otwartości, klient ma możliwość nabyć, dodatkowo, praktyczną wiedzę.

Transparentność postępów prac jest dziś standardem i należy jej oczekiwać

Obecnie standardem na rynku B2B staje się całkowita transparentność i możliwość cotygodniowego, a nawet codziennego obserwowania postępów prac dostawcy przez klienta. Dzięki cyklicznemu nadzorowi strony mają czas na wspólną ocenę postępów w projekcie. Umożliwia to szybką reakcję na pojawiające się problemy i ewentualne szybsze zakończenie projektu, co pozwoli ograniczać dalsze jego koszty. Stąd z punktu widzenia klienta zapis umowny o transparentności jest kluczowym elementem umowy z dostawcą.

Zapewniając w kontrakcie właścicielowi produktu możliwość częstej kontroli i szybkiego zakończenia projektu, a nawet współpracy z dostawcą, unikamy jako firma sytuacji, o których słyszymy w kontekście przetargów na realizację projektów informatycznych w administracji państwowej. Tam mechanizm kontrolny uruchamiany jest rzadko, niekiedy dopiero na końcu projektu, czyli najczęściej po latach od jego startu. Niestety może się wtedy okazać, że wytworzone oprogramowanie nie odpowiada na aktualne potrzeby rynku, lub np. nie jest zgodne z obowiązującymi obecnie przepisami prawa albo też użytkownicy stworzonego rozwiązania po prostu nie chcą go używać. W konsekwencji słyszymy o zmarnowanych setkach tysięcy lub nawet dziesiątkach milionów złotych na informatyzację administracji państwowej. Opisywane tutaj rozwiązania pozwalają w praktyce zminimalizować powyższe ryzyko.

Wiele projektów powinno zakończyć się wcześniej niż planowano

Co w przypadku, kiedy współpraca z dostawcą układa się doskonale, ale projekt traci swoje uzasadnienie biznesowe? Z taką sytuacją mamy do czynienia, gdy np. w trakcie realizacji okazuje się, że konkurencja stworzyła podobne rozwiązanie szybciej, a bycie drugim na rynku nie pozwoli nam osiągnąć zamierzonych dla projektu celów finansowych. Może też być tak, że o funkcjonalność, którą w projekcie chcieliśmy stworzyć, zostanie rozbudowane oprogramowanie, jakie już w firmie mamy. Alternatywnie, że na rynku pojawi się gotowe rozwiązanie, które możemy zakupić szybko oraz kosztem znacznie mniejszym, niż inwestycja w jego budowanie tylko dla naszej firmy. Właśnie wtedy rozsądnym jest skorzystanie z możliwości szybkiego zatrzymania dalszych prac projektowych.

Podsumowując, wcześniejsze zakończenie projektu nie zawsze jest złą decyzją. Wręcz przeciwnie, często bywa uzasadniona - stąd zadbać należy o taką możliwość w kontrakcie z dostawcą.

Marcin Kaczmarek
CEO Consileon Polska

Tematy: IT (65) | branża IT (38) |
aktualizowano: 2016-08-19 01:13
Wszystkich rekordów:

Kalendarz

1
Listopad Środa
09:00 - 18:00

Konferencja Bioekonomia 2017, Anklam

czytaj więcej »
8
Listopad Środa
10:00 - 20:00

Targi Bazaar Berlin 2017, Messe Berlin

czytaj więcej »
23
Listopad Czwartek
09:00 - 15:00

Industrial Bridge 2017, Szczecin, Regionalne Centrum Innowacji i Transferu Technologii ZUT

czytaj więcej »

Społeczność