Produkt "szyty" na miarę...

Metafora

Wiele firm właśnie tak mówi o swoich aplikacjach, idąc tym tropem zacząłem się przyglądać bliżej tej metaforze.
Chcąc być posiadaczem ręcznie uszytego garnituru/sukni klient udaje się do zakładu krawieckiego. Tłumaczy krawcowi jakiego rodzaju ma być to garnitur (ślubny, zwykły etc.). Klient wybiera kolor, fason i fakturę materiału. Krawiec może w tym wyborze pomóc, doradzić, a czasem zasugerować. Następnie mierzy on klienta i przystępuje do pracy.
Po jakimś czasie klient przychodzi na przymiarkę. Sprawdza czy krawiec zastosował się do jego wymagań, a następnie przymierza "wyrób". Krawiec jeżeli to konieczne nanosi poprawki, wykańcza drobiazgi, a następnie dostarcza gotowy produkt.

Analogia

Czytając książki na temat metodyk tworzenia oprogramowania mam wrażenie, że ta metafora jest bardzo prawdziwa. Z jednym małym ale...
Przychodząc do krawca wierzymy, że jest on specjalistą w swojej dziedzinie. Z reguły ufamy jego radą i sugestią, a co najważniejsze pozostawiamy mu szczegóły techniczne. Wybraliśmy tego szewca, a nie innego. Polecił nam go znajomy, który był zadowolony, więc i my powierzamy w jego ręce wykonanie naszego zamówienia.
W świecie tworzenia oprogramowania zaufanie do wykonawcy to towar dość mocno deficytowy. Nie chodzi o zaufanie do firmy jako solidnego partnera w interesach, ale do ludzi tworzących produkt jako fachowców. Klient bardzo często nie mówi jedynie czego oczekuje od produktu i jakie jego potrzeby ma on zaspakajać. Klient często (bardzo często/przeważnie) decyduje o wszystkim od kolorów począwszy, a na układzie formularzy skończywszy. Nie było by w tym nic złego, gdyby klient był ekspertem od danego typu aplikacji, ale najczęściej nie jest.
Właśnie z tego powodu, gdy przychodzimy do krawca nie mówimy mu jakim ściegiem ma szyć, czy w jaki sposób kroić materiał. Wybieramy co prawda fason, ale nie projektujemy każdej kieszeni i kołnierza. Dlaczego ? Bo na tym zna się lepiej krawiec, który uszył już setkę innych garniturów. Ma on dostateczną wiedzę i doświadczenie, więc prawdopodobnie zrobi to lepiej.

Klient ma zawszę rację

Klient najczęściej wie wszystko najlepiej, przecież to on będzie korzystał z tego systemu (być może "do końca życia"). Dlatego specjalista od ubezpieczeń może zaprojektować formularz, a Pani Krysia określić przepływ stron.
Dlaczego klient nie ufa fachowcom ? Dlaczego klient chce wykonywać pracę projektanta ?
Po pierwsze: "Bo może". Czy gdyby producent samochodów poprosił nas o współpracę w tworzeniu nowego modelu. Czy nie kusiło by nas, aby zrobić to auto pod siebie ? Pewnie tak i każdy z nas zrobił by to czysto subiektywnie. Subiektywnie w tym wypadku nie znaczy lepiej. Dla kogoś innego ten produkt może nie być tak intuicyjny i wygodny jak nam się wydaję. Jak często nowy model samochodu/telefonu zaskoczył nas bardzo użyteczną funkcją, której sami byśmy nie wymyślili ? Zaufajmy tym ludziom ! To twórcy dla których jakość ich dzieła jest często nie mniej ważna niż dla klienta.

Po drugie: "Bo to Pani Krysia będzie całe życie kożystała z tego produktu i to dla niej ten system".
Twierdzenie często nieprawdziwe, ponieważ kadra się zmienia, ludzie przychodzą i odchodzą, a produkt zostaje. Co więcej pewne przyzwyczajenia Pani Krysi mogą być niewspółdzielone przez inne osoby (np. nie miały styczności z poprzednim oprogramowaniem używanym w firmie).

Po trzecie: "Bo już mamy taki jeden system i nikt nie umie się nim posługiwać. Dodatkowo jest strasznie nieintuicyjny".
Trzeba sobie postawić pytanie, dlaczego ten system jest taki "zły" ? Czy osoby korzystające z niego zostały należycie przeszkolone ? Jeżeli nie, to lepszym rozwiązaniem jest zorganizowanie szkoleń dla pracowników, zamiast angażowanie ich w "projektowanie" aplikacji. Jeżeli tak, należy zapewnić użytkowników, że podczas fazy analizy ich potrzeby i sposób pracy zostaną dokładnie zgłębione i uwzględnione w projekcie aplikacji. Co więcej można konsultować pewne rozwiązania z "biznesem".

