CASE STUDY: Flexi Project – czyli jak zarządza się oprogramowaniem do zarządzania?

Powiedzieć, że za stworzeniem FlexiProject stoi potrzeba rynku to zdecydowanie za mało. System powstał w odpowiedzi na realne potrzeby i problemy firm prowadzących projekty. Potrzeby te identyfikowane były przez lata, dzięki czemu można było zbudować coś, co przyniesie użytkownikom dużą wartość. Jeśli kiedykolwiek zastanawialiście się jak wprowadza się nowe systemy na rynek, jak ważne jest słuchanie klienta i po co komu dokumentacja w Scrumie ten wywiad jest dla Was 😊

FlexiProject – case study

Moi rozmówcy Włodzimierz Makowski oraz Dominik Wrzosek z FlexiProject, zgodzili się specjalnie dla narudo.pl opowiedzieć o historii powstania systemu oraz o tym jak wygląda jego rozwój. Niedawno odbyliśmy więc bardzo interesującą rozmowę, w której panowie opowiedzieli mi „Jak zarządza się oprogramowaniem do zarządzania”. Dzisiaj mam przyjemność ją Wam zaprezentować. Więcej o samym systemie FlexiProject znajdziecie w artykule: FlexiProject – skuteczne zarządzanie projektami

Od prowizorycznego Excela do systemu zarządzania projektami

Co było pierwsze – jajko czy kura? Albo raczej w tym przypadku problem czy system? Na naszym rodzimym rynku nie ma zbyt wielu narzędzi do zarządzania projektami, dlatego sam pomysł wydaje się interesujący. Na początek pytam więc moich rozmówców skąd się wziął pomysł na taki produkt jak FlexiProject.

Włodzimierz Makowski– Cofnę się do pewnej historii. My, przed FlexiProject, mieliśmy firmę doradczą, która się nazywała MDDP Business Consulting. W tej firmie realizowaliśmy dużo różnego typu projektów. Były to projekty optymalizacji procesów, restrukturyzacji firm, wdrażania strategii na rynek. W pewnym momencie bardzo duża spółka paliwowa poprosiła nas o stworzenie metodyki zarządzania projektami. Poprosiliśmy tę firmę, żeby nam przedstawiła listę projektów, które obecnie realizują. Usłyszeliśmy, że potrzebują na to tydzień lub dwa. Strasznie nas zdziwiło, że tak duża firma ma problem z podaniem liczby realizowanych projektów.

Wtedy zaproponowaliśmy im, że zbudujemy prosty system oparty o Excela i bazę SQL. Będą mogli w nim rejestrować wszystkie projekty, które obecnie toczą się w organizacji. Firma ta powiedziała, że z tego prostego systemu będą korzystać pół roku dopóki nie znajdą lepszego systemu. Okazało się, że z tego naszego prostego systemu korzystali prawie 5 lat. W międzyczasie pomyśleliśmy, że może warto ten „prosty system” ładnie opakować, trochę zmodyfikować i spróbować sprzedawać na polskim rynku. Chcieliśmy zbadać czy jest potencjał na tego typu produkt.

Zrobiliśmy to. I wtedy nasz system sprzedał się u kilku klientów, ale było to bardzo proste rozwiązanie.

Ponieważ widzieliśmy potencjał na rynku, zdecydowaliśmy się na budowę profesjonalnego systemu, który będzie oparty o nowe technologie, przeglądarkę internetową. I tak powstał system, nad którym pracujemy już 3 lata.

Automatyczne przeglądy projektowe, powiązanie z celami strategicznymi oraz standaryzacja

O ile wśród narzędzi do zarządzania projektami nie ma zbyt wielu rodzimych rozwiązań, to jednak takich systemów jest całkiem sporo. Szczególnie na zachodzie jest spora konkurencja. Wiele funkcjonalności, o których rozmawialiśmy w czasie naszego spotkania ma podłoże pragmatyczne. Powstają w odpowiedzi na potrzeby klienta.

