Inne podejście do wyceny zadań programistycznych

Na początku stycznia napisałem taki zaczepny tekst o tym co zrobić jak nie można dostać podwyżki. Był to taki mój autorski pomysł, dość kontrowersyjny. W czasie wymyślania tamtego pomysłu, wymyśliłem też inny pomysł na to jak można bardziej zmotywować programistów do szybszej pracy a jednocześnie też jak lepiej wyceniać czas pracy nad danym zadaniem i nie doprowadzać do sytuacji wyciskania ostatnich potów z ludzi. Zapraszam na mój kolejny pomysł.

Tło

Jest kilka sposobów aby dobrze wycenić daną zmianę. Można pogadać z programistą i ustalić na spokojnie ile dana zmiana zajmie i jeśli każdy ma jakieś doświadczenie to taka wycenia jest dość miarodajna. Są też takie sposoby, że można zrobić głosowanie w zespole, ile taka zmiana zajmie i np: wyciągnąć średnią. Wszystko spoko, ale żaden w tych sposobów nie gwarantuje, że uda się wykorzystać w 100% potencjał danego programisty lub zespołu. No czasem ktoś zawyża, czasem ktoś ma chorą ambicję i mocno się przecenia i później nic z tego nie wychodzi.

Żebyście mnie źle nie zrozumieli to wszystko dobrze działa, bo każdy jest tego świadom, że taka 100% wycena jest nie możliwa do zrobienia ale nikt Nas nie broni przed szukaniem nowego podejścia.

Kasa, Kasa, Kasa

Mój pomysł jest prosty, zakładamy, że przychodzi szef i pyta się ile taka zmiana zajmie. Wyceniasz ten pomysł na tyle ile myślisz, że go zrobisz. A szef mówi (lub nawet Ty(choć było by to moralnie nie pewne)), że np: 5 dni to sporo ale dołoży programiście, który będzie się tym zajmował 300zł jeśli do zrobi w 3 dni. Wtedy programista może się zastanowić jeszcze raz, czy da się to zrobić w 3 dni. I tu następuje najważniejszy moment tego pomysłu.

programista sam decyduje czy chce się mocniej spiąć, być może poświęcić więcej czasu prywatnego aby dokonać tego heroicznego czynu jakim jest szybsze zrobienie tematu za 300zł

… a firma dzięki zainwestowaniu 300zł ma pewność, że po pierwsze temat będzie gotowy szybciej a po drugie, że dokręciła śrubę do przyzwoitego oporu czyli do tego momentu, że sam pracownik chce to zrobić.

Pomysł ten można też rozszerzyć o inne opcje, że sam szef może wyceniać zadanie i od razu proponować stawki za szybsze wykonanie zadania.

Może być tych stawek więcej niż jedna. Za 2 razy szybciej 1000zł za 5 razy szybciej 10000. To już oczywiście żarty ale rozumiecie o co mi chodzi : )

To tylko pomysł, ma swoje wady o których niżej ale zawsze też można do jakoś zmodyfikować i dostosować do okazji.

Kasa to nie wszystko (?)

Ma ten pomysł kilka minusów. Najważniejszy to taki, że koniec końców i tak było by można zawyżać wyceny i w końcu firma by dokładała 300zł i też by nie było to zbyt akuratne. Ale… można by taki pomysł stosować tylko w ważnych momentach a nie na co dzień.

Wg podręczników, motywacja wg kasy zawsze się w końcu źle kończy lub nie daje takich wymiernych korzyści (10 dni po podwyżce, każdy i tak znów pracuje tak samo szybko jak przed podwyżką).

Po czasie pewnie, stawki programistów spadną, bo i tak każda firma będzie dopłacała do każdego zadania i wtedy ktoś może zapytać.

Motywacja do pracy

No i w sumie, dochodzimy do tego jak znaleźć dobrą motywację do pracy, a nie ma na to prostej ani też trudniej ale pewnej odpowiedzi, więc pomysł kasy za czas może być całkiem udany.

Gdy mówię o tym pomyśle publicznie to dużo osób się śmieje jednak wydaje mi się, że można by kiedyś spróbować takiego rozwiązania. Na pewno się to nie nadaje do wszystkich zespołów jednak wyobrażam sobie, grupę studentów i zastosowanie takiego pomysłu może przynieść jakieś korzyści.

Teoretycznie jest to też pomysł dla firm, które zlecają wykonanie danego zadania. Najpierw wycena, potem negocjacje aby ją obniżyć a potem kolejna tura aby zaproponować większą kasę ale zbić na dniach. Pod warunkiem, że takie negocjacje by były zrobione odpowiednio to wydaje mi się, że by taki pomysł miał rację bytu.

A Wy co myślicie?

4 komentarze do “Inne podejście do wyceny zadań programistycznych

  1. „A szef mówi (lub nawet Ty(choć było by to moralnie nie pewne)), że np: 5 dni to sporo ale dołoży programiście, który będzie się tym zajmował 300zł jeśli do zrobi w 3 dni. Wtedy programista może się zastanowić jeszcze raz, czy da się to zrobić w 3 dni”

    Jeżeli programista stwierdza, że za 3 stówy więcej jest w stanie daną rzecz zrobić szybciej to albo pierwsza wycena 5 dni była zawyżona, albo jest pracownikiem który sobie leci w chuya przy robieniu zadań xD.
    Co za tekst bez sensu.

    1. Własnie o to chodzi. Aby jakoś temu przeciwdziałać, aby deweloperzy nie lecieli sobie w kulki. Wyobraź sobie, że taka propozycja idzie na 2-3 ludzi i każdy z nich, ma różne umiejętności. Dzięki konkretnej cenie, ktoś kto umie więcej będzie wiedział, że te 5 dni to są z czapki więc wycena się obniży. A potem szef będzie podnosił poprzeczkę i kolejne zadanie będzie po prostu lepiej wyceniane na początku. Dzięki za komentarz.

  2. Myślę ze cena powinna być kreowana od podstawowej stawki za wykonanie zadania + dodatki jak expresowe wykonanie, dodatkowe zadania który wynikły podczas pracy czy jakość ( ma działać czy ma wyglądać )

    1. Cześć, dzięki za komentarz. Świetny pomysł. Tak by było super. Czasem człowiek się stara aby było szybko i potem w sumie się okazuje, że to nie było potrzebne. Gdyby takie stawiki były ustalone przed projektem można było by się pokusić o osiągniecie ich. Takie osiągnięcia jak w grach.

Możliwość komentowania została wyłączona.