Mam mały problem z jednym z klientów. Podpisałem z nimi (klient jest firmą IT, dość poważną) umowę o dzieło. Aplikację, określoną przez specyfikację wykonałem. Dodatkowo podczas trwania prac nad aplikacją pozwoliłem, aby klient na bieżąco uzupełniał dane dotyczące około 1/4 aplikacji (szczegółowy opis algorytmiki). Ogólnie wiedziałem, co to jest, mogłem więc wyestymować. Nie wiem czy w ogóle jest to istotne.

Problem pojawił się w momencie oddania działa. Mianowicie klient zaczął być problematyczny i próbuje wymuszać zmiany w systemie argumentując, że tak jest napisane w specyfikacji. Dla przykładu jeżeli mamy zwrot w specyfikacji: "Zalogowany użytkownik ma mieć możliwość edycji danych zawartych w tabeli A.", to jak dla mnie jasnym jest, że można to wykonać poprzez użycie edytora WYSWIG. Klient domaga się oskryptowanego formularza i możliwości dodawania / edycji / usuwania wierszy. Argumentuje to, trudnością w użyciu edytora WYSWIG. Z jednej strony argument trafny (zgadzam się, że jest to trudniejsze) natomiast nie zgadzam się, że fragment specyfikacji jest jednoznaczny. Myślę, że każdy się zgodzi, co do tego, że edytor WYSWIG zrobi się dużo szybciej niż oskryptowanie skomplikowanej tabelki. To wpływa na estymacje czasową i finansową. Dodam, że tabelek jest naprawdę sporo... Klient nie pytał, ani nie sugerował jak mają być wykonane te elementy.

Kolejna rzecz, klient zażyczył sobie cytuję: "eksport danych z tabelek do pliku PDF lub XLS". Tutaj również, eksport HTML to PDF jest szybki, łatwy i przyjemny, natomiast do XLS już niekoniecznie (bardzo delikatnie mówiąc). Wykonałem eksport do PDF, rozumiejąc, że to wystarczy. Klient argumentuje, że ma być i do PDF i do XLS. Czy klient ma rację? Moim zdaniem znów nie.

I następny przykład. Zaprojektowane algorytmy działają wolniej, niż klient by chciał. W specyfikacji nie było i nie ma, ani jednego słowa na temat wydajności algorytmów. Zaproponowałem za dodatkową opłatą optymalizację. Klient upiera się, że tak mam zrobić bez żadnych dopłat.

Co ciekawe, klient w umowie (zaakceptowanej przeze mnie) wymusił wykonanie części aplikacji do określonego dnia (bez tych problematycznych elementów) i od około 2 miesięcy sobie tego używa...

Ogólnie pytanie jest takie, czy mam rację? Jeśli mam rację, to gdzie z tym dalej iść (klient wygląda na dość upartego)? Jeśli nie mam racji, to jak to odkręcić? Zrobienie tego, czego wymaga ode mnie klient to dodatkowe 8 tygodni pracy... Nie wziąłem zaliczki, cała płatność miała nastąpić po oddaniu dzieła.

Proszę o poradę kolegów (i koleżanek) po fachu :-)

wtf? Zrobiłeś formularze w edytorze WYSIWYG?! Jak?! Gdzie?! Pokaż! To co napisałeś jest jednoznaczne z tym co wymaga klient, zgadzam się z klientem.


Skoro pisze do PDF i XLS to czego Ty oczekujesz? Zapłacił to tego wymaga. Ludzie jak nie potraficie czegoś wykonać to się za to nie zabierajcie bo szkoda waszego i klienta czasu, a pieniądze można zarobić zbierając ogórki. Najlepszy jest fragment - Wykonałem eksport do PDF, rozumiejąc, że to wystarczy - made my day!


Skoro działają wolno to trzeba je przyspieszyć, no ludzie. Algorytm działa wolno bo go źle napisałeś, czego oczekujesz w specyfikacji, żeby klient pisał, że wyszukiwanie ma działać szybko? To chyba jasne.



Ciesz się, że Cię po sądach nie ściga

Piotr, dzięki za uwagi, ale...

klient jest firmą IT, dość poważną

Raczysz Waść żartować. Jak napisał mój przedmówca, jeśli nie jesteś w stanie zrealizować zlecenia, to go nie bierz. Weź też sobie do serca "klient ma zawsze racje".

Jeśli chcesz zrezygnować, to mu o tym napisz. Jednak powinieneś się liczyć z tym, że może Ci wysłać rachunek za poniesione koszty np. niewywiązania się z umowy i/lub wdrożenia tego co stworzyłeś.

Eksport do PDF lub XLS, czyli ma być menu z wyborem, a nie to że ma być zaimplementowany albo PDF albo XLS.
Nie rozumiem o co Ci chodzi z tymi tabelami, jakie html, sql?

Pierwszy poważny błąd. Tak się nie robi, specyfikacja ma być gotowa do wyceny, a wszelkie zmiany mają być uwzględnione w umowie (ich ewentualny zakres i sposób rozliczenia).


Klient ma zdecydowanie rację. Nie wiem jak w ogóle mogło Ci przyjść do głowy użycie edytora wizualnego.


Powinieneś to wziąć pod uwagę na początku jeśli Ty nie byłeś czegoś pewien, powinieneś był dopytać. Zdecydowanie Twoja wina.


Ty czytasz co sam piszesz? Jeśli zamówisz obiad, ale dostaniesz bez ziemniaków pieczonych będziesz zadowolony? Wątpię. Co kogo obchodzi ile to czasu zajmie. Klient płaci za specyfikację, której nie dorzymałeś.


Kwestia tego jak to wszystko działa.


Skoro taką umowę zaakceptowałeś, to problemu nie widzę.


