it-swarm-eu.dev

Projektový manažer, který chce uzavřít odhad času s podepsanou smlouvou

V předchozím zaměstnání nebyl projektový manažer (PM) spokojen s dodací lhůtou kódu na projektu, na kterém jsem byl. Podle mého vedoucího projektu mi bylo řečeno, že PM uvažuje o tom, že mě podepíše smlouvu na zablokování mých odhadů času , které jsem dal na úkoly a termíny dodání .

Situace na projektu byla v tom, že jsme pracovali s novými technologiemi, codebase, kódovacími standardy a velmi náchylnými na změnu požadavků. Učil jsem se nové věci a aplikoval je co nejlépe na požadavky, které se neustále měnily. Požadavky během iterací vzrostly 2-3krát, přičemž můj odhad na dokončení rostl zhruba 5-8krát. Jediné, co se nezměnilo, byly odhady a termíny dodání.

Ano, nakonec mi chybí většina termínů. A pracoval jsem na některých velmi nových technologiích, na které by nikdo jiný v celém vývojovém týmu nemohl pomoci, protože by s tím nebyli obeznámeni. Alespoň ne snadno.

Tehdy mi připadalo, že PM chtěla, aby se jeho čísla sčítaly - a tak chtěla, abych podepsal smlouvu na „zajištění“, že vždy dodám pracovní kód včas. Předpokládám, že s podepsanou smlouvou by PM mohl použít proti mně, kdybych nemohl dodat včas.

Věřím, že to, co se stalo potom, bylo to, že mě obhajovali jiní projektoví manažeři a/nebo vedoucí projektů, a nedovolili, aby se to stalo.

Moje otázka zní: mělo by to zvýšit červenou vlajku o manažeru? Je běžnou praxí, že správce uzavírá odhady času vývojáře softwaru pomocí podepsané smlouvy? Nebo v tomto případě zkuste.

Vezměte prosím na vědomí, že jsem byl zaměstnancem na plný úvazek, nikoli nezávislým konzultantem.

Aktualizace: Chci dodat, že jsem dával nové odhady každý týden, ale zdá se, že původní odhady a termíny dodání byly PM bylo opraveno.

116
spong

Moje otázka zní, mělo by to zvýšit červenou vlajku o manažerovi?

Ano . To znamená, že je čas, abyste svůj životopis/životopis aktualizovali a začali hledat nové zaměstnání. Nebo to znamená, že váš manažer se s vámi chystá začít hrát velmi ošklivé hry .

Je běžnou praxí, že správce uzavírá odhady času vývojáře softwaru s podepsanou smlouvou?

Nikdy jsem neslyšel o tom, že by se to vztahovalo na zaměstnance.

Odhad času a úsilí je vždy obtížný. Zejména proto, že naše profese je plná nadměrného optimismu. Existuje několik systémů odhadu, které by mohly v budoucnu pomoci s odhady, ale potřebují shromažďovat historické statistiky od sebe. Jedním z nich je PSP . Další je Function Points . Mnoho vývojářů nemá rádi ani jeden, a proti oběma najdete velmi silné názory.

Klíčovým problémem při odhadování času a úsilí je nedostatek zpětné vazby v naší odhadovací heuristice. Jedním z klíčů je zapsat, co si myslíte, že je odhad, a jaké parametry jste použili k odhadu. Poté, na základě toho, co se skutečně dělá, porovnejte to s tím, co jste si mysleli, že uděláte. A to použijte k úpravě parametrů odhadu. Ve strojírenství to nazýváme „ zpětná vazba .“

109
Tangurena

Ano, to by mělo absolutně znít alarmové zvonky.

Kdybych byl v pozici, pro svou osobní zábavu bych požádal manažera, aby podepsal smlouvu zmrazující všechny požadavky. Představuji si, že by manažer pravděpodobně zachránil kauci. Pak jsem odešel.

160
whatsisname

To je jednoduché. Řekněte pouze svému manažerovi, že se přihlásíte k odhlašování svého odhadu času, kdy se přihlásí k uzamčení specifikace. Protože nemůžete určitě poskytnout odhady pro něco, co není známo. Kompletní specifikace projektu před začátkem, žádné změny - a můžete je dokončit včas :)

