Czy powinieneś naliczać klientom godziny spędzone na niewłaściwym torze? [Zamknięte]

Podjąłem małe wyzwanie CSS do rozwiązania dla klienta i będę otrzymywać wynagrodzenie według stawki godzinowej. W końcu go rozwiązałem, zajęło to 5 godzin, ale spędziłem około 25% czasu na niewłaściwym torze, próbując rozwiązania CSS3, które działało tylko w najnowszych przeglądarkach, i wreszcie odkryłem, że nie ma możliwości powrotu przez JS (jak pierwotnie myślałem). Czy powinienem obciążyć klienta 25%?

Więcej szczegółów: nie podałem prognozy, podoba mi się wyzwanie jako takie, więc zacząłem nad nim pracować przed podaniem prognozy (ale pracowałem z nim wcześniej, więc wiem, że nie należy do osób, które mają nierealne oczekiwania ). W najgorszym przypadku spędzę 5 niezapłaconych godzin na intrygującym wyzwaniu CSS. Podam jak najbardziej sprawiedliwy szacunek dla nas obu, ponieważ już wykonałem pracę. :)

Edycja: Dziękuję wszystkim, chciałbym zaakceptować więcej niż jedną odpowiedź! Skończyło się na tym, że nie naliczyłem go za dodatkowe godziny (naliczyłem go za 3 i pół), ale wspomniałem o nich, aby wiedział, że pracowałem nad tym więcej niż za to. Być może dlatego natychmiast przyjął „oszacowanie” (które w tym przypadku nie było oszacowaniem, stąd cytaty).

Często mam takie sytuacje, gdy spędzam kilka godzin, robiąc coś, a potem zauważam, że istnieje łatwiejsze rozwiązanie w jednym wierszu lub że mój pierwszy pomysł był zbyt zły itp.

Ogólnie rzecz biorąc, w tych przypadkach robię różnicę między trzema sytuacjami:

• Nowo odkryte rozwiązanie nie było oczywiste i / lub przeciętny deweloper prawdopodobnie też znalazłby się na niewłaściwym torze i / lub zły tor był warunkiem wstępnym znalezienia ostatecznego rozwiązania. W takim przypadku obciążam klienta za czas spędzony na niewłaściwym torze.

• Nowo odkryte rozwiązanie nie było tak oczywiste, ale prawdopodobnie wielu przeciętnych programistów poszło tą drogą bezpośrednio. Innymi słowy, gdybym pomyślał lepiej przed rozpoczęciem pisania kodu, prawdopodobnie mógłbym bezpośrednio znaleźć ostateczne rozwiązanie, a może nie. W takim przypadku obciążam klienta, ale obniżam cenę o połowę lub procent, który wydaje się najbardziej odpowiedni.

• Oczywiście byłem zbyt głupi, zbyt senny lub wcale nie myślałem, zanim zacząłem pisać kod, ponieważ ostateczne rozwiązanie było niezwykle łatwe do znalezienia. W tym przypadku, nawet jeśli spędziłem dwa dni na niewłaściwym torze, to na własną odpowiedzialność, a klient nie musi za to płacić.

Nie sądzę, że byłeś na złym torze. Zakodowałeś rozwiązanie, przetestowałeś rozwiązanie (kudos) i okazało się, że nie działa zgodnie z oczekiwaniami. Debugowałeś rozwiązanie, a następnie dokonałeś naprawy, idąc w innym kierunku.

IMHO, to nie jest zły utwór. To regularne tworzenie oprogramowania.

Gdybym był tobą, naliczałbym za pełne 4 godziny.

Większość programów, które piszemy, piszemy, ponieważ rozwiązanie nie jest od razu, łatwo dostępne. Prawie wszystko, co robimy, obejmuje naukę czegoś nowego. Klient nie płacił za produkt. Płacił za naukę budowy produktu i dawanie rezultatów (a jeśli sam nazwał to „wyzwaniem”, oczekiwał, że się czegoś nauczysz). Zobacz „Walc z niedźwiedziami” Toma de Marco i Timothy Listera - „Jeśli projekt nie ma ryzyka, nie rób tego”.

Jeśli chcesz odpowiednio spłacić klientowi, prześlij mu swoje rozwiązanie wraz ze szczegółami rozwiązań, które nie zadziałały, aby mógł przekazać je każdemu zatrudnionemu personelowi i pomóc im również poświęcić mniej czasu.

