To musi wiedzieć każdy manager !

Jak to osiągnąć, tłumaczy na podstawie własnych doświadczeń Piotr Bogobowicz z firmy OMEC.

Swego czasu podjąłem się wraz ze swoim zespołem projektu budowy całkiem nowego oprogramowania dla  przedsiębiorstwa z branży nieruchomości. W tamtym czasie była to młoda firma, która powstała w wyniku kilkuletniego procesu planowania i modelowania przedsiębiorstwa przez jego założyciela. Z prawdziwą ciekawością obserwowałem proces jej powstawania – widziałem zaczątek firmy, który był zwyczajnym arkuszem w Excelu, potem odwiedziłem jej pierwszą siedzibę, poznawałem nowych pracowników i byłem świadkiem ich zaangażowania w tworzenie procesów i poszukiwanie pierwszych klientów.

Założyciel firmy już na etapie planowania biznesu wiedział, że musi zainwestować we wsparcie informatyczne. To pragmatyczne podejście wynikało z przekonania, że lepiej jest zaprojektować system CRM od zera, który będzie skrojony pod specyficzne potrzeby i modyfikowany na bieżąco, niż wdrażać nowe rozwiązania w już funkcjonującą organizację. Na tym etapie do prac zostałem włączony ja wraz z moim zespołem.

Z początku proces przebiegał standardowo – po wielu latach pracy w branży rzadko kiedy coś nas zaskakuje. Jednak w tym wypadku było inaczej. Zebraliśmy wymagania jakie wyspecyfikował odbiorca systemu, zdefiniowaliśmy przypadki użycia – krótko mówiąc przeprowadziliśmy pogłębioną analizę i w oparciu o nią zaprojektowaliśmy system. Wszystko postępowało zgodnie z tradycyjnym procesem budowy systemu informatycznego – wypuściliśmy pierwszy przyrost systemu, wprowadziliśmy użytkowników, przeprowadziliśmy szkolenia i na bieżąco usuwaliśmy mniej lub bardziej spodziewane problemy. Po uruchomieniu systemu użytkownicy informowali nas o swoich pomysłach na jego rozwój i modyfikację, którymi zarządzaliśmy przy pomocy prostego oprogramowania ticketowego.

I właśnie w tym momencie nasze plany i przyzwyczajenia zderzyły się z rzeczywistością. Ogromna liczba nowych wymagań oraz częste zmiany ich priorytetów nie pozwalały nam na stworzenie harmonogramu działań, który nie zmieniałby się w ciągu tygodnia. Myślę, że nie muszę dodawać, że każda kolejna zmiana wg. klienta powinna być wprowadzona natychmiast. Wszystko to powodowało częste przesunięcia priorytetów w pracy deweloperskiej i rzutowało na jakość oraz komfort pracy.

Nie mogąc sobie pozwolić na spadek jakości oraz chcąc uniknąć narastających napięć zarówno w zespole, jak i po stronie klienta, musieliśmy szybko znaleźć rozwiązanie tej sytuacji. Mimo dużej liczby odbytych przeze mnie wcześniej szkoleń, żadne z nich nie przygotowało mnie na tak patową sytuację – albo praca wykonana przez nasz zespół byłaby niskiej jakości, albo powinniśmy powiadomić klienta o niemożliwości wykonania zadania w takiej formule – i nie skończymy projektu.

Nie chcąc sobie na to pozwolić, skorzystaliśmy z powszechnie przyjętego narzędzia – burzy mózgów. Zespół spotkał się ze zleceniodawcą i w wyniku dyskusji zaproponował rozwiązanie. Ustalono, że podstawową jednostką czasu w projekcie będzie tydzień. Pod koniec każdego okresu określano cele na następny i szeregowano je według priorytetów. W międzyczasie zleceniodawca mógł przedstawić wymagania i poprawki, ustalając najpilniejsze potrzeby. Dzięki temu mieliśmy ustalony zakres prac na kolejny tydzień i mogliśmy nadać im odpowiedni rytm, nie marnując czasu na niespodziewane zadania.

Ten sposób prowadzenia procesu okazał się bardzo skuteczny – zbudowaliśmy procedurę, która była wystarczająco elastyczna z punktu widzenia klienta, a naszemu zespołowi zapewniała niezbędny komfort pracy. Ponadto, zespół zaczął pracę w siedzibie klienta, żeby jak najbardziej skrócić proces przekazywania informacji zwrotnej. Było to szczególnie istotne z perspektywy naszego zleceniodawcy, któremu zależało na jak najszybszym wprowadzaniu nowych funkcjonalności. Kolejne elementy były wprowadzane do użytkowania niemal od razu, a ewentualne błędy były na bieżąco zgłaszane przez użytkowników już pracujących z systemem.

Nowy system pracy pozytywnie wpłynął na morale nie tylko zespołu deweloperów, ale również na użytkowników systemu. My wiedzieliśmy, że nie marnujemy czasu i wszystko to, co zbudowaliśmy, jest od razu dostępne dla użytkowników – co wcześniej nie było oczywiste, a wiele linijek kodu nie zostało wykorzystanych z powodu kolejnych zmian po stronie klienta – a użytkownicy mogli od razu zacząć korzystać z potrzebnych im funkcji. W tym systemie moja rola jako kierownika projektu została ograniczona do dbałości o dobre warunki pracy zespołu oraz rozwój poszczególnych jego członków. Po latach wiemy, że pracując nad tamtym projektem udało nam się opracować metodę pracy w stylu zwinnym, która przypomina dzisiejsze podejście Scrum oraz AgilePM. Gdybyśmy w tamtym czasie mieli wiedzę o możliwości pracy w takiej metodyce, nie musielibyśmy tworzyć procesu od samego początku.

Opisany wyżej projekt dał nam wiele jako zespołowi, ale również mi osobiście jako kierownikowi projektów. Wtedy przekonałem się, że warto szanować inicjatywy zespołu i należy pozwalać mu na pracę według metodyki, w której najlepiej się czuje. Oczywiście o ile specyfika projektu na to pozwala.

Taki samoorganizujący się organizm jest mocniej zmotywowany i pracuje skuteczniej. Lekcją dla mnie, która pomogła mi w kolejnych projektach, jest to że warto – choć to niezwykle trudne – wyrwać się z utartych metod zarządzania, zdobyć się na dystans i zbudować coś kompletnie nowego, co sprawdzi się w tym konkretnym przypadku. Przełamanie tej bariery jest według mnie podstawą, dzięki której możemy usprawnić development IT i skutecznie realizować projekty. Takie podejście skutkuje pracą w dobrej atmosferze oraz poczuciu odpowiedzialności zmotywowanego zespołu za projekt, nad którym pracuje.