it-swarm-eu.dev

Jaký je příklad dobrého cíle SMART) pro programátora?

V návaznosti na tato otázka , jsem přemýšlel, jestli by lid nebyl schopen navrhnout nějaké vzorky toho, co by mohlo být považováno za „dobrý“ cíl v periodickém revizním cyklu pro programátora?

Pojďme definovat SMART z nejpopulárnějších definic v položka Wikipedia :

  • Charakteristický
  • Měřitelný
  • Dosažitelný
  • Relevantní
  • Časově vázané
20
Mike Woodhouse

Uvědomil jsem si, že SMART cíle) se nejlépe používají, když lidé mají nedostatek, který musí napravit, a nejsou tak dobří, když chcete, aby lidé rostli nebo přecházeli z dobrého na skvělý. někdo například nedělá časové rozvrhy, a to poškozuje společnost, protože někdy musíte zpoždění fakturace, můžete mít chytrý cíl, například: „během následujících 6 týdnů bude alespoň 5 týdnů vyplněno do 10 hodin příští pondělní ráno. “O 6 týdnů později máte pravdu nebo nepravdu; vývojář to udělal nebo mu chyběl. Buď je nový zvyk na místě, nebo se rozhodnete, zda chcete zaměstnat někoho, komu nevadí oddálení vaší fakturace „Pracuje pro lidi, kteří mají i jiné špatné návyky:„ Během následujících dvou týdnů bude mít alespoň 75% vašich kontrolních komentářů checkin, který se řídí pokyny pro checkin (odkaz na interní dokument). “Znovu máte pěkný ostrý/ne na konci této krátké doby.

Tam, kde považuji tyto konstrukty za méně užitečné, je, když se časový rámec prodlužuje, když je požadovaný úspěch nejasný (naučte se jazyk, je více nápomocný), nebo když je to v pořádku, pokud se cíl nedosáhne (můžete ocenit certifikace, ale pokud někdo selhal) jejich test byste pravděpodobně neučinili disciplinárním řízením.) Najednou všechny výhody inteligentního cíle odpadnou. Nesnažte se je použít k ničemu jinému než k nápravným opatřením. Snadno se zapisují, pomáhají vývojáři dostat se na očekávanou úroveň a snadno se vyzkouší, kdy čas vyprší. Problémy s jejich napsáním znamenají, že nejsou tím pravým nástrojem pro tento cíl.

37
Kate Gregory

Vzhledem k tomu, že se chystám na rozhovor se svým šéfem o stanovení cílů, myslel jsem, že přidám několik příkladů, které jsou podobné těm, které zvažuji pro sebe:

  • Do 31. března zvýšíte pokrytí testem pro kód v projektu X alespoň na 95%.
  • Dokončete a distribuujte první koncept dokumentu Project Y Architecture do 30. dubna
  • Shromážděte komentáře k revizi dokumentu architektury, v případě potřeby aktualizujte a do 30. června vydejte dokument v1.-0

Očekávám, že se další práce uskuteční ve lhůtách, které jsem stanovil (vždy to mělo vždycky, nakonec) a že práce může mít vliv zejména na aspekt „včasný“. To by neměl být problém: cíle by měly být pravidelně přezkoumávány, aby bylo zajištěno, že i nadále splňují kritérium „dosažitelné“. Budu se muset ujistit, že o tom nechám svého manažera ve smyčce - nikdo nemá rád nepříjemná překvapení na konci roku ...

7
Mike Woodhouse

Pokud prodáváte software nebo produkt se softwarem v něm ...

Zvýšení prodeje n%.

Opravdu.

Pokud by software nepracoval, příliš byste ho neprodali.

Pokud by software fungoval SKUTEČNĚ RALLY WELL, prodali byste hodně.

(To bude mít softwarové kluky sledovat prodejní kluci jako jestřábi, aby se ujistili, že nevyhodí svůj výkonnostní bonus.)

Pokud máte software interní systém:

snížení nákladů na podnikání n%.

Pokud nové softwarové systémy zabere 10x tak dlouho, stojí to firemní peníze. Pokud je nový systém rychlý a zabraňuje chybám, šetří společnost peníze.

Tento přístup se zdá, jako by se vztahoval na prodejce nebo možná na viceprezidenta procesu změny podnikání, ale ve skutečnosti jsou vývojáři softwaru první linií pro oba druhy procesů.

Moje základní myšlenkou je pokusit se explicitně sladit strukturu odměňování zaměstnanců s nejlepším možným výsledkem pro společnost.

2
Tim Williscroft