Do ciebie należy negocjowanie, czy on myśli, że płaci za dużo. Z pewnością spodziewałbym się, że zapłaci za naukę, której nie można łatwo wykorzystać w innym miejscu.

Czasami rozwiązanie problemu polega na wyeliminowaniu nieoptymalnych rozwiązań z zestawu rozsądnych opcji. Proces eliminacji jest jednym z narzędzi rozwiązywania problemów; klient płaci za rozwiązanie i powinien oczekiwać, że użyjesz wszelkich dostępnych narzędzi.

Byłby to nierozsądny klient, który oczekuje, że natychmiast wyobrazisz sobie najlepsze rozwiązanie - od razu po odprawie do projektu na klawiaturze, gdzie emitujesz szybki i optymalny strumień kodu bez wolnego miejsca. Co nie znaczy, że nie ma takich klientów. Poprosiłem klienta, który zadzwonił w trakcie projektu, aby sprawdzić, czy faktycznie płaci tylko za „programowanie, a nie debugowanie”. I oczywiście są klienci (lub szefowie), dla których programowanie jest fizycznym pisaniem.

Twoja ślepa uliczka może reprezentować najlepiej wydane pieniądze klienta: inny programista może nie był tak dokładny jak Ty i dostarczył tańsze, ale mniej kompatybilne rozwiązanie, które odgrywałoby w przyszłości.

te pytania doprowadzają mnie do szału ...

jeśli mechanik lub prawnik spędził czas pracując nad twoją sprawą / problemem, obstawiasz swoją @ $$, że zostaniesz obciążony, nawet jeśli spędziłby czas na złym torze

programiści muszą zacząć bardziej cenić swój czas

To, co zrobiłeś, było całkowicie normalne. Fred Brooks omawia to zjawisko w rozdziale „Plan wyrzucenia z domu” swojej przełomowej książki o inżynierii oprogramowania „The Mythical Man-Month”.

Pracowałeś na umowę na czas i materiały; dlatego należy obciążyć jej klienta za cały czas spędzony na pracy nad projektem. Klient musi ustalić, czy otrzymał wystarczającą wartość dla swojej inwestycji.

Patrzę na to w ten sposób: pod koniec dnia to opłata za połączenie. Istnieje wiele zmiennych, takich jak zadowolenie klienta, istniejące relacje, umiejętności sprzedaży itp. Wszyscy jesteśmy z nimi zaznajomieni. To, co ostatecznie zapewniasz klientowi i czego naprawdę chce, to wartość. Jaką wartość dałeś klientowi i jakie rozwiązanie / produkt dostarczasz mu wart?

Rozwiązanie problemu może zająć 10 minut, ale zajęło Ci 10 lat, aby nauczyć się, jak rozwiązać ten problem. To zasługuje na rozważenie. Jednocześnie niektórzy z nas rozważają możliwość nauki kompensacji „w pracy”. Często uczę się rzeczy, które tak naprawdę leżą po stronie klienta, uważam to za formę niepieniężnej rekompensaty.

Możesz również dodać go do rachunku, a następnie oznaczyć go jako „uprzywilejowaną zniżkę dla klienta” na fakturze, nie obciążaj i nie buduj dobrej woli. Robię to co jakiś czas, co sprawia, że ​​klient czuje się dobrze.

Twoje pytanie, czy są programiści zarabiający tysiące dolarów dziennie, odpowiedź brzmi: tak. Powinieneś być jednym z nich, posiadając swoje umiejętności. Jestem praktycznie tam i nie jestem bliski bycia w tej samej lidze z tobą w CSS.

To zależy od pierwotnej umowy.

Czy powiedziałeś, że zamierzasz dostarczyć to gotowe i gotowe? Następnie lepiej ładuj za cały czas, który spędziłeś na jego rozwijaniu. Wszystko!

Jeśli zatrudnisz prawnika, który będzie się za ciebie kłócił, a oni skończą z tym i przegrywają, nadal płacisz rachunek.

Tak robią wszystkie inne zawody. Nie ma powodu, dla którego programiści powinni robić inaczej.

Jeśli klient myśli, że zapłacił za dużo, nie wróci do ciebie. Utrzymanie ich jako stałego klienta jest jedynym rozsądnym powodem, aby nie rozliczać się za wszystkie przepracowane godziny.

