Vykazovanie práce a odpracovaného času

[Syu-]

Ahoj!

Zaujímalo by ma akoto majú iní developeri v práci čo sa týka vykazovania práce, resp. odpracovaného času na projektoch.

Ja pracujem v e-commerce, kde sa pracovný čas programátora predáva zákazníkovi.Takže v Jire máme tickety s požiadavkami a na vypracovanie je vymedzený čas. Po splnení ticketu si odpracovaný čas vykážeme. To dáva docela zmysel...

ALE je potrebné mať vykázaných aspoň 80% z celkového časového fondu zamestnanca za mesiac. Takže to je asi 6 a pol hodiny plnotučného sekania kódu za 8 hodinovú šichtu. Polhodinová obedová prestávka sa tam nezarátava. Takže máme 1,5 hodiny denne ako rezervu. Z toho si odpočítame prestoje (cik-pauza, chodenie do kuchynky po jedlo a pitie atď) cca 30 min.. Odpočítame si aj 30min. ako cesta po/na obed. Zostane nám plus mínus 30 min. v rezerve - dajme tomu na ďalšie prestoje medzi ticketmi atď.

Poviete si, no dobre, spravím ten task rýchlejšie a vykážem si plný čas. No nie celkom. Tickety sú častokrát časovo nacenené docela natesno, navyše by sme si mali vykazovať len 80% kvôli tomu, že ešte sa tam vykazuje code review prípadne testovanie. Keď to neprejde testovaním alebo si projekt manager zmyslí, že tam chce niečo pridať, tak sa ticket vráti a treba to riešiť, ale estimate by sa aj tak nemal prekračovať. A keď sa to už aj nejak stihne rýchlejšie než je vymedzený čas, tak by sa mal vykazovať realny čas.

Takže vo výsledku u nás programátor príde do práce, sadne na zadok a seká kód až do konca šichty. Žiadna playstation, oddychová zóna, šípky a podobné kolotočariny. Proste sedíš a makáš a keď nestíhaš, musíš robiť doma po víkendoch alebo si zobrať dovo.   A aby ľudia neprichádzali zbytočne o čas, tak existujú tickety aj na vykazovanie standupov a meetingov...

Zaujímalo by ma, ako to máte v práci vy?
Myslíte si, že takýto štýl práce je v IT bežný alebo je lepšie radšej utekať?
Díky moc

[Reklama]

[kanoe22]

Utekat.

Ak niekto prida nieco do uz ohodnoteneho ticketu (cize tam prida robotu naviac) a odmietne dovolit jeho re-estimaciu, tak je to uprimne ko.ko.t

Konkretne tickety by mali hodnotit ludia ktori na tom budu robit, resp mozno budu robit - hodnotite to ako tim (predpokladam ze tam mate nejaky agile nasadeny a ste zgrupovany do timov), s tym ze niekto na tom robi. Manazment to nema co hodnotit (cize ani product owner, alebo co tam mate za rolu, on je v principe tiez sucastou manazmentu, nie vyvojar), lebo oni by najradsej aby sa plnil plan na 200% a viac, pretoze potom zhrabnu velmi tucne odmeny, kdezto ty dostanes iba beznu mzdu.

Brat si dovolenku alebo makat cez vikend lebo sa nestiha lebo si nejaky manazer uzmysli za kolko sa co urobi? Hmm, tak nech to za ten cas urobi sam. Vyvoj softveru nie je vzdy dokonale casovo odhadnutelny, niekedy proste narazis na problem ktoreho vyriesenie trva proste dlhsie ako sa ocakavalo na zaciatku. Softverovy vyvoj nie je pasova vyroba.

[anonacct]

Toto jsem nikdy nezažil, utíkej pryč než z toho zblbneš...

[pomprda]

