Průměrná IT firma má požadavky, historii task trackerů, zdroje (třeba i s komentáři v kódu), návody na typické, důležité a složité případy ve výrobě, popis obchodních procesů (od onboardingu až po „jak vyrazit na dovolenou“ ”) , kontakty, přístupové klíče, seznamy lidí a projektů, popisy oblastí odpovědnosti – a hromadu dalších znalostí, na které jsme pravděpodobně zapomněli a které lze uložit na ta nejúžasnější místa.
Znalosti =/= dokumentace. To se nedá vysvětlit, to se musí pamatovat
Jak zajistit, aby ti, kteří z toho něco potřebují vědět, pochopili, kde a jak to najdou, a každý, kdo potřebuje mít povědomí o jednotlivých věcech a dohodách, se mohl okamžitě a přesně dozvědět o změnách v nich.
V poslední epizodě podcastu „Team Lead Will Call“ mluvili kluci ze Skyeng o řízení znalostí s Igorem Tsupko je členem programového výboru KnowledgeConf a „ředitelem neznáma“ ve Flantu.
Celý záznam je k dispozici jako a níže jsme shromáždili několik zajímavých tipů a odkazů na užitečné materiály, které byly zmíněny ve zvuku nebo rozšiřují informace z něj. Bylo by skvělé, kdybyste se v komentářích podělili také o triky a triky svého týmu.
První hack: už nemusíte vědět, do kterého systému se dívat
„Vzal jsem naše zdroje znalostí a provedl jsem pro ně obecné vyhledávání: jediné okno se systémem filtrování pro zmenšení oblasti vyhledávání. Ano, zároveň je potřeba stále sledovat jeho kvalitu, doplňovat znalostní základnu a bojovat s duplicitou a chybnými informacemi.
Jeden kus papíru, abyste našli, to je vše
Ale již asi 60 % inženýrů Flant používá toto vyhledávání alespoň 1-2krát denně – a obvykle najde odpovědi na první nebo druhé pozici. A formou důkazu konceptu je indexování dokumentů Google: všechny doxy, složky, jednotky van a tak dále – to vše lze také snadno vložit do interního vyhledávání.“
Druhý hack: jak si nenechat ujít kriticky důležité věci ve spoustě chatů
„Pokud pracujete v distribuovaném týmu, pak pravděpodobně podstatnou část vašeho dne trávíte ve Slacku – a v takovém případě jste zvyklí dělat něco takového: „@myteam, pomozte/podívejte se/zadejte tu správnou... “.” Jenže je tu problém s přemírou informací – a mezi ostatními zprávami může chybět samostatná zmínka.
Ve Skyeng nám pomáhá bot, jehož prostřednictvím můžete napsat zprávu a označit libovolný počet lidí nebo skupin. Používáme ho v případech, kdy je opravdu důležité, aby lidé četli nebo reagovali: bude donekonečna šťourat, dokud nestisknete tlačítko „Čtu“ – nebudete ho moci přeskočit ani ignorovat.“
Otázka k zodpovězení: co dělat s dokumentací?
„Mnoho znalostí pochází od techniků, ale ne každý ví, jak je dobře popsat.
Koneckonců, nemáte žádný kompilátor nebo linter, který by vám řekl, zda to děláte správně nebo ne – a výstup, který máme, je často nesrozumitelný, špatně formátovaný a neúplný text. Samozřejmě to musíte udělat normálně, ne proto, že někdo přišel a řekl „je to nutné“ - děláte to dobře pro sebe: za měsíc nebo dva si to přečtete a pochopíte. A další osoba, která dokument otevře, jej okamžitě nezavře navždy, protože si uvědomuje, že je k ničemu.
Část podcastu věnovaná otázce „Kolik lidí je potřeba k napsání dobré dokumentace nebo vytvoření normálního dema“
Otázkou však zůstává: kolik času tomu věnovat a jak to udělat efektivně?
A pokud zde existuje upřímná odpověď: pokud nejsou zapojeni obchodníci a pokud empiricky nezažijí dopad dobré dokumentace, existuje riziko, že vynaložené úsilí přinese malou návratnost. Toto je spíše příběh o změně kultury.
Zbytek vás zachrání zkušenost a mentoring. Zde se mohou hodit analogy párového programování, sledování pokroku a kontroly kódu – ukazovat osvědčené postupy, šťourat se do chyb a nakonec nudit.“
Bonus: „Dobře, řeknu jim to takhle, oni to pochopí“
Otázka „kolik času tomu věnovat a na jaké úrovni to udělat“ je důležitá nejen v rámci dokumentace, ale obecně pro přenos jakýchkoli znalostí. Demo je také skvělým příkladem sdílení informací. Existují však nuance: například jak zajistit, aby zabíraly minimální čas.
Kanál sdílení znalostí mezi vývojem: interní zprávy, užitečné knihy, články atd. Strukturovaný extrakt je také uložen v Notion.
Částečně lze tyto problémy řešit praxí interních výkazů. Jednou týdně se zabere 40–60 minut v méně vytíženém čase – a kluci natočí videoreportáž pro kolegy z různých projektů. Frontendový tým klíčového produktu - Vimbox - o vaší sadě uživatelského rozhraní, která může být tematicky zaměřena na jakýkoli jiný projekt. Vývojový tým marketingu hovořil o knihovně pro sledování a protokolování požadavků, která okamžitě přitáhla zájem několika dalších projektů. Tým projektu Mathematics se podělil o své zkušenosti s přechodem z REST API na GraphQL. Tým skupinových lekcí uvažuje o tom, že se podělí o to, jak jako první přešli na PHP 7.4. A tak dále.
Seznam je veden od května 2018 a má více než 120 záznamů
Všechny schůzky začínají prostřednictvím firemního Google Meet, zaznamenávají se a do 1.5 hodin se objeví ve složce na sdíleném disku Google a odkazy na nahrávky jsou duplikovány ve stejném Slacku. To znamená, že v případě nouze nemusíte přijít, ale podívejte se na to později rychlostí 20 – obvykle samotná zpráva trvá až XNUMX minut a diskuse – jak to dopadne. Ale nepřekročíme hodinu)
PS Co se vám osvědčilo a co ne?
Užitečné odkazy:
- Rodion Nagornov z Kaspersky Lab asi a proč to není dokumentace (díky Igorovu kanálu za odkaz , takových je mnohem víc).
- Igor Tsupko z Flat o tom v mé společnosti
- Alexey Kataev ze Skyeng (znalostní mezery v technologiích a specifických oblastech) v distribuovaném týmu.
- Sergey Goncharuk z Flant o předávání informací - , pokud narazíte na problém v distribuovaném týmu.
Zdroj: www.habr.com