Z miesiąc temu wziąłem sobie z biurowej biblioteczki na weekend książkę Rapid Development. Zrobiła na mnie wrażenie tak wielkie, że aż postanowiłem opublikować notatki powstające podczas jej lektury.
Książka kierowana jest głównie do team leaderów (czyli od kilku tygodni – do mnie;)). Z pewnością jednak każda osoba zaangażowana w tworzenie projektów informatycznych znajdzie tam coś dla siebie.
Steve McConnell rozpoczyna naszą podróż do świata “racjonalnego IT” wytłumaczeniem pojęcia “Rapid Development”. Definicja jest prosta – zawsze chodzi po prostu o zrealizowanie projektu szybciej. Dla jednej organizacji będzie to 2 lata – jeśli przez ostatnie 5 nie udało jej się zrobić NIC. Dla innej – pół roku, jeśli do tej pory jej cykl wydawania kolejnych wersji trwał rok. I tak dalej… Zrobić COŚ szybciej. Szybciej – i lepiej, bo przez całą książkę autor wielką wagę przywiązuje do jakości tworzonego oprogramowania, niejednokrotnie szokując badaniami prezentującymi koszt zaniedbań jakości, wracających wkrótce w postaci 100-krotnie droższych do naprawy problemów.
Kolejna część książki prezentuje listę najczęściej popełnianych błędów podczas realizacji projektów informatycznych. Błędy podzielono na cztery kategorie: ludzkie (managera/programisty), procesu (metodyki), produktu (wymagań klienta) oraz technologiczne (narzędzi). Lista jest dość imponująca. Co prawda po pierwszym rzucie oka każdy może powiedzieć “no ale ja przecież bym nigdy…..”, jednak na jakiejś podstawie ta lista powstała.
Pozycje w niej zawarte znajdziecie na devBlogach, w poście Ucieczka z Wyspy Gilligana (tłumaczenie tekstu Jeffa Atwooda).
Po przetrawieniu najczęściej popełnianych błędów nadeszła pora na zapoznanie się z, parafrazując Jarosława, “podstawowymi podstawami” obowiązków głównych członków zespołu: programistów i leadów/managerów. Podstawy te niby powinny być “oczywistymi oczywistościami” – jak np. ciągłe dbanie o własny rozwój – jednak często-gęsto firmy świadomie ignorują takie kwestie, bo one “wymagają czasu”. Czasu, który można przeznaczyć na klepanie w klawiaturę.
Właściwie przez całą książkę non stop napotykałem bardzo ważne i mądre rozdziały. Genialnym ich uzupełnieniem były perfekcyjnie dobrane do kontekstu case-studies – czyli opisy sytuacji z życia wziętych, w których główny nacisk kładziono szczególnie na poruszaną właśnie problematykę. Szczególnie przypadły mi do gustu historie o estymacji i planowaniu – momentami aż pięści mi się zaciskały, gdy wczuwałem się w rolę biedaków przedstawionych w tych sekcjach:).
Dalej w temacie estymacji – spodobało mi się dokładne wyjaśnienie pojęć “precyzja” i “trafność” (precision, accuracy). Bardzo precyzyjne przedstawienie terminu realizacji (“dostarczymy system za 37 tygodni”) może być szpanerskie i wyglądać “PRO” dla niezorientowanych w temacie klientów, jednak niewiele ma wspólnego z rzeczywistością. Po prostu NIE DA się tak dokładnie tego przewidzieć i na dłuższą metę szkodzi to projektowi. O wiele lepsze jest podanie szacunków realnych na danym etapie prac. Na przykład stwierdzenie “implementacja systemu zajmie od 6 do 9 miesięcy” jest najdokładniejszą możliwą TRAFNĄ deklaracją przed fazą szczegółowej analizy wymagań, mimo że nie jest precyzyjna. Następnie co jakiś czas estymacje te można konsekwentnie zawężać. Mądry klient powinien takie podejście docenić. Klient niedoświadczony będzie preferował podanie dokładnej daty zakończenia prac już na pierwszym etapie rozmów o projekcie, i na tej podstawie zaplanuje dalsze działania. A potem, im bliżej tej daty, będzie wszystkie plany w locie przeorganizowywał – bo oczywiście projekt się przesunie.
Podano też przykłady dialogów, które można prowadzić z klientem (czy to zewnętrzny zleceniodawca, czy szef, czy dział marketingu), aby w grzeczny sposób uświadomić mu, że nie ma do końca kompetencji aby z góry narzucać swoje sztywne terminy, jednocześnie nalegając na niezmienny budżet oraz zakres funkcjonalności. Takie podejście jest bardzo szkodliwe, i im szybciej się to wyjaśni tym lepiej. Na pewno nie można obiecywać gruszek na wierzbie, a po kilku miesiącach raz po raz przesuwać premierę produktu tylko dlatego, że na początku nie mieliśmy jaj aby mówić coś innego niż “tak, panie, tak, panie, tak, panie“.
Mnie szczególnie interesowały kwestie, które od niedawna wchodzą w skład moich obowiązków. Chyba najciekawszy z tych tematów to motywacja programistów – i jak można tą motywację podwyższać środkami innymi niż zastrzyk kasy. Teoretycznie jako programista powinienem wiedzieć wszystko na ten temat, ale mimo to ciekawie czytało się o tym mając przed sobą cały rozdział napisany w usystematyzowany, profesjonalny sposób. Co mogę jako team leader, a czego mi nie wolno? Sam dopiero się w całej sytuacji odnajduję, i taka lektura pozwoli mi, mam nadzieję, rozpocząć tą przygodę podążając od razu w dobrym kierunku. Ale o motywacji w kontekście mojego “dev-leadowania” skrobnę chyba jeszcze osobnego posta.
O motywację zahacza też bardziej ogólne pojęcie “pracy zespołowej”. Poczytać można m.in. rozważania o różnicy pracy w grupie a pracy zespołowej oraz różnych sposobów organizacji współpracy, w rezultacie generujących różne typy zespołów. Zebrać do kupy grupę ludzi i kazać im coś robić jest łatwo. Ale zbudować prawdziwy zespół to już zupełnie inna para kaloszy, wymagająca nie lada wysiłku ze strony “budowniczego”.
W książce kilkukrotnie pojawiło się pojęcie “voluntary overtime”, czyli “nadgodziny z własnej woli”:). Moje poglądy na ten temat są od lat niezmienne i bardzo radykalne: po prostu nie uznaję czegoś takiego jak nadgodziny. Oczywiście trochę inaczej wyglądało to, gdy pracowałem na etacie, a inaczej, gdy parałem się freelancerką, ale w uproszczeniu uważam, że coś takiego jak “praca po godzinach” w ogóle nie powinno istnieć. Rolą i zadaniem PMa lub leada jest wynegocjowanie takich terminów i taka organizacja pracy, żeby zespół mógł zrealizować zadania w normalnym wymiarze godzin, a nie siedząc nocami czy weekendami i zaniedbując wszelkie inne aspekty życia poza pracą.
Dopiero pod koniec książki w pełni zrozumiałem pogląd i rekomendacje autora na ten temat. Po przeczytaniu całego rozdziału poświęconemu pracy po godzinach pojawiło mi się w głowie sporo refleksji i spostrzeżeń. Najważniejsze z nich to: “przecież nie uznaję nadgodzin, a mimo to w obecnej firmie średnio co drugi dzień albo pracuję trochę dłużej niż “powinienem”, albo zajmuję się czymś “pracowym” przez jakiś czas wieczorem i… nie mam z tym problemu!”. Dziwne, ale dopiero teraz zwróciłem na to uwagę. Chyba jednak nic nie jest po prostu czarno-białe. Ale to chyba też temat na specjalną notkę, bo skądś się to w końcu bierze.
Sporą część książki pominąłem (ok 60% tylko przejrzałem). Trzeba pamiętać, że książka została wydana w 1996 roku, więc dobre 4 czy 5 lat przed zdefiniowaniem metodyk “agile”. Swego czasu mocno się takimi kwestiami interesowałem, więc darowałem sobie rozdziały o pracy z klientem czy iteracyjnym sposobie realizacji projektów.
Narodziło się też spostrzeżenie: z jednej strony, jako branża, poszliśmy bardzo do przodu. Kilka z przedstawianych w książce problemów po prostu przestało istnieć – jak chociażby kwestia wersjonowania kodu. Z drugiej strony jednak – bardzo wiele case studies z pewnością opisuje rzeczywistość w niejednej teraźniejszej firmie, co bardzo smutne. Narzędzia zmienić łatwiej niż ludzi. I nauka na błędach wcale taka oczywista nie jest.
Książka zawiera masę tabelek i danych opisujących projekty informatyczne z tamtych lat. A to średni czas ich realizacji, a to “procentaż” przedsięwzięć zakończonych powodzeniem etc… Z wielką chęcią zobaczyłbym ich aktualizację z ostatnich lat – w epoce Javy, .NET, języków dynamicznych, ale też innego, “zwinnego”, podejścia do tworzenia systemów. Ciekawe jak bardzo coś się tu zmieniło? Czy idziemy do przodu – a jeśli tak to w jakim tempie?
Poza przedstawionymi przeze mnie pobieżnie tematami Steve McConnell w niezwykle interesujący sposób porusza ogromną wprost liczbę kwestii związanych z procesem wytwarzania oprogramowania.
Książkę polecam dosłownie wszystkim z branży. Programiści być może nie znajdą w codziennym życiu zbyt wiele okazji do zastosowania tego w praktyce, ale do poczytania i ewentualnego wyjścia w firmie z jakąś inicjatywą – bardzo ciekawe. Zgodnie z zapowiedzią autora faktycznie najwięcej wynieść z niej mogą chyba team leaderzy (szczególnie początkujący, jak ja). Ale z pewnością większości obecnych w naszych realiach menażerów, kierowników, “osób decyzyjnych” przydałoby się czasami buchnięcie taką 650-stronicową cegłą w łeb i błagalne zawołanie o opamiętanie. W tej książce jasno opisano sytuacje spotykane w bardzo wielu firmach, i są to przykłady nazwane wprost, bez owijania w bawełnę, scenariuszami ZŁYMI. A za krytyką idzie argumentacja, z którą bardzo ciężko jest się sprzeczać.
Podobne zagadnienia (choć pewnie nie aż tak obszernie) porusza następująca pozycja:
http://helion.pl/ksiazki/sprzedaj-swoj-program-droga-do-udanych-projektow-programistycznych-jared-r-richardson-william-a-gwaltney-jr,sprogr.htm
Takie przynajmniej odniosłem wrażenie czytając powyższy wpis, tak jakbym już gdzieś to czytał ;).
Natomiast ciekawią mnie Twoje wnioski odnośnie estymacji w kontekście teoria – praktyka. Osobiście uważam, że zieje ogromna przepaść pomiędzy tym co napisane jest w książkach, a tym co przynosi rzeczywistość. Powiedzenie, że coś może zająć 6 do 9 miesięcy, to jednoczesne stwierdzenie, że koszty mogą być 1.5 raza większe (albo o 1/3 mniejsze – zależy z której strony patrzeć). Niemniej klient, który oczekuje kosztów nie będzie opierał się na "widełkach". Co więcej, z tych "widełek" i tak w świadomości klienta istnieje tylko da dolna kwota. I ciężko mu potem przyjąć do świadomości, że to jednak będzie ta górna (albo prawie górna). Zaczyna podejrzewać próbę naciągnięcia.
A do tego dochodzi jeszcze problem z realnym oszacowaniem czasu, skoro wiadomo (Agile), że nie da się z góry ustalić ile rzeczywiście czasu zajmie realizacja projektu, można najwyżej oszacować ile czasu zajmie pierwsza iteracja. A klienta nie obchodzą iteracje, obchodzi go ile to będzie kosztowało.
PaSkol,
Pewnie sporo książek na ten temat napisano, ja czytałem tylko tą:).
Co do estymacji – to przemyśleń mam sporo, ale prawdopodobnie ubiorę je pewnie w osobnego posta, tak na szybko, dodatkowo z gorączką, nic składnego mi nie wyjdzie:). Z jednej strony – zgadzam się, że klient może nie "docenić" takiego podejścia. Z drugiej strony – klient z założenia nie ma pojęcia o tworzeniu projektów i naszym zadaniem jest przekonanie go, że to my mamy rację. Przykład z książki: gdy klient idzie do lekarza, lekarz diagnozuje raka, to klient robi to co lekarz mówi, a nie odwrotnie. Bo to lekarz wie jak sobie z takim rakiem poradzić. Wszystko to kwestia sensownej argumentacji ("czy wolisz, żebym w tej chwili powiedział Ci dokładnie kiedy dostaniesz działające rozwiązanie, a potem będziesz gasić pożar, czy też może lepiej współpracować tak, aby wspólnie każdą sytuację na bieżąco kontrolować?").
Ale – więcej kiedy indziej:). Szczególnie jeśli chodzi o stronę finansową, bo to faktycznie może być problem.
Ok. Poczekam (choć sam też gorączkuję, to w tej kwestii nie będę ;) ). A w tzw. międzyczasie podumaj trochę nad taką sytuacją, że klient zamawia u Ciebie aplikację (np. kiosk informacyjny). I oczekuje ściśle określonych kosztów, bo nie jesteś jedynym, do którego wysłał zapytanie ofertowe, a koszt jest dla niego głównym kryterium. Wróć. Precyzyjniej. Chce wydusić jak najwięcej za jak najmniejszą cenę. I on nie chce się leczyć, on chce zaspokojenia swoich potrzeb, na szali jest tylko jego kasa, a nie jego życie (to jest właśnie – ta analogia – to, co napisałem wcześniej – przepaść pomiędzy teorią, a praktyką; górnolotne metafory, w których ulatuje sedno).
I cały czas pamiętaj, że jeśli się przestrzelisz, to albo klient zrezygnuje, albo Ty będziesz to robił po kosztach lub poniżej :\. A zlecenie by się przydało.
PaSkol,
Takie sytuacje znam z doświadczenia i są całkowicie naturalne. Tak jak napisałem – moim zdaniem zadaniem zleceniobiorcy jest odpowiednie zaprezentowanie się potencjalnemu klientowi. Nie będę zaniżał stawki tylko dlatego że pewnie ktoś inny zaoferuje zrobienie systemu za mniej niż ja. Jeśli klient już na tym etapie odrzuca wszelkie uwagi/sugestie i jest najmądrzejszy na świecie to prawdopodobnie zrezygnowanie ze współpracy będzie najlepszym rozwiązaniem – zaoszczędzi masy stresu później.
Nie rozumiemy się. Masz zachować swoją stawkę, a klient niczego nie odrzuca, bo go to w ogóle nie obchodzi. Zgłosił się do Ciebie z zapytaniem ofertowym, w którym określił, że potrzebna jest mu aplikacja do tzw. kiosku informacyjnego, który będzie sobie stał w jego sklepach. Kiosk ma pomagać klientom w poznaniu szczegółów dotyczących oferowanego asortymentu, z naciskiem na promowanie dodatkowych produktów, które można korzystnie zakupić, jeśli weźmie się właśnie obecnie sprawdzany produkt (za pomocą czytnika kodów kreskowych). Kiosk ma informować o cenie sprawdzanego produktu, jego unikalnych cechach, związanych z nim promocjach.
No to ile by to kosztowało?
Drugim przykładem może być nowo powstająca sieć hipermarketów, która chce mieć system obsługi sprzedaży zgodny z profilem jej działalności (będzie taki samy jak Tesco, Auchan, Carrefour) i pyta ile to będzie kosztować.
W obu przykładach klient na oprogramowanie oczekuje podania kwoty, bo musi ocenić czy stać go na taką inwestycję. A Ty na jej określenie masz tylko to, co podano wyżej. Możesz prosić o dodatkowe informacje i zostaną Ci one dostarczone, ale w pewnym momencie musisz coś zaproponować, a jak wiemy nie ma takiego momentu (po to wymyślono iteracje), w którym masz pewne chociaż 50% kształtu aplikacji. Więc wszystko co powiesz jest pisane palcem na wodzie.
PaSkol,
W scenariuszu idealnym: tak jak napisałem wyżej – określam że to będzie kosztować od…do, i zajmie od X do Y miesięcy/tygodni. Podkreślam że na chwilę obecną dokładniejszego szacunku nie podam.
Koniec.
W życiu: szacunki mam dla siebie, klient dostaje górne granice zarówno czasowe jak i kosztowe.
Słyszałem już dobrą opinię o tej książce od znajomego i już niedługo sam się wezmę za lekturę. Tak po prostu w ramach rozwoju, nie jestem team leaderem, ale widzę, że książka i tak może mnie nauczyć niezmiernie wiele rzeczy.