Zdecydowanie klient. Próbować to załagodzić, bo klient ma rację (według tego co przedstawiłeś), że aplikacja jest niezgodna z umową.


Błąd. Ja nie wiem dlaczego niektórym kwota ewentualnej umowy przesłania zdroworozsądkowe myślenie.

Tu masz rację. Mogę tylko wyciągnąć wnioski na przyszłość.


Chyba się nie rozumiemy, co do tego co jest przedmiotem edycji. Edytujemy wynik działania algorytmu prezentowany w postaci tabeli. Nie jest on nigdzie zapisywany, niż poprzez eksport do pliku (bez importu). Klient chce wziąć konkretną krotkę i ewentualnie zmienić np znak z + na -. Dlaczego mi to przyszło do głowy? Ponieważ był to najszybszy sposób na wykonanie tego, czego klient sobie życzył. Powtórzę się. Zauważ proszę, że klient nie neguje tego, że jest to funkcjonalne (czyli robi to co chcieli), ale że jest to niewygodne. Nie mogę zgadywać, co jest dla klienta wystarczająco wygodne, a co nie jest.


Wina jest po obydwu stronach. Ja nie zapytałem, klient nie sprecyzował. Cały czas przypominam, to jest umowa o dzieło (nie kontrakt, nie umowa zlecenie, nie umowa o pracę). To naprawdę ma znaczenie. To co mówisz to sytuacja idealna, coś takiego nie istnieje. Dla mnie to było oczywiste.


Idziesz do restauracji. Zamawiasz z menu ziemniaki + mielony LUB schabowy. Kelner nie zapytał, o nic, ty nie powiedziałeś niczego więcej. Naprawdę myślisz, że dostaniesz i schabowy i mielony z ziemniakami? W restauracji pewnie jak narobisz rabanu, to szybo Ci dodadzą to czego Twoim zdaniem brakuje, a kelner dostanie opierdziel. Ale jest to tylko gest dobrej woli, w stylu "klient ma zawsze racje" Z punktu prawnego, nie muszą.


A ja widzę, dałem zgodę na używanie aplikacji i boli jedynie to, że może nigdy nie zapłacić, a tego co już mu dałem będzie używał. Do tego mają całość również, pewnie będą używać (bo czemu nie?).


Chyba innego wyjścia nie ma. Widzę, że nie mam racji według zwyczajów na rynku. Udobruchać, wyciągnąć kasę (albo chociaż uniknąć kary!) i nie zapomnieć tej lekcji. Aczkolwiek nadal się nie zgadzam, że to tak działa system. Specyfikację też trzeba umieć napisać w sposób jednoznaczny. Nie moja wina, że firmy nie stać na analityka systemu i specyfikację piszę młodszy PM w trakcie przyuczenia.

No fakt, nie zrozumieliśmy się. Przyjąłem, jak widać błędnie, że to zwykły CRUD. Tak czy siak, powinieneś zapytać. Po co, żeby uniknąć właśnie takich sytuacji!


Nie. Wina leży po Twojej stronie. Dlaczego? Bo nie dopytałeś. Klient może:
a) tego nie wiedzieć
na to nie wpaść
c) myśleć, że Ty się domyślisz.

To w Twojej gestii jest dopytywanie, aby wszystko było:
a) jasne
zrozumiałe dla obu stron.


Dla mnie ten zapis jest jasny. Klient ma mieć możliwość generowania wyników w postaci PDF lub XML, w zależności od tego co kliknie. Znowu nie dopytałeś.


Skoro podpisał umowę, to zapłacić musi. Ale z w pełni działającą aplikację. Bez tego ani rusz.


Ale do cholery jasnej, Ty tę specyfikację zaakceptowałeś! W tym związku to TY jesteś programistą, to TY piszesz aplikację i jak widać, poruszasz się w całym procesie tak naprawdę po omacku, bo nie wiesz, czego chce klient. Klient może napisać specyfikację pismem obrazkowym, a to jest Twój obowiązek dopytać o znaczenie tych obrazków, bo inaczej mamy sytuację jak w tym temacie.

Ja bynajmniej nie bronię ogółu klientów, bo 4 lata prowadzę działalność i wiem jacy potrafią być. Ale na miłość boską, nie możesz akceptować czegoś, czego sam nie jesteś pewien, a potem mieć pretensji do klienta, że chodziło mu o coś innego.

To Ty im wysłałeś efekty swojej pracy przed zapłatą? Chłopaku, skądś Ty się urwał.



Jakby klient wiedział czego chce, to byś zarabiał o połowę mniej lub w ogóle. Wyjaśnij, o jakim to znaczeniu piszesz w przypadku umowy o dzieło.

Absolutnie nie zgadzam się z tym, że "klient ma zawsze rację". Na szczęście jestem na takim etapie życia, że albo podejmuję z klientem współpracę i traktujemy się jako współpracowników, albo dziękuję za taki interes, bo rola inna niż równoważna mi nie odpowiada. To tak tytułem wstępu.

Hmm, pytanie jest jedno: skoro klient odmawia przyjęcia dzieła to dlaczego z niego korzysta? Niech przyjmie dzieło, ale z zastrzeżeniami.

Nie jest do końca tak, że umowę interpretujemy wyłącznie po myśli klienta. Jeżeli dana operacja nie wymaga wykonywania przez klienta nadmiernych czynności (np. panelem administracyjnym) i jest uważana za powszechną praktykę to w czym problem? O ile faktycznie tak jest, bo ja absolutnie nie rozumiem co Ty edytujesz przez WYSIWYG.