Np. funkcjonalność scoringu, o której opowiedział mi pan Włodzimierz, pozwalająca selekcjonować najlepsze pomysły a następnie przekształcać je w projekty. Funkcjonalność ta, była odpowiedzią na problem pewnej firmy logistycznej. Miała ona w ciągu roku kilkadziesiąt pomysłów na projekty, jednak moce przerobowe starczały by rozpocząć wyłącznie kilka. Wybór najlepszych, najbardziej atrakcyjnych projektów do realizacji okazał się bardzo trudnym zadaniem. Moduł scoringu, który jest w systemie pozwala oceniać inicjatywy na projekty. Innymi wartymi uwagi funkcjonalnościami, które również nie są często spotykane, są np. moduł zasobów pozwalający na monitorowanie obciążenia czy też karta projektu.

Wydaje mi się jednak, że jest kilka funkcjonalności mocno wyróżniających FlexiProject na tle konkurencji, o których powinniśmy opowiedzieć.

Włodzimierz Makowski: To co nas najbardziej wyróżnia, to są automatyczne przeglądy projektowe. Mianowicie wiele firm ma taki proces, że jest biuro zarządzania projektami, jakiś standard prezentacji, np. szablon dwóch slajdów PowerPoint, w którym każdy kierownik projektu podsumowuje status swojego projektu. Slajdy te są wysyłane do PMO, następnie PMO składa z tego prezentację i wysyła do zarządu. Jest to proces czasochłonny, mocno analogowy, nie zawsze efektywny.

My taki proces odzwierciedliliśmy w systemie i dzieje się on automatycznie. Wybieramy dane projekty do przeglądu, oznaczamy datę przeglądu. System automatycznie powiadamia kierowników projektów, że zarząd firmy chce przejrzeć określone projekty np. strategiczne. Wtedy muszą oni wypełnić wszystkie dane w systemie. Powstaje tzw. „executive summary” dla zarządu. Po czym system to automatycznie zbiera i komunikuje, który kierownik już to zrobił. Wówczas zarząd, niezależnie od tego gdzie się znajduje, ma szybką informację jak toczą się projekty. Od razu widać, które projekty toczą się słabo, które lepiej. Bardzo transparentna sytuacja. Tego w innych systemach nie ma, to jest nasz autorski pomysł.

Drugi element, który zdobywa coraz większe uznanie firm to jest powiązanie projektów z celami strategicznymi firmy. Bardzo często firmy definiują cele strategiczne firmy oraz projekty, ale nie ma bezpośredniego linku między tymi celami i projektami. My stworzyliśmy w systemie moduł strategii pozwalający powiązać cele strategiczne firmy z projektami. Monitoruje on w ten sposób jak jest wdrażana strategia firmy przy mądrym zarządzaniu projektami.

Trzecia funkcjonalność, która jest bardzo ciekawa to jest możliwość tworzenia standardów projektowych. Mówiąc prościej jest to możliwość tworzenia szablonów projektowych dla projektów, które mają charakter powtarzalny. Żeby nie zaczynać planowania projektu zawsze od nowa można stworzyć kilka standardów. Przy tworzeniu nowego projektu można pobrać standard i system z automatu tworzy plan nowego projektu. Kierownik projektu może zmodyfikować i dostroić do aktualnych potrzeb i specyfiki projektu.

Te trzy funkcjonalności nas wyróżniają i są strategicznym spojrzeniem na potrzeby firmy i zarządu. Na potrzeby ogólnego zarządzania i usprawniania firmy.

Dominik Wrzosek: Mamy również bardzo dobry system raportowania. Nie narzucamy z góry jak ma wyglądać raport. Użytkownicy mają dostęp do wszystkich informacji. Są one w systemie i mogą w bardzo przyjazny sposób poukładać raporty tak jak chcą. U nas użytkownik może poprzez moduł raportów wyciągnąć dowolne dane, poukładać je, przefiltrować.

To co nas jeszcze wyróżnia to bardzo intuicyjny system. Klienci często to podkreślają, chwalą np. pracę na harmonogramie czyli podstawowym narzędziu.

Dajemy klientom klocki, z których sami zbudują sobie to czego potrzebują

Geneza FlexiProject pokazuje, że najpierw była potrzeba, testowanie rynku a dopiero potem produkt. Jak wygląda rozwój takiego systemu? Jak przebiega typowanie funkcjonalności, które będą realizowane kolejne? Czy komunikujecie się z klientami ustalając kierunek rozwoju?

Dominik Wrzosek: Sposób zmieniał się w czasie. Na samym początku, kiedy startowaliśmy z narzędziem, to te potrzeby próbowaliśmy wymyślać sami, wewnętrznie. W dużej mierze definiował je Włodzimierz, posiadający wiedzę biznesową.

