Pewnie niejednokrotnie Twój Project Manager wrzucił Ci pseudo wymagania w postaci jakiejś notatki ze spotkania lub spisanych na kolanie wymagań i zapytał wprost: ile zajmie implementacja tego projektu? Ileż różnych frustracji przeżywałem na początku swojej kariery programistycznej dostając tego typu zadania. Na usta cisnęły się słowa – Chłopie, skąd ja mam wiedzieć? Jak wiele razy niedoszacowałem projektu i pod koniec developmetu okazywało się, że jesteśmy pod wodą z budżetem. Lata prób i błędów pozwoliły mi wypracować własną metodykę estymowania projektów. Poniżej kilka punktów, na które chciałbym zwrócić uwagę.
Dekompozycja projektu
Pierwszym i najważniejszym elementem dobrej wyceny jest dekompozycja projektu. Podział projektu na mniejsze składowe pozwala na przyjrzenie się poszczególnym zadaniom. Ważne jest, by jedno zadanie nie przekraczało tygodnia pracy jednego programisty. Jeśli zadanie jest dłuższe – oznacza to, że da się to jeszcze bardziej „rozdrobnić”. Pozostaje pytanie: czy powinniśmy dekomponować wymagania biznesowe, czy też tworzyć własne (techniczne) wymagania, które później zostaną zmapowane na wymagania biznesowe. W swojej pracy zawodowej próbowałem obydwu podejść. Drugi sposób jest czytelniejszy dla programistów, pierwszy natomiast – dla biznesu. Aktualnie swoje wyceny opieram na wymaganiach biznesowych dekomponując je na mniejsze składowe. W końcu to biznes płaci za projekt i chce dokładnie wiedzieć za co płaci. W przypadku, gdy w zadaniu jest ukryte niefunkcjonalne wymaganie techniczne – piszę to jako komentarz do danego wymagania.
Zespół
Nie wyobrażam sobie próby wyceny projektu nie znając zespołu, który będzie go realizował. Programiści są różni i mają różne preferencje – jedni wolą tworzyć frontend, inni dobrze czują się modelując „user stories”, jeszcze inni uwielbiają optymalizować zapytania SQL. W momencie, gdy rozpoczynam wycenę praktycznie wiem, która osoba w zespole będzie realizowała dane wymaganie. Widząc zadanie i przypisując do niego developera w precyzyjny sposób mogę określić czas jego realizacji.
Planning poker
Kolejną ciekawą metodyką wyceniania projektów jest planning poker. W praktyce wykorzystuję jedynie fragmenty tego podejścia, tzn. zbieram swój zespół (lub podpytuję indywidualnie) i proszę o podanie czasu realizacji danego zadania. Następnie konfrontujemy ze sobą wycenę dyskutując o detalach, co w danym zadaniu należy zrobić. Tego typu dyskusje bardzo często otwierają mi oczy na szereg szczegółów, których jako architekt nie dostrzegam.
Mnożnik
Ciekawym, ale bardzo skutecznym podejściem jest ustalenie tzw. mnożnika. Kiedyś, jako młody developer, zostałem poproszony o wycenienie dość dużego projektu. Nie mając pojęcia jak to zrobić zapytałem swego Project Managera. Odpowiedź była krótka: pomyśl na oko ile Ci zajmie i następnie dorzuć 30%. W pierwszej chwili się roześmiałem – ja młody inżynier mam wykorzystywać tak trywialne podejście i tak bardzo naiwne? Po wielu latach widzę, że ma to olbrzymi sens. W tych tajemniczych 30% są ukryte wymagania niefunkcjonalne, błędy szacowania, czas potrzebny na upgrade’y, etc. Nie dodając bufora na tego typu elementy – prawdopodobnie utopimy projekt.
Wymagania niefunkcjonalne
Podczas zbierania wymagań bieznesowych bardzo często zapominamy o tym, że oprogramowanie to nie tylko formatka do wprowadzania danych lub zbiór reguł biznesowych, które dla zadanych warunków wejściowych dają wynik. Oprogramowanie to jest produkt, który musi spełniać ostre kryteria końcówych użytkowników jak również Klientów. Jakie to wymagania?
- Niezawodność i dostępność – umowy utrzymaniowe często mają określony współczynnik dostępności, np. 99%. Dobrze zaprojektowany system oraz sposób wykonywania aktualizacji pozawala na utrzymanie określonego współczynnika. Wyceniając projekt musimy przyjąć pewne założenia odnośnie polityki upgrade’ów, architektury serwerów, itd.
- Bezpieczeństwo – w tym wymagniu nie chodzi mi tylko o autentykację i autoryzację. Podczas planowania budżetu należy się pochylić nad oszacowaniem audytu bezpieczeństwa w oparciu o Open Web Application Security Project (OWASP).
- Wydajność – jakże trudne zagadnienie, gdy myślimy o portalach lub systemach Big Data. Chyba każdy developer zderzył się z problemem wydajności. Analiza tego typu zgłoszeń jest czasochłonna. Warto na początku planowania projektu wziąć pod uwagę ten aspekt i zarezerwować budżet na testy wydajnościowe, audyt, czy też czas na ewentualne „strojenie” aplikacji.
- Skalowalność projektu – każdy projekt można zrealizować „na pałę” tworząc działający kod, ale kompletnie nierozszerzalny. Możemy napisać 10 if’ów w jednej metodzie i gdy przyjdzie nowe wymaganie – dołożyć kolejne. Na koniec wszystko otoczyć klauzulą try i catch łapiąc wszystkie wyjątki i wrzucając informację do logów. Brzmi komicznie? Niestety rzeczywistość jest brutalna i nawet w ostatnich dniach widziałem taki kod. Powód? W większości przypadków terminy i Project Manager stojący nad głową i tupiący z niepokojem nogą, że czas kończyć dany ticket. Ogromną rolą architekta jest zarezerwowanie czasu na poprawę architektury, refaktoring kodu czy być może pokazanie wzorców projektowych dla konkretnego problemu.
- Monitoring – system nie kończy działania w momencie uruchomienia go na produkcji. Oprogramowanie musi być monitorowane przez cały czas działania. Musimy wiedzieć co robi system, gdy my śpimy. Już w momencie wyceniania projektu powinniśmy mieć za plecami pomysł, jak dany komponent monitorować, jak napisać „health check” czy też jakie informacje wrzucić do logów aplikacji. Tego typu taski nie robią się same. Również musimy przewidzieć zasoby finansowe na implementację monitoringów.
- Zarządzanie konfiguracją – w skrócie: „dziwne, u mnie działa”. Programista tworząc dany moduł często zapomina o tym, że nasza aplikacja będzie wdrażana w różnych miejscach – czy to na produkcji, na środowisku UAT czy może na środowisku integracyjnym. Niezmiernie ważnym elementem architektury jest takie opracowanie naszego oprogramowania, w którym konfiguracja jest poza aplikacją. Mogą to być zewnętrzne pliki properties, być może definicja kontekstowa, a może dedykowany serwer konfiguracji.
- Dane audytowe – czyli śledzenie użytkowników. Jeśli miałeś przyjemność utrzymywać aplikację to wiesz dobrze, jak trudno jest zreprodukować błąd i znaleźć sytuację, w której to następuje. Audyt log jest często ostatnią deską ratunku. Warto o tym pamiętać już na starcie projektu.
- i18n (internationalization) oraz L10n (localisation) to kolejny istotny aspekt. Oprogramowanie, które dostarczamy często powinno być dostępne w wielu językach. Co więcej, Klienci wymagają by samo rozpoznawało kraj, z którego pochodzi użytkownik i serwowało odpowiedni język.
Bugfixing
Nie znam developera, który nie popełnia błędów. Natomiast znam charakterystykę swoich poprzednich projektów. Po każdym projekcie tworzę statystykę zgłoszeń, które były re-open oraz mierzę czas zalogowany w poprawianie bugów. Pozwala mi to oszacować procent czasu, który poświęcamy na bugfixing w stosunku do oryginalej estymacji projektu. Taka wiedza w bezpośredni sposób może być przelana na nasz szablon ofertowy.
Wyczucie klienta
Inaczej robi się wyceny dla sektora publicznego, gdzie wszystko musi być sformalizowane i w wielu przypadkach zamawiający nie ma pojęcia, co zostało napisane w dokumentach ofertowych. Potrafi jedynie dostrzec kwotę oraz termin realizacji. W zupełnie inny sposób powinniśmy podchodzić do świadomego Klienta, który jest ekspertem w swojej branży i dokładnie wie jak ma wyglądać system. My, programiści, bardzo często musimy się uczyć danej branży i nie zawsze wszystko wiemy i rozumiemy. W zależności więc, czy tworzymy oprogramowanie „na wagę”, czy też dostarczamy oprogramowanie dla świadomych Klientów musimy ich wyczuć i wyekstrahować ryzyka dodając pewien bufor na zmianę wymagań czy ich uszczegółowienie.
Rejestr ograniczeń
Dobry, doświadczony architekt podczas ofertowania powinien umieć „zamknąć” wymagania. Oznacza to tyle, że poszczególne wymaganie powinno być opisane w taki sposób, by nie pozostawiało pola do popisu dla Zamawiającego. W przypadku, gdy Zamawiający zmienia zdanie – łatwo możemy wrócić do oferty pokazując zmianę wymagań i sprzedając to jako Change request.
3 x Praktyka
W tym punkcie zasmucę młodych adeptów sztuki programistycznej. Lata praktyki pozwalają na stworzenie dobrej wyceny, z którą czujemy się bezpiecznie podczas realizacji projektu. Niestety trzeba kilka razy się sparzyć, by w końcowym efekcie być jak Mistrz Jedi Yoda. Powodzenia!
PS. Powyższy temat został przedstawiony z punktu widzenia architekta. Jeśli jesteś Project Managerem to zauważyłeś, że to tylko fragment całościowej wyceny projektu. Jesteś w stanie dodać kolejne 10 punktów, takich jak testy, czas potrzebny na analizę, czas zarządzania, itd. Celowo pominąłem te punkty z prostego powodu – jestem architektem 🙂