Jedna změna smlouvy spec => je neplatná. Pravděpodobně to bude neplatné hned po 10 minutách prvního dne :)

59
Slawek

Ano, je to červená vlajka. Říká vám, že manažer nerozumí tomu, jak řídit rizika v softwarových projektech. To, co by měl dělat, je zjistit, co přesně způsobilo zpoždění na prvním místě, a pak začít instrumentovat proces efektivního řízení rizik plánu, k nimž nevyhnutelně dojde během softwarového projektu.

NIKDY bych za žádných okolností nepodepsal smlouvu se svým manažerem, který by zaručoval harmonogram. Jiní se zmínili o tom, že mu podepíše uzamčení podle specifikací. To podle mého názoru nestačí. To nezohledňuje nepředvídané potíže s nástroji nebo technologií, neúplné nebo špatné konstrukce, výkon ostatních členů týmu atd.

31
Pemdas

Toto není červená vlajka, to je hloupost na úrovni zbraní.

Jsou-li odhady a termíny důsledně vyfukovány, je racionální věcí identifikovat příčiny a zlepšit procesy.

Pokud obviňujete a kopnete koně, protože nevíte, kam jdete, nenechte se překvapit, pokud vás kůň kousne a uteče!

27
Steven A. Lowe

Zatímco manažer byl mimo jeho požadavek. Není plně na vině. Pokud jste pracovali na zcela neznámém území, není nic špatného říkat „nevím.“ Chvíli mi trvalo, než jsem si uvědomil, že „já nevím“ je naprosto přijatelná odpověď, takže vím, jak moc to bodá k vyslovení těchto slov. Ale pokud to opravdu nevíte, pak je to odpověď. A pokud se jim to podaří, požádají je, aby vám poskytli odhad toho, kolik haléřů bude zapotřebí, aby byl stack stejně vysoký jako věž Sears (aby to byla Willis). A byli by ochotni podepsat smlouvu, která vám zaplatí za každý cent, který byli pryč?

Každý vedoucí projektu, který stojí za jeho plat, by měl vědět, že některé věci se nehodí do tabulky pěkně a pěkně. Někdy se věci dělají, když jsou hotové. Myslím, že se vám daří dobře, když dosáhnete pokroku v tom, kolik jste udělali. Přestaňte dávat aktualizace čísla.

Dalším úkolem je rozdělit velký úkol na menší odhadnutelné jednotky. Toto cvičení vám pomůže lépe porozumět tomu, co musíte udělat také. Tipy: Podívejte se na softwarový odhad Steve McConnella a Stephen Withall vzory softwarových požadavků , kde najdete tipy o rozepisování úkolů a odhalování skrytých požadavků, resp.

Nestřílejte z kyčle podle odhadu. Udělejte si čas, abyste to rozebrali. Odhadování velkého počtu malých úkolů vám poskytne lepší celkový odhad (kvůli zákonům o průměrech budou některé z vašich odhadů pod, ale některé budou pryč a některé budou mít tendenci se navzájem vážit) velkého úkolu.

19
Michael Brown

Zeptejte se svého „projektového manažera“: Prodáváme software nebo termíny?

14
ThomasW

Jsem projektový manažer a programátor :-) Mohl bych se dlouho rozčarovat o tom, jak je většina PM mimo průmysl a nedokážu zvládnout nic, co se pěkně nehodí do modelu výrobní linky ... ale já ne, ne tady. Místo toho je zde dlouhá polemika o tom, co vlastně dělat (pane Mod, pokud je to příliš dlouho, udělejte, co s ní budete). Souhlasím s komentáři, které zde byly předneseny, některé byste měli udělat před ostatními, ale tady je to, co by podle mě mělo být vaším prvním krokem. Jo, a zřejmá odpověď na vaši otázku je ano, ale to je zpracováno níže v barevném a podrobném jazyce.

