Je to už nějaká chvilka, co jsme ve firmě absolvovali povídání o Teorii omezení (aneb Theory of contrains, zkráceně TOC) a musím říct, že se mi tam myšlenka relativně zalíbila. Když nic jiného, tak je to úplně jiný pohled na stávající zvyky. S tím možná souvisí i povídání o Kritickém řetězu projektu (Critical Chain Project Management), ale ty správné názvy jsou mi celkem jedno.
Primárně se to prý vysvětluje na výrobních firmách, kde to jde nejlépe pochopit, ale dalším příkladem je třeba využití špičkových konzultantů pouze na to, co přináší ty zajímavé peníze. Každému je jasné, že by se neměli věnovat kravinám, ale né všem je jasné, že úzká místa (konzultanti) by se měla využívat opravdu pouze na to, co přináší zisk.
Doteď naprosto jasné úplně každému. Další myšlenka je ale revoluční – lidé okolo těch úzkých míst (hlavně ti před) nemusí pracovat naplno a je naprosto správné, že se flákají. Na to jsem v první chvíli koukal, ale pak to začne dávat smysl.
Skočíme trochu bokem, asi všechny projekty s sebou nesou několik zákonů – Parkinsonův (vždy se využije všechen čas na projekt), Studentský (ještě je čas, není kam spěchat a práce počká) a Nebuď blbej (a raději si naplánuj pořádnou rezervu). Takže všichni při plánování počítají s rezervami, ty se pro jistotu ještě navýší, většina projektů je ve finále naplánovaná na dvakrát tak dlouho než skutečná práce a pořád se jich 80% nestihne. Což zní skoro jako zázrak.
Většina manažerů se snaží projekt řídí po jednotlivých úkolech a pokud se nestihnou tak je problém. A to je důvod takového navyšování, protože lidé nemají rádi, když se jim říká, že jsou pomalí.
Myšlenkou tedy je vzít projekt tak jak je naplánovaný a celkový čas rozdělit na polovinu. V jedné by se to mělo stihnout, druhá slouží jako nárazník pro ty úkoly, které se nestihnou. A tenhle nárazník je možné ještě rozdělit za úkoly, na kterých něco závisí, pořád by však měla zůstat vata na konci.
Důležité je vysvětlit lidem, že se vůbec nic neděje, když něco nestihnou, ale ať to stihnout zkusí – aneb pokud celý projekt skončí včas, je nám úplně jedno jak skončily jednotlivé úkoly. Prioritně je následně nutné řešit zpožděné úkoly, které odčerpávají čas z toho celkového nárazníku na konci, dokud čerpají pouze z toho svého tak je to v pohodě. Současně nám rychlost odčerpávání tohoto nárazníků říká, zda projekt běží v pohodě nebo ne – pokud jsme v půlce projektu a 90% nárazníku je v čudu, tak je něco špatně.
S tím souvisí další kupa myšlenek:
- nepřepínej projekty, bere to čas (občas mám – nejen z programátorů – pocit, že celý den přepínají, ale na vlastní práci jim už čas nezbývá)
- dělej méně a bude to rychleji, pokud na někoho čekáš tak si mu stoupni za záda, v klidu relaxuj a počkej až to bude (což ani jinak nejde, pokud člověk nepřepíná projekty)
- limitovat počet úkolů na projektu, na kterých se aktuálně pracuje
No a pomocí tohoto zázraku (tedy nepřepínání, minimalizace rozpracovaných úkolů, kratších časů) se prý při stejných vstupních podmínkách dosáhne toho, že už na 3 projektech se uspoří 50% původně odhadovaného času, aniž by to kladlo vyšší nároky na pracovníky nebo se lidé dohadovali o prioritách.
To je totiž asi ta největší smrt, že všichni mají ty nejdůležitější projekty, které se musí řešit a přitom kdyby se seřadily za sebe, tak budou dřív, než když se snaží stihnout najednou.
Teď jenom vymyslet, jak to zavést do praxe. Asi budu muset přesvědčit kolegy, aby tak nelpěli na svých projektech, hodili jsme je na hromadu a nechali na ně programátory v klidu postupně pracovat. Ale současně je super, že vývojáři jsou úzké místo a já se tak mohu flákat 😉