Povprečno IT podjetje ima zahteve, zgodovino sledilcev opravil, vire (morda tudi s komentarji v kodi), navodila za tipične, pomembne in zapletene primere v proizvodnji, opis poslovnih procesov (od onboardinga do »kako iti na dopust«). ”) , kontakti, ključi za dostop, seznami ljudi in projektov, opisi področij odgovornosti - in kup drugega znanja, na katerega smo verjetno pozabili in ki ga je mogoče shraniti na najbolj neverjetnih mestih.
Znanje =/= dokumentacija. Tega ni mogoče razložiti, to si je treba zapomniti
Kako poskrbeti, da bodo tisti, ki morajo od tega nekaj vedeti, razumeli, kje in kako to najti, in da bodo vsi, ki morajo biti seznanjeni s posameznimi stvarmi in dogovori, takoj in natančno izvedeli za spremembe v njih.
V zadnji epizodi podcasta “Team Lead Will Call” so se fantje iz Skyenga z Igorjem pogovarjali o upravljanju znanja Tsupko je oseba v programskem odboru KnowledgeConf in "režiser neznanega" pri Flantu.
Celoten posnetek je na voljo kot , spodaj pa smo zbrali nekaj zanimivih nasvetov in povezav do uporabnih gradiv, ki so bila omenjena v zvočnem posnetku ali razširila informacije iz njega. Odlično bi bilo, če bi v komentarjih delili tudi trike in trike svoje ekipe.
Prvi vdor: ni vam več treba vedeti, kateri sistem iskati
»Vzel sem naše vire znanja in izvedel splošno iskanje zanje: eno okno s sistemom filtriranja za zmanjšanje območja iskanja. Da, hkrati pa morate še vedno spremljati njegovo kakovost, dopolnjevati bazo znanja ter se boriti proti podvajanju in napačnim informacijam.
En kos papirja, da najdem, to je vse
Toda že približno 60 % inženirjev Flanta uporablja to iskanje vsaj 1-2 krat na dan – in običajno najde odgovore na prvem ali drugem mestu. In kot dokaz koncepta je indeksiranje Googlovih dokumentov: vsi dokumenti, mape, pogoni kombijev in tako naprej - vse to je tudi enostavno potisniti v interno iskanje.«
Drugi vdor: kako v množici klepetov ne zamuditi kritično pomembnih stvari
»Če delate v porazdeljeni ekipi, potem verjetno velik del vašega dneva preživite v Slacku - in v tem primeru ste navajeni narediti nekaj takega: »@myteam, pomagaj/poglej/vnesi pravega ... ”.” Toda obstaja težava z obilico informacij - med drugimi sporočili lahko zgrešimo ločeno omembo.
Pri Skyeng nam pomaga bot, preko katerega lahko napišete sporočilo in označite poljubno število ljudi ali skupin. Uporabljamo ga v primerih, ko je res pomembno, da ljudje preberejo ali reagirajo: neskončno bo zbadalo, dokler ne pritisnete gumba »Preberem« - ne boste ga mogli preskočiti ali prezreti.«
Vprašanje za odgovor: kaj storiti z dokumentacijo?
»Veliko znanja prihaja od tehnikov, vendar ga vsi ne znajo dobro opisati.
Navsezadnje nimate nobenega prevajalnika ali linterja, ki bi vam povedal, ali delate prav ali ne - in pogosto je rezultat, ki ga imamo, nerazumljivo, slabo oblikovano in nepopolno besedilo. Seveda morate to storiti normalno, ne zato, ker je nekdo prišel in rekel, da je "potrebno" - to naredite dobro zase: čez mesec ali dva boste to prebrali in razumeli. In druga oseba, ki odpre dokument, ga ne bo takoj za vedno zaprla, saj se zaveda, da je neuporaben.
Del podcasta posvečen vprašanju “Koliko ljudi je potrebnih, da napišeš dobro dokumentacijo ali narediš običajen demo”
Ostaja pa vprašanje, koliko časa za to nameniti in kako to narediti učinkovito?
In če je tukaj iskren odgovor: razen če niso vključeni poslovneži in če empirično ne izkusijo vpliva dobre dokumentacije, obstaja tveganje, da se bo trud malo povrnil. To je bolj zgodba o spreminjanju kulture.
Za ostalo vas bodo rešile izkušnje in mentorstvo. Tu so lahko primerni analogi programiranja v parih, sledenje napredka in pregledi kode – prikazujejo najboljše prakse, iščejo napake in na koncu dolgočasijo.«
Bonus: "V redu, tako jim bom povedal, razumeli bodo"
Vprašanje, koliko časa porabiti za to in na kateri ravni to narediti, ni pomembno le v okviru dokumentacije, ampak na splošno za prenos kakršnega koli znanja. Predstavitev je tudi odličen primer izmenjave informacij. Vendar obstajajo nianse: na primer, kako zagotoviti, da vzamejo minimalen čas.
Kanal za izmenjavo znanja med razvojem: interna poročila, uporabne knjige, članki itd. Strukturirani izvleček je shranjen tudi v Notionu.
Deloma je te težave mogoče rešiti s prakso internih poročil. Enkrat na teden si vzamejo 40-60 minut v manj zasedenem času - in fantje naredijo video poročilo za kolege iz različnih projektov. Frontend ekipa ključnega produkta - Vimbox - o vašem kompletu uporabniškega vmesnika, ki ga je mogoče tematizirati za kateri koli drug projekt. Ekipa za razvoj trženja je govorila o knjižnici za sledenje in beleženje zahtev, ki je takoj pritegnila zanimanje več drugih projektov. Projektna skupina Mathematics je delila svojo izkušnjo prehoda z REST API na GraphQL. Skupina za skupinske lekcije razmišlja o tem, kako so prvi prešli na PHP 7.4. In tako naprej.
Seznam se vodi od maja 2018 in ima več kot 120 vnosov
Vsi sestanki se začnejo prek korporativnega Google Meeta, posnamejo in se v 1.5 urah prikažejo v mapi na skupnem Googlovem disku, povezave do posnetkov pa se podvojijo v istem Slacku. To pomeni, da vam ni treba priti, če je nujen dogodek, ampak si ga oglejte pozneje s hitrostjo 20 - običajno samo poročilo traja do XNUMX minut, razprava pa - kako se izkaže. Vendar ne presegamo ure)
PS Kaj je pri vas delovalo in kaj ne?
Koristne povezave:
- Rodion Nagornov iz Kaspersky Lab o in zakaj to ni dokumentacija (hvala Igorjevemu kanalu za povezavo , še veliko je tega).
- O tem Igor Tsupko iz Flanta v moji družbi
- Alexey Kataev iz Skyeng (vrzeli v znanju v tehnologijah in specifičnih področjih) v porazdeljeni ekipi.
- Sergey Goncharuk iz Flanta o posredovanju informacij - , če naletite na težavo v porazdeljeni ekipi.
Vir: www.habr.com