Než začnu, všimněte si, že PM vám nejspíš dává zármutek, protože někdo jiný, kdo je dále v potravinovém řetězci, je zármutkem. Oni (my) jsou jednoduchá stvoření ... Existují způsoby, abychom se vyhnuli situaci, kterou jste popsali - Mike Brown to dobře zvládne. Také není nic špatného na tom, že něco připravíte na 3/4/5 .. hodin před tím, než na něj začnete kopat (ve skutečnosti všechny druhy alarmů musí zmizet, pokud to není možné ') Pokud se chystáte do neznámého teritoria, zatlačte zpět a požádejte o týden, abyste prozkoumali oblast a technologie, abyste mohli udělat rozumný odhad (budete to chtít dělat správně, protože se chcete učit nové technologie) a hrajte si s nimi?). Pokud váš PM a vedení v místě, kde se právě nacházíte) tomu nerozumíte ... aktualizujte svůj životopis a vyhledejte nejbližší východ, nechat je tak osudu, že si tak bohatě zaslouží. Že PM) by dokonce přemýšlel, jak dostat zaměstnance na plný úvazek k podpisu smlouvy, jako je špatný špatný signál n ... jediný způsob, jak jsem viděl, že nemusí být úplně nekompetentní, je to, že opravdu hráli mysli s vaším vedoucím projektu a vy (Z toho, co jsem četl, to ti přímo nepřidali a nakonec na hrozbu nesledovali). PMing je přece koneckonců útočištěm vašeho standardního firemního psychopata. Bylo dobré, že pro vás ostatní šli do netopýrů z toho, co jste řekli, takže níže uvedená rada by nakonec se vám nakonec ukázalo jako pozitivní. Představuji si, že by měli na rukou revoluci, kdyby se ukázalo, že je víc než jen mluvit.

Takže ke skutečné situaci/díře, kterou jste popsal, protože se to stane znovu někomu, někde (jako asi před 5 minutami a znovu v dalších 5, scheduleRepeat ()). Pravděpodobně bez smluvní hlouposti, ale základní děj je vždy stejný. Uspořádejte schůzku (!), Mají rádi schůzky ;-) každý se může nakonec poplácat po zádech, jako by se něco skutečně stalo. DŮLEŽITÉ: Nezapomeňte do schůzky pozvat svého vedoucího technického projektu/vedoucího týmu/architekta/designového manažera, aby již s nimi problém vyřešil a dostal je na palubu. Čím vyšší je hierarchie, můžete jít pro někoho na vaší „straně“, tím lépe. Protože váš PM to uvidí a pokuste se spojit svého návrháře s ekvivalentem. Pokud ne, jsou hloupí a vy jste již vyhráli. To samo o sobě je obecně vytáhne zpět do řady , protože nyní jsou viditelné pro někoho, kdo je pravděpodobně může vyhodit na místě. Pokud s vámi hrají hry, máte právo vrátit laskavost.

Na schůzce projděte technické podrobnosti o tom, s čím se zabýváte, a proč to vyžaduje čas. Měli by to chtít vědět (a jak vám to mohou pomoci), ale smutnou skutečností je, že se to obvykle nestane ... pravděpodobně dostanete 10 minut, než se jejich oči vrátí zpět do jejich hlavy. Teď to, co bych tady chtěl udělat, asi není legální ... jo, zkontroloval jsem, je to ve skutečnosti velmi nezákonné a nechceš se tak dlouho nechat vězit. Jde o to, že jste vynaložili maximální úsilí, abyste byli aktivní, a pokud máte nějaké vyšší postavy, vaše bolest je nyní jejich ... jak by měla být. Budete muset použít svůj úsudek o tom, jak se věci pravděpodobně odehrají, protože se stane „eskalace“. Pokud je vedení na místě, kde jste, napůl slušné, udělá správnou věc a také uděláte správnou věc také vy. Pokud ne, měli byste si svůj životopis nechat předem na trhu ... stejně byste odešli při první příležitosti (a vypadá to, že jste to nakonec udělali). Vedení se rozdělí do dvou skupin - buď jsou technicky důvtipní a okamžitě uvidí váš názor; nebo nejsou a co s tím udělají, kromě úsměvu a nesou to? Pokud by mohli dělat to, co děláte, pak by to už dělali.