Jeśli to projekt, który specjalnie podjąłem, aby ktoś mi zapłacił, podczas gdy ja nauczyłem się nowych technologii, zwykle robię to za mniej niż zwykle naliczam czas. Z drugiej strony, nie możesz licytować zbyt nisko, bo w przeciwnym razie będzie wiecznie dziwiał się z tym klientem („Hej, w przeszłości, kiedy zrobiłeś tę naprawdę fajną rzecz, zapłaciłeś o wiele mniej niż to!”) W przeciwnym razie nie T Bill za czas, w którym spieprzyłem i skończyło się to zbyt długo.

Mój wyjątek od tej zasady: jeśli powodem, dla którego problem zajął wiele godzin, jest to, że klient wkurzył mnie za coś, co złamał, naliczę opłatę za całość.

Zwykle nie pobierałbym opłat, gdyby to była rażąco moja wina i po prostu szarpałem się, ale wcale nie jestem mądry. Przekonałem się, że większość inteligentnych ludzi biznesu stosuje tę filozofię, że klienci płacą za swój czas , a nie tylko efekt końcowy. Wiele razy w mojej karierze z perspektywy czasu żałowałem, że nie pomyślałem w ten sposób. Wszystko, o czym myślałem, to wynik końcowy jako wartościowy, a mój czas jest bez znaczenia, chyba że poprawi to wynik końcowy. Można jednak ciągnąć za sobą i tracić dużo czasu w wyniku zmiany zdania przez klientów, współpracowników powodujących błędy, które są przypisywane do ciebie i opóźniających pracę, np. Nie tylko dlatego, że potrzebujesz trochę więcej badań z góry, aby naprawdę wiedzieć, co robisz.

Kiedy zaczniesz naginać zasady i robić wyjątki od tego, za jaki czas pracy należy płacić i co powinno być bezpłatne, można w końcu łatwo skorzystać. Czas jest najłatwiejszym wskaźnikiem płatności. Uwalnia cię od złożonej odpowiedzialności, która może wydawać się nieodpowiedzialna, ale chroni cię przed ciągnięciem za sobą i pociąganiem do odpowiedzialności nieodpowiedzialności klienta, co może prowadzić do obniżki płac.

W moim przypadku byłoby beznadziejnie, gdybym nie mógł pobierać opłat za zejście niewłaściwą ścieżką, ponieważ często pracuję nad takimi rzeczami:

... próbując pokonać prawie 40-letni algorytm podziału Catmull-Clarka, który został ugruntowany w branży i wielokrotnie udoskonalany przez firmy takie jak Microsoft i Pixar, próbując zapewnić bardziej intuicyjne wyniki, zachowując jednocześnie taką samą konkurencyjność jak te wielkie firmy pod względem prędkości.

W 95% przypadków w takich przypadkach wybieram złą drogę, ciągle wracając do tablicy po awarii po awarii po awarii. Gdybym nie mógł naliczyć opłat za swoje niepowodzenia, byłbym już bezdomny. Widzę ponad połowę mojej pracy jako badania, kiedy nikt nigdy wcześniej nie próbował takich rzeczy i nie ma sposobu, żebym mógł znaleźć idealne podejście do rozwiązania problemu przy pierwszej próbie (może 20. próbie). Dla mnie celem nigdy nie było odniesienie sukcesu przy pierwszej próbie, ale porażka tak szybko, jak to możliwe, a każda porażka po porażce dostarczała pewnych wskazówek co do tego, jakie może być właściwe rozwiązanie, które może zmienić świat.

Nie każdy może pracować w tak intensywnym obszarze badań i rozwoju, w którym klienci chcą i oczekują, że pokonasz najbardziej ugruntowane techniki po prostu dlatego, że zaczynasz nowy projekt, ale dla mnie programowanie nigdy nie jest rutynowe bez względu na to, jak proste i ustalone rozwiązanie jest. To, jak projektujesz i integrujesz części, będzie nadal wyjątkowe, zawsze jakaś forma sztuki sama w sobie przyniesie unikalne zalety i wady, nie mechaniczna, nie do końca naukowa, w przeciwnym razie roboty mogłyby to zrobić. Myślę więc, że nieuchronnie zawsze będziemy musieli naliczać opłaty za zejście niewłaściwych tras tu i tam, w przeciwnym razie bylibyśmy w stanie skorzystać z najbardziej rutynowej pracy, którą wykonaliśmy już sto razy, dla której stosujemy dokładnie to samo rozwiązanie za każdym razem, w którym to przypadku pobieramy opłatę za naciśnięcie przycisku kopiuj i wklej.

Nieprzewidywalność

