Wpis z mikrobloga

@trb: stawka godzinowa x roboczogodziny na podstawie projektu i jego oszacowania pracochłonności, budżet zaakceptowany przed rozpoczęciem prac. Wszelkie prace poza pierwotny zakres projektu szacowane dodatkowo i ponownie akceptowane.
  • Odpowiedz
@aaandrzeeey: chodzi mi właśnie o to jak nabijacie godziny. Czy siedzicie ze stoperem w łapie czy może podchodzicie do tego bardziej liberalnie?
  • Odpowiedz
@trb: Ciężko siedzieć ze stoperem w łapie. Klient chciałby z góry wiedzieć ile zapłaci. To, że jeden task zajął Ci 10x więcej czasu, to wtedy już Twój problem niestety. Dlatego trzeba się uczyć trafnego szacowania czasochłonności zadań, co nie jest łatwe. Wiele początkujących osób niedoszacowuje czasochłonności i potem są problemy, klient niezadowolony, bo deadline przekroczony, Ty niezadowolony, bo tłuczesz kod po o wiele niższej stawce niż sobie to zakładałeś. Czyli
  • Odpowiedz
@the4dk: co ty za głupoty gadasz ;) od mierzenia czasu pracy jest soft a nie stoper w ręku, a klient jest od płacenia za siedzenie przy jego projekcie, absurdem jest branie ryzyka projektowego na siebie.
  • Odpowiedz
@the4dk: ale ja wiem na czym polega szacowanie. mam teraz taki układ, że robię co mam robić, bez pośpiechu i nabijam godziny. Wiadomo, że jezeli pracuję 6h to nie jest to 6h pisania na klawiaturze. Dlatego zastanawiam się jak rozliczacie czas, żebyście i wy, i klient nie byli pokrzywdzeni.
  • Odpowiedz
Dlatego zastanawiam się jak rozliczacie czas


@trb: klik w togglr start, rozpoczecie pracy, koniec pracy klik w stop. koniec. kurtyna ;) Dodam, ze button toggla wyskakuje na jirach, trelach srellach i niemal wszędzie więc nawet nie wchodze na serwis tylko przy zadaniu klikam. a na koniec miesiaca drukuje zestawienie.
  • Odpowiedz
@trb: liberalnie nie można bo klient Ciebie zje. Staram się robić to po prostu uczciwie.

Dzielę na etapy, oraz taski w ramach etapów i szacuję godziny dla tasków.

Task to dla mnie 1- do nawet 40 h. Takie coś można zrobić nawet w
  • Odpowiedz
@aaandrzeeey: w modelu szacunkowym NIGDY nie jest uczciwie bo ZAWSZE traci jedna ze stron: ktoś musi wziąc na siebie ryzyko, a każdy kto robi w tej branzy dobrze wie, że szanse idealnego trafienia z szacunkiem są niewielkie. Więc wykonawca wtedy musi przeszacowywać żeby nie być stratnym.
  • Odpowiedz
Podoba mi się podejście @aaandrzeeey. Napisz proszę jak technicznie rozwiązujesz kwestie dogadywania się i ew. sporów. Jak wygląda umowa itd., bo wiadomo, dopóki wszystko idzie zgodnie z planem, to wszyscy zadowoleni, ale jak coś zaczyna iść nie tak, to trzeba mieć dupochron. Co w sytuacji, jak miało być szybciej i za mniej, ale nie wyszło z jakiś rozsądnych powodów (klient nie wziął czegoś pod uwagę, a Ty też nie zauważyłeś)?
  • Odpowiedz
Dobre wyceny to poważny problem w IT, do tego stopnia, że budżetowaniem zajmują się osobne osoby, nawet działy.


@aaandrzeeey: bierze kase za czas poswiecony na kontakt z klientem i task-owanie czy dajesz za darmo swoj czas ;P
  • Odpowiedz
@normanos: dlatego najpierw szacujesz, a potem się rozliczasz z faktycznej pracy.

Szacowanie pomaga przy tworzeniu budżetów, oraz przy kontraktowaniu pracowników.

A weryfikowane jest to podczas
  • Odpowiedz