Udržujte problém s měnícími se požadavky jako svou trumfovou kartu na konci ... bude sloužit jako out pro všechny. Samotný projekt a zatracený klient/zúčastněná strana budou mít své jméno marně. Nejbolestivější cestou vpřed by bylo, kdyby se v projektu došlo k určitému resetu, a možná by to PM) bylo tiše přiděleno do jiné oblasti. Zázraky se občas dějí. vznesen na schůzce premiérem, poté zasáhl požadavky zmrazení kontrarozpytové poptávky - pokud jde o mě, už spálili své mosty s vámi as celým vývojovým týmem, když začali hrát takové druhy mysli hry.

Než se odhlásím: Změna rozsahu/požadavků - jeden z nejlepších důvodů pro přijetí metodiky Agile, takže klienti/zúčastněné strany jsou řádně odpovědní za to, že změnili názor na to, co chtějí ...

Ach, ještě jedna věc: v prohlášení „Nevím“ bylo vždy mým osobním měřítkem, jak měřit hodnotu kolegy technologa nebo člena v jednom z mých projektových týmů. Zjistil jsem, že jediní lidé, kteří jsou schopni říci, že přímo na vaši tvář, jsou nejlepší, především proto, že někdo, kdo ví, že jsou mimo jejich hloubku, to nikdy neřekne. tlukot srdce. Na druhou stranu někdo, kdo se postaví dopředu a řekne to, bude mít také základní plán (i když to nebyl myšlenkou), jak řešit neznámé, takže za 24 hodin bude užitečnější odpověď, a za týden ještě lepší. Když Apollo 13 létal kolem temné strany Měsíce, došlo k celé partii „nevím“. Pokud se s takovým druhem nedokážete vypořádat, jste ve špatné hře.

10
nomaderWhat

Ano, mělo by to zvýšit červenou vlajku, zejména pokud jste zaměstnancem na plný úvazek. Jaké byly podmínky smlouvy? Byl bys skutečně propuštěn, kdybys zmeškal termíny? Nebo vám chybí bonus? Co by dělali?

Vlajka, která to vyvolává, spočívá v tom, že manažer netuší, jak řídit projekt zabývající se novými/neznámými technologiemi a požadavky na řazení, které přímo ovlivňují odhadované úsilí. I když někdy dochází k pevným termínům, manažer, který zná situaci, by se neměl snažit přimět zaměstnance, aby podepsali smlouvy, aby je vymáhali. Pozdní noci a doby krize budou špatné, ale to je zřejmě pro kurz stejné. A někdy někdy lhůta sklouzne. Stává se to, a stejně jako někdo jiný zveřejněný, jediným způsobem, jak se držet plánu, je zmrazit požadavky EARLY ON, aby bylo stále dost místa pro dodržení časové osy.

Z toho, co jste řekl, jsou poplašné zvonky o několik měsíců příliš pozdě. Za normálních okolností je riskantní založit časově citlivý projekt na technologiích, které personál dosud nezná. Je hloupé to dělat, pokud nemáte přehled o shromažďování požadavků a správě rozsahu.

To znamená, že souhlasím s ostatními odpověďmi. Můžete také chtít aktualizovat svůj životopis, pokud jste tak ještě neučinili.

8
Larry Coleman

Stejně jako všichni ostatní respondenti jsem nemohl více souhlasit s tím, že by to mělo vyvolat červenou vlajku.

Vypadá to, že se PM nechce zapojit do procesu vývoje).

Ve své osobní praxi jsem se dlouho vzdaloval od podrobných podrobných specifikací, odhlášení, úplného odhadu projektu nebo stanovení ceny za pevnou nabídku (z pohledu konzultace).

Důvodem je realizace, o které mnozí guruové Agilní a Leanoví hovoří, že tento software není pevnou vyrobitelnou entitou, ale je to většinou proces objevování.

Mnoho lidí má stále problémy s touto představou a zní to, jako by to udělal váš PM). Jde o jednoduché pochopení kompromisů.

