Umowa o dzieło i "niezgodność" dzieła ze specyfikacją Opcje

[lukasz_freelance...]

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 :-)

[Piotr33]

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.

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.

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.

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!

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.

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.

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...

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

[lukasz_freelance...]

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

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.

Nie rozumiem. o żadnych formularzach nie wspominałem. Mamy tabelę, w niej dane do edycji. Edytujemy za pomocą edytora WYSWIG. Klient nie neguje takiej formy edycji, mówi tylko, że jest to niewygodne.

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!

Jest napisane PDF LUB XLS. Czytaj proszę uważnie. "Lub" może znaczyć: 1) Opcja A 2) Opcja B 3) Opcja A i Opcja B razem.

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.

Nie rozumiesz specyfiki umowy o dzieło. Przyspieszyć do jakiego stopnia, aż klient powie, że wystarczy? Nie ma problemu, ale przy płatności za godzinę pracy - nie przy umowie o dzieło, gdy cenę ustalamy z góry na podstawie specyfikacji w której nie ma wzmianki o wymaganej wydajności poszczególnych algorytmów.

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

Gdybym tylko miał czas, to bym się chętnie spotkał w sądzie, bo jednak prawodawstwo dotyczące umowy o dzieło jest dość jasne.

[memory]

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

[!*!]

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.

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?

[pedro84]

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.

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).

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.

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

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.

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

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.

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ś.

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.

Kwestia tego jak to wszystko działa.

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...

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

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...

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

Nie wziąłem zaliczki, cała płatność miała nastąpić po oddaniu dzieła.

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

[lukasz_freelance...]

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).

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

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

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.

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

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.

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ś.

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ą.

Kwestia tego jak to wszystko działa.


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

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?).

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.

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.

[pedro84]

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.

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!

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.

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.

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ą.

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ś.

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?).

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

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.

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.

[!*!]

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?).

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

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.

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.

[Daiquiri]

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.

Ogólnie wiedziałem, co to jest, mogłem więc wyestymować.

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 .

[!*!]

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

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.

[lukasz_freelance...]

"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ć).

[!*!]

Czy mógł napisać w specyfikacji "PDF i XSL - do wyboru z menu"? Mógł.

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

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ć).

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ś.

[pedro84]

"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ł.

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?

Czy mógł napisać "wydajność algorytmu X na takim poziomie dla takiej ilości danych"? Mógł.

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

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ą).

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.

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.

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

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ż.

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

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

Powodzenia!

Dałem swoją cenę i czas na wykonania mojej wizji aplikacji całkowicie zgodnej ze specyfikacją.

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

[lukasz_freelance...]

@!*! 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?).

[Daiquiri]

Dlaczego miałby przyjąć coś co jest niekompletne, tylko dlatego że autor tematu nie wywiązał się z umowy?

!*!, autor napisał, że klient korzysta z części jego oprogramowania. Czyli jednak z czegoś tam się wywiązał.

Drugim błędem jest wysłanie próbki, zamiast prezentacja u siebie. Trudno udowodnić korzystanie już PO.

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 .

[Damonsson]

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.

[pedro84]

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ć .

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.

[Spawnm]

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

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?

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

[pedro84]

@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?).

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.