Jak vybudovat malou softwarovou firmu
Plánování práce a projektů
Při řízení lidí je potřeba rozdat úkoly. Úkoly se většinou sdružují do nějakých skupin, a i ty skupiny můžeme seskupit do hromady a vzniká projekt. Budujeme malou SW firmu, je třeba organizovat práci aby firma šlapala. Mě se osvědčili projekty jak pro krátkodobé cíle, tak dlouhodobé cíle - takové vlastně nekonečné projekty. Proberu zde obě varianty, jejich specifika a jak je používáme.
Konečný projekt
Řekněme, že nás zákazník osloví s představou aplikace. Ví v principu co by měla dělat. Občas zabrousí do nějakých detailů, občas chápe věci povrchně, nebo ve zkratce. Našim úkolem bude z těchto informací, které rozhodně nejsou kompletní sestavit nějaký plán práce, který se ale kompletnosti blíží, protože jinak bychom došli při odhadu potřebného času, potřebných lidí a jejich schopností k mylným závěrům.
Z neuspořádaných myšlenek chceme složit strukturovaný plán práce. Já při takovémto plánování postupuji z hora dolů, tedy od komplexních problémů k jejich řešení a to pak drobím na úkoly a jejich pod-úkoly.
Můžeme si to představit jako myšlenkovou mapu, kde hlavní centrální prvek je sám projekt.
Dále si určíme hlavní části ze kterých se bude řešení skládat. V průběhu času se mi vyprofilovaly hlavní body, které jsem využil skoro u každého projektu.
Hlavní body pak dělíme na menší části, nutné k jejich realizaci - stále se pohybujme spíše v abstraktní rovině … ostatně je lepší se nijak neomezovat v úrovních zanoření.
Také je dobré pro tyto abstraktní úkoly používat kontejnery, kde není nutné odhadovat čas a náročnost, protože stále tyto veličiny nelze v podstatě správně odhadnout. To lze u těch nejzákladnějších úkolů, které již nelze nebo nemá smysl dělit. Poznáte je tak že trvají v řádu minut až hodin! Tyto úkoly doporučuji odhadnout jako rozmezí: V nejlepším případě to bude trvat takto a v nejhorším takto.
Když se vám podaří rozdělit práci na nejzákladnější úkoly a ty ohodnotit časem a náročností vznikne vám odhad. Odhad celkového času a odhad celkové náročnosti.
Můžete si být jistí, že pod tento odhad času se při realizaci nedostanete a spíše se realita bude pohybovat někde u pesimistické varianty odhadu. Tak praví mé dlouhodobé zkušenosti.
Úkoly můžete lidem přidělovat hned, nebo později. Nebo si je mohou rozebrat sami.
Dlouhodobý / nekonečný projekt
Někdy práce na projektu nemá jasný konec. Například na fungování firmy jsem si založil projekt. Tam jsem si naskládal zejména dlouhotrvající úkoly. Lidi si zde zapisují opakující se činnosti které souvisí s obecným pracovním životem.
Stejně tak komerční projekty se mohou protáhnout a je potřeba si evidovat práci na nich vedenou. Vlastně v tom není žádný problém. Prostě je třeba zakládat další úkoly a přidělovat k nim pracovníky.
Nebo si mohou úkoly zakládat pracovníci sami, když například si vede zákazník úkoly v jiném systému. Pracovníci tak importují úkoly do vašeho projektu a práce je evidována. Je dobré, když umí váš systém pro vedení projektů zrcadlit práci do systému zákazníka.
Zadání - popis úkolu
Jak jsem psal výše, při plánování práce rozčleněné do projektů nejdříve vytvářím abstraktní úkoly a ty někdy v třetí úrovni zanoření dělím na základní úkoly.
Abstraktní úkoly se podpisem odlišují od základních. Abstraktní popisuji jakoby z pohledu zákazníka. Například : “Role účetní chce vidět v menu jemu příslušné položky a ostatní vidět nechce. Účetní položky jsou : …výčet položek…”
Při zadání nejzákladnějšího úkolu rozlišuji dvě varianty. Pracovník dělá danou činnost poprvé a pracovník ji dělá znovu exaktně stejnou.
V prvním případě popisuji úkol opravdu obšírně a snažím se ho strukturovat do odstavců, seznamů a používat další stylovací prvky. Co se týče obsahu, píši jej jakoby pro někoho kdo neví o problému absolutně nic. A vy mu chcete vysvětlit o co vám jde. Důvodem je snaha eliminovat další dotazy, zmatení, chyby z nepochopení.
Razím zásadu že pokud pracovník nepochopí správně zadání a musí se dotazovat, případně ho špatně realizuje, je to chyba toho kdo úkol zadával.
V druhém případě se odkazují na již provedený úkol, kde pravděpodobně je stejně napsané zadání jako v první variantě. A pouze vyjmenuji výjimky. Pokud je ale vyjímek moc, je lepší prostě zase napsat zadání znovu.
Opravdu je lepší napsat kvalitní zadání, než se dohadovat se zákazníkem, ztrácet čas a peníze opakovanou realizací a vnášet do týmu nepěknou atmosféru.
Datový model
V následujícím článku rozeberu návrh Datového modelu. Myslím že každý SW dnes pracuje s daty a jejich dobré propojení je absolutní základ úspěšného dlouhodobého projektu.
Tak zase příště
Josef Chmel
Jednatel v WorkVector. s.r.o.
https://workvector.com
Komentáře
Okomentovat