Pevné předběžné specifikace a pevné odhady fungují pro systémy, kde jsou náklady na změnu vysoké. Jako budování výškové budovy. Pokud jste zapomněli prozkoumat šachty výtahu dopředu, bude po opravě budovy opravdu těžké dovybavit. Vysoké náklady na změnu vyžadují hodně prvotního plánování, učení neznámých komponent a technologií a experimentování předem. Rozpočet a náklady můžete odhadnout pouze jednou.

V softwaru si lidé zvykli na myšlenku, že náklady na změnu jsou nízké, a tak rádi využijí možnosti změnit věci, jakmile uvidí vydání, začlení nové porozumění aplikaci, podniku, zákazníkovi na průběžně. To vše je dobrá a obrovská příležitost, pokud je využíváno správně. Většina lidí se softwarem, se kterými jsem se setkal a s nimiž jsem pracoval, si ve skutečnosti nemiluje trávit mnoho času plánováním nebo vyšetřováním; většina z nás (včetně PM) chce vidět pokračující trakci. Odtud pochází iterativní vývoj s malými, přírůstkovými funkcemi. Existují i ​​jiné postupy, které lze použít, jako je vývoj založený na testech, který zaručuje, že náklady na změnu zůstanou nízké a technické zadlužení je omezeno.

Realizace této práce zahrnuje „smlouvu“ mezi oběma stranami, vlastníkem produktu (Agile hovoří za váš PM nebo zákazníci nebo tým QA) a vývojáři. Vývojáři souhlasí, že budou pracovat pouze na věcech, které mají prioritu jako nejdůležitější pro danou iteraci, a ne s tím trvat věčně, ale snažit se uvolňovat plně integrované kusy funkcí často (např. týdenní nebo měsíční). Majitelé produktů se naopak souhlasí s nepřetržitým přezkoumáváním přírůstkových verzí a poskytováním okamžité zpětné vazby. také souhlasí se stanovením priorit pro příští iteraci a jednou nastavenou tak, aby po dobu trvání iterace nezměnily svůj názor.

Tato druhá část dohody je něco, čemu vaše PM pravděpodobně nerozumí. Mnoho tradičních PM vlastně nerozumí. Někteří z nich si myslí, že jejich práce se provádí, když upustí od specifikace; nechtějí slyšet o problémech, alternativách, lepších způsobech atd. Nevýhodou je, že to není jen proti proudu vývoje softwaru, ale také to poškozuje organizaci tím, že ponechává mnoho příležitostí na stole.

Podívejte se na Agilní manifest: http://agilemanifesto.org/ Může s vámi rezonovat. Dobrou knihou je také „Lean Software Development“ Mary Poppendieckové

Hodně štěstí.

4
Wolfram Arnold

Zní to, jako by manažer hledal někoho, kdo by za něj mohl vinit, když se hlásí svému nadřízenému.

Zjistil jsem, že pokud máte nepřiměřeného manažera, který si myslí, že „odhad“ je stejný jako „pevné období“, nejlepší věcí, které musíte udělat, je vymyslet velmi štědré odhadované období a poté jej zdvojnásobit!

Rovněž nutte správce, aby zajistil, že požadavky budou plně podrobné a pevné. Změny od té doby nebudou řešeny bez „formálního vyjednávání“ s projektovým manažerem nové doby dokončení.

Nakonec projektový manažer získá nápad a podle toho plánuje.

4
martinws

Moje osobní zkušenost s takovým druhem je, že vedoucí projektu se snaží nastavit papírovou stopu, aby vás zbavila, zatímco vaše ukončení je vaší vlastní vinou. To by z ní udělalo velmi červenou vlajku. Váš počet najetých kilometrů se může samozřejmě trochu lišit.

2
PSU

Dobré odpovědi všude kolem, ale dovolte mi přidat moje 2 centy.

Pokud někdy studujete pravděpodobnost, existuje něco jako „náhodná proměnná“. To je číslo, jehož hodnotu nevíte, ale můžete popsat své nevědomí s distribucí, jako je normální distribuce (zvonová křivka) nebo jiné.

Jde o to, že práce bude nějakou dobu trvat, ale jakýkoli předchozí odhad bude špatný, trochu nebo hodně, na negativní straně nebo pozitivní, takže existuje riziko, a někdo musí riskovat. Obecně platí, že pokud lidé riskují, dostanou za to zaplaceno. Pojištění stojí peníze.