Inna sprawa, że wszystko było robione ewidentnie na wariata. To, co moim zdaniem jest rozsądne (i sprawiedliwe) to mediacja. Albo robisz wszystko w zamian za dodatek pieniężny, albo wspólnie ograniczacie liczbę poprawek i robisz to w ramach przewidzianego budżetu. Próbowałeś rozmawiać z klientem po ludzku? Jak każdy z Was będzie wypisywał wyłącznie swoje racje to sprawa skończy się albo w sądzie, albo klient będzie w plecy z dziełem a Ty z pieniędzmi.

Odnoszę wrażenie, że projekt Cię troszkę przerósł i zrobienie kilku poprawek stanowi drogę przez mękę. Architektura to bardzo ważna sprawa o czym wiele osób zapomina.

Wyestymować? Że niby co? Na podstawie estymacji parametrycznej uzyskałeś konkretną wartość estymatora czy przedział ufności ;-)? O ile dobrze rozumiem, miałeś na myśli możliwość oszacowania czasu potrzebnego na realizację.

PS. Z tym PDF lub XLS to dałeś ciaaaaaała .

Dlaczego miałby przyjąć coś co jest niekompletne, tylko dlatego że autor tematu nie wywiązał się z umowy? Drugim błędem jest wysłanie próbki, zamiast prezentacja u siebie. Trudno udowodnić korzystanie już PO.

"Głupi klient spotkał głupiego wykonawcę." :-) Całą dyskusję można podsumować jednym zdaniem. Wy uważacie, że moim obowiązkiem jest dopytać o każdy szczegół, ja natomiast uważam, że każdy ISTOTNY szczegół jest jednoznacznie opisany w specyfikacji, a wszystko to, co tam nie jest jasno określone, jest do mojej interpretacji (Czy mógł napisać w specyfikacji "PDF i XSL - do wyboru z menu"? Mógł. Czy mógł napisać "wydajność algorytmu X na takim poziomie dla takiej ilości danych"? Mógł. itd.). Czy mogłem zapytać o interpretację przed akceptacją specyfikacji? Mogłem, ale nie było takiej potrzeby, bo wiedziałem, co mam zrobić (miałem swoją interpretację i wizję aplikacji zgodną ze specyfikacją). Wyraziłem się na ten temat (tzn. jeśli czegoś nie ma jasno określonego w spec. to jest to moją decyzja) bardzo dobitnie przed rozpoczęciem współpracy z klientem (niestety rozmowa ustna), tym bardziej nie rozumiem jego obecnego zachowania. Jeżeli klient by stwierdził, że to nie przejdzie i mam pytać o wszystko co może być niejednoznaczne - to ok. siadamy i przerabiamy specyfikację razem słowo po słowie (ale oczywiście koszt wzrasta i klient musi znaleźć te X dni czasu) i z niejednoznacznej staje się w 99% jednoznaczna. Klient tego nie chciał. Zaufał specyfikacji.

Ogólnie, to zgadzam się z wami, że można było i dopytać i zrozumieć jako wersję bardziej w stronę klienta. To co mówi klient spełnia specyfikację, ale to co ja zrobiłem również.

Przykład jeszcze jeden. Zamawiasz u krawca spodnie. Mówisz, że mają być kolorowe. Krawiec nie zapytał jakie konkretne kolory, ty nie sprecyzowałeś. Po tygodniu odbierasz i masz spodnie: żółto, czerwono, zielone. I teraz zaczynasz marudzić, bo myślałeś, że jak powiesz kolorowe, to będzie więcej kolorów, a nie tylko trzy. Wina krawca - nie dopytał? Wina klienta - nie sprecyzował? Po raz kolejny krawiec liczy się z opinią, machnie ręką na te dwa dni i zrobi od nowa. Albo i nie, wtedy płacisz (praca została wykonana) i ewentualnie dopłacasz za zmiany na takie jak chcesz (tym razem jesteś precyzyjny). Kwestia decyzji krawca.

Mam nadzieję, że emocje opadną i w przyszłym tygodniu dojdę z nimi do porozumienia.

@!*!
Nie rozumiem, o co Ci chodzi, ale postaram się wyjaśnić sytuację bardziej. Firma A, szukała wykonawcy dla systemu B opisanego w specyfikacji (długiej). Wysłali zapytanie, zapoznałem się szczegółowo ze spec., potem seria spotkań omawiających to, co trzeba zrobić. Dałem swoją cenę i czas na wykonania mojej wizji aplikacji całkowicie zgodnej ze specyfikacją. Umówiliśmy się, że część szczegółowej spec dot. algorytmów zostanie dosłana później (to było ok, bo wiedziałem czego się spodziewać - mogłem oszacować). Jakiekolwiek zmiany w spec oprócz algo, niemożliwe bez uzgodnienia dwóch stron. Brak określonych godzin pracy. Brak jakiegokolwiek nadzoru. Miałem tylko dotrzymać terminów i zrobić to co w spec. Firma miała wgląd do aplikacji (chcieli kontrolować postęp prac, jakość kodu i ewentualnie odstąpić od umowy jak coś nie halo), miałem do nich zaufanie. Moim zdaniem typowa umowa o dzieło. Jednorazowy strzał. Klient określa czego chce - ja mu to robię. Nie może zmienić wymagań w czasie pracy, bo to już nie jest umowa o dzieło tylko podchodzi pod umowę-zlecenie. Dodatkowo umowa o dzieło z założenia musi być wykonana osobiście (mam to dodatkowo określone w umowie, więc mogę się mylić).

I napisał. Nie wiem jak Ty, ale ja widzę różnicę między LUB a ALBO ;)



