Jakiś czas temu miałem kolejną przygodę:
- wykonałem pewien projekt obiecując klientowi, że przyszłe ewentualne rozbudowy i integracje będą relatywnie mało kosztowne,
- wykonawca zignorował zalecenia i projekt, przerobił model dziedziny upraszczając go mocno, normalizując (!) moje diagramy klas ukrywając to przede mną (projekt był załącznikiem do umowy),
- po pewnym czasie pojawiła się potrzeba integracji z nowym ERP,
- klient do mnie dzwoni, że wykonawca aplikacji za tę integracje żąda kwoty znacznie większej niż pierwotnie planowana,
- pytam wykonawce o uzasadnienie kosztorysu i tu odkrycie: zaimplementowany model dziedziny jest zupełnie inny niż w moim projekcie.
Gdyby zrobili zgodnie z projektem integracja była by znacznie tańsza (co sami przyznali) a teraz czeka tę firmę alternatywa: kara za wykonanie zmian w projekcie poza umową, praca poniżej kosztów, wszyscy się chandryczą bo czas ucieka…. Po drugie wykonawca, który składając ofertę zaakceptował projekt (wymagania) a potem neguje treść tego projektu … kim jest?
Dlatego w chwili wolnego czasu polecam dyskusję na GL, gdzie napisałem prośbę do programistów:
Jak dostajecie wyniki obiektowej analizy “świata rzeczywistego” to nie zamieniajcie jej, nie upraszczajcie itp. tylko przyjmijcie z pokorą model tego świata bo języki obiektowe powstały po to by Wam to ułatwić a nie nie po to by zmienić paradygmat. Zawsze możecie zapytać autora jaki maił w tym cel i omówić to.
Jak piszecie kod, którego celem jest szyfrowanie transmisji, renderowanie obrazków itp. to róbcie to jak najlepiej potraficie ale jak implementujecie model dziedziny, czyli logikę biznesową, to dajcie mu spokój, to nie Wasz problem, po protu skopiujcie go, a jak Wasz analityk nie potrafi Wam dać takiego modelu obiektowego to zmieńcie analityka…
Zalecenie dla zamawiających: zawsze patrz na ręce wykonawcy… ten nieuczciwy wykonawca miał małego pecha bo miałem aktywną umowę na nadzór autorski. A na poprawę humoru:
Bo wykonawca zawsze wie lepiej 🙂 skad ja to znam.
wykonawcy zawsze muszą dawać upust swoich “kompetencji” – dla mnie o wiele gorszą sytuacją (ponieważ zdecydowanie częściej mam z tym do czynienia)jest to, kiedy programista robi po swojemu funkcjonalności niezależnie od grafik, wireframe’ów, diagramów i zaleceń, bo jego zdaniem “to będzie lepiej wyglądało” i “to bardziej się spodoba”.
a klient na pytanie dlaczego sie na to zgodził odpowiada “bo wykonawca mówił, że tak będzie lepiej”. porażka 😉
Moja znajoma, dziennikarka, nazywa to: “bo czasem jest tak, że ktoś uważa, że jest mądrzejszy od radia” 🙂 , niestety krzywdę robią sobie klienci, którzy najpierw płacą za kompetencje analityka a potem ignorują efekty jego pracy, zawierzając komuś, kto ma inny cel on sam. Na szczęście czasami dobra umowa (jak ta tu opisana) chroni takich klientów przed nimi samymi…:) i chyba czasami o to właśnie chodzi w pracy z dobrym analitykiem.