Zapraszam do dyskusji o wycenach projektów webowych i o testowaniu
0
0
Z kasowaniem szmalu za zrobienie specyfikacji to ciekawy pomysł. W zasadzie wydaje mi się to całkiem naturalne w przypadku bardziej złożonych specyfikacji. Akurat firmowe witryny www w miarę często tworzy się z podobnych modułów, ponieważ firmy mają podobne potrzeby (ewentualnie: nie stać ich na to, by ktoś zrobił im wiele wyspecjalizowanych modułów). Specyfikacje do takich modułów jak newsy, galeria czy kontakt (z formularzem) można mieć gotowe i sprawdzone w praniu na wielu klientach. Nie wydawało mi się niezbędne żądanie zapłaty za specyfikację, która w większości i tak składała się z gotowych klocków.
Z drugiej strony: za każdą pracę klient powinien płacić. Jak nie jawnie, to w sposób ukryty. Bo liczymy sobie -- albo chociaż szacujemy metodą "na pałę" -- ile czasu poświęcamy na te niby-darmowe specyfikacje i jak często przygotujemy specyfikację, a nie wykonamy projektu (a więc nie dostaniemy za projekt pieniędzy). I ten cały poświęcony czas, tak samo jak ryzyko utraty projektu, są wliczone w stawkę godzinową za wykonywanie projektu. Naturalnie, nie musi być to wliczone jawnie.
Czy więc nie byłoby uczciwiej po prostu mówić, co ile kosztuje? A nie ściemniać, że COKOLWIEK zrobimy za darmo? W ten sposób klient nigdy nie byłby stratny. Zawsze zapłaciłby dokładnie za to, co dla niego zrobiliśmy i miałby te koszty jawnie wypisane na rachunku. Nie płaciłby za swoją "darmową" specyfikację przy okazji rozliczania się za wykonanie projektu; nie płaciłby za "darmowe" specyfikacje dla innych klientów, którzy po otrzymaniu specyfikacji zrezygnowali ze współpracy.
Inna sprawa jest taka, że nie zawsze taka uczciwość musi popłacać. Być może lepiej, gdy klientowi wydaje się, że coś ma za darmo. A że potem liczymy mu stawkę godzinową np. 50 zł zamiast 40 zł -- to może psychologicznie być dla niego po prostu niezauważalne.
Pomysł płacenia za każdą specyfikację wydaje mi się jednak ciekawy i wart rozważenia. Płacenie za czasochłonne do wykonania specyfikacje wydaje mi się całkiem naturalne, choć te koszta też można jakoś ukryć. Zauważ proszę, że w wielu (wszystkich? niemal?) firmach klient dostaje tylko koszt wykonania całego projektu. Nie ma wyszczególnionego, że programista spędził nad projektem X godzin, a PM Y godzin. Tymczasem połowa pracy, jaką wykonał PM, mogła dotyczyć tworzenia specyfikacji.
A co do testowania...
To, co niektórzy mówią, że "nie mają czasu na testy" jest zwykle -- za jednym zamachem -- bzdurą oraz strzałem w stopę (który odstrzeliwuje nam obie nogi na wysokości... szyi). Kod z testami, szczególnie ten bardziej skomplikowany, jest na ogół DOSTARCZANY szybciej niż kod bez testów. Przy czym za "dostarczenie" uważam jego wdrożenie gdy kod robi całkiem sprawnie to, co powinien. W tym momencie nie ma już "jeszcze jednej małej rzeczy do dodania" i "jednego małego bugu do poprawienia". Z reguły osiągniesz to stadium szybciej z testami niż bez testów.
Być może problem z przekonaniem ludzi do testów nie leży po stronie klienta, tylko... ludzi stojących nad programistami.
O testach klient nie musi przecież wiedzieć. Klient chce mieć DOSTARCZONY w terminie, działający program. Niech firma produkująca kod zastosuje metody, które to zapewnią. Jestem przekonany, że w tych metodach swoje miejsce powinny mieć również automatyczne testy. To po prostu jedno z narzędzi, troszkę podobnie jak np. edytor kodu. Klient nie jest od tego, by mówić koderom, w jakim edytorze (a czasem nawet: w jakim języku!) mają pisać kod i czy mają spamować zmiennymi globalnymi, czy też powinni zastosować hermetyzację oraz dbać o ortogonalność kodu.
Niech czas pisania testów będzie po prostu wliczony do czasu pisania kodu. Przecież tak czy siak, choćby szacując tempo pisania kodu, uwzględnia się również debugowanie. Dzięki testom tego debugowania (i sympatycznego, acz niesławnego: print "dupa") jest po prostu mniej. Zamiast ślęczeć godzinę nad szperaniem po wszystkich modułach i szukaniem buga, który powoduje, że "coś nie działa", poświęcamy tę godzinę na napisanie testów i zapewnienie ich przechodzenia. Odnoszę wrażenie, że to nawet nie jest 1:1. Gdy aplikacja robi się złożona, to debugowanie zajmuje więcej czasu niż pokrycie kodu testami. Ale nawet licząc 1:1, nawet uwzględniając, że dzięki testom nie zaoszczędzimy czasu, to przynajmniej po skończeniu projektu będzie dodatkowy efekt naszej pracy: zestaw testów. Ten zielony paseczek z napisem "OK" i pokrycie kodu testami dają większą pewność, że nie wywali nam się jakiś bug, niż pokonanie w czasie trwania projektu np. kilkudziesięciu bugów.
Jeśli firmy produkujące kod będą zdawały sobie z tego sprawę, to testy po prostu będą pisane -- obojętnie czy klient będzie miał za to osobną pozycję na rachunku, czy nie.
Na koniec ze smutkiem dodam, że w branży webowej testów automatycznych wydaje się być jakby mniej niż w innych branżach. U nas w ogóle toleruje się bylejakość. Może dlatego, że łatwo dostępni są początkujący programiści-amatorzy, którzy zrobią coś byle jak, wezmą za to 4x mniej pieniędzy i może nawet będzie to działało... trochę. Gdy w firmie masz profesjonalnych, ogarniętych programistów, dla których fakt nauczenia się frameworka czy konkretnego języka jest w sumie najmniej ważny, a najbardziej liczą się pewne uniwersalne zasady tworzenia dobrego kodu (włącznie z bezpieczeństwem, optymalizacją wydajnościową/semantyczną etc.), to już należysz u nas w zasadzie do elity. Nawet gdy olewasz testy i w sumie Twój kod wcale nie jest taki dobry, jak powinien być. Po prostu jest mniej gówniany niż kod 95% innych twórców.
I tym optymistycznym akcentem...