Nie bardzo widzę tu zastosowania o różnicach w umowach, ponieważ Ty się po prostu z niej nie wywiązujesz, więc tu o naginaniu ich ze strony klienta nie może być mowy.
A Ty jako specjalista (w mniemaniu klienta) musisz wiedzieć co i jak chcesz zrobić, aby było dobrze a klient był zadowolony, po to powstała specyfikacja, którą jak sam przyznałeś, zaakceptowałeś.

Mógł. Ale to nie zmienia faktu, że za te nieporozumienie tak czy siak odpowiedzialność ponosisz Ty. Dlaczego? Bo jeśli nie zrozumiałeś, to po co akceptowałeś specyfikację bez wyjaśnienia?


A tutaj to mnie ciśnienie podniosłeś: robisz coś jak najlepiej czy na odpier*ol się? Bo odnoszę wrażenie, że to drugie


Dalej idziesz w zaparte. To nie ma być Twoja interpretacja, tylko zgodność z faktami, do cholery! A jak widać, specyfikacji nie zrozumiałeś i winieneś był po prostu rozwiać wątpliwości.


Którą to:
1. zaakceptowałeś jako podstawę do wykonania aplikacji
2. nie zrozumiałeś, tylko bazowałeś na własnej interpretacji


Moim zdaniem nie. Z resztą, tak naprawdę to nie wiemy co tam w środku siedzi i znamy relację tylko jednej strony.


Powodzenia!


To nie ma być Twoja wizja aplikacji zgodnej ze specyfikacją, tylko aplikacja z nią zgodna. Tyle. Czy Ty coś palisz?

@!*! Ok, mistrzu. Skoro tak dobrze rozumiesz, to wytłumacz, gdzie tkwi błąd w moim rozumowaniu.

ALBO: "Do sklepu pójdę ja albo ty" Może mieć dwa znaczenia (interpretacja!): 1) Do sklepu pójdę tylko ja 2) Do sklepu pójdziesz tylko ty.

LUB: "Do sklepu pójdę ja lub ty" Może mieć trzy znaczenia (interpretacja!): 1) Do sklepu pójdę tylko ja 2) Do sklepu pójdziesz tylko ty. 3) Do sklepu pójdziemy obaj, ty i ja.

I: "Do sklepu pójdę ja i ty" Może mieć tylko jedno znaczenie. (Nie ma interpretacji).

Zamień w przykładach powyżej "ja" na PDF i "ty" na XLS. :-) Rozumiesz, o co mi chodzi? Klient zrozumiał poprawnie, ale ja również zrozumiałem poprawnie. Dałem duppy i nie zapytałem, ale klient też dał duppy, bo nie sprecyzował. I nie zrobiłem tego specjalnie. Po prostu nie zwróciłem wcześniej uwagi, że może to być zinterpretowane jako i jedno i drugie razem. Proszę wytłumacz różnicę, jeśli właśnie robię z siebie idiotę.


@pedro84 Nie palę, ale chyba zaraz zacznę ;-) Generalnie męczę Cię tak i idę w zaparte, bo nie przekonują mnie argumenty typu "Powinieneś, musisz itd." To jest dobry trening przed mediacjami z klientem. :-)))) Nie podpierasz swoich argumentów żadnymi przykładami. Jeżeli tego wymaga prawo, to napisz, że tego wymaga prawo (jest tak?). Przerzucasz całą odpowiedzialność za nieporozumienia na stronę wykonawcy. Nie zrobiłem tego, co zrobiłem na odpierdol, czy z jakąś premedytacją, ale dostosowałem sposób wykonania do możliwości finansowych i czasowych klienta. Gdybym chciał zrobić najlepiej jak umiem, potrzebował bym roku (jest mnóstwo opcji do optymalizacji, poprawy, doradzenia czegoś lepszego). Staram się być maksymalnie elastyczny, natomiast klient sądzi, że zapłaci za wersję minimum, a dostanie wersję maksimum wykorzystując niejasność specyfikacji. Jeżeli Twoje specyfikacje są w 100% jednoznaczne, albo możesz sobie pozwolić na zrobienie aplikacji w sposób idealny dla klienta wypytując o wszystko i mając zapłatę z góry - gratuluję. Ja niestety często muszę interpretować specyfikację i klient to akceptuje na samym początku (tak jak w tym przypadku) albo płaci ekstra za czas na stworzenie i zrozumienie jego wizji. Jak możesz to odpisz na jakimś konkretnym, uproszczonym przykładzie (może ten krawiec się nada?).

!*!, autor napisał, że klient korzysta z części jego oprogramowania. Czyli jednak z czegoś tam się wywiązał.
Nie rozumiem wielkich emocji związanych z wysłaniem produktu przed otrzymaniem zapłaty. Przecież mają umowę, a jeżeli jedna ze stron zechce spróbować zrobić drugą w bambuko to i tak spróbuje. Wystawiam FV i czekam do terminu płatności. Co w tym dziwnego?

Gwoli ścisłości: zdaję sobie sprawę, że autor w pewnych aspektach dał po prostu ciała. Jednak (tutaj kieruję uwagę do Pedro84) nie rozumiem dlaczego odpowiedzialność ma ponosić wyłącznie zleceniobiorca. Obie strony trochę zawaliły, a nie tylko jedna i to w całej rozciągłości. Programista akceptował warunki specyfikacji, ponieważ rozumiał je w określony sposób. Nie da się jednak napisać umowy, która zdefiniuje najdrobniejszy aspekt zlecenia. Tutaj trzeba trochę zrozumienia z dwóch stron i dojścia do rozsądnego consensusu. Nie zaś działania na zasadzie "Jestem klientem, a Ty zaakceptowałeś MOJĄ specyfikację. A w MOJEJ specyfikacji ważna jest tylko moja interpretacja". Dajcie żyć .

