Ciekawe jest to, że dostawcy i wykonawcy oprogramowania często zawyżają wartość swoich usług w zasadzie na życzenie zamawiających. Robią nie ze złej woli, robią to bo zamawiający niejako sami o to proszą. Dyskutuję przy okazji projektów z wieloma programistami, projektantami, wdrożeniowcami i prawie wszyscy mówią jedno: to zamawiający ma określić swoje wymagania, jeśli określi jej zbyt ogólnikowo musimy w ofercie założyć margines bezpieczeństwa kosztów na wszelkie zmiany i uściślenia jakie klient najprawdopodobniej wniesie podczas realizacji tak słabo udokumentowanego projektu. Korekty będą na pewno bo na podstawie “jednej strony” opisu wymagań nie da się stworzyć miarodajnego projektu, twórca oprogramowania będzie więc gdybał na koszt zamawiającego. To z tego powodu, moim zdaniem, popularne są metody odkrywania wymagań poprzez kolejne prototypy. Programista sam nie określi wymagań ale będzie żądał pieniędzy za te prototypy no bo przecież nie będzie dopłacał do swoich usług.

Czy tu ktoś kogoś naciąga? Absolutnie nie! Albo inaczej: taki ?oszczędny? zamawiający naciąga sam siebie…

Zapytałem na tym forum: kto więc ma określić wymagania na oprogramowanie czy serwis WWW? Padła zgodna odpowiedź: zamawiający. A jak nie potrafi? To niech sobie kogoś do tego wynajmie. Padło także inne ciekawe stwierdzenie: wykonanie kosztorysu i harmonogramu (np. jako oferta na przetarg czy konkurs) wymaga szczegółowego opisu co ma zostać wykonane. Jeżeli zamawiający nie potrafi sam takiego szczegółowego opisu wykonać powinie kogoś zaangażować. Zapytałem, jak? Znowu w drodze konkursu lub przetargu? Zgodnie usłyszałem: NIE! Bo wygra najtańszy a to nie wróży dobrze, ma być najlepszy bo im lepszy opis tym tańsze oferty złożymy. Ciekawe nie?

No tu zapytałem dlaczego. Odpowiedź: dobra dokumentacja wymagań to także dobra wycena, która wtedy nie wymaga nakładania wielu dodatkowych narzutów na wszelką niewiedzę i prototypy. Klienci tak na prawdę zawsze zapłacą za całość wykonanej pracy czyli spędzone roboczo-dni (podobno programiści i firmy IT raczej nie dopłacają do interesu). Rzecz w tym, że jak nabywcy źle udokumentują wymagania to zapłacą za wszelkie niepowodzenia i dodatkowe prace.

Skąd ta dyskusja? Niedawno miałem przyjemność wzięcia udziału w dyskusji na forum programistów zapoczątkowanej lakonicznym pytaniem:

Zlecę wykonanie małego serwisu www. Planuję utworzenie serwisu z lokalnymi informacjami kulturalnymi bądź społecznymi. W serwisie znajdą się elementy takie jak:

  • wydarzenia
  • kalendarz wydarzeń
  • forum dyskusyjne
  • ogłoszenia
  • profile użytkowników
  • galeria
  • artykuły
  • + kilka innych, typu “kontakt”, “cennik”, etc.

proszę o oferty.

Pierwszy post z odpowiedzią na to zapytanie:

Klient pisze “mały”, żeby podkreślić, że mało zapłaci. Podobne w brzmieniu są teksty tupu: “dla fachowca to 5 minut roboty”, “Cóż to jest postawić kilka kresek w korelu”, “chcemy dokonać drobnej korekty” (i litania na 100 stron), i tym podobne…

Jak widać, Ci ludzie mają chyba duże doświadczenie z takimi zamawiającymi. Szczególnie tymi, którym się wydaje, że np. freelancer to desperat, który zrobi wszystko za jałmużnę (to głos z tego forum). Sam zresztą coś takiego kiedyś usłyszałem, negocjacje skończyłem dość szybko a jak potem się okazało pracownicy tej firmy sami opisali wymagania bo prezes nie dał na to budżetu, niestety słono zapłacił wykonawcy za kilka wersji oprogramowania i przedłużające się prace.

Co o tym sądzić? Z rozmów i doświadczeń wielu ludzi na tym forum i nie tylko tym można ciekawy wniosek wyciągnąć. Obawiam się, że menedżerowie dużych firm i korporacji, publikujący specyfikację wymagań w postaci niemalże kilku czy kilkunastu zdań zrzucają odpowiedzialność za to co otrzymają (za otrzymane oprogramowanie) na dostawcę, ten ostatni więc narzuca ?swoje 1000% marży? na zapas. Zamawiający o tym wie ale godzi się bo za te marżę zrzucił odpowiedzialność z siebie na dostawcę zaznaczając, że przecież ogłosił konkurs ofert (lub przetarg) i wybrał najkorzystniejszą.

Co ciekawe wielu ludzi w mniejszych firmach nie zdaje sobie chyba sprawy z tego zjawiska i naśladuje te praktyki ?większych kolegów? widząc tylko treść takich zapytań ale nie widząc już ich skutków (do których mało kto się zresztą przyznaje). Spisując swoje wymagania np. na przysłowiowej już ?jednej stronie A4?, są jednak szczerze zdziwieni jak zobaczą cenę bo nie rozumieją jej wysokości. Wtedy uciekają się do szukania tanich programistów, w końcu ?to proste oprogramowanie do wykonania?. Skutki wielu z nich zna: pieniądze wydane a oprogramowania gotowego do pracy nie ma, w przypadku stron i serwisów WWW kończy się to często jakimś żałosnym portalem, z którego drwią użytkownicy ale nie ma już budżetu na stworzenie lepszego.

Co zrobić? Posłuchać programistów: dać im porządnie opracowane swoje wymagania nie zapominając, że z reguły oni tego nie lubią robić sami. Jak ich zmusić, to będą po protu podejmować kolejne próby na podstawie kolejnych życzeń zleceniodawcy (to projekty ?czas i materiał?) lub powiedzą, że poza tym co wykonali niczego więcej się nie da. Ta druga wersja to projekty ?stała cena za dzieło?. Ogłaszając konkurs na wykonanie takiej specyfikacji wymagań należy się zaś kierować głównie rozsądkiem a nie ceną.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.