Oto pytanie przeciwne. Jeśli myśli o rozwiązaniu w drodze do domu, czy może wystawić rachunek za to, że pracował nad problemem?

Programowanie to MYŚLENIE , a nie pisanie. Jeśli spróbujesz to zniwelować, NIKT nie będzie pracował dla Ciebie.

Jeśli jego komputer zawiesza się lub ulega awarii, czy chcesz, aby przestał naliczać opłaty po ponownym uruchomieniu? Czy zamierzasz odliczać czas użytkowania jego łazienki i odliczać to od jego godzin pracy?

To, co robi twój kolega, jest powszechną praktyką wśród programistów i ludzi w ogóle, nazywaną „ostrzeniem piły”. To sięga aż do czasów, gdy drewno było wycinane ręcznymi piłami. Po pewnym czasie piła stępiała się i była mniej efektywna. Od czasu do czasu trzeba było zatrzymywać i naostrzać piłę, w przeciwnym razie ścinałbyś mniej drewna, gdybyś kontynuował pracę, zamiast poświęcać czas na ostrzenie piły.

To, co robi twój inżynier, to właśnie to. Ostrzenie piły, a dokładniej umysłu. Rozwiązanie tego problemu zakończy się źle, ponieważ w końcu otrzymasz więcej rozliczanych godzin za mniejszą wydajność.

Kontynuuj na własne ryzyko

Płacisz ludziom za pracę, a nie maszynom. Jest to ważny czynnik, który należy wziąć pod uwagę. Niektórzy ludzie robią sobie przerwę i po powrocie wykonują znacznie więcej pracy niż próbują się przebić. Przerwy w łazience również są częścią tej sytuacji, ponieważ ludzie muszą sobie radzić. Zwykle jest to analiza „racjonalności”. Różne kraje i instytucje mają różne definicje tego, co jest rozsądne dla utrzymania człowieka przy wykonywaniu pracy.

Stany Zjednoczone zezwalają federalnie na 2 15 min. płatne przerwy w ciągu dnia pracy. W niektórych krajach obowiązuje 35-godzinny tydzień pracy. To naprawdę zależy. Ogólnie osobiście uważam 30 min. w ramach normalnej pracy, kiedy jest powyżej, zaczynam to kwestionować, ale to tylko ja. Twoja firma i podmioty stowarzyszone powinny dyktować, co uważają za rozsądne w granicach prawa krajów / stanów / prowincji / terytoriów.

Jakie są godziny podlegające rozliczeniu?

To jest pierwsze pytanie, na które musisz odpowiedzieć, aby wiedzieć, jaka jest prawidłowa odpowiedź. Twoje pytanie sugeruje, że Twoim zdaniem godziny podlegające rozliczeniu to czas spędzony aktywnie na dostarczaniu Ci produktu lub usługi. Różni się to w szczególności od definicji, w której rozliczane godziny to czas, który musiał zostać spędzony , aby dostarczyć Ci produkt lub usługę.

Twierdzę, że druga definicja jest dużo bardziej realistyczny. Jeśli okaże się, że inny programista mógłby wykonać tę pracę o połowę krócej, czy spodziewasz się, że rozliczane godziny również w tym projekcie zostaną zmniejszone o połowę? To nie wydaje się realistyczne, ponieważ ten programista musiał poświęcić ten czas na dostarczenie produktu. Nie mogli spędzić tego czasu pracując nad innymi produktami lub usługami i spędzili ten czas w Twoim imieniu.

Czy to 30 minut spacerem jest dla nas płatne?

Jest to coś, o co musisz zapytać międzynarodową firmę informatyczną, ponieważ zależy to wyłącznie od umowy z nią. Nie różni się to zbytnio od pytania „czy za przerwę obiadową nalicza się opłatę?”

Osobiście, gdybym miał zespół wykonawców pracujących nad projektem i widziałem, jak każdego dnia robili 30-minutowe przerwy na spacer , Byłbym bardzo zaniepokojony. Wracałem do firmy wykonawczej i pytałem, co się dzieje. A moja umowa z nimi zazwyczaj pozwalała mi na wymianę części lub wszystkich, gdyby nie spełniały moich oczekiwań.

Gdybym uważał, że 30-minutowa przerwa jest konieczna (zazwyczaj nie jest) , a produkowana praca była do tego lepsza, więc nie narzekałbym. A jednorazowa lub bardzo sporadyczna 30-minutowa przerwa, gdy utkniesz, jest całkowicie rozsądna.

Ale każdy, kto wielokrotnie utknie i potrzebuje 30 minut, aby się odblokować, pokazuje, że nie ma wystarczających kwalifikacji, aby pracować w siedzibie klienta. Chciałbym je usunąć i zastąpić kimś, kto nie zacinał się tak często.

TL; DR: Jeśli chcesz wiedzieć, co jest płatne, a co nie, przeczytaj umowę i porozmawiaj z kampania kontraktowa. Tylko w ten sposób będziesz wiedzieć na pewno.