Lukasz_freelancer, przyjąłeś trochę wesołe założenie, że pójście na skróty i "interpretowanie" zgodnie ze swoim widzi mi się zostanie przyjęte przez klienta bez zająknięcia .

1. Z tym "LUB" popłynąłeś. Musisz to zrobić i tyle.
2. Z tym WYSIWYG już nie do końca, możesz się uprzeć i nikt Ci tego nie zakwestionuje, chyba, że jest to naprawdę oderwane od rzeczywistości i zrobione na odwal. Musiałbyś pokazać.
3. Z wydajnością Twój błąd, musisz dopytać jakie są oczekiwanie, jak wygląda to co zrobiłeś i dociągnąć, oczywiście, jeżeli oczekiwania są realne, musisz to obiektywnie ocenić, porównać z innymi skryptami.
4. Podpisując umowę o dzieło, nigdy, ale to nigdy nie robisz nic dodatkowo. Albo podpisujesz na to osobny papier, albo zastrzegasz coś takiego wcześniej klauzulą i zrywasz umowę. Jeśli projekt jest rozwojowy i klient chce Ci coś dosyłać pracujesz w rozliczeniu godzinowym, traktujesz to jak etat. Bo co zrobisz z innymi projektami, jak klient dośle coś co zajmie Ci 40h pracy, a oszacowałeś to na 10h?

Klient podpisując z Tobą umowę za jakieś grosze domniemywam, miał świadomość, że nie będzie to projekt idealne jakości, to jest na Twoją korzyść. A nauczka dla klienta.

Już Ci wyjaśniam Moja Droga.

Mając niemałe doświadczenie z klientami (z tymi polskimi jednak o wiele mniejsze niż zagranicznymi) nigdy nie zdarzyło mi się podpisać pod umową jeśli czegoś nie byłem pewien na sto procent. OP wygodnie założył, że w przypadku tego zlecenia jest miejsce na interpretację, jak widać po temacie, sporo się pomylił.

Daiquiri, nie powiesz mi chyba, że jakikolwiek wykonawca winien zaakceptować specyfikację pracy bez pewności o jej jednoznaczności? Sam OP napisał, że "wydawało mu się, że klientowi wystarczy". Tutaj nie ma miejsca na "wydaję mi się". Moi stali klienci, na początku, często żalili się, że zadaję od groma pytań, że rozmowy się przeciągają, że spotkania trwają w nieskończoność. Ale zawsze potem jednak przyznawali rację, że moje podejście było słuszne.

Nawet zakładając to, że specyfikacja była tragiczna, jakie to ma znaczenie? Czy wykonawcy ktoś kazał, pod rygorem kary finansowej, podpisywać umowę? Raczej nie. Chyba normalne i logiczne jest, że skoro wykonawca nie jest pewien, nawet całości specyfikacji, to po prostu próbuje dowiedzieć się od klienta wszystkiego co mu potrzeba?

Reasumując, wiem, że klienci są naprawdę różni, ale w tym konkretnym przypadku i mając tę wiedzę co obecnie, będę po prostu za tym klientem stał murem, bo programista dał dupska. Tyle.

Przy średnich(większych) aplikacjach lepiej zlecenie rozbić na moduły i rozliczać się co skończony moduł.

To że jak ktoś nie ma produktu dopóki nie zapłaci to szybciej płaci + mniej kombinuje z darmowymi wodotryskami/poprawkami/zmianami.

To nie zaczynaj, bo ja papierosy już długo rzucam i jakoś nie mogę

Zobacz sobie moją odpowiedź na post @Daiquiri, da Ci trochę światła na mój tok rozumowania.

Bez stuprocentowej pewności nie powinieneś był podpisywać umowy. Możliwości finansowe czy czasowe klienta nie mają w tym momencie znaczenia. Dlaczego? Ano dlatego, że pojawił się wątek "interpretacji", na który nie ma miejsca w biznesie.

Dam Ci przykład, buduję dom. Różne ekipy budowlane przychodzą i odchodzą, bo nie stać mnie na jedną firmę, która wybuduje mi całość. Dodatkowo mam specyficzne wymagania dot. materiałów i po prostu trzeba rozłożyć w czasie. Ale to nieistotne. Moją specyfikacją jest projekt budowlany, z naniesionymi przeze mnie zmianami. To jest moja specyfikacja. Jest bardzo szczegółowa. I każda powinna taka być. Wyobrażasz sobie sytuację, w której projekt to byłby prostokąt walnięty na kartce z zeszytu? Czy jakakolwiek sensowna firma budowlana by Ci coś takiego wzięła pod uwagę. Wątpię.

Druga kwestia. Nawet jeśli specyfikacja dawała duże pole do popisu przy interpretacji to powinieneś poprosić o doprecyzowanie. Dlaczego? Bo:
1. ona dla klienta może być jednoznaczna
2. bo Ty zobowiązałeś się do dostarczenia produktu z nią zgodnego. Poza tym, zobacz punkt pierwszy.

Lepiej się pracuje w zgodzie, niż idąc na materace.

Pedro84, a czy ja twierdzę że autor nie dał ciała? Uważam po prostu nie da się wszystkiego spisać i wyjaśnić w umowie. Bo chyba nie powiesz mi, że jest inaczej? Zawsze jest miejsce na jakieś niedopowiedzenia, zwłaszcza przy większych projektach. Ty zaś kategorycznie napisałeś, że "za te nieporozumienie tak czy siak odpowiedzialność ponosisz Ty. Dlaczego? Bo jeśli nie zrozumiałeś, to po co akceptowałeś specyfikację bez wyjaśnienia". Programista nie twierdzi, że nie zrozumiał specyfikacji, tylko że zrozumiał ją inaczej niż klient. Czyja jest to wina?

