Kto powinien płacić za poprawki / błędy? [Zamknięte]

Więc zacząłem freelancingu zarówno w programowaniu na komputery / strony, jak i do tego klienta, który już zaakceptował moją pracę i płacił mi, wciąż do mnie wraca za każdym razem, gdy znajdzie błąd itp. I znalazłem, że spędzam więcej czasu, niż myślałem, naprawiając je wolny. Czy to w porządku, czy powinienem zacząć pobierać opłatę za wsparcie?

Jaki jest najlepszy sposób radzenia sobie z poprawkami rzekomo zaakceptowanej i ukończonej pracy?

Część umowy powinna opisywać testy akceptacyjne, tj. Testy, które wykona klient, a aplikacja musi je zaliczyć, aby umowa została wykonana. Za wszystko, co nie jest objęte tymi testami, odpowiada klient. Wszystko, co obejmuje, należy do Ciebie.

Ponieważ nie jest możliwe (szczególnie dla klienta nietechnicznego) przewidzenie wszystkich możliwych problemów, należy dodać do swojego kontaktu klauzulę określającą okres, w którym naprawisz wszelkie nowe problemy w ramach umowy. Następnie powinieneś oferować tylko płatne wsparcie.

To zależy.

W pierwszej kolejności powinieneś zapłacić, ponieważ można argumentować, że praca nie jest ukończona.

Później klient powinien płacić za ciągłe wsparcie.

Problem polega jednak na podjęciu decyzji, gdzie jest granica, co stanowi błąd i co jest nową funkcją. Posiadanie wymagań i / lub testów akceptacyjnych jest długą drogą do zdefiniowania tego.

Naprawdę trzeba dostać te rzeczy w miejscu, zanim dostarczy pracę, ale jeśli nie ma to może teraz jest czas Tak mówią - „Będę wspierać to za darmo dla dzień następny N / tydzień, ale potem my muszę omówić umowę o wsparcie ”(zwróć uwagę na mój nacisk na„ my ”).

Powiedziawszy to wszystko, są chwile, kiedy trzeba będzie naprawić błąd za darmo i przyjąć trafienie. Jeśli nic innego nie buduje dobrej woli.

Wszystkie powyższe odpowiedzi są dobre. Chciałbym jednak dodać kilka punktów do rozważenia:

• Czy klient jest dla ciebie cenny? Czasami warto przejść kilka dodatkowych jardów, aby zadowolić klienta, jeśli uważasz, że jest on dla ciebie cenny i przyniesie ci więcej pracy w przyszłości. Musisz znaleźć równowagę między ścisłością a elastycznością, co może być różne dla każdego klienta. Nie ma sensu tracić przyszłej pracy tylko dlatego, że jesteś przekonany, że łatwy do naprawy błąd nie wchodzi w zakres. Z drugiej strony nie chcesz, aby klient chodził po tobie. To delikatna równowaga!

• Czy błąd jest czymś, czego łatwo można pominąć w testach użytkowników? Weźmy na przykład błąd związany z datą, który pojawia się w grze dopiero po wprowadzeniu określonego roku (pomyśl błąd Millennium itp.). Nie można oczekiwać, że klient wykryje to podczas testowania, dlatego to na tobie spoczywa obowiązek naprawy.

Kiedy pracowałem jako wolny strzelec, moja podstawowa umowa z klientem zdefiniowała warunek zwany „akceptacją”, który był wymagany przed udostępnieniem projektu publicznie. W momencie akceptacji rozpoczął się 30-dniowy okres, który nazwałem „wsparciem i działaniem wsparcia”. Po tym 30-dniowym okresie bieżące prace nad projektem były rozliczane co godzinę.

Jeśli masz dobre relacje z tym klientem, miej z nim serce do serca na temat tego, jak niewykonalna jest dla ciebie obecna sytuacja, i zaproponuj godziwą stawkę godzinową za bieżące utrzymanie i wsparcie. Ludzie czasem myślą, że kupowanie niestandardowego oprogramowania jest jak kupowanie kanapki lub czegoś takiego, jak po zbudowaniu. Po prostu tak nie jest.

Zasadniczo możesz skorzystać z bezpłatnej pomocy technicznej przez określoną liczbę dni od dostarczenia aplikacji. Z pewnością wsparcie na całe życie nie jest możliwe / niedopuszczalne.

Upewnij się, że zgłoszony błąd to BŁĄD, a nie zmiana istniejącej funkcji. Za każdą zmianę funkcji należy naładować.

Gdyby go przetestował i podpisał, możesz argumentować, że powinien zapłacić.

Jeśli jesteś dumny i cenisz swoją pracę, możesz argumentować, że naprawisz kod. Ucz się na podstawie doświadczeń i buduj lepszy kod następnym razem, wydajniej. Lub uwzględnij większy zysk, aby pokryć usuwanie błędów.

Jeśli program robi coś niepożądanego lub nieoczekiwanego przy danych wejściowych, oznacza to błąd i powinien zostać naprawiony.

Mógłbyś podać z góry opłatę za wsparcie jako dodatek do początkowych prac rozwojowych.

W umowie określ stawkę za godzinę i śledź swój czas. Podając klientowi cenę, należy podać, że jest to wartość szacunkowa, a rzeczywisty wynik może być mniejszy lub większy.

Informuj klienta na bieżąco o postępach, a kiedy nieuchronnie przedstawi sugestie, możesz po prostu powiedzieć mu, ile czasu zajmie ci to (jeśli zmiana jest niezgodna z oryginalnymi specyfikacjami), a on może zdecydować, czy zmiana jest warta pieniędzy. Dlatego zostaną dodane tylko ważne dla niego zmiany.

Osobiście obejmowałbym akceptowalne i nieakceptowalne (płatne wsparcie vs. bezpłatne wsparcie) błędy w umowie, dzięki czemu masz przynajmniej coś na piśmie od samego początku. Bez wątpienia będzie się zastanawiał, dlaczego powinieneś potrzebować tej klauzuli, więc bądź z góry i wyjaśnij, że jeśli pojawi się nowa aktualizacja systemu operacyjnego, która coś psuje, to nie jest darmowe wsparcie. Błędy w twoim kodzie zgodnie z oryginalną specyfikacją na określonych platformach zostałyby jednak uwzględnione.

Powinienem jednak wspomnieć, że wykonywałem jedynie prace związane z informatyką, a nie programowanie. Może to odstraszyć klientów, ale tylko upewnij się, że twoja praca się sprzedaje, będzie bardziej profesjonalna, towarzyska i pomocna niż reszta, a także przedstawi powody, dla których masz ściślejszą umowę.

Poza tym klient, który nie zaakceptuje tej klauzuli, jest najprawdopodobniej złym klientem.