W momencie wydania na rynek pierwszej wersji zaczęliśmy od klientów zdobywać informacje. Pytaliśmy czego im brakuje, jakie są ich potrzeby. Teraz rozwój aplikacji mamy tak stworzony, że co dwa, trzy miesiące publikujemy nowe wersje.

W dużej mierze opieramy się na potrzebach zgłaszanych przez klientów. Mamy oczywiście takie rozwiązania, które stworzyliśmy sami, ale wszystkie są konsultowane z naszymi klientami. Staramy się cyklicznie spotykać z naszymi klientami, rozmawiać z nimi. Jesteśmy bardzo otwarci na to, żeby oni zgłaszali nam nowe funkcjonalności.

Natomiast, wielu klientów chciałoby system bardzo mocno dopasować do siebie, do swoich potrzeb. W każdej organizacji ten proces zarządzania projektami jest inny. Każda organizacja ma swoje własne metodyki wypracowane przez lata, które u nich świetnie się sprawdzają. W innej firmie w ogóle by się nie sprawdziły.

Niektórzy klienci próbują w naszym systemie odzwierciedlić te metodyki, chcieliby aby jakieś funkcje były napisane specjalnie dla nich. My staramy się jednak, żeby system był rozwijany uniwersalnie, staramy się filtrować takie potrzeby oraz nadawać im priorytety.

My dajemy klocki, klient sam sobie układa własną wieżę, czy budynek z tych klocków. Staramy się znaleźć uniwersalne rozwiązanie, konsultujemy je z innymi klientami, tak aby dane rozwiązanie było przydatne dla wszystkich klientów.

A czy budując FlexiProject mieliście na uwadze jakieś konkretne procesy zarządcze? Chcieliście żeby system wspomagał jakieś wybrane metodyki? Czy może raczej kierowaliście się zbiorem doświadczeń i najlepszych praktyk?

Włodzimierz Makowski: Ja mam certyfikat PMI, przeanalizowaliśmy razem z Dominiakiem metodyki PRINCE, obecnie współpracujemy z IPMA. Wbudowywaliśmy w nasz system komponenty z metodyki Stage Gate Methodology, która jest skierowana przede wszystkim na projekty badawczo rozwojowe i wdrażanie nowych produktów. Nie staramy się zbudować systemu wokół żadnej konkretnej metodyki. Uważamy, że te metodyki są do siebie podobne. Staramy się przede wszystkim budować takie funkcjonalności, które częściowo są zgodne z metodykami ale przede wszystkim rozwiązują pragmatyczne problemy w zarządzaniu projektami w firmach.

My rozmawiając teraz z dziesiątkami firm, słuchając ich potrzeb coraz bardziej rozumiemy te pragmatyczne potrzeby. I te potrzeby nie są też oderwane od metodyk bo te metodyki są mądre. Nie próbujemy literalnie w naszym systemie odzwierciedlić żadnej metodyki.

Dominik Wrzosek: Uważamy, że metodyki bardziej pokazują kierownikowi projektu w jaki sposób ma ten projekt prowadzić. Natomiast potrzeby, które zgłaszają nam klienci są zupełnie inne. Nie są związane z metodyką. Np. Jeżeli użytkownicy działają na Excelach to problemem jest to, że po przypisaniu zadań zwykły użytkownik nie wie na jakich projektach ma wykonać zadania czy skąd je wziąć. I na to nie ma wpływu żadna metodyka. Czy my to będziemy robili PRINCE czy inną metodyką. Jest potrzebna funkcjonalność, która pozwoli użytkownikowi zobaczyć swoje zadania na projekcie.

Zarządzanie po polsku?

Czasem w publikacjach czy raportach można spotkań określenie „polski sposób zarządzania”. Czy obserwując potrzeby zgłaszane przez klientów i to, w jakim kierunku zmierza rozwój systemu, czy też porównując się do zagranicznych, konkurencyjnych narzędzi można powiedzieć, że potrzeby polskich firm są jakieś inne lub specyficzne? Czy Wasze doświadczenia potwierdzają, że jest coś takiego jak zarządzanie po polsku?