Rozumiem, że w idealnej sytuacji programista (przede wszystkim!) powinien zapytać czy na pewno dobrze się rozumieją. Jeżeli jednak umknie to jego uwadze to czy jest to wyłącznie Jego wina? Idąc Twoim tokiem rozumowania to tak. Ja się z tym po prostu nie zgadzam. Dojdziemy do sytuacji w której w 30-stronnicowej umowie o wykonanie pierdoły w postaci strony internetowej, będzie 25-stronniciwy słownik definicji pojęć.

Dodatkowa pula zrozumienia należy się dla klienta "nieprofesjonalisty", który pewnych rzeczy nie rozumie, chociaż w tym przypadku klient to "firma IT".

Jeżeli odnosisz się wyłącznie do tej konkretnej sprawy - to jasne, jest spora szansa, że lwia część winy wynika z ułańskiej fantazji programisty. Nie zgadzam się jednak że za każde nieporozumienie w kwestii specyfikacji winę ponosi programista (jakikolwiek programista, nie autor tematu), ponieważ "zaakceptował umowę" (a tak rozumiem Twoje wypowiedzi).

Spawnm,
Jasne, że lepiej rozliczać się etapami - przynajmniej ja praktykuje takie rozwiązania. Jednak nie wiem skąd takie czepialstwo względem osób, które rozliczają się w całości "po fakcie". Rozliczenie jak każde inne.

Jak każde inne? To czemu tylko oni płaczą?
Rozliczanie przed 'faktem' zapewnia spokojny sen, mniej stresu, a przecież o to chodzi

Spawnm, dla mnie rozliczenie przed "faktem" oznacza tyle, że jak mi klient nie zapłaci to tyle "mojego", że nie poużywa sobie mojej aplikacji... ale ja nadal jestem o taką kwotę w plecy* . Jednak nie w tym rzecz, bo mimo iż uważam rozliczanie etapami za korzystniejsze, to wypowiedzi a la !*!: "To Ty im wysłałeś efekty swojej pracy przed zapłatą? Chłopaku, skądś Ty się urwał." (wybacz, że posłużyłeś mi za przykład !*! ) są już nieco męczące bo sugerują, że w tej branży nie ma już uczciwych klientów .

*. Tj, też mogę "płakać" jak nie sprzedam apki komuś innemu .

Daiquiri, rozbiję na części. Przypominam Ci tylko, że ja odnoszę się tutaj do konkretnej sytuacji opisanej przez OP.


Programisty.

Dlaczego?
Bo dla klienta specyfikacja zawsze (ok, prawie zawsze) będzie:
1. jasna
2. jednoznaczna
3. szczegółowa.

Dlatego, że on po prostu (ok, najczęściej) wie czego chce i wie jak to ma wyglądać. To, czy potrafi to przenieść na specyfikację to inna kwestia, ale wykonawca NIE MOŻE pozostawić sobie miejsca na interpretację.

Robiliśmy kiedyś jeden całkiem spory system dla jednej firmy. Z 40 stronicowej specyfikacji, po przerobieniu jej przeze mnie, wyszła 90 stronicowa księga. Ale było w niej wyszczególnione wszystko. Ile mi to zajęło? Dwie, trzy godzinki, wliczone z resztą do wartości projektu. Opłacało się?


I co w tym złego? Obie strony zadowolone. Wykonawca, bo ma wszystko jasne, a klient ma mniej możliwości kręcenia, czy próbowania zrobić go w bambuko. A wykonawca, bo jest pewien, że wykonawca dostarczy mu to co on konkretnie chce.

BTW. Skąd Ty wiesz jak moje umowy wyglądają? Cholerne NSA, zwerbuje każdego...


Klient nietechniczny to w ogóle inna para kaloszy :-)


Daiquiri, on nie ponosi winy za specyfikację, co piszesz, tylko za to, że ją zaakceptował. Sam z resztą pisze w swoim pierwszym poście, że interpretował jak funkcjonalność ma wyglądać. A takie coś ma wynikać ze specyfikacji.

Przykład:
"Zalogowany użytkownik ma mieć możliwość edycji danych zawartych w tabeli A." - dla mnie jest logiczne, że mówimy tutaj o forumalarz edycji/dodawania/usuwania. Dla klienta także. Ale dla OP już nie. Z czego to wynika? Z jego interpretacji. Wystarczył jeden durny email bądź telefon: "czy w punkcie mówiącym o tym, że zalogowany użytkownik ma mieć możliwość edycji danych zawartych w tabeli A chcą Państwo mieć osobne formularze dla każdej akcji? Jeśli chcesz, możemy dalej dyskutować nad tym czyja to wina Winę za specyfikację ponosi TYLKO I WYLĄCZNIE (sorry za brak dużego ł, coś mi znowu wali się, argh) klient, ale pełna odpowiedzialność za jej akceptację ponosi programista.

Są i uczciwi, nawet bardzo fajni w współpracy, jednak jest też trochę krętaczy, więc lepiej dmuchać na zimne i się nie sparzyć bo nie wiesz na co wpadnie klient.
Fajnego/uczciwego klienta nie rusza fakt że musi płacić przez a nie po.


Mylisz się, już ci pisałem, przy takim wymogu ludzie z automatu są mniej problematyczni, nie zwlekają miesiąc z zapłatą itd. Zupełnie inaczej wyglądają rozmowy z takimi klientami.

@Pedro84 Pozwól, że odpowiem na twoim przykładzie. Generalnie rozumiem i szanuje Twoje podejście. Kwestia do zastanowienia się, czy to nie jest dużo lepsza droga.