Když jsem byl konzultantem, měl jsem obvykle na výběr podepsání smlouvy o čase a materiálu versus smlouva s pevnou cenou. S časem a materiály nese klient riziko. S pevnou cenou nesu riziko. S pevnou cenou buduji jistotu bezpečnosti, protože pokud se mi nepodaří cíl splnit, nikdo nevyhraje.

Požadavek na závazek k pevnému datu dodání, zejména bez pevných požadavků, zní jako pokus o přenesení rizika na vás, i když není jasné, co vlastně riskujete. V každém případě je jednou z odpovědí jednoduše poskytnout skutečně velkorysou rezervu bezpečnosti.

P.S. Vidíte to pořád s vládními smlouvami. K dispozici je počáteční žádost, nabídky, nabídky, nízká nabídka je přijata, a pak začnou přicházet žádosti o změnu, takže náklady jsou balóny a dodavatel je obviňován. Věci fungují mnohem lépe, pokud mezi klientem a dodavatelem existuje týmová spolupráce, než kontradiktorní.

1
Mike Dunlavey

"Chůze po vodě a vývoj softwaru podle specifikace jsou snadné, pokud jsou oba zamrzlé."

- Odměna V. Berarde

Pokud se vaše požadavky mění, pak je nepřiměřené očekávat, že vaše počáteční odhady budou přesné. Ano, měla by to být červená vlajka.

0
Bill the Lizard

Ano, samozřejmě to vyvolává vlajku o zkušenostech a schopnostech vašeho bývalého šéfa. Ano, jak většina lidí navrhlo, bylo by vhodné aktualizovat váš životopis.

Ano, jak uvádějí ostatní odpovědi, ve většině situací byste tuto dohodu nechtěli podepsat. Chtěl bych však navrhnout, že by se mohly vyskytnout situace, kdy byste mohli zvážit jejich podepsání.

Většina vývojářů a manažerů si je vědoma neustálého tření mezi funkčností, termínem a rozpočtem. Mnozí by také nominovali kvalitu jako čtvrtou dimenzi („Dokážu splnit jakýkoli soubor požadavků, zítra za nízký rozpočet, pokud jste ochotni akceptovat, že to nebude fungovat!“)

Existuje však ještě další rozměr: riziko. Pokud potřebuji splnit pouze 50% času, mohu nesmírně snížit své odhady; jsou vycpané, aby zvládly mnohem vyšší rychlost doručení.

Riziko můžeme řešit několika způsoby (a odhady výplní jsou jedním z nich). Manažer není ochoten přijmout žádné riziko, a chce to vystavit riziku na svých bedrech. Normálně byste měli takový krok odmítnout ... pokud vám nebude dobře odškodněno.

Pokud jste schopni nominovat svůj termín, s oboustranně přijatelným množstvím výplně, abyste se vypořádali s neočekávanými zpožděními, a jste schopni vyjednat (velmi velký) bonus, pokud ho zasáhnete, a jste ve finanční pozici, abyste byli schopni zvládnout pokuty (např. vyhození), pokud to nemůžete, možná zjistíte, že stojí za to „hazardovat“, abyste toto riziko přijali sami a podepsali smlouvu - s vhodnými klauzulami pro vyřízení změn požadavků.

0
Oddthinking

Říkám, že si se oblékáš a snaží se pochopit, co to motivovalo. Z pohledu potenciálních manažerů/účetních potřebují počet, aby ospravedlnili, co se děje a jak se to děje.

Mohlo by to být tak, že byl vysmíván v zasedací místnosti pro posunutí termínů, chybějící příliš mnoho lhůt, zkusil nejjednodušší možný způsob, jak je zamknout. Dej mi číslo a podepište se sem! Jste na druhém konci, mohli jen vnímat, že je to něco proti vám. Pro něj je však někdy užitečnější provádět odhady a průběžně si uvědomovat, že je třeba je upravit. Pokud rozumíte tomu, co motivovalo žádost a jaký je skutečný problém, kterému čelí, možná byste mu mohli pomoci i sami sebe. Jako programátoři řešíme problémy. To se neliší, pochopte a vyřešte jeho problém a bude vaším nejlepším přítelem. Je toho tolik práce, že nikdo nemá čas vymyslet osobní vendetu! Potřebuje pomoc s jeho prací, nejjednodušším řešením bylo, aby někdo podepsal papír! Pravděpodobně to dostal od vedení pro knihu figurín, „Nechte své pracovníky, aby se podepírali, a aby vám pomohli zodpovídat za určitý počet.“ Legrační, ale smutné

