254
editací
Změny
Založena nová stránka s textem „Část sekce Agilní přístup =Tvorba plánu prací (roadmapy)= Plán prací ukazuje, jak se produkt nebo služba bude průběžn…“
[[Agilní přístup|Část sekce Agilní přístup]]
=Tvorba plánu prací (roadmapy)=
Plán prací ukazuje, jak se produkt nebo služba bude průběžně vyvíjet.
Plány musí být srozumitelné a snadno přizpůsobitelné, když se změní priority, jak se často stává při agilním způsobu práce.
== Proč je plán prací důležitý ==
Plán prací vysvětluje, čeho se snažíte dosáhnout a jaké budou následovat kroky k dosažení cíle. Platí to na celou službu, i na produkt, který podporuje službu.
Stejně jako plán vysvětluje, co děláte, vysvětluje také, co neděláte.
Plán pomáhá větším týmům pochopit, na čem právě pracují v souvislosti s budoucí prací a prioritami.
Každý, kdo se podílí na řízení nebo financování z rozpočtu, potřebuje znát tento plán, aby chápal kdy a jak se produkt nebo služba dostane k uživatelům.
Díky otevřenému plánu je ostatním dodavatelským týmu jasné, na čem právě pracujete, kyždý může vidět, kde se mohou věci překrývat a včas zamezit duplicitě. Když jsou věci otevřené, je jednodušší najít a sdílet uživatelský kód, vzory a podpůrné materiály k produktu.
Uživatelé produktu nebo služby mohou zjistit, jaké jsou plány rozvoje, stejně jako lidé, kteří poskytují veřejné služby nebo financování.
== Principy tvoření plánu ==
=== 1. Plán vás dovede k vizi v etapách / iteracích ===
Váš produkt nebo služba by měly mít dlouhodobou vizi, která popisuje, čeho se ve finále snažíte pro uživatele dosáhnout. Tento plán může být rozdělen do etap nebo iterací, které vás dovedou do cíle. V UK (GDS) se každá tato produktová iterace nazývá “mise”.
=== 2. Plán ukazuje, čeho se snažíte dosáhnout ===
Produkty i služby byste měly posuzovat podle toho, co přinášejí uživatelům. Příkladem zhodnocení pro uživatele je, že jsou věci rychlejší, jednodušší a šetří úsilí.
Plány prací jsou nástroje, které ukazují, jakou hodnotu bude mít produkt. Zobrazují etapy, ve kterých se tato hodnota dostane se k uživatelům.
=== 3. Každá služba nebo produkt by měly mít plán prací ===
Produkt může mít svůj plán prací nebo může být součástí většího plánu, který dává souhrnný pohled na produkty související se službou.
Nejlepší je uchovávat plán online s použitím tabulkového procesoru nebo jiného softwaru, abyste minimalizovali riziko ztráty informací.
Pokud se ukáže, že pro uživatele nebo tým potřebujete více než jednu verzi plánu, např. jednu na zeď, jednu online, používejte jednu jako hlavní verzi a vždy se ujistěte, že každá verze je aktuální s nejčerstvějšími informacemi.
=== 4. Plány upravujte opakovaně a pravidelně ===
Vytváření a opakované úpravy vašeho plánu dělejte společně, obvykle pod vedení projektového manažera. Můžete do toho [http://www.jamiearnold.com/blog/2014/07/22/seven-questions-to-build-a-roadmap <span class="underline">zahrnout tým i zúčastněné strany</span>] a použijte také vše co, jste se dozvěděli z [[Analýza výkonů|analýzy výkonů]] a [[Uživatelský průzkum|uživatelského průzkumu]], abyste mohli vysvětlit vaše rozhodnutí.
=== 5. Plán by měl být otevřený ===
Měl by být dostupný k nahlédnutí i ostatním státním zaměstnancům a pokud možno ve veřejném vlastnictví. Hlavní výjimky mohou nastat, pokud existuje dobrý důvod k zabezpečení a nezveřejnění, pokud je situace kolem sdílení plánů politicky citlivá.
=== 6. Plán musí být snadno pochopitelný ===
Plán by měl využívat jednoduché vizuální prvky, které usnadní a urychlí pochopení. Měl by být psán [[Jak psát pro veřejnost|jednoduchou řečí]] bez žargonu, aby byl přístupný a využitelný pro celou řadu lidí, kteří ho budou používat. Může obsahovat odkazy na stránky, kde je více informací, jako např. Backlog (seznam nevyřízených věcí) nebo blog.
=== 7. Iterace mají jasné cíle ===
Každá iterace ve vašem plánu by měla mít svůj cíl, který vás dostane blíže k dosažení dlouhodobé vize. Pokaždé by měl existovat jasný cíl (často problém, který má být vyřešen) a popis toho, jak bude měřen pokrok.
Návrh prací není to samé jako “<span class="underline">backlog</span>” (seznam nevyřízených věcí), který tým využívá k tomu, aby řídil dodávky jednotlivých funkcionalit a otázek v kratších časových intervalech.
=== 8. Mise a fáze mají pevně stanovenou dobu ===
Mise jsou plánovány průběžně – mají být prováděny čtvrtletně. Tyto časové úseky musí být konzistentní.
Když plán obsahuje [[Agilní přístup#F.C3.A1ze_agiln.C3.ADho_projektu|alfa či beta fáze]], měly by být časově rozvržené.
=== 9. Plány prací se řídí prioritami ===
Dobré plány znázorňují, co se dělo, co se děje a co se bude dít podle priority. [[Stanovování priorit]] musí být konzistentní a transparentní.
=== 10. Zachycení záměrů plánu a možnost změn ===
Plány prací umožňují plánovat změny. Zachycují záměr, ne řešení.
Čím vzdálenější je budoucí mise, tím více je nejistá. Číme se dostanete blíže, tím více se naučíte a ujistíte se, zda se jedná o správnou věc.
Do plánu se dá přidávat i odebírat.
=== 11. Plány popisují “kdo” a “jak” ===
V plánech by mělo být popsáno kdo a jak je má číst.
Také by měla být zahrnuta informace, kdo udržuje plán, jak často je aktualizován a jak lze přispívat k jeho rozvoji.
=== 12. Plány jsou znovu využitelné ===
Pokud používáte na sestavení plánu software, obsah by měl být exportovatelný, aby mohl být v případě potřeby přenesen a použit.
== Příklady a případové studie ==
* [https://gds.blog.gov.uk/2017/03/27/how-we-are-using-roadmaps-in-government/ <span class="underline">Jak používat plány prací ve veřejné správě</span>]
* [https://insidegovuk.blog.gov.uk/2017/02/13/the-2017-to-2018-gov-uk-roadmap/ <span class="underline">Plán prací GOV.Uk v období 2017 až 2018 </span>]
* [https://insidegovuk.blog.gov.uk/2017/03/17/how-we-made-the-gov-uk-roadmap/ <span class="underline">Jak jsme tvořili návrh prací pro GOV.UK</span>]
* [https://gds.blog.gov.uk/2017/08/03/make-the-most-of-your-roadmap/ <span class="underline">Využijte váš plán prací co nejvíce</span>]
== Diskuze a příspěvky ==
* [https://medium.com/@rossferg/roadmap-elements-b311f74b7ba4 <span class="underline">Read and comment on ‘Roadmap elements’</span>] - the original Medium post this guide is based on
* [https://www.gov.uk/service-manual/communities/product-and-service-community#get-involved <span class="underline">Discuss on the Product People mailing list or UK government Slack</span>]
=Tvorba plánu prací (roadmapy)=
Plán prací ukazuje, jak se produkt nebo služba bude průběžně vyvíjet.
Plány musí být srozumitelné a snadno přizpůsobitelné, když se změní priority, jak se často stává při agilním způsobu práce.
== Proč je plán prací důležitý ==
Plán prací vysvětluje, čeho se snažíte dosáhnout a jaké budou následovat kroky k dosažení cíle. Platí to na celou službu, i na produkt, který podporuje službu.
Stejně jako plán vysvětluje, co děláte, vysvětluje také, co neděláte.
Plán pomáhá větším týmům pochopit, na čem právě pracují v souvislosti s budoucí prací a prioritami.
Každý, kdo se podílí na řízení nebo financování z rozpočtu, potřebuje znát tento plán, aby chápal kdy a jak se produkt nebo služba dostane k uživatelům.
Díky otevřenému plánu je ostatním dodavatelským týmu jasné, na čem právě pracujete, kyždý může vidět, kde se mohou věci překrývat a včas zamezit duplicitě. Když jsou věci otevřené, je jednodušší najít a sdílet uživatelský kód, vzory a podpůrné materiály k produktu.
Uživatelé produktu nebo služby mohou zjistit, jaké jsou plány rozvoje, stejně jako lidé, kteří poskytují veřejné služby nebo financování.
== Principy tvoření plánu ==
=== 1. Plán vás dovede k vizi v etapách / iteracích ===
Váš produkt nebo služba by měly mít dlouhodobou vizi, která popisuje, čeho se ve finále snažíte pro uživatele dosáhnout. Tento plán může být rozdělen do etap nebo iterací, které vás dovedou do cíle. V UK (GDS) se každá tato produktová iterace nazývá “mise”.
=== 2. Plán ukazuje, čeho se snažíte dosáhnout ===
Produkty i služby byste měly posuzovat podle toho, co přinášejí uživatelům. Příkladem zhodnocení pro uživatele je, že jsou věci rychlejší, jednodušší a šetří úsilí.
Plány prací jsou nástroje, které ukazují, jakou hodnotu bude mít produkt. Zobrazují etapy, ve kterých se tato hodnota dostane se k uživatelům.
=== 3. Každá služba nebo produkt by měly mít plán prací ===
Produkt může mít svůj plán prací nebo může být součástí většího plánu, který dává souhrnný pohled na produkty související se službou.
Nejlepší je uchovávat plán online s použitím tabulkového procesoru nebo jiného softwaru, abyste minimalizovali riziko ztráty informací.
Pokud se ukáže, že pro uživatele nebo tým potřebujete více než jednu verzi plánu, např. jednu na zeď, jednu online, používejte jednu jako hlavní verzi a vždy se ujistěte, že každá verze je aktuální s nejčerstvějšími informacemi.
=== 4. Plány upravujte opakovaně a pravidelně ===
Vytváření a opakované úpravy vašeho plánu dělejte společně, obvykle pod vedení projektového manažera. Můžete do toho [http://www.jamiearnold.com/blog/2014/07/22/seven-questions-to-build-a-roadmap <span class="underline">zahrnout tým i zúčastněné strany</span>] a použijte také vše co, jste se dozvěděli z [[Analýza výkonů|analýzy výkonů]] a [[Uživatelský průzkum|uživatelského průzkumu]], abyste mohli vysvětlit vaše rozhodnutí.
=== 5. Plán by měl být otevřený ===
Měl by být dostupný k nahlédnutí i ostatním státním zaměstnancům a pokud možno ve veřejném vlastnictví. Hlavní výjimky mohou nastat, pokud existuje dobrý důvod k zabezpečení a nezveřejnění, pokud je situace kolem sdílení plánů politicky citlivá.
=== 6. Plán musí být snadno pochopitelný ===
Plán by měl využívat jednoduché vizuální prvky, které usnadní a urychlí pochopení. Měl by být psán [[Jak psát pro veřejnost|jednoduchou řečí]] bez žargonu, aby byl přístupný a využitelný pro celou řadu lidí, kteří ho budou používat. Může obsahovat odkazy na stránky, kde je více informací, jako např. Backlog (seznam nevyřízených věcí) nebo blog.
=== 7. Iterace mají jasné cíle ===
Každá iterace ve vašem plánu by měla mít svůj cíl, který vás dostane blíže k dosažení dlouhodobé vize. Pokaždé by měl existovat jasný cíl (často problém, který má být vyřešen) a popis toho, jak bude měřen pokrok.
Návrh prací není to samé jako “<span class="underline">backlog</span>” (seznam nevyřízených věcí), který tým využívá k tomu, aby řídil dodávky jednotlivých funkcionalit a otázek v kratších časových intervalech.
=== 8. Mise a fáze mají pevně stanovenou dobu ===
Mise jsou plánovány průběžně – mají být prováděny čtvrtletně. Tyto časové úseky musí být konzistentní.
Když plán obsahuje [[Agilní přístup#F.C3.A1ze_agiln.C3.ADho_projektu|alfa či beta fáze]], měly by být časově rozvržené.
=== 9. Plány prací se řídí prioritami ===
Dobré plány znázorňují, co se dělo, co se děje a co se bude dít podle priority. [[Stanovování priorit]] musí být konzistentní a transparentní.
=== 10. Zachycení záměrů plánu a možnost změn ===
Plány prací umožňují plánovat změny. Zachycují záměr, ne řešení.
Čím vzdálenější je budoucí mise, tím více je nejistá. Číme se dostanete blíže, tím více se naučíte a ujistíte se, zda se jedná o správnou věc.
Do plánu se dá přidávat i odebírat.
=== 11. Plány popisují “kdo” a “jak” ===
V plánech by mělo být popsáno kdo a jak je má číst.
Také by měla být zahrnuta informace, kdo udržuje plán, jak často je aktualizován a jak lze přispívat k jeho rozvoji.
=== 12. Plány jsou znovu využitelné ===
Pokud používáte na sestavení plánu software, obsah by měl být exportovatelný, aby mohl být v případě potřeby přenesen a použit.
== Příklady a případové studie ==
* [https://gds.blog.gov.uk/2017/03/27/how-we-are-using-roadmaps-in-government/ <span class="underline">Jak používat plány prací ve veřejné správě</span>]
* [https://insidegovuk.blog.gov.uk/2017/02/13/the-2017-to-2018-gov-uk-roadmap/ <span class="underline">Plán prací GOV.Uk v období 2017 až 2018 </span>]
* [https://insidegovuk.blog.gov.uk/2017/03/17/how-we-made-the-gov-uk-roadmap/ <span class="underline">Jak jsme tvořili návrh prací pro GOV.UK</span>]
* [https://gds.blog.gov.uk/2017/08/03/make-the-most-of-your-roadmap/ <span class="underline">Využijte váš plán prací co nejvíce</span>]
== Diskuze a příspěvky ==
* [https://medium.com/@rossferg/roadmap-elements-b311f74b7ba4 <span class="underline">Read and comment on ‘Roadmap elements’</span>] - the original Medium post this guide is based on
* [https://www.gov.uk/service-manual/communities/product-and-service-community#get-involved <span class="underline">Discuss on the Product People mailing list or UK government Slack</span>]