To chyba najpopularniejsze powody dla których klient staje się projektantem. Czasami trzeba po prostu zastanowić się co za nimi stoi i poprzez ich zrozumienie przekonać klienta do zmiany podejścia. Czasami jednak nie mamy wpływu na klienta i wtedy wszystko staje się kwestią zaufania, dlatego apeluje do "klientów" zaufajcie fachowcom (sprawdzajcie, nadzorujcie, audytujcie ale ufajcie...).

Broken Window Theory...

Teoria


Nie pamiętam już gdzie ale jakiś czas temu czytałem o "teorii rozbitej szyby". Termin ten kojarzony jest przede wszystkim z Rudolphem Giulianim burmistrzem Nowego Jorku.
Teoria ta w skrócie mówi iż jedna zbita szyba pozostawiona w budynku sprawi że będzie on dalej niszczony w dużo szybszym tempie.
Sam widziałem zastosowanie tej teorii w praktyce widując pozostawione na długie tygodnie/miesiące samochody. Gdy były "całe" nikt ich nie dewastował, wystarczyło że ktoś wybił pierwszą szybę, reflektor (i nikt go nie wymienił,nie zakleił folią szyby), a dewastacja następowała lawinowo z dnia na dzień. Milczące przyzwolenie sprawiało, że ludzie czuli się mniej odpowiedzialni, a odpowiedzialność za zniszczenie samochodu stawała się coraz bardziej rozmyta na wiele osób.


Problem


W wielu projektach w których byłem widziałem rozwiązania mało eleganckie lub wręcz sprzeczne z powszechnie przyjętymi zasadami tego rzemiosła. Gdy po krótkim dochodzeniu udawało się zlokalizować winnego ten tłumaczył się, że zrobił tak samo jak było to rozwiązane w innym miejscu. Na argument, że jest to zrobione w sposób nieprawidłowy, odpowiadał, że jemu też się to rozwiązanie nie podoba, ale przecież w innych miejscach ktoś inny też tak postąpił, więc nie wpłynie to istotnie na jakość projektu. Gdy udało się znaleźć tego kto zapoczątkował złą praktykę okazywało się, że to było rozwiązanie "tymczasowe" i "później" miało być zrobione to lepiej (lub w inny sposób tłumaczone deadline-ami). Bardzo szybko jedna zbita szyba zamieniła się w 2, potem 3 i liczba ta stale rosła. Co więcej wszyscy zaczęli narzekać na wyjątkowo niską jakość projektu, któremu "nic" już nie zaszkodzi, więc wszystkie chwyty stały się dozwolone.


Rozwiązanie ?


Sam muszę przyznać że zdarzało mi się rozwiązywać problem "łatając" coś w sposób brzydki ("skoro wszyscy tak robią"). Ale gdy ktoś zwrócił mi uwagę na pierwszą rozbita przeze mnie szybę zwykle od razu starałem się ją naprawić. Większość programistów, gdy popełnią taki błąd i zostanie im zwrócona uwaga nie jest dumna z tego faktu. Taki "winny developer" stara się jak najszybciej poprawić swój błąd/niedopatrzenie/lenistwo.
Burmistrz Giuliani zwiększył uprawnienia Policji i wypowiedział bezwzględną walkę graficiarzom, a co może zrobić architekt/lead developer/kierownik projektu ?


Myślę, że powołanie "Policji projektowej" nie jest złym pomysłem ;) Być może brzmi to śmiesznie, biurokratycznie i formalnie ale można spojrzeć na to pod innym kontem.
Policjant będzie to rola odpowiedzialna za jakość kodu. Może być nią jedna osoba lub grupa osób, może być to także funkcja "przechodnia". Policjant nie musi całymi dniami przeglądać kodu w poszukiwaniu "zbrodni". Wystarczy, że gdy przypadkiem ją zauważy nie przejdzie obok niej obojętnie. Być może przydało by się miejsce w którym takie fragmenty były by wypisywane (np. bug tracker, tablica korkowa) nawet anonimowo bez dochodzenia kto je popełnił. Osoba mając w danej chwili więcej czasu mogła by je poprawić i zdjąć z tablicy, mógłby zrobić to także sam autor widząc swoje "dzieło" na tablicy. Czy takie rozwiązanie sprawdziło by się w praktyce ? Prawdopodobnie tak, ale pewności nie mam gdyż nigdy nie widziałem jego zastosowania.
Na pewno najlepszą metodą dbania o jakoś kodu jest pisanie kody wysokiej jakości, ale jak sami widzimy różnie z tym bywa. Czasami taki błąd może być źródłem pośpiechu, niezrozumienia danego fragmentu aplikacji czy braku umiejętności. Jak pokazuje praktyka takich sytuacji uniknąć się nie da, ale to nie znaczy, że nie można z nimi walczyć.
Inną metodą przeciwdziałania są rewizje kodu. W takim podejściu każdy kawałek kodu musi zostać zaakceptowany przez innego programistę. Jest to metoda bez wątpienia bardziej skuteczna ale zarazem wymaga poświęcenia większej ilości dodatkowego czasu oraz skutecznego jej egzekwowania (np. za pomocą odpowiednich narzędzi zintegrowanych z repozytorium).