Włodzimierz Makowski: Przypatrujemy się niektórym amerykańskim systemom. Mają one bardzo rozbudowane, mówiąc ogólnie- „korporacyjne funkcjonalności” takie jak: bardzo obszerne modelowanie portfeli projektowych czy tworzenie pewnych symulacji. Wydaje nam się, że to jest potrzebne w wielkich korporacjach. Natomiast naszym obecnym targetem są raczej średniej wielkości firmy i trochę większe niż średniej wielkości firmy. Powiedziałbym tak pomiędzy 50 mln zł obrotu rocznego do załóżmy miliarda, ale to nie są wielkie korporacje.

Wydaje nam się, że my mamy bardzo ciekawe funkcjonalności potrzebne właśnie w tym segmencie firm. Czasami wyprzedzamy to co się dzieje w amerykańskich systemach, czasami podpatrujemy i przemycamy pewne elementy, które nam się bardzo podobają. Tu gdzie odbiegamy, to są duże korporacyjne potrzeby i nie zamierzamy iść w tym kierunku. Natomiast zamierzamy zbudować system, który będzie bardzo przyjazny w pracy dla zespołów projektowych, dla biur zarządzania projektami i zarządów firm. Będzie odpowiadający potrzebom właśnie tego segmentu rynku.

Nie chcemy też zbyt komplikować systemu próbując dorównać konkurentom z zachodu w momencie kiedy na polskim rynku te funkcjonalności aż tak rozbudowane nie są potrzebne.

Dominik Wrzosek: Myślę też, że ciężko porównywać rynek amerykański z rynkiem polskim. Tak naprawdę kultura zarządzania projektami w Stanach jest dosyć duża. Natomiast u nas firmy mają dużo mniejsze doświadczenie w zarządzaniu projektami i dlatego te potrzeby są zupełnie inne. Firmy są na zupełnie innym etapie jeżeli chodzi o doświadczenia. Bardzo dużo firm, które do nas się zgłasza zarządza projektami tylko i wyłącznie w Excelu i ich głównym problemem jest to, że już nie dają rady, gubią się w Excelach.

Faktycznie, jeżeli organizacja rośnie od małej do dużej to Excel na początku jest tak uniwersalnym narzędziem, że to się fajnie sprawdza. Natomiast z biegiem lat jak firma się rozrasta, Excel przestaje spełniać oczekiwania. Firma nie zawsze w porę zdąży przeskoczyć na inne rozwiązanie.

A jak się właściwie zarządza systemem do zarządzania?

No właśnie. Jak zarządza się wytwarzaniem takiego produktu? Otóż FlexiProject wytwarza zespół Scrumowy. Pan Włodzimierz pełni rolę Product Ownera. Dominik jest w nim analitykiem. Zespół faktycznie dba o wszelkie scrumowe ceremonie, sprinty itd. Ale i na tym polu moi rozmówcy mają dla nas cenne przemyślenia. Zdaje się, że nie oni pierwsi i zapewne nie ostatni w historii zarządzania projektami wpadli w pułapkę „zbyt ubogiej” dokumentacji. Udało im się jednak udoskonalić proces i wyeliminować braki.

Włodzimierz Makowski: Ja jestem biznesowym właścicielem produktu a Dominik jest analitykiem, który ze mną rozmawia i przekształca to w wiedzę. Na jej bazie programiści mogą budować system. Dominik bardzo dużo pracy poświęca na to, żeby opracować bardzo dobre makiety i opisać to co chcemy osiągnąć. W tak precyzyjny sposób, żeby to wymagało jak najmniej interpretacji od programistów. Chodzi o to żeby oni mogli naprawdę efektywnie pracować i żeby mogli rozumieć co do nich mówimy.

Na początku robiliśmy nie dość precyzyjne koncepcje, które dawaliśmy programistom, którzy musieli interpretować je trochę po swojemu. Budowali system tak jak się im wydaje, a na końcu dostawaliśmy coś co nie było efektem, który sobie wyobrażaliśmy. Wymagało to powtórek, które kosztowały nas bardzo dużo czasu i bardzo dużo pieniędzy. Z czasem dopracowaliśmy to. Dużo dyskutujemy o nowej funkcjonalności. Analizujemy bardzo dużo różnych przypadków granicznych. Jak klient może postąpić, co może kliknąć, co może chcieć kliknąć. Jakie potrzeby biznesowe może chcieć załatwić.

