Tento článek není o hard skills typu UML nebo BPMN, ačkoliv jsou tyto notace pro práci analytika cenné. Bude převážně o soft skills, které Vás jako analytika můžou posunout dále a Vaše práce bude mít vyšší přidanou hodnotu pro ostatní role v týmu.
Budujte důvěru s Vaším businessem
- Ačkoliv to zní jako fráze, když budete mít důvěru vašeho zákazníka, tak se vám s ním bude lépe definovat zadání a spíše dá na váš názor. Podrží vás v konfliktních situacích nebo dostanete pochvalu, což vždy potěší.
- Důvěru můžete budovat pečlivým zadáním pro vývojový tým nebo nabídnutím pomoci s úkolem, který nemusí být součástí vaší pracovní náplně. Možností je samozřejmě více.
Staňte se pravou rukou Projektového manažera
Zajímejte se o priority a termíny
- I v agilních projektech jsou termíny a priority, a pokud nestihnete připravit zadání pro vývojáře nebo jste připravovali něco, co nemá prioritu a vaší výmluvou bude, že jste prioritu a termíny neznali, tak jste si vaší analytickou loď potopili sami.
Musíte vědět, na kolik MD je změna naceněna
- Pokud jste změnu nenaceňovali a jedná o FTFP projekt, tak byste měli vědět, kolik MDs na danou změnu máte (včetně všech rolí PM, analytika, vývojáře, testingu), abyste nevymýšleli “kanón na vrabce”, který vám zákazník nezaplatí.
Upozorňujte na nesoulad v projektovém plánu nebo termínech
- Ani PM není robot, který má všechno pod kontrolou nebo nevidí do detailu dané změny. Upozorňujte na nesoulad vývoje (např. který požadavek musí předcházet nebo následovat, nebo že detailní analýza ukázala mnohem náročnější požadavky na vývoj, než byl předpoklad).
Učte se z minulosti na základě tvrdých dat
- Analytik často dělá odhady pracnosti. Ačkoliv není vývojář, tak PM to většinou chce po něm. Kromě toho, že víte, jaký máte tech stack v projektu, je důležitá také zkušenost na projektu nebo minulých projektech. Proto, když víte, kolik skutečně stálo implementovat požadavek, může vám to v budoucnosti pomoci při odhadech.
Učte se od vývojářů a testerů
- Vývojáři mají větší technické know-how než vy a budete lepším analytikem, když nezůstanete pouze business analytikem, ale budete pokládat zvídavé dotazy vývojáři, jak danou změnu implementuje. Určitě vám pomůže, pokud máte alespoň základy objektového programování.
- Test analytik nebo tester bude připravovat test případy a scénáře na základě výstupu vaší práce. Pracujte se zpětnou vazbou na vaše zadání a snažte se ho psát tak, v bylo co nejvíce čtivé.
Dokumentujte svoji práci nejenom pomoci modelů
- Ačkoliv obrázek vydá za tisíc slov, mým názorem je, že text v analýze je stále nezbytný. Proto pište zadání jako knihu s obrázky.
Na co se často zapomíná
Happy day scénář
- Business často zadává svoje požadavky/user story tak, že myslí pouze na základní scénář tzv. happy day (nebo sunny day) scénář. Je dobrou prací analytika pokrýt i alternativní scénáře a výjimky ve scénáři. Jedná se v podstatě o alternate a exception flow v UML use cases.
Role a oprávnění
- Občas analytik má zadání opravdu promyšlené, ale zapomene na role a oprávnění. Myslete na to u každé implementace.
Ačkoliv výčet možných rad a tipů je nekonečný, protože každý projekt má svá specifika. Výše zmíněné rady Vám mohou pomoci ve vaší práci. Snad Vám pomůžou!