Něco vzdáleně podobného jsem v práci měl, ale tam by ta motivace za tím jiná.
Museli jsme mít jako tým průměrně nějakou určitou část hodin napsanou na produktivní konta. Bylo to tuším 85%. Jinak nebyl měsíční bonus. Šlo snad jenom o 1500 Kč nebo něco takového, ale i tak jsme o to samozřejmě nechtěli přijít. V praxi to nakonec vypadalo tak, že když by to bylo ohrožené, tak jsme to na konci měsíce trošku pošmelili a vykázali "na projekt" i dobu kdy jsme byli třeba na nějakém důležitém školení o firemní politice "rovných příležitostí" a vedení bylo spokojené. Hlavně, že oni dosáhli nějakých ukazatelů utilizace personálu, od které se jim beztak určitě odvíjela pohyblivá část odměny.

Jak to uvádíš ty, tak pokud nejsi ohodnocen od úkolu a to v nějaké nadstandartní výši, tak to zní jako fabrika na kód.

[Syu-]

väčšie implementácie nových vecí alebo úpravu tých starých si naceňujeme v rámci teamu my sami v konzultáci s projekťákmi. Bugy a "menšie" veci stanovuje priamo projekťák alebo tester. Takže kto chce byť relatívne v pohode, robí na ticketoch nacenených niekým z teamu. Horšie sú tie bugy a menšie zmeny. Tickety od projekťáka majú estimate prevažne 1 hodinu, takže real môžeš pracovať 50 min. Projekťák poriadne ani nevie čo má v tom projekte, zadanie častokrát nejasné, dokumentácia žiadna, nutnosť debuggingu, kód z roku 2017 a cca 20 - 30 projektov, ktoré sa spravujú. Ja ako nováčik dostávam hlavne tie bugy a už sa mi stalo aj také, že v rámci jednohodinového ticketu som riešil štyri rôzne veci alebo som mal implementovať feature, kde by sa podľa množstva kódu uživili v pohode 2-3 hodiny. 

[Reklama]

[kanoe22]

Tiket ktory trva iba jednu hodinu neexistuje.

Ak ma nejaky tiket fakt trvat iba hodinu a to ho ma po tebe este niekto skontrolovat kym sa to mergne do development branche, hmm, je to proste nonsens, a to z viacerych dovodov:
- ste (minimalne) dvaja ludia ktory si maju nastudovat o co ide (developer a tester), aj keby to kazdemu zhltlo len 5minut -> vo vysledku ste prave minuly 10minut z jednej hodiny
- implementacia nieco trva, testovanie nieco trva, a nie, ani jedna vec urcite netrva len 15minut, ak ano, vid nasledujuci bod
- ak ide fakt o tak primitivnu vec na par minut, netreba na to robit tiket a hodnotit ho, pretoze sa tym prave zrejme zabilo viac ako hodina casu. Dajme tomu manazer to napise za 10minut co tam treba, tim napr 5tich ludi na to kuka 10minut co tam treba urobit a ohodnoti to, vo vysledku je ta jedna hodina uz spotrebovana. 50% casu by sa stravilo spisovanim ulohy a odhadom jej narocnosti, len 50% casu by bolo stravenych implementaciou.

[Idris]

Zaujímalo by ma, ako to máte v práci vy?

U nás se čas nevykazuje, Jira slouží na sledování stavu ticketů a jejich provázání s Gitem a dalšími nástroji. Časové odhady mají u nás granularitu půl dne a nikdo to moc neřeší, beztak se většinou čeká na zákazníky, než se vyžvejknou se specifikací, testy apod.

[alex6bbc]

silene, ja zapisuju kazdy den 8 na stejny ukol a je to :-)

[to_je_jedno]

silene, ja zapisuju kazdy den 8 na stejny ukol a je to :-)

nebo 7,5 a k tomu pul hodky na standup :-)

Tazatel by mel vzit nohy na ramena a zdrhat. Vubec nechapu jak muze projektak nebo testar "stanovit" nejaky pracnosti. Miluju realne vedeny agile.

[e3k]

pracujem cez personal leasing a musim bookovat hodiny v mojej spolocnosti. potom bookovat hodiny u zakaznika. zakaznik je nemec takze tam na kazdy ukon potrebujem konto na ktore bookujem pracu. nie vzdy to konto mam takze po odrobeni prace si musim vypytat konto. no a ked mi ho nakoniec daju tak zistim o tyzden ked robim na 2hom tasku pre rovnake konto ze uz mi konto neni platne takze si ho musim pytat znova.