Wracając do przykładu. Mocno przejaskrawiony, aby to dobrze zobrazować. Ja bym Ci ten dom zbudował, gdybyś mi dał kartkę papieru z narysowanym prostokątem. :-) To jest Twój wymarzony dom. Dla Ciebie to jest jednoznaczna specyfikacja. Oczywiście opowiadasz mi co tam jest, zakładam że rozumiem, co to ma być (ale np. nie specyfikujesz gdzie ma być wejście. Okna mają się otwierać poziomo LUB pionowo, a w środku ma być ciepło zimą). Proponuję Ci, że zrobimy specyfikację razem i wtedy na pewno dostaniesz to, czego chcesz (ale trzeba będzie zapłacić powiedzmy 10% z góry + poświęcić kilka dni). Uważasz, że specyfikacja jest wystarczająca w obecnej formie i się nie zgadzasz na moją propozycję. "Ma być tak jak w specyfikacji! - mówisz" Ustalam więc budżet i czas wykonania, mojej interpretacji twojej specyfikacji. Ja ją doskonale rozumiem. Podejrzewam, że po wykonaniu prac, nawet dużo dużo głębiej niż ty. Zbuduję Ci ten prostokątny budynek. Ale zauważ jedną rzecz. Jak po wykonaniu budynku, przyjdziesz i powiesz, że wejście miało być od wschodniej części, a nie od zachodniej, to ja zadam Ci jedno pytanie. Gdzie w specyfikacji jest to określone w sposób jednoznaczny, że tak ma być? Jeżeli zapytasz czemu okna otwierają się tylko poziomo, to ja pokażę Ci specyfikację i pokażę fragment "okna otwierane poziomo LUB pionowo". A jak zimą powiesz, że Ci zimno w domu, to ja przyjdę i powiem, że mi ciepło i jak jest za zimno to trzeba było określić w specyfikacji efektywność cieplną (czy jak to się tam nazywa).

Twoim zdaniem to tylko i wyłącznie moja wina, że nie zapytałem o to wejście, czy inne rzeczy. Moim zdaniem jest to wina obu stron, a może nawet bardziej klienta (zwłaszcza, że proponowałem wykonanie specyfikacji razem). Ja przecież wykonałem to co było w specyfikacji! Nic innego, tego właśnie chciałeś. Teraz załóżmy, że przeniesienie tego wejścia na inną stronę to jest koszt 25% całości projektu, a wymiana okien kolejne 10% i ocieplenie następne 15%. Przenosić je gratis w imię tego, że nie zapytałem o szczegóły? Popełniłem błąd, ale nie ja jeden w tym momencie i nie ja jeden powinienem za nie ponieść konsekwencje.

BTW: specyfikacja do tego systemu ma 155 stron i jest naprawdę szczegółowa.

Poproszę argumenty, bo nadal tylko nie może, nie wolno itd. Są do tego jakieś podstawy prawne? Jedyną podstawą prawną jaką ja znam do tej sytuacji jest to, że efekt końcowy musi być zgodny ze specyfikacją. Jeżeli klient nie potrafi się "wysłowić" i nie chce pomocy, to jak dla mnie, nie jest to moja wina i oczekuję zapłaty za pracę.

Czy możesz wytłumaczyć, co rozumiesz przez "akceptacja specyfikacji"? Czy ja nie zaakceptowałem twojej specyfikacji prostokątnego domu w powyższym przykładzie? Jak mam być pewny tego, że specyfikację zrozumiałem tak jak ty? Czy uważasz, że o tym nieszczęsnym XSL wiedziałem w trakcie projektu i się cieszyłem, że nie muszę tego robić bo jest "LUB" pomiędzy? To nie tak.

Pedro84, ja nie mam najmniejszego zamiaru bronić autora tematu, bo... chyba sam z resztą wiesz dlaczego.

Nie zgadzam się jednak z kategorycznym stwierdzeniem, że jeżeli programista (jakikolwiek, nie autor!) akceptuje umowę wraz z specyfikacją to obowiązuje go wyłącznie interpretacja klienta. I nie przekona mnie twierdzenie, że jak nie zapytałam klienta co rozumie pod każdym pojęciem i czy przypadkiem nie myli przeglądarki z wyszukiwarką to jest to moja wina.

Inna sprawa, że nie chcę pracować z ludźmi przy których muszę się obstawiać trzydziestoma stronami umowy na stworzenie banerka na stronę. Dla mnie to krok w złą stronę, ale rozumiem, że czasami trzeba.

Ja także nie. Ani nie zamierzam nań najeżdżać, ani bronić. Analogicznie z klientem.


Twój przykład jednak chyba troszkę jest zbyt daleko idący. Ale uwierz, jeśli klient pomyli przeglądarkę z wyszukiwarką, wyłapiesz to z kontekstu. Interpretujesz jednak, moim zdaniem, na wyrost. Nie pod każdym, tylko pod każdym budzącym wątpliwości, a takich podejrzewam było niemało.


Nie zawsze, nie do banerka.


Widzisz, cały problem w tym temacie polega na tym, że wszyscy bazujemy na wersji jednaj strony i nikt z nas nie widział specyfikacji poza Tobą


Tylko, że wówczas ja nie mam na swoją obronę nic. Ty masz. Co? Specyfikację tegoż domu szumnie zwaną projektem.


W tym konkretnym powyższym przykładzie, tylko i wyłącznie moja, jako klienta. Ale ten przykład przejaskrawiony jest. Poza tym, sam piszesz, że specyfikacja jest obszerna i szczegółowa. Ja w dalszym ciągu bazuję tylko na tych szczątkowych informacjach z Twojego pierwszego postu i tylko biorąc je pod uwagę wyrażam opinię.


