Hadrone PPM jest oprogramowaniem gotowym (pudełkowym), które jest dopasowywane do potrzeb Klienta podczas wdrożenia poprzez odpowiednią konfigurację. Wdrożenie produktu gotowego niesie ze sobą wiele korzyści (w tym szybsze i tańsze wdrożenie i utrzymanie), ale może mieć też ograniczenia, związane z uwzględnieniem specyficznych potrzeb danej organizacji.

Przy oprogramowaniu gotowym szczególnie ważne jest zrozumienie jego architektury biznesowej i zakresu funkcjonalności, żebyśmy wiedzieli, czego możemy się po nim spodziewać obecnie i jak się może rozwijać w przyszłości. Wdrożenie systemu klasy PPM jest dużą zmianą organizacyjną, więc my zawsze zalecamy, aby sprawdzić dane rozwiązanie (lub kilka) przed podjęciem decyzji. Więcej piszemy o tym w artykule „Czy mogę sprawdzić Hadrone PPM przed zakupem (pilotaż)?”.

Obecne potrzeby organizacji to jednak nie wszystko. Pytanie, jak gotowy produkt, jakim jest aplikacja Hadrone PPM, zmienia się w czasie, aby uwzględniać zmieniające się potrzeby Klientów? I jaki wpływ na te zmiany mają Klienci? W naszym przypadku ten wpływ jest bardzo realny, w przeciwieństwie do rozwiązań innych globalnych dostawców, z którymi konkurujemy.

Customer-driven development jest wpisany w nasze DNA. Rozwijając produkt na początku to autor ma na niego pomysł i nadaje mu określony kształt. Tak też było z Hadrone PPM – zauważyliśmy lukę na rynku i postanowiliśmy stworzyć produkt, który będzie wystarczająco kompleksowy, aby pokryć potrzeby wymagających organizacji, a z drugiej strony możliwie łatwy do wdrożenia i przyjazny dla użytkowników.

Po pewnym czasie, gdy użytkowników oprogramowania było coraz więcej (w przypadku Hadrone PPM są to tysiące osób), to oddolnie zaczęło do nas spływać coraz więcej szczegółowych potrzeb i pomysłów na rozwój, wynikających z wielu sytuacji, z którymi mierzą się organizacje. Bardzo cenimy ten wkład i chętnie korzystamy z tych podpowiedzi, bo nie bylibyśmy w stanie wszystkiego sami wymyślić. W miarę upływu czasu nasza rola też się zmieniła. Obecnie słuchamy potrzeb klientów, standaryzujemy je i wdrażamy funkcjonalności, które będą mieć zastosowanie w tej konkretnej sytuacji, jak i w wielu innych. Często dostajemy informację zwrotną od klientów, że nie tylko pomogliśmy im w tej konkretnej sytuacji, ale też przewidzieliśmy kilka kolejnych :) Budujemy więc mechanizmy uniwersalne, które pozwalają dopasować się do różnych okoliczności.

Jednym z przykładów ilustrujących takie podejście są etapy projektów, które odpowiadają cyklowi wytwórczemu w projekcie. Nasi Klienci oczekują, że w jednym miejscu w Hadrone PPM będą w stanie zarządzać i monitorować cały portfel projektów, który może obejmować bardzo różne rodzaje projektów: IT, inwestycyjne, remontowe, R&D, marketingowe etc. Każdy z nich ma inne etapy, które odpowiadają głównym krokom w takim projekcie. W pewnym momencie wprowadziliśmy więc funkcjonalność schematów etapów projektów, konfigurowanych indywidualnie dla każdego Klienta. Dany schemat jest tworzony dla określonego typu projektu i obejmuje etapy charakterystyczne dla tego typu projektu. W ramach monitorowania portfela projektów możemy jednocześnie zobaczyć wszystkie projekty, z uwzględnieniem ich indywidualnych etapów.

Oczywiście cały czas rozwijamy też nowe funkcjonalności, gdzie inspiracja pochodzi od naszego zespołu. Tutaj też często okazuje się, że Klient dostaje nową funkcjonalność, o której jeszcze wczoraj nie myślał i dzisiaj już nie potrafi bez niej żyć :)

Jak więc rozwijamy system Hadrone PPM, uwzględniając potrzeby naszych Klientów? Na trzy sposoby:

  • roadmapa rozwoju Hadrone PPM na dany rok,
  • bieżące zmiany zgłaszane przez Klientów,
  • rozwój wyzwalany przez konkretnego Klienta.

Roadmapa rozwoju Hadrone PPM na dany rok 

Praca nad roadmapą Hadrone PPM rozpoczyna się w październiku, a finalną roadmapę na dany rok publikujemy na przełomie stycznia i lutego. Roadmapa obejmuje listę funkcjonalności, które zostaną wprowadzone w poszczególnych kwartałach danego roku (publikujemy 4 nowe wersje Hadrone PPM w każdym roku).