Wydaje mi się, że wiele firm niedostatecznie dużo uwagi poświęca na opracowanie koncepcji i komunikację między analitykiem biznesowym właścicielem produktu a programistami.

Dominik Wrzosek: Ja jeszcze dodam, że my na samym początku, jak zaczynaliśmy, wiedzę przekazywaliśmy raczej na spotkaniach, czy jako komentarze na makietach. W pewnym momencie jednak tych zwrotek było na tyle dużo, że zaczęliśmy wytwarzać dokumentację do systemu opisującą jak ma on wyglądać.

Finalnie teraz przez kilka lat mamy tej dokumentacji tyle, że gdybyśmy ją chcieli wydrukować to zajęłaby nam kilka ładnych regałów.

Kiedy przychodzą do nas nowe osoby są często zdziwione, że mamy dokumentację 😊 Wiemy z doświadczenia w różnych firmach, że dokumentacja przy wytwarzaniu oprogramowania jest często problemem. Natomiast to się może okazać kluczem do sukcesu. Wiadomo- ciężko utrzymać w dokumentacji poziom, aby zawsze była jak najbardziej aktualna. Przy takiej ilości musielibyśmy mieć zespół dedykowany wyłącznie wytwarzaniu dokumentacji dla programistów.

Jak mamy gotową analizę, zanim programiści przystąpią do pracy, często robimy spotkania z klientami. My mamy już wtedy makiety gotowe i zaczynamy z klientami rozmawiać. Okazuje się, że czasami już w tym momencie ktoś nam zgłasza uwagi, że coś mu nie pasuje.

Dzięki temu oszczędzamy pracę programistów, bo już na podstawie makiet czy analizy rozmawiamy z klientami i dopiero jak to jest uzgodnione programujemy. Tworząc nowe funkcjonalności staramy się w dużej mierze rozmawiać z klientami, patrzeć jak to się sprawdzi u nich. Dzięki temu te rozwiązania które dajemy są przydatne dla użytkowników.

A gdyby tak zacząć jeszcze raz?

Czy z perspektywy czasu macie jakieś refleksje związane z wprowadzaniem takiego produktu na rynek, którymi chcielibyście się podzielić?

Włodzimierz Makowski: Ciągle znam dylematy, przed którymi stawaliśmy wcześniej i nawet nie wiem czy umiałbym je w 100% teraz rozwiązać. Można podejść do budowy takiego systemu w ten sposób, że budujemy dwa moduły. Staramy się je dopracować, wypuszczamy produkt na rynek i staramy się go sprzedawać i dobudowywać kolejne moduły. Tylko klienci chcą relatywnie dopracowanego rozwiązania. Nie chcą połowy produktu i obietnicy rozwoju.

Drugie podejście to takie, które my zastosowaliśmy. Zbudowaliśmy kompleksowy system, ale uprościliśmy wiele funkcjonalności. Wiedzieliśmy, że będziemy musieli je kiedyś poprawić, ale chcieliśmy, żeby to był kompleksowy system od razu, atrakcyjny dla rynku. Chcieliśmy także, żeby klienci nam w pewnym momencie powiedzieli z czego bardziej korzystają, w jaki sposób coś modyfikować i co się w praktyce dzieje.

Konsekwencją takiego podejścia jest to, że spędziliśmy dużo czasu na budowaniu systemu, a teraz musimy go modyfikować i poprawiać. Ale tego nie uniknęlibyśmy również w tym drugim, laboratoryjnym podejściu.

To jest ciągła ewolucja. W budowie takiego systemu nie można stanąć i powiedzieć, że to już jest gotowy system i nie wymaga już zmian. Na rynku pojawiają się nowe trendy, zmienia się świat my musimy się adaptować do tego świata.

Dominik Wrzosek: Budując takie oprogramowanie, dopóki nie pokazaliśmy tego światu czyli nie wyszliśmy na poligon, to budowaliśmy według naszych przeświadczeń. Teraz jak byśmy zaczęli od zera mając już zebrane doświadczenie z kilku lat- niektóre procesy zbudowalibyśmy inaczej.

Faktycznie fajne było to, że w pewnym momencie powiedzieliśmy, że my chcemy budować elastyczny system i nie tworzymy systemu, który jest ściśle dopasowany do jednego klienta czy branży. Takie podejście ma też swoje konsekwencje.

---