Podstawy prawne do czego? Jeśli nie chcecie się porozumieć, to klient zarzuci Ci nie wywiązanie się z umowy i wypowie umowę powołując się na niezgodność produktu z umową (której częścią jest specyfikacja techniczna). Potem sąd, to wszystko zajmie: czas, pieniądze. A wynik - znając polskie sądownictwo - będzie randomowy.


W dalszym ciągu niestety nie rozumiesz o co mi w ogóle chodzi. Właśnie tak samo jak @Daiquiri. W tym naszym budowlanym przykładzie wszystko jest ok. A wiesz dlaczego? Bo tylko tyle zawarte było w specyfikacji.

A w Twoim przypadku mowa o formatach eksportu była. O obu.

eksport danych z tabelek do pliku PDF lub XLS - dla mnie jest to logiczne, że warunek to wybór użytkownika. Nie programisty polegający na wyborze łatwiejszego do wdrożenia elementu.
Zalogowany użytkownik ma mieć możliwość edycji danych zawartych w tabeli A - analogicznie, z tym, że założyłem, że to jakiś CRUD.

Na tych tylko dwóch przykładach budowałem swoje zdanie i tylko do nich się odnosiłem. Możliwe jest, że jesteś leser i nie chce Ci się robić, ale możliwe jest także, że klient to oszust i szuka frajera, a Ty jesteś bez winy. Obie możliwości są tak samo prawdopodobne

Tak naprawdę, to my mamy zbyt mało danych na temat tej całej sprawy. Tak sobie każdy brodzi w temacie mając szczątkowe informacje.

Pedro84, to nie jest kwestia interpretacji, tylko zasadności Twojego kategorycznego stwierdzenia, że za winę zawsze odpowiada programista bo "podpisał umowę wraz ze specyfikacją". Jak wspominałam - ja się z tym nie zgadzam. Pierdoły w stylu (XLS lub PDF) będę oczywiście interpretować na korzyść klienta, bo nawet chłopska logika podpowiada że wybór pomiędzy tak odległymi formatami ma niewątpliwie jakieś znaczenie dla klienta.

Jak już zapewne zauważyłeś jesteś w błędzie. Znaczenie LUB zawsze określało też "i", a raczej mieściło się w nim, a ALBO to alternatywa. I w kontekście plików PDF lub XLS pasuje idealnie ... nie sądzisz że oba warianty były logiczne? Po co klient miałby zawracać Ci głowę i kazać wybierać? To już Ci nie zapaliło żadnej lampki... Cóż, teraz zamiast czytać posty na forum, musisz to poprawiać ;) Tak, można się upierać przy interpretacji słowa LUB, ale to już ustaliliśmy, że nie w tym przypadku.


Tak i co z tego? Część oprogramowania nie była przedmiotem umowy i krótko mówiąc nic z tym nie zrobisz, chyba że zapis czy licencja były określone w umowie bądź w kodzie aplikacji. To jest taka sama sytuacja jak zwrócenie programu komputerowego do sklepu (znowu to;)), sprzedawca nie musi Ci oddać kasy i nie ma tu prawa reklamacji towaru.



Dodatkowe zabezpieczenie po prostu. Klient który nie dostał towaru, odbiera jeszcze telefony ;) po co się później stresować wysyłaniem faktur, ponaglaniem do zapłaty czy mieszać w to windykatora.

Niestety Spawnm nie masz podstaw żeby stwierdzić, że się mylę*. Co znaczy "z automatu"? Rozmawiałeś z klientami moich znajomych czy nawet moimi? Możesz pisać jedynie o swoich doświadczeniach, podobnie jak ja. A zdarzyło mi się nawet, że klient rozliczył się za trzy etapy prac (z bodajże pięciu), jednak na tym się skończyło. Ten czwarty etap byłam w plecy. Tak już jest i jedynie płatność z góry pozwoliłaby na uniknięcie kuriozalnych sytuacji .

*To tak jak napisałbyś, że "mylisz się, wolisz sernik niż szarlotkę".

!*!, tak jak już pisałam o tutaj .

W tym konkretnym przypadku? Jak najbardziej tak. W innych, to już bywa różnie.

Tak jak pisałem wcześniej, tak powtórzę. Ja się odnoszę tylko do tej wiedzy, którą mamy i specyficznego, konkretnego przypadku.

może bramki rozwiążą problemy 'lub' / 'i'
http://en.wikipedia.org/wiki/Logic_gate#Symbols
: D

podsumowując:

Swego czasu miałem podobną sytuację. Klient faktycznie mylił pojęcia wprowadzając mnie tym samym w błąd (przykładowo: jako wyszukiwarkę rozumiał menu nawigacyjne). Mieliśmy spisaną umowę, była specyfikacja. W końcu udałem się do prawnika, który mi wyjaśnił: jeśli specyfikacja nie precyzuje pewnych kwestii to zleceniodawca zdaje się w tym przypadku na interpretację przez wykonawcę. Nie musimy się zatem dopytywać o każdy szczegół, który wydaje nam się jasny. Co nie zmienia faktu, że w opisywanym przypadku "eksport do X lub Y" również zainterpretowałbym jako eksport do obu formatów, a nie tego, który jest w stanie napisać programista

Niestety jest to rynek klienta, to on bedzie pracował z tym co dostanie i od tego tez jak będzie zadowolony bedzie zalezała dalsza wspołpraca, a taka zawsze będzie. Miałem okazję pracowac przy projekcie, który był rozpisywany przez programistów dla klienta, klient próbował się w to wgryżć, jednak widac było, że sprawia mu to ogromne problemy, pojawiły sie też rozczarowania co do rozwiazan wychodzących od nas. Dopiero po tym jak produktowiec usiadł z klientem i zaczal go sluchac powstało dobre działo, które do dzisiaj jest rozwijane. A było blisko zerwania umowy.