0
Arjang

To je přímá hloupost. Nevím, co bylo konečným cílem, ale každý slušný projektový manažer na půli cesty zodpovědný za softwarové produkty by si měl být vědom toho, že odhady jsou přesně to, čemu se říká: odhady. Nejedná se o sliby a nemohou být učiněny, aniž by vyčerpali veškerou svou energii vývojáře softwaru nebo je donutili, aby přesto „sliby“ porušili.

Pokud chcete ukázat, jak směšná je taková smlouva, mohly by zde být dva návrhy:

a) Vysoce přeceňte do bodu, kdy projekt trvá pět až desetkrát tak dlouho, jak byste odhadovali bez smlouvy. Pokud se vedoucí projektu zeptá, proč jsou odhady tak vysoké, jednoduše řekněte, že se jen ujistíte, že můžete smlouvu splnit.

b) To již bylo navrženo: Požádejte o smlouvu, která zajistí, že se nezmění ani jediný požadavek, a zajistěte, aby to zahrnovalo opravu pravopisných chyb. Podle mých zkušeností neexistuje jediný softwarový projekt, kde se požadavky během vývoje nezmění. Projektový manažer s větší pravděpodobností bude muset porušit svou smlouvu než vy.

Pokud by vedoucí projektu souhlasil s některým z těchto dvou návrhů, měli byste si být jisti, že jim to nevadí.

Jak mimochodem, jak by smlouva na zaměstnance na plný úvazek fungovala? Nevím o pracovních předpisech v jiných zemích, ale jako zaměstnanec na plný úvazek ve společnosti si nemyslím, že by vás někdo mohl donutit k podpisu závazné smlouvy, abyste dodrželi termín a měli platný případ. Jistě, mohli by vám dát peklo, pokud nedodržíte termín, ale na to nepotřebují smlouvu. Nikdo vás nemohl vystřelit ani vám dát méně peněz. V nejhorším případě by mohli snížit váš dohodnutý bonus. Pokud se to v jiných zemích liší, zdá se to spíše jako prázdná hrozba, než cokoli, co byste měli brát vážně.

0
Anne Schuessler

Tady půjdu proti zrnu.

Situace, kterou popisujete, není na úrovni Engineering tým neobvyklá, zejména po zvláště pozdním projektu/vydání. V mnoha situacích může být vaše vedení a celá vaše organizace ve skutečnosti zaregistrována k určitému datu vydání a další části organizace budou přizpůsobeny k tomuto datu. Na váš řetězec správy může být obrovský tlak, aby dosáhl tohoto data.

Zde přichází obecný inženýrský proces. Pravděpodobně jste už slyšeli o vodopádovém modelu. Existují i ​​jiné modely, ale konečným cílem všech z nich je důsledně dodávat něco , když se očekává a obsahuje ) s čím bylo dohodnuto. Funkční specifikace, návrhy, seznamy úkolů atd. Směřují k tomu, aby byl tento proces předvídatelný. Komunikace, analýza rizik a (jak jste uvedl) pravidelná aktualizace očekávání o plánu snižují překvapení a zpřístupňují informace co nejdříve, aby bylo možné plány upravit. A ano, plán by měl být upraven vždy, když jsou přidány nebo odebrány funkce.

V některých týmech, se kterými jsem spolupracoval, bych neváhal zacházet se svými odhady jako s podepsanými závazky, ale to odráží kvalitu týmů a vedení, a ne žádné zvláštní dovednosti při odhadování. tým, který je ochoten podepsat smlouvu na dodání včas, je ukazatelem dobře fungujícího týmu, nikoli červená vlajka.

0
TREE