Dlaczego efektywna współpraca to klucz do sukcesu projektu
Każdy project manager oraz biznes online wie, ze współpraca wewnątrz zespołu jest kluczowa do dowiezienia projektu. Kiedy zaczynasz współpracę z Software Housem, staje się on nieodłączną częścią Twojego biznesu. Należy więc go traktować jako de facto część zespołu. Co nie będzie dowiezione przez Software House – będzie wpływać na Twój biznes. Co nie zostanie przekazane Software House – nie zostanie przez niego wyprodukowane. Każdy Team Lider (czy Scrum Master) może powiedzieć, że do efektywnej współpracy zespołu potrzebne są przede wszystkim 3 rzeczy: komunikacja, komunikacja i komunikacja. Jednak co ta komunikacja oznacza w praktyce, w przypadku współpracy z Software Housem? Rozważmy to sobie na przykładach.
Przed rozpoczęciem prac
Określ jasne cele i oczekiwania
Podobnie jak w przypadku umowy o pracę czy umowy zlecenie, bardzo ułatwia komunikację konkretne ustalenie celów, które powinny zostać osiągnięte w ramach współpracy. W przypadku Software House’u sytuacja jest nieco lepsza, ponieważ dobry Software House – w przeciwieństwie do zwykłego pracownika – rozumie kontekst biznesowy projektu. To oznacza, że dobry Software House może również radzić odnośnie rozwiązań projektowych z uwzględnieniem skuteczności biznesowej przedsięwzięcia.
Oczywiście aby komunikacja na takim poziomie przebiegała w klarowny sposób, Software House powinien znać otoczenie biznesowe projektu, którym się zajmie. Istotne więc jest nie tylko przedstawienie samego projektu, ale też otoczenia biznesowego, oczekiwań użytkowników końcowych, czy też strategii operacyjnej samego przedsiębiorstwa czy firmy. Dobrze jest też przed współpracą założyć sobie pewne KPIs – pozwolą one zmierzyć efektywność rozwiązania po jego wdrożeniu.
Jeżeli założymy, że kaszym celem jest poprawa KPIs, to naszym oczekiwaniem może być poprawa wybranych wskaźników o konkretne wartości. Oczywiście jest to rozumienie tego punktu na wysokim – operacyjnym – poziomie. Natomiast niekoniecznie musi takie być. Dla projektu startupowego. Najważniejszym oczekiwaniem we współpracy z Software Housem może być szybkie dowiezienie projektu. Dla startupu, któremu zależy na dobrej obsłudze klientów lub działającemu w bardzo zmiennej branży, kluczowe może być powdrożeniowe wsparcie. Twoim zadaniem jako właściciela biznesu jest zdefiniowanie jaki aspekt takiej współpracy jest dla ciebie najistotniejszy – i zakomunikowanie go bardzo jasno i wyraźnie. Natomiast zadaniem Software House jest odpowiedzenie, czy i w jakim zakresie – oraz jakim sposobem – jest w stanie temu sprostać.
Wybór modelu komunikacji: narzędzia, rytm spotkań, kanały raportowania
Kanały komunikacji to element, który przewija się. Od samego początku od pierwszego nawiązania kontaktu do samego końca i wsparcia po wdrożeniowego. Te kanały komunikacji mogą być zupełnie różne dla pierwszego etapu. Inne dla etapu deweloperskiego, a jeszcze inne dla etapu. Po wdrożeniowego.
Przykładowo na samym początku komunikacja najpewniej odbywać się będzie przez e mail oraz telefon. Natomiast po ustaleniu zakresu prac oraz umowy komunikacja z Software Housem może się odbywać na platformach project managerskich – takich jak Asana czy Jira. Pomocniczo komunikacja z deweloperami może odbywać się również na Slacku, jeśli przewidziano model komunikacji bezpośredniej z deweloperem. Natomiast po samym wdrożeniu, jeśli podpisane jest umowa typu SLA oraz określone są czasy reakcji, najpewniej wymagane będzie korzystanie z konkretnych kanałów, które wykorzystują automatyczne przypisywanie osób odpowiedzialnych. Takie kanały najczęściej obsługują monitoring statusu zgłoszonych problemów.
Rytm spotkań będzie zależał od dobranej metodologii rozwoju oprogramowania. jeżeli wybrano metodologią jest SCRUM, to należy wprowadzić klienta we wszystkie artefakty i upewnić się że je rozumie. Jeśli wybraną metodologią będzie Kanban, to i tak warto wprowadzić pewne spotkania organizacyjne na przykład co 2 tygodnie.
Rola discovery phase: warsztaty, prototypy i weryfikacja pomysłu
Discovery phase – czyli faza odkrywcza – jest istotnym etapem w procesie planowania rozwoju oprogramowania, ponieważ pozwala niskim kosztem zweryfikować, czy występują potencjalne problemy z pomysłem. Ta faza może się składać z kilku elementów. To jest na przykład badania rynku, badania zachowań użytkowników, weryfikowania technologii, planowania strategicznego, czy też warsztatów organizacyjnych lub scrumowych.
Każdy z tych elementów może być zarówno odrzucony przez foundera jak i potraktowany w szczególny sposób. Choć generalnie odradzam odrzucanie discovery phase, to jeśli podłoże projektu jest bardzo dobrze przemyślane i przygotowane, może czasem obyć się bez tego etapu. Przykładem takiej sytuacji jest budowanie narzędzia wewnętrznego dla firmy, które ma usprawniać przepływ dokumentów. W takim wypadku pewnikiem jest, że grupa docelowa będzie korzystać z danego rozwiązania (przykazem odgórnym), więc badanie zapotrzebowania może nie mieć sensu. Jeśli do tego zakres prac jest bardzo szczegółowo rozpisany, przygotowane są widoki oraz struktura bazy danych, a technologia wybrana, to w zasadzie można przechodzić do wyceny takiego projektu. W takim wypadku aspektem komunikacyjnym będzie dobrze przygotowany zakres prac.
Natomiast jeśli founder nie jest pewien co do wartości swojego rozwiązania, faza ta może być potraktowana jako element komunikacji z potencjalnym odbiorcą technologii. W takim wypadku kanałem komunikacji staje się niejako prototyp rozwiązania. Prototypem może być nie w pełni działająca strona lub landing zbierający potencjalnie chętnych użytkowników. W rezultacie daje to również weryfikację rynkową i pozwala obliczyć lub oszacować stopę zwrotu z inwestycji.
Rozpoczęcie prac programistycznych
Ustalanie zakresu prac i priorytetów w backlogu
Jeśli faza Discovery została poprawnie przeprowadzona, to projekt powinien być omówiony, więc zakres prac powinien na tym etapie już być znany i szczegółowo opisany. Należy więc po prostu wprowadzić wszystkie elementy, które są potrzebne wykonania zadania, do narzędzia od project managementu (tj. Jira lub Asana). Wprowadzenie wszystkich zadań do takiego systemu jest również elementem komunikacji. Klient powinien mieć dostęp do tablicy ze wszystkimi zadaniami.
W szczególności gdy projekt może być uruchamiany etapami, to prace powinny być rozpoczęte od elementu z najwyższym priorytetem. Jest to prawda rozumiana instynktownie natomiast nie zawsze klarowne jest co ma najwyższy priorytet. Bez wcześniejszej rozmowy o priorytetach może się okazać że właściciel biznesu rozumiem priorytet w inny sposób niż Software House. Problemem może być również zdefiniowanie co może być uruchamiane w produkcji. Zazwyczaj określa się taki zakres jako MVP. Zgodnie ze SCRUMem oraz podejściem które ja zawsze proponuję, należy uruchamiać system w produkcji gdy tylko daje jakąkolwiek wartość użytkownikom. W ten sposób można zebrać wczesny feedback i wyłapać potencjalne problemy wcześniej. O tym właśnie jest następny akapit czyli zarządzanie zmianami.
Skuteczne zarządzanie zmianami: handling change requests
W mojej karierze nie trafiłem jeszcze na ani jeden przypadek projektu, którego zakres nie zmieniłby się podczas jego developmentu. Zapewne takie sytuacje występują przy zamówieniach publicznych, gdzie zakres prac i oczekiwany skutek musi być opisany przez klienta w szczegółach od samego początku. Dlatego w normalnych warunkach aby efektywnie współpracować z Software Housem wymagane jest omówienie zarządzania zmianą.
W przypadku gdy umowa Software Housem jest umową typu Agile, to znaczy w praktyce abonamentową na określoną ilość godzin w miesiącu, najczęściej zmiana nie jest problemem i musi być po prostu zgłoszona aby być podebrana w następnym sprincie. Nieco większym problemem jest gdy umowa jest typu fixed price. W takim wypadku każda większa zmiana wymaga podpisania aneksu do umowy. W przypadku mniejszych zmian zostaje w gestii dogadania się między stronami czy zmiana może być zawarta w zakresie prac – na przykład przez podmianę innego elementu lub z wykorzystaniem przewidzianego marginesu błędu. Taki margines standardowo zawieramy w umowach typu Hybrid.
Monitorowanie postępów: metryki, demo i retrospekcje
Monitorowanie postępów jest również elementem komunikacji. W metodologii SCRUMM wystarczającym jest przedstawienie demo produktu oraz omówienie problemów na spotkaniu retrospekcji. Do mierzenia tempa prac można wykorzystywać również bardziej zaawansowane metryki typu na przykład burn down chart.
Jeśli projekt ma stały budżet to jest ustalony fixed price, zapewne ma również ustalony termin wykonania. W takim wypadku należy po prostu monitorować tempo prac w ujęciu na przykład tygodniowym lub dwutygodniowym oraz sprawdzać czy jest zgodne z przewidywaniami. W razie nieścisłości należy je natychmiast zgłaszać i omawiać, aby zachować pełną transparentność tego na jakim etapie projekt się znajduje. Z drugiej strony zespół deweloperski również powinien być transparentny gdy występują opóźnienia – z powodów na przykład choroby czy większego skomplikowania elementu niż zakładany.
Inne elementy okołoprogramistyczne
Zapewnienie jakości: testy, code review i automatyzacja CI/CD
We wszystkich projektach które u nas robimy zawsze w wycenie znajduje się automatyzacja i CI/CD. Takie podejście wymaga pełnych dostępów do serwerów produkcyjnych dostarczonych przez nas lub przez samego klienta. Ten element traktujemy u nas jako niezbędną podstawę, ale nie u wszystkich musi tak być.
Jeśli chodzi o pisanie testów automatycznych oraz code review, bardzo dużo zależy od wymagań samego klienta. Z jednej strony te 2 elementy zapewniają wysoką jakość kodu oraz minimalizują ryzyko błędów, z drugiej strony ich wprowadzanie zawsze w pewien sposób zwiększa budżet projektu. W Sailing Byte zawsze proponujemy by przynajmniej ścieżki krytyczne były pokryte testami automatycznymi.
Natomiast w przypadku systemów które przetwarzają bardzo wrażliwe dane (na przykład dane medyczne, dane personalne, numery PESEL)(oprócz testów jednostkowych powinny być prowadzone również testy bezpieczeństwa. Absolutnym minimum powinny być testy typu SAST. Jeśli klient nie rozumie znaczenia testów bezpieczeństwa, testów jednostkowych, code review, należy mu wyjaśnić w jaki sposób będzie to wpływać na stabilność projektu. Czasem w projektach startupowych stabilność może być poświęcona na rzecz szybszego i tańszego uruchomienia kluczowych funkcjonalności jest to dla mnie zrozumiałe z punktu widzenia biznesowego.
Transparentność kosztów: budżet, stawki godzinowe i raporty
Jak wspomniałem w jednym z punktów powyżej, praktycznie nie ma projektów w których zakres prac się nie zmienia – dlatego ustalenie stawek godzinowych czy budżetu projektu jest kluczowe, aby móc dowieść biznesową wartość projektu. Do tego transparentność stawek godzinowych jest kluczowa do obliczania dodatkowych opłat– na przykład pracy poza godzinami standardowymi.
Przy niektórych modelach rozliczeniowych konieczne są również raporty dotyczące ilości prac w rozbiciu na godziny. Z mojego doświadczenia wynika, że użyteczność takich raportów zależy od tego jakie podejście ma klient (czy jest to podejście partnerskie czy wyzyskujące) mogą więc one albo dostarczać wartość albo być elementem sporu. Jednak Software House powinien moim zdaniem i tak zawsze prowadzić śledzenie godzin, ponieważ raporty takie mogą również służyć celom wewnętrznego doskonalenia zespołu. W zdecydowanej większości projektów w których pracujemy takie raporty nie są potrzebne, ponieważ klienci rozumieją wartość jaką dostarczamy w Sailing Byte.
Budowanie partnerskich relacji: zaufanie, feedback i kultura ciągłego doskonalenia
Ten punkt dotyczy bardziej elementów wewnętrznych Software House’u, jednak jeśli jesteś klientem warto mieć jego świadomość. Brak występowania elementów które świadczyłyby o istnieniu kultury ciągłego doskonalenia może być elementem alarmującym. Taki Software House docelowo nie będzie interesował się by stawać się coraz lepszym, a więc współpraca z nim nigdy nie będzie się poprawiać.
Ten element może przybrać różne formy, na przykład: ankiet spotkań retrospektywnych, prywatnych spotkań jeden do jednego czy też dostosowywania procesu tworzenia oprogramowania w reakcji na zidentyfikowane problemy. Należy pamiętać, że konstruktywne procesowanie feedbacku może odbywać się wyłącznie w atmosferze wzajemnego szacunku oraz zaufania, dlatego jeśli coś nie układa się we współpracy z twoim Software Housem, po prostu zwróć im na to uwagę i Obserwuj co zrobią z tą informacją.
Utrzymanie i wsparcie po wdrożeniu: SLA, maintenance i dalszy rozwój
Utrzymanie projektu może przybierać różne formy – może być po prostu podpisywaniem umowy na następne etapy lub przejściem z umowy typu fixed price na time and materials. Natomiast w przypadku systemów gdzie istotny jest czas reakcji konieczne może być podpisanie umowy typu SLA. Ponieważ umowa tego typu jest już zobowiązaniem prawnym na reakcję w określonym czasie, normalną rzeczą jest że Software House będzie wymagał dodatkowej płatności za utrzymanie i dostarczenie takiej usługi.
W większości przypadków z mojego doświadczenia wynika, że wystarczy przejście na umowę abonamentową bez podpisywania SLA. Zapewne jest tak dlatego, że w Sailing Byte potrafimy dostarczyć rozsądne czasy reakcji nawet w przypadku niekluczowych systemów.
Podsumowanie: 5 kluczowych zasad efektywnej współpracy
Efektywna współpraca z Software Housem jest kluczowa dla sukcesu projektu technologicznego i powinna być traktowana równie poważnie jak współpraca z wewnętrznym zespołem. Fundamentem udanej kooperacji jest jasna komunikacja – od zdefiniowania celów, przez wybór modeli współpracy i narzędzi komunikacyjnych, aż po zarządzanie zmianami i monitorowanie postępów. Kluczowe etapy projektu, takie jak faza discovery, ustalanie priorytetów w backlogu czy testowanie, wymagają zaangażowania obu stron i transparentności – zarówno kosztowej, jak i decyzyjnej. Równie istotne jest budowanie partnerskich relacji (co jest mottem w Sailing Byte) opartych na wzajemnym zaufaniu oraz ciągłym feedbacku.
Jeśli chcesz przekonać się, jak w praktyce wdrażamy to wszystko w życie, napisz do nas – opisz swój projekt a my pomożemy Ci go zrealizować w partnerskiej atmosferze!
