Radzenie sobie ze wzrostem zakresu i pozłacaniem w projektach oprogramowania

W przypadku projektów IT popularnym zagrożeniem jest Scope Creep (pochodzący ze strony właściciela) i Gold Plating (pochodzący od PM, Scrum Master lub programistów). Niekontrolowane zmiany w projektDodawanie nowych funkcjonalności czy wprowadzanie zmian niewątpliwie należą do zagrożeń, które wpływają zarówno na wydajność, jak i szybkość realizowanych projektów. W przeszłości mieliśmy okazję współpracować z takimi startupami i większymi korporacjami jak Livenation / Ticketmaster, Stroer czy Agora (największa grupa medialna w Europie). W tym czasie koordynowałem wiele projektów IT - szczególnie tych związanych z rozwój oprogramowania. To doświadczenie pozwoliło mi zrozumieć, że nie ma znaczenia, czy pracujesz w małej czy dużej firmie: jeśli chcesz odnieść sukces, musisz być o krok przed konkurencją.

Chciałbym podzielić się moimi spostrzeżeniami na temat skutecznego rozwoju projekty rozwoju oprogramowania. Jako CCO w Codest codziennie realizujemy projekty dla globalnych firm na całym świecie. Odpowiednie podejście do zarządzania to pierwszy kluczowy etap, który później wpływa na sukces projektu. Wyróżniam cztery podstawowe zasady, których zachowanie pozwoliło na my aby opracować naprawdę skuteczny model zarządzania. Dzięki nim unikamy późniejszych problemów - w tym tych związanych z pełzającym i złotodajnym "scope'm". Oto one:

1. Metodolog. Niezależnie od wielkości projektu czy poziomu jego zaawansowania, zawsze wdrażamy odpowiednią metodologię, która pozwoli nam zarządzać projektem w sposób zgodny z zasadami zrównoważonego rozwoju. Zwinność podejście. W tym przypadku pomaga nam metodyka Scrum. Dzięki temu mamy pod kontrolą wszystkie etapy projektu. Każdy z członków skupia się na ściśle określonych zadaniach. W ten sposób unikamy niepotrzebnego rozpraszania uwagi i utrzymujemy maksymalną efektywność pracy.

2. MVP. Można to nazwać naszą główną zasadą. Jeśli chcesz stworzyć aplikację, zrób to, ale w bardzo podstawowym zakresie. Zaoszczędzisz czas i unikniesz ryzyka wypalenia budżetu. Początkowa wizja aplikacji produkt często jest później weryfikowana i zmieniana. Klient z czasem może zmienić zdanie co do wymaganych funkcji aplikacji, co z kolei generuje niepotrzebne koszty i wydłuża pracę.

Podejście MVP sprawdza się całkiem dobrze. Tworzymy aplikację, która ma na przykład 20% wszystkich funkcjonalności, ale jest już w stanie zweryfikować swoją wartość na rynek. W ten sposób klient otrzymuje informacje zwrotne od użytkowników i wie, jakie cechy powinien mieć jego produkt, aby był skuteczny. Następnie skupiamy się na rozwoju tych elementów. Świetnym odzwierciedleniem tego procesu jest grafika załączona poniżej:

3. Testowanie. Testowanie poszczególnych funkcjonalności aplikacji jest bezpośrednio związane z MVP. Jeśli okaże się, że coś nie działa tak jak powinno, lepiej to odrzucić i poszukać alternatywnego rozwiązania. W Codest spotykaliśmy się z klientami, którzy od samego początku narzucali sobie ostateczny kształt aplikacji i byli pewni, że jest to jedyna słuszna wizja. Nie chciałbym rozwodzić się nad dalszymi skutkami takiego podejścia. Dlatego uważam za konieczne podkreślić raz jeszcze, że prostota jest kluczem do sukcesu.

4. Rozwój. Budowa aplikacji powinna rozpocząć się od UXDesign, Backend i Frontend. Krótko mówiąc, wszystko zaczyna się od prostych zadań "must have", które składają się na produkt MVP. Po osiągnięciu tej fazy rozwoju można skupić się na rozwoju funkcjonalności zwanej "nice to have".

Podsumowanie

Moim zdaniem są to cztery podstawowe zasady, które świetnie nadają się do zarządzania projektami rozwoju oprogramowania. Takie podejście zmniejsza ryzyko niepotrzebnego rozpraszania uwagi, dłuższych godzin pracy i nieefektywności kosztowej.

Na koniec podam jeszcze jeden przykład. Jakiś czas temu otrzymaliśmy specyfikację projektu od klienta. Natychmiast dołączyliśmy do zespół aby go ocenić. Klient oczekiwał, że stworzymy produkt w ciągu dwunastu miesięcy. Zgodnie z naszym podejściem zaproponowaliśmy podejście MVP i trzymiesięczny okres rozwoju. Ostatecznie udało nam się przekonać klienta. Po kilku miesiącach byli pod wrażeniem rozwiązania. Klient otrzymał działający produkt w stosunkowo krótkim czasie. W przypadku kilku funkcjonalności zdecydował się na zmianę założonego na samym początku projektu.

Model, który opisałem w tym artykule, to nasz sposób na skuteczną realizację projektów rozwoju oprogramowania. Uwierz mi, to rozwiązanie nie tylko usprawnia pracę i czyni ją efektywną, ale w efekcie pomaga uniknąć scope creep i gold plating.