Praca nad roadmapą obejmuje poniższe główne kroki:

  1. zgłaszanie potrzeb przez Klientów,
  2. opracowanie propozycji zmian i nowych funkcjonalności na roadmapę,
  3. głosowanie Klientów,
  4. przygotowanie i zakomunikowanie roadmapy.

Planowanie roadmapy rozpoczynamy w październiku danego roku. Wówczas wysyłamy do naszych Klientów prośbę o przesłanie propozycji zmian i nowych funkcjonalności, które miałyby się pojawić w oprogramowaniu Hadrone PPM w kolejnym roku.

Po otrzymaniu potrzeb rozwojowych Klientów porządkujemy je i uwspólniamy, dopytując czasem o dodatkowe szczegóły i na tej podstawie powstaje lista proponowanych zmian i nowych funkcjonalności do wyboru przez Klientów. W tych propozycjach znajdują się także nasze własne pomysły, które Klienci mogą później ocenić.

W trzecim kroku przedstawiciele Klientów głosują na poszczególne propozycje zmian i nowych funkcjonalności, układając je w kolejności od najważniejszych do najmniej istotnych. W ten sposób powstaje lista rankingowa, która jest dla nas punktem wyjścia do opracowania roadmapy rozwoju Hadrone PPM na kolejny rok.

Czwarty krok obejmuje naszą pracę analityczną, w wyniku której powstaje roadmapa. Wymiarujemy poszczególne zmiany i układamy je w odpowiedniej kolejności, finalnie grupując w ramach czterech wersji, które planujemy wydać w danym roku (planowanie i późniejszy monitoring roadmapy odbywa się w Hadrone PPM ;). Finalna roadmapa jest przesyłana do naszych Klientów, aby każdy wiedział, kiedy i jakich zmian może się spodziewać w oprogramowaniu. Dzięki temu nasi Klienci mogą się wcześniej przygotować do wykorzystania nowych możliwości Hadrone PPM.

Bieżące zmiany 

Z roadmapy wynikają główne zmiany, które zostaną wprowadzone w Hadrone PPM w danym roku. Nie są to jednak wszystkie zmiany, które wdrażamy. W trakcie roku nasi Klienci na bieżąco zgłaszają nam mniejsze i większe propozycje zmian. Część z nich udaje się wprowadzić w tzw. „międzyczasie” (często nawet drobne zmiany są bardzo ważne dla naszych Klientów), a inne oczekują na planowanie roadmapy na kolejny rok.

Dodatkowo wprowadzane są również zmiany techniczne, zapewniające odpowiedni poziom bezpieczeństwa i wydajności aplikacji oraz zapobiegające powstawaniu długu technologicznego.

Rozwój wyzwalany przez konkretnego Klienta 

Co do zasady oprogramowanie Hadrone PPM jest rozwijane zgodnie z roadmapą, z uwzględnieniem mniejszych zmian wprowadzanych na bieżąco. Występują jednak wyjątki.

W przypadku nowych Klientów czasami zdarza się, że oprogramowanie Hadrone PPM spełnia zdecydowaną większość potrzeb, więc Klient chciałby skorzystać z gotowego rozwiązania, ale występują także ważne potrzeby, których Hadrone PPM obecnie nie spełnia. Czasami jakiemuś Klientowi bardzo zależy na konkretnej funkcjonalności, która jednak nie jest tak istotna dla większości klientów i stąd nie pojawiła się na roadmapie. W jeszcze innym przypadku taka pilna potrzeba pojawia się w trakcie roku. Czy wówczas jest możliwość wprowadzenia takich zmian „poza roadmapą”? Tak, choć nie zdarza się to często.

W takim przypadku najpierw analizujemy, czy pomysł na zmianę lub nową funkcjonalność jest zbieżny z domeną naszego oprogramowania.

Przykładowo nie zamierzamy wprowadzać do Hadrone PPM funkcjonalności fakturowania klientów, dla których są realizowane projekty – Hadrone PPM może dostarczyć informację, ile godzin kto przepracował w jakim projekcie i na tej podstawie w systemie księgowym zostanie wystawiona odpowiednia faktura. Sam przepływ danych między systemami może zostać zautomatyzowany z wykorzystaniem technologii API i webhooks.

Jeśli zakres proponowanej zmiany mieści się w domenie naszego oprogramowania, to uzgadniamy z Klientem w jakim zakresie może partycypować w kosztach rozwoju takiej funkcjonalności. Po wdrożeniu zmiany jest ona dostępna dla wszystkich Klientów, a więc nie tylko dla tego Klienta, który ją zainicjował. Dbamy o to, aby produkt był jednolity – oczywiście nie ma obowiązku korzystania z nowych funkcjonalności, jeśli dany Klient uzna je za niepotrzebne, a jeśli ich nie skonfigurujemy to często w ogóle nie pojawią się na interfejsie aplikacji.