Inną rzeczą jest to, że programowanie jest zawsze trudne, nieprzewidywalne, nigdy rutynowe. To nie jest rutynowa dostawa pizzy, w której można wyjaśnić wszystko oprócz wypadku samochodowego (niestety pracowałem kiedyś u szefa, który zrównał szacunki programisty z szacunkami dostawy pizzy i myślałem, że jedyną pracą, którą faktycznie wykonujemy, było pisanie) . Uczą się na stronie, zawsze - nie wyobrażam sobie, aby kiedykolwiek stała się w pełni rutynowa, chyba że ktoś faktycznie wielokrotnie płacił mi za wdrażanie w kółko. Tam zawsze będą jakieś eksperymenty i nauka, i dopóki nie będzie to przesadne, nie musisz czuć się winny z tego powodu.

Często marzyłem o zostaniu rolnikiem lub czymś takim, aby móc znaleźć o wiele więcej rutynowych ruchów w mojej pracy, nie zawsze przekraczając granice mojej istniejącej wiedzy. Zamiast tego staram się to zrekompensować, czyniąc moje życie poza pracą tak rutynową i tak przyziemną, jak to tylko możliwe, aby dodać trochę przewidywalności i rutynowych ruchów ze względu na zdrowie psychiczne, co sprawia, że ​​nudzę się wśród ludzi, którzy chcą znaleźć podniecenie w swoim życiu na zewnątrz pracy - w pracy jest wystarczająco dużo.

Mówi o uczeniu się nowych rzeczy, a nie pracy nad złym rozwiązaniem.

Praca nad niewłaściwym rozwiązaniem polega na uczeniu się nowych rzeczy, prawda? Czy wiesz, że było to złe rozwiązanie, kiedy zacząłeś, czy nadal wytrwale nad nim pracujesz, nawet jeśli wiedziałeś, że jest to beznadziejnie złe? Mam nadzieję, że nie ten drugi. Często proces uczenia się odbywa się przez pomyłki. To najlepszy nauczyciel. Najbardziej skuteczną strategią, którą znalazłem, jest jak najszybsze popełnienie błędów, odkrycie, że to one rzeczywiście projektują błędy tak szybko, jak to możliwe, zanim przekażemy im wszystko i poślubimy takie rozwiązania, ponieważ jedyną stałą, jaką mogę policzyć i przewiduj z niemal 100% pewnością, że popełnione zostaną błędy. Są drogie tylko wtedy, gdy zostaną odkryte naprawdę późno.

To naprawdę zależy od tego, jak zaproponowałeś projekt i od tego, jak projekt jest rozliczany.

Na przykład, jeśli jest to umowa oparta na wynikach, wówczas wszystkie godziny, niezależnie od tego, należy śledzić w kierunku projektu, nawet jeśli chodzi o naukę czegoś nowego.

Jeśli jest to umowa oparta na czasie i materiałach, musisz być bardziej wrażliwy na to. Na przykład, jeśli jesteś w kontekście problemu i masz problemy, powinno to być rozliczane. Przykładem tego jest, jeśli uczysz się starszego API lub nieco kodu i próbujesz uzyskać to do pracy z twoim kodem.

Jednakże, jeśli ktoś śledzi Cię na boku, próbując coś zrobić lub po prostu chcesz nauczyć się, jak to robić w nowy sposób, naliczę tylko tyle czasu, ile zajęło wdrożenie rzeczywistego rozwiązania, a nie tyle czasu, ile się nauczyłem.

Nie zgadzam się z Lunivore, że płacą nam za naukę. Płacą nam za naszą wiedzę i przez większość czasu powinniśmy już wiedzieć, jak to zrobić. Płacą nam za wdrożenie.

Krótko mówiąc, jeśli początkowe oszacowanie nie zawierało czasu potrzebnego na poznanie problemu, prawdopodobnie nie powinieneś za niego naliczać. Podziwiaj to jako doświadczenie edukacyjne i wiedz, że następnym razem nie będziesz mieć takiego opóźnienia.

Edycja: Ponieważ później określiłeś, że nie było oszacowania, z pewnością nie uwzględniłbym tego czasu, jeśli uważasz, że będzie to klient powtarzalny. Zawsze w przyszłości zawsze przedstawiam szacunek z góry.

Aby obejść ten problem, myślę, że moim zdaniem byłby to zły przypadek i cytuję na podstawie godzinowej oceny tego, co moim zdaniem powinno zająć, z maksymalną kwotą ustaloną przez „zły” przypadek. W ten sposób oboje jesteśmy zwycięzcami.