Pamiętaj, że nie pytamy, czy jest to płatne w konkretnym przypadku, ale aby zrozumieć, jak to zwykle działa, ponieważ nigdy nie pracowaliśmy z zewnętrzną konsultant programista.

„Jak to zwykle działa” nie jest tak ważne, jak to, jak chcesz , aby to działało. Włącz ją do umowy, a ktokolwiek ją zaakceptuje, będzie robił rzeczy tak, jak chcesz, bez względu na to, jak robią to inni.

Mam doświadczenie w zamawianiu tworzenia niestandardowych systemów informatycznych dla moich miejsc pracy, a także dostosowywaniu istniejących systemów 3D do naszych specyfiki.

Opierając się na tym doświadczeniu, w Twoim przypadku ograniczyłbym zadanie do wykonania do momentu, gdy wykonawca będzie mógł oszacować liczbę godzin potrzebnych do wykonania tego zadania.

Zwróć uwagę, że w zależności od wielkości projektu samo zawężenie może być nie lada zadaniem. Jeśli masz wykwalifikowany personel do opisywania wymagań biznesowych, możesz to zrobić na miejscu, w przeciwnym razie może to mieć miejsce w przypadku niektórych godzin konsultacji.

Niezależnie od tego, nie przystąpiłbym do żadnego projektu bez oszacowania wydatków wykonawcy. Po uzgodnieniu kosztów - w tym fakturowania za potencjalne nieprzewidziane okoliczności niezawinione przez wykonawcę - faktycznie spędzone godziny stają się nieco nieistotne. Nadal służą jako podstawa do rozliczeń, ale nie ma sensu spierać się o +/- 1 godzinę, ponieważ w tworzeniu oprogramowania trudno [iw tym przypadku niepotrzebne] jest kontrolować, co dokładnie zostało zrobione w którym momencie.

EDYTUJ:

Aby wyjaśnić. Moim zdaniem i z doświadczenia złą praktyką jest liczenie godzin i minut w sposób, w jaki zakładano to w pierwotnym pytaniu, ponieważ oznacza to brak zaufania do wykonawcy ORAZ - chyba że sam jesteś sklepem IT - masz generalnie niewielką drogę KONTROLOWANIA go. Możesz więc skończyć z kłótniami o godziny w sytuacji, w której często nie masz innego (lub żadnego taniego) sposobu na sprawdzenie jego prawdziwości.

Moje podejście byłoby następujące:

1. Ogólnym celem jest kontrolowanie wydatków na osiągnięty wynik, dlatego należy zawęzić rzeczywiste potrzebne godziny tak bardzo, jak to tylko możliwe. Załóżmy, że zadanie zajmie 40 godzin programowania + testowania, dodaj do niego ~ 10-20% max godzin na korekty z powodu nieprawidłowych wymagań biznesowych itp. I zgódź się, że po maksymalnie 50 godzinach pracy uzyskasz wynik roboczy z tymi parametrami.

Jest to szczególnie prawdziwe w przypadku istniejącego wcześniej systemu ERP, który wymaga jedynie dostosowania do środowiska pracy. Istniejąca funkcjonalność jest dostępna, więc większość adaptacji można opisać jako zmiany w istniejącym systemie - zwykle znacznie łatwiejsze niż tworzenie czegokolwiek od podstaw.

2. Jeśli to niemożliwe aby wiedzieć, ile godzin zajmie programowanie, zadania programistyczne muszą zostać podzielone lub zebrane dodatkowe informacje o zadaniach, aż można będzie podać konkretne szacunki.

3. Jeśli nadal Wykonawca nie jest w stanie podać żadnych szacunków, które mogłyby stanowić podstawę umowy, wykonawca prawdopodobnie nie jest tego wart.

Należy zauważyć, że jest to sprzeczne z poglądami niektórych firm programistycznych. Praktyki zwinne, które są obecnie często spotykane. Z mojego doświadczenia wynika, że ​​sklepy programistyczne zwinne mają tendencję do przenoszenia całej odpowiedzialności za wynik końcowy na klienta - zrobimy wszystko, co powiesz, za X USD / h. Tak naprawdę nie wiedziałeś, czego chcesz? Trudno.

Myślę, że różne kultury używają różnych terminów do rozliczenia.

Firma, z którą pracuję, omawia projekt z klientem i sprzedaje mu zestaw godzin przed terminem (uwaga, to nie znaczy, że sprzedajemy 40 godzin i otrzymujesz produkt w ciągu jednego tygodnia pracy).

Teraz, jak wspomniał @mutt, zatrudniasz ludzi i nie każda minuta z rozliczonej godziny może być wykorzystana wyłącznie na kodowanie. Moja firma sprzedaje x godzin, ale przez większość czasu spędzamy więcej czasu nad projektem (nie cytuj mnie, ponieważ wiele firm działa inaczej, a ja nie jestem zaangażowany w proces rozliczeniowy tutaj).