Dobrý den, přátelé. Docela často, zejména v outsourcingu, vidím stejný obrázek. Nedostatek jasného pracovního postupu v týmech na různých projektech.
Nejdůležitější je, že programátoři nechápou, jak komunikovat se zákazníkem a mezi sebou navzájem. Jak vybudovat kontinuální proces vývoje kvalitního produktu. Jak si naplánovat pracovní den a sprinty.
A to vše má v konečném důsledku za následek nedodržování termínů, přesčasy, neustálé zúčtování, kdo za to může, a nespokojenost zákazníků s tím, kde a jak se vše hýbe. Dost často to vše vede ke změně programátorů, nebo dokonce celých týmů. Ztráta zákazníka, zhoršení pověsti a tak dále.
Jeden čas jsem prostě skončil na takovém projektu, kde byly všechny ty slasti.
Nikdo nechtěl převzít zodpovědnost za projekt (velké tržiště služeb), fluktuace byla hrozná, zákazník byl prostě rozpolcený a frustrovaný. Jednou za mnou přišel generální ředitel a řekl, že máte potřebné zkušenosti, takže tady máte karty ve svých rukou. Vezměte si projekt pro sebe. Pokud to pokazíte, projekt zavřeme a všechny vyhodíme. Vyjde to, bude to cool, pak to veďte a rozvíjejte, jak uznáte za vhodné. V důsledku toho jsem se stal vedoucím týmu projektu a vše padlo na moje bedra.
První věc, kterou jsem udělal, bylo vytvořit pracovní postup od nuly, který byl v souladu s mou tehdejší vizí, a napsat popis práce pro tým. Jeho realizace nebyla jednoduchá. Zhruba do měsíce si ale vše sedlo, vývojáři i klient si zvykli a vše šlo v klidu a pohodě. Abych týmu ukázal, že nejde jen o „bouři v šálku“, ale o skutečné východisko ze situace, vzal jsem na sebe maximum zodpovědnosti a odstranil jsem z týmu nepříjemnou rutinu.
Již uplynul rok a půl a projekt se vyvíjí bez přesčasů, bez „krysích závodů“ a všech druhů stresu. Někteří lidé ve starém týmu tak pracovat nechtěli a odešli, jiní byli naopak velmi rádi, že se objevila transparentní pravidla. Ale nakonec jsou všichni v týmu velmi motivovaní a znají obrovský projekt naplno, včetně front-endu i back-endu. Včetně základny kódu a veškeré obchodní logiky. Dospělo to dokonce do bodu, kdy nejsme jen „veslaři“, ale sami přicházíme s mnoha obchodními procesy a novými funkcemi, které se firmě líbí.
Díky tomuto přístupu z naší strany se zákazník rozhodl objednat u naší společnosti další tržiště, což je dobrá zpráva.
Jelikož to na mém projektu funguje, možná to také někomu pomůže. Takže samotný proces, který nám pomohl zachránit projekt:
Proces týmové práce na projektu „Můj oblíbený projekt“
a) Proces interního týmu (mezi vývojáři)
- Všechny problémy jsou vytvářeny v systému Jira
- Každý úkol by měl být co nejvíce popsán a měl by provádět pouze jednu akci
- Jakákoli funkce, pokud je dostatečně komplexní, je rozdělena do mnoha malých úkolů
- Tým pracuje na funkcích jako na jediném úkolu. Nejprve všichni společně pracujeme na jedné funkci, odešleme ji k testování a poté vezmeme další.
- Každý úkol je označen pro backend nebo frontend
- Existují typy úkolů a chyb. Musíte je správně označit.
- Po dokončení úkolu se přenese do stavu kontroly kódu (v tomto případě je vytvořen požadavek na stažení pro kolegu)
- Osoba, která splnila úkol, okamžitě sleduje svůj čas na tento úkol.
- Po kontrole kódu PR schválí a poté jej ten, kdo provedl tento úkol, samostatně začlení do hlavní větve, poté změní její stav na připraveno k nasazení na dev server.
- Všechny úlohy připravené k nasazení na dev server jsou nasazeny vedoucím týmu (jeho oblast odpovědnosti), někdy členem týmu, pokud je něco naléhavé. Po nasazení se všechny úlohy z připraveného na nasazení do dev přenesou do stavu – připraveno k testování na dev
- Všechny úlohy jsou testovány zákazníkem
- Když zákazník úlohu otestuje na vývojáři, přenese ji do stavu připraveného k nasazení do výroby
- Pro nasazení do výroby máme samostatnou pobočku, kde master sloučíme až před nasazením
- Pokud během testování zákazník najde chyby, vrátí úlohu k revizi a nastaví její stav jako vrácený k revizi. Oddělíme tak nové úkoly od těch, které neprošly testováním.
- Výsledkem je, že všechny úkoly jdou od vytvoření až po dokončení: Úkol → Ve vývoji → Kontrola kódu → Připravené nasazení na vývoj → Kontrola kvality na vývoji → (Návrat k vývoji) → Připravené nasazení do výroby → Kontrola kvality na prod → Hotovo
- Každý vývojář testuje svůj kód nezávisle, a to i jako uživatel webu. Není dovoleno sloučit větev do hlavní, pokud není jisté, že kód funguje.
- Každý úkol má priority. Priority určuje buď zákazník, nebo vedoucí týmu.
- Vývojáři nejprve dokončují prioritní úkoly.
- Vývojáři si mohou navzájem přidělovat úkoly, pokud byly v systému nalezeny různé chyby nebo jeden úkol sestává z práce několika specialistů.
- Všechny úkoly, které zákazník vytvoří, jdou k vedoucímu týmu, který je vyhodnotí a buď požádá zákazníka, aby je upravil, nebo je přidělí jednomu z členů týmu.
- Všechny úkoly, které jsou připraveny k nasazení do vývoje nebo výroby, také jdou k vedoucímu týmu, který nezávisle určuje, kdy a jak nasazení provést. Po každém nasazení na to musí vedoucí týmu (nebo člen týmu) upozornit zákazníka. A také změnit stavy úkolů na připraveno k testování pro dev/cont.
- Každý den ve stejnou dobu (pro nás je to ve 12.00) pořádáme setkání všech členů týmu
- Všichni na schůzce, včetně vedoucího týmu, referují o tom, co dělali včera a co plánují dělat dnes. Co nefunguje a proč. Celý tým tak ví, kdo co dělá a v jaké fázi se projekt nachází. To nám dává možnost předvídat a v případě potřeby upravit naše odhady a termíny.
- Vedoucí týmu na schůzce hovoří také o všech změnách v projektu a míře aktuálních chyb, které zákazník nenašel. Všechny chyby jsou vyřešeny a přiděleny každému členovi týmu, aby je vyřešil.
- Na schůzce vedoucí týmu zadává úkoly každému člověku s přihlédnutím k aktuálnímu pracovnímu vytížení vývojářů, jejich odborné přípravě a také s přihlédnutím k blízkosti konkrétního úkolu k tomu, co vývojář právě dělá.
- Na setkání vedoucí týmu vypracuje obecnou strategii pro architekturu a obchodní logiku. Poté o tom celý tým diskutuje a rozhodne se provést úpravy nebo přijmout tuto strategii.
- Každý vývojář píše kód a vytváří algoritmy nezávisle v rámci jediné architektury a obchodní logiky. Každý může vyjádřit svou vizi realizace, ale nikdo nikoho nenutí, aby to dělal takto a ne jinak. Každé rozhodnutí je oprávněné. Pokud existuje lepší řešení, ale teď na něj není čas, tak se v tuku vytváří úkol pro budoucí refaktoring určité části kódu.
- Když se vývojář ujme úkolu, přenese jej do stavu vývoje. Veškerá komunikace ohledně vyjasnění úkolu se zákazníkem leží na bedrech developera. Technické otázky lze položit vedoucímu týmu nebo kolegům.
- Pokud vývojář nerozumí podstatě úkolu a zákazník to nedokázal jasně vysvětlit, přejde k dalšímu úkolu. A vedoucí týmu vezme ten aktuální a probere to se zákazníkem.
- Každý den by měl vývojář napsat do chatu klienta, na kterých úkolech pracoval včera a na kterých bude pracovat dnes
- Pracovní proces probíhá podle Scrumu. Vše je rozděleno do sprintů. Každý sprint trvá dva týdny.
- Sprinty vytváří, plní a uzavírá vedoucí týmu.
- Pokud má projekt striktní termíny, tak se snažíme všechny úkoly přibližně odhadnout. A dali jsme je dohromady do sprintu. Pokud se zákazník pokusí přidat další úkoly do sprintu, nastavíme priority a přeneseme některé další úkoly do dalšího sprintu.
b) Proces práce se zákazníkem
- Každý vývojář může a měl by komunikovat se zákazníkem
- Zákazníkovi není dovoleno vnucovat si vlastní pravidla hry. Zákazníkovi je potřeba slušně a přátelsky dát najevo, že jsme specialisté ve svém oboru a jen my musíme budovat pracovní procesy a zapojovat do nich zákazníka
- V ideálním případě je nutné před započetím implementace jakékoli funkcionality vytvořit vývojový diagram celého logického procesu pro funkci (workflow). A zašlete jej zákazníkovi k potvrzení. To platí pouze pro komplexní a ne zcela zřejmé funkce, například platební systém, systém oznámení atd. To nám umožní přesněji porozumět tomu, co přesně zákazník potřebuje, uložit dokumentaci k funkci a také se pojistit proti tomu, že zákazník může v budoucnu říci, že jsme neudělali, co požadoval.
- Všechny diagramy/vývojové diagramy/logika atd. Ukládáme do Confluence/Fat, kde požádáme zákazníka o potvrzení správnosti budoucí realizace v komentářích.
- Snažíme se zákazníka nezatěžovat technickými detaily. Pokud potřebujeme porozumět tomu, jak to zákazník chce, pak nakreslíme primitivní algoritmy ve formě vývojového diagramu, kterému zákazník porozumí a vše si sám opraví/upraví.
- Pokud zákazník najde v projektu chybu, pak vás žádáme, abyste ji velmi podrobně popsali v Zhira. Za jakých okolností k tomu došlo, kdy, jaký sled akcí zákazník při testování provedl. Připojte prosím snímky obrazovky.
- Snažíme se každý den, maximálně každý druhý den, nasadit na dev server. Zákazník poté začne testovat funkčnost a projekt nezůstane nečinný. Zároveň je to pro zákazníka značka, že projekt je v plném vývoji a nikdo mu neříká pohádky.
- Často se stává, že zákazník úplně nerozumí tomu, co potřebuje. Protože pro sebe vytváří nový byznys s procesy, které ještě nebyly zavedeny. Velmi častá je proto situace, kdy vyhodíme celé kusy kódu do koše a předěláme aplikační logiku. Z toho vyplývá, že byste testy neměli pokrývat úplně všechno. Má smysl pokrýt testy pouze kritickou funkčnost a pak pouze s výhradami.
- Jsou situace, kdy si tým uvědomí, že neplníme termíny. Poté provedeme rychlý audit úkolů a neprodleně o něm informujeme zákazníka. Jako východisko ze situace doporučujeme včasné spuštění důležitých a kritických funkcí a zbytek ponechat až po vydání.
- Pokud zákazník začne vymýšlet různé úkoly z hlavy, začne fantazírovat a vysvětlovat prsty, pak ho požádáme, aby nám poskytl rozložení stránky a tok s logikou, která by měla plně popisovat chování celého rozložení a jeho prvky.
- Před převzetím jakéhokoli úkolu se musíme ujistit, že tato funkce byla zahrnuta v podmínkách naší smlouvy/smlouvy. Pokud se jedná o novou funkci, která jde nad rámec našich původních dohod, musíme tuto funkci nacenit ((odhadovaný čas dokončení + 30 %) x 2) a sdělit zákazníkovi, že nám zabere tolik času, než ji dokončíme, plus termín se posune o odhadovaný čas vynásobený dvěma. Udělejme úkol rychleji – skvělé, všichni z toho budou mít prospěch. Pokud ne, pak jsme vám pomohli.
c) Co v týmu nepřijímáme:
- Nezávaznost, nedostatek vyrovnanosti, zapomnětlivost
- "Krmení snídaně." Pokud nemůžete dokončit úkol a nevíte jak, musíte o tom okamžitě informovat vedoucího týmu a nečekat na poslední chvíli.
- Obočí a chlubí se od člověka, který ještě neprokázal své schopnosti a profesionalitu. Pokud se to prokáže, tak je to možné, v mezích slušnosti :)
- Podvádění ve všech jeho podobách. Pokud úkol není dokončen, neměli byste jeho stav měnit na dokončeno a do klientského chatu psát, že je připraven. Počítač se porouchal, systém havaroval, pes žvýkal notebook - to vše je nepřijatelné. Pokud dojde ke skutečné události vyšší moci, musí být okamžitě informován vedoucí týmu.
- Když je specialista neustále offline a v pracovní době je těžké ho zastihnout.
- Toxicita v týmu není povolena! Pokud někdo s něčím nesouhlasí, pak se všichni sejdou na shromáždění a diskutují a rozhodují o tom.
A řada otázek/tezí, které občas pokládám svému zákazníkovi, aby objasnil všechna nedorozumění:
- Jaká jsou vaše kritéria kvality?
- Jak zjistíte, zda má projekt problémy nebo ne?
- Porušením všech našich doporučení a rad o změně/vylepšení systému nesete všechna rizika pouze vy
- Jakékoli velké změny projektu (například všechny druhy toku navíc) povedou k možnému výskytu chyb (které samozřejmě opravíme)
- Není možné během několika minut pochopit, jaký druh problému se na projektu vyskytl, natož jej okamžitě opravit
- Pracujeme na konkrétním toku produktu (Úkoly v Zhira - Vývoj - Testování - Nasazení). To znamená, že nemůžeme reagovat na celý tok požadavků a stížností v chatu.
- Programátoři jsou programátoři, nikoli profesionální testeři, a nemohou zajistit správnou kvalitu testování projektů
- Zodpovědnost za závěrečné testování a přijímání výrobních úkolů leží zcela na vás
- Pokud jsme již převzali úkol, nemůžeme okamžitě přejít na jiné, dokud nedokončíme ten aktuální (jinak to vede k ještě většímu množství chyb a prodloužení doby vývoje)
- V týmu je méně lidí (kvůli dovolené nebo nemocem), ale práce je více a fyzicky nestihneme odpovědět na vše, co chcete
- Žádáme vás, abyste provedli nasazení do produkčního prostředí bez otestovaných úloh na vývojáři – to je pouze vaše riziko, nikoli vývojáři
- Když zadáváte nejasné úkoly, bez správného postupu, bez návrhových rozvržení, vyžaduje to od nás mnohem více úsilí a času na implementaci, protože my musíme dělat další množství práce místo vás
- Jakékoli úkoly týkající se chyb, bez podrobného popisu jejich výskytu a snímků obrazovky, nám nedávají příležitost pochopit, co se pokazilo a jak můžeme tuto chybu opravit
- Projekt vyžaduje neustálé zdokonalování a vylepšování pro zlepšení výkonu a bezpečnosti. Tým proto věnuje část svého času těmto vylepšením
- Vzhledem k tomu, že máme přesčasy po hodině (urgentní opravy), musíme je kompenzovat v jiné dny
Zákazník zpravidla okamžitě pochopí, že při vývoji softwaru není všechno tak jednoduché a samotná touha zjevně nestačí.
To je obecně vše. Nechávám v zákulisí spoustu jednání a prvotního odlaďování všech procesů, ale ve výsledku se vše povedlo. Mohu říci, že tento proces se pro nás stal jakousi „stříbrnou kulkou“. Noví lidé, kteří do projektu přišli, se mohli hned od prvního dne zapojit do práce, protože všechny procesy byly popsány a dokumentace a architektura ve formě diagramů okamžitě dávala představu o tom, co jsme tady všichni dělali.
PS Rád bych upřesnil, že na naší straně není žádný projektový manažer. Je to na straně zákazníka. Vůbec ne technik. evropský projekt. Veškerá komunikace probíhá pouze v angličtině.
Hodně štěstí všem ve vašich projektech. Neshořejte a snažte se zlepšit své procesy.
Zdroj v mém .
Zdroj: www.habr.com