5 wyzwań, z którymi musi zmierzyć się każdy projekt software developmentu

Software development to złożony proces, który potrafi być nieprzewidywalny. Często pojawiają się problemy wymagające szybkiego rozwiązania, a żaden programista nie jest w stanie zabezpieczyć się na każdą okoliczność związaną z budową nowych rozwiązań. Na szczęście część wyzwań towarzyszących developmentowi jest — przynajmniej w jakimś stopniu — powtarzalna. Tym samym wystarczy odrobina wiedzy i odpowiedniego przygotowania, aby uniknąć najczęstszych błędów i efektywniej pracować przy kolejnych projektach IT.

5 najczęstszych wyzwań w procesie software developmentu

Obecnie software development jest kluczowy dla obsługi procesów biznesowych oraz rozwoju firm i organizacji praktycznie każdej wielkości. Mając na uwadze skalę przedsięwzięcia, w poniższym artykule chcielibyśmy omówić kilka najczęściej powtarzających się wyzwań związanych z projektami IT, jakie praktycznie każdy programista napotka na swojej drodze zawodowej. Podpowiemy, w jaki sposób się na nie przygotować, a tym samym uniknąć błędów i niepotrzebnych frustracji oraz zachować produktywność w działaniu.  

Zapraszamy do zapoznania się z listą 5 typowych wyzwań związanych z tworzeniem oprogramowania oraz sposobów na ich uniknięcie. 

Wyzwanie nr 1. Zrozumienie celu projektu

Oprogramowanie tworzymy z konkretnym zamysłem biznesowym, najczęściej chcąc rozwiązać jasno zdefiniowane problemy lub potrzeby przyszłych użytkowników. Gorzej, jeżeli przed rozpoczęciem prac developerskich grupa docelowa i potencjał rynkowy zostaną niedostatecznie dobrze zbadane. Brak dogłębnej analizy grozi niespójnymi wymaganiami projektowymi, a niezrozumienie odbiorców budową niedopasowanego produktu. Powtarzającym się wyzwaniem na start każdego projektu software’owego jest potrzeba ustalenia: jaki problem rozwiązujemy?, co robimy?, dlaczego i po co to robimy? oraz w jaki sposób to robimy? Inaczej bardzo szybko natkniemy się na ryzyka wynikające ze zwykłej niewiedzy. Są to m.in.: 

• Niski lub zupełny brak popytu grupy docelowej na MVP naszego produktu, 
• Ograniczony produkt, nieoferujący wystarczająco dużo możliwości, 
• Powtarzalne rozwiązanie, zbyt podobne do konkurencyjnych produktów, 
• Brak przewagi konkurencyjnej i jasno wypracowanego modelu biznesowego. 

Z punktu widzenia software developmentu, konsekwencjami zmaterializowania się tego typu ryzk są nieplanowane zmiany w zakresie projektu IT, a tym samym jego budżecie i harmonogramie.

Zrozumienie celu projektu IT – jak przygotować się na to wyzwanie?

• Koniecznie: wykonać analizę standardów rynkowych, analizę rynku i konkurencji oraz ocenę możliwości rozwiązania. Dodatkowo warto zdefiniować persony oraz przeprowadzić wywiady pogłębione, skupiając się na zrozumieniu perspektywy użytkownika końcowego.  
• Nice to have: analiza zachowań nabywczych klientów, analiza zyskowności (długoterminowa), studium wykonalności produktu, zdefiniowanie Business Model Canvas i wstępne dopasowanie produktu do rynku.

Wyzwanie nr 2. Komunikacja w projekcie IT

W dzisiejszych czasach komunikacja jest najważniejszym skillem każdego managera. Bez umiejętności komunikacji nie można dobrze zarządzać ludźmi, a w konsekwencji nie można także dobrze zarządzać software developmentem. W przypadku projektów, w których pracuje kilkadziesiąt osób podzielonych na co najmniej kilka zespołów (znajdujących się w różnych lokalizacjach, a nawet w różnych strefach czasowych), komunikacja staje się kluczowa dla powodzenia zadania i powinna zwierać około 10-15% czasu zespołów IT.   