osobne to robim ale tak ze nebookujem skoro nikde a cakam kym ma vyhodia za to

[3ugeene]

Cywe,

to mi pripomina firmu, kde po zadani ukolu zakaznikem (vsechno jelo pres redmine) musel programator dany ukol casove 'nacenit' jak dlouho to bude trvat. Zakaznik to pak schvalil a dany limit se nesmel prekrocit. Pokud se tak stalo, prekroceny casovy limit nebyl programatorovi pocitan jako prace.

Takze jsem si myslel, ze to je jednoducha vec, dal jsem tomu hodinu, ta byla schvalena a relaita byla takova, ze jelikoz projekt byl sama spagetarna, tak se to misto hodiny delalo celej den a najednou si vas zavolalo vedeni s tim co to jako ma znamenat. Nastesti muj odchod vyresilo neco uplne jineho, ale i pres to bych tam dalsi ctvrtrok nevydrzel, protoze se tam taky resily kokotiny typu 'Z minulyho mesice ti tady chybi hodina, kdy si to hodlas nadelat???!?!!?'

Nedavno jsem koukal na webovky ty firmy a z 8 programatoru zustali dva, kde jeden je novacek a druhej spolumajitel firmy.

No zkratka rychle vypadnout. Takhle se s programatorama nejedna

[registrovany123]

Pozor na takove firmy.
Ja tohle zazil ve firme Lundegaard. Odesel jsem odtamad jeste ve zkusebnce. Taky tam meli playstation atp., ale tipuju ze zejmena proto, aby si ho mohli dat na Facebook a ukazat ho pri vstupnim pohovoru.

Ad situace, kdy se neco programatorovi nepocitalo jako prace, kdyz prekrocil estimate. To jednoznacne porusuje zakonik prace. Kdyby mi rekli, ze na necem budu pracovat, a ze se mi to nebude zapocitavat do prace, tak bych se hecl, a jdu normalne pryc. Uvedomte si, ze kdyz zamestnavatel porusuje zakonik, tak vy se muzete zvednout a adios amigo okamzite.

Neni to ani prace prescas, protoze:

"Práci přesčas může zaměstnavatel nařídit jen "z vážných provozních důvodů","

Vyse uvedene neni vazny provozni duvod.

[MalyTomi]

Ano, aj ja som to tak mal. Ale:
1) pocitalo sa s 80% aktivnej prace
2) nacenoval to programator + davala sa tam rezerva min. 40% na opravy, alebo ked narazis na nieco necakane
3) Ak by hrozilo, ze sa prekroci cas, tak sme zvykli to dopredu oznamit aj s dovodom preco - napr. narazili sme na kod, ktory je jeden velky bordel a kym ho preluskam, tak to potrva.
A nebol problem dat aj viac hodin, proste normalny sef pochopi, ze taketo komplikacie sa stavaju.

[Gregor Fefor]

Zakaznik to pak schvalil a dany limit se nesmel prekrocit.

Toto vedie spoľahlivo k tomu, že sa odhady práce násobia vysokou bulharskou konštantou. Vidím to na kolegovi (ja robím operatívu, teda mňa sa to veľmi netýka), čo vyvíja nejaké polointerné skripty, ktoré reálne platí zákazník. Jeho odhady sú nadstrelené aspoň 3-4krát, za tie časy by som to vyprodukoval aj ja, čo s tým nemám prakticky žiadnu skúsenosť a moc sa tomu nerozumiem...

[kotelgg]

Zakaznik to pak schvalil a dany limit se nesmel prekrocit.

Toto vedie spoľahlivo k tomu, že sa odhady práce násobia vysokou bulharskou konštantou.

Takový postup jsem zatím viděl všude a úplně nevím, jak jinak by to šlo řešit. Schválení ceny musí proběhnout předem (většinou i zaplacení) a to nejde jinak než odhadem počtu hodin. Firma nemůže jít do ztráty, takže počet hodin bude vždy vyšší.