Niewłaściwa komunikacja powoduje problemy związane z niezrozumieniem celu projektu, zadawaniem wielokrotnie tych samych pytań, zdublowaniem pracy czy błędną implementacją. Wszystko to prowadzi do rosnącej frustracji zespołów, a finalnie do przestojów w pracy lub jej całkowitego zatrzymania. Konsekwencją jest niedotrzymanie zobowiązań, opóźnienia w projekcie, a także zwolnienia. Doświadczeni programiści rzadko chcą pracować w źle zarządzanych projektach IT.

Komunikacja w projekcie IT – jak przygotować się na to wyzwanie?

Fundamentem, na którym budujemy komunikację i układamy współpracę między zespołami, jest zaufanie — to właśnie o nie należy zadbać już na samy początku. Zaufanie tworzy przestrzeń, w której znajdzie się miejsce na szczerą i otwartą rozmowę, szczególnie w przypadku problemów w projekcie.

Kolejnym krokiem jest plan komunikacji, który musi zawierać w sobie wszystkie niezbędne informacje, tj.:

• Z jakich kanałów komunikacji korzystamy w zespołach i do czego służy każdy z nich?
• Kiedy komunikować się osobiście, a kiedy asynchronicznie?
• Jakie kto pełni funkcje w projekcie? Kto jest kierownikiem? Kto należy do zespołu projektowego? Kim są interesariusze projektu?
• W jaki sposób komunikowane będą ważne informacje, takie jak np. aktualizacje statusu projektu? Jak często będą one udostępniane?

Wyzwanie nr 3. Integracja oprogramowania

Integracja jest jedną z najważniejszych faz software developmentu. Większość ukrytych problemów z oprogramowaniem wychodzi na jaw właśnie na tym etapie projektu. Statystyki wskazują, że nawet 70% integracji systemów nie osiąga założonych celów, co pokazuje, że ta jest prawdziwym wyzwaniem dla zespołów IT.  

Najlepszą opcją na integrację oprogramowania jest wykorzystanie usług sieciowych. Chcąc osiągnąć integrację i przepływ danych między platformami, elastyczne usługi sieciowe muszą obsługiwać standardy protokołu SOAP (Simple Object Access Protocol) i REST (Representational State Transfer). Poprawnie wdrożona integracja powinna umożliwiać przejście z integracji opartej na plikach do integracji opartej na usługach sieciowych.

Integracja oprogramowania – jak przygotować się na to wyzwanie?

• Kluczowym aspektem, który pomoże zmitygować ryzyko wystąpienia problemów na etapie integracji oprogramowania, jest dobrze zaprojektowana architektura systemu (w oparciu o API, web serwisy, szynę danych).
• Po odpowiednim zaprojektowaniu integracji należy stworzyć specyfikację, która opisze interfejsy oraz flow przepływu danych. Bardzo ważnym aspektem jest zdefiniowanie odpowiedzialności, czyli tego, która strona odpowiada za konkretny interfejs.
• Następnym krokiem jest udostępnienie API do środowisk DEV i TEST. Istotne jest, aby API testowe zawierało właściwe dane, pokrywające wszystkie przypadki testowe. Tylko w takim przypadku możliwe jest pełne sprawdzenie integracji na środowiskach poprzedzających środowisko UAT (testy akceptacyjne) czy PROD (produkcyjne).
• Ostatnim, ale równie ważnym elementem jest dodanie testów integracyjnych do procesu CI/CD.

Wyzwanie nr 4. Jakość oprogramowania

Niska jakość oprogramowania to szereg negatywnych skutków ubocznych, co w prostej mierze przekłada się na niezadowolenie klienta. A jak wiadomo, niezadowolony klient to klient, który odmawia zapłaty lub wręcz wycofuje się z umowy i odchodzi do konkurencji. Częste wdrażanie niskiej jakości rozwiązań powoduje obniżenie lojalności klientów i ich rezygnację, a tym samym spadek wydajności firmy oraz redukcję etatów.  

Dodatkowym wyzwaniem jest fakt, że słaba jakość oprogramowania ma również swoje negatywne odbicie w produktywności programistów. Zespoły IT tworzące produkty niskiej jakości są wolniejsze, mniej zaangażowane i doświadczają więcej stresu. 

Jakość oprogramowania – jak przygotować się na to wyzwanie?

• Aby poprawić jakość oprogramowania, kluczowe jest wczesne testowanie. Wczesne testy pozwalają wyłapać drobne defekty, które w przyszłości mogłyby zamienić się w większe i bardziej skomplikowane problemy. Jest również szansa, że już na wczesnym etapie projektu uda się zauważyć poważne błędy (np. w architekturze czy integracji), których naprawa w przyszłości kosztowałyby ogromne pieniądze. Wyłapane odpowiednio wcześnie, będą kosztowały ułamek tej sumy.
• Testuj wcześnie i testuj często, dzięki automatyzacji. Testy manualne wymagają ogromnej uwagi testerów, a są niestety żmudne i powtarzalne, co naraża projekt na błędy. Efektywniejsze rozwiązanie to automatyzacja testów i włączenie ich do procesu CI/CD.
• Wdrażaj kontrolę jakości od samego początku projektu IT. Rolą testerów jest monitoring kontroli jakości, która powinna zaczynać się wraz ze startem developmentu i trwać przez cały okres dostawy. Pozwoli to zbudować wśród zespołów świadomość, że ich praca spełnia standardy, a tym samym dostarczają produkt wysokiej jakości.

Na przykładzie jednego z naszych projektów możemy pokazać, jak zmienia się koszt naprawy błędów w zależności, na jakim etapie software developmentu uda się je wykryć: 

Wyzwanie nr 5. Dług techniczny

Dług techniczny to swego rodzaju droga na skróty — jego zaciągnięcie kusi, kiedy chcemy szybko zaspokoić potrzeby biznesowe i np. wypuścić produkt na rynek przed naszą konkurencją. W ten sposób sięgamy po nieoptymalne rozwiązania techniczne, które, chociaż zaspokajają krótkoterminowe cele firmy (i czasami są uzasadnione biznesowo, jeśli np. chcemy szybko zweryfikować jakąś hipotezę), to w przyszłości mogą utrudniać (lub wręcz uniemożliwiać!) realizację planów długoterminowych. Wyzwaniem jest zrozumienie, że w obliczu długu technicznego wszystkie kolejne inwestycje w software development i usprawnienia procesów możliwe są dopiero po spłaceniu zaciągniętego zadłużenia.

Opóźnienie lub zaniechanie spłaty długu naraża nas na ryzyko:

• Wzrostu liczby błędów w kodzie i spadku bezpieczeństwa aplikacji;
• Mniejszej elastyczności oprogramowania oraz kosztownych zmian w funkcjonalnościach;
• Skupienia pracy zespołów wyłącznie wokół utrzymania systemu, bez przestrzeni na wdrażanie innowacji;
• Spowolnienia prac, eskalacji stresu i fali zwolnień wśród programistów,
• Przekraczania budżetów i terminów oraz ograniczenia konkurencyjności firmy.

Dług techniczny – jak przygotować się na to wyzwanie?

• Dług techniczny powinien być zaciągany wyłącznie po konsultacji z biznesem, a następnie na bieżąco rejestrowany; 

• Zarejestrowane pozycje to wsad do kolejnych sprintów, które muszą uwzględniać nie tylko dalszy rozwój oprogramowania, ale również spłatę długu; 
• Firma powinna zbudować proces, który pozwoli na ewidencjowanie i sukcesywne spłacanie długu; 
• Każda osoba zaangażowana w projekt IT musi być świadoma długu i procesu jego spłaty; 
• Zespół, wraz z Product Ownerem, decydują o kolejności spłaty długu, w oparciu o ustalone priorytety. 

Należy także pamiętać, że odpowiednie standardy kodowania w połączeniu z refaktoryzacją pomagają zminimalizować niebezpieczeństwo wystąpienia długu technicznego. „Małe” zmiany powinny być wprowadzane na bieżąco, a średnie i duże rejestrowane i realizowane zgodnie z priorytetami.

Podsumowanie

W powyższym tekście wyodrębniliśmy 5 przykładów powtarzalnych wyzwań projektowych, o których część developerów zapomina, a które powinny być mitygowane już od samego startu prac. Oczywiście nie są to wszystkie ryzyka — istnieje jeszcze wiele zagrożeń, przed którymi warto odpowiednio wcześnie się zabezpieczyć, a przynajmniej podjąć działania ograniczające niebezpieczeństwo. W świadomości każdego team leadera i osób decyzyjnych powinny być również takie aspekty jak choćby: obniżanie wskaźnika rotacji pracowników, zarządzanie efektywnością zespołu czy zarządzanie ryzykiem (np. pod postacią procedur lub planów na wypadek zmaterializowania się ryzyk).