Kuidas luua ettevõttes teadmistevahetust nii, et see ei teeks nii palju haiget

Keskmisel IT-ettevõttel on nõuded, ülesannete jälgijate ajalugu, allikad (võib-olla isegi koos kommentaaridega koodis), juhised tüüpiliste, oluliste ja keerukate juhtumite jaoks tootmises, äriprotsesside kirjeldus (alates sissevõtmisest kuni "kuidas puhkusele minna"). ”), kontaktid, juurdepääsuklahvid, inimeste ja projektide loendid, vastutusvaldkondade kirjeldused – ja hunnik muid teadmisi, mille me ilmselt unustasime ja mida saab talletada kõige hämmastavamatesse kohtadesse.

Kuidas luua ettevõttes teadmistevahetust nii, et see ei teeks nii palju haiget
Teadmised =/= dokumentatsioon. Seda ei saa seletada, seda tuleb meeles pidada

Kuidas teha nii, et need, kes sellest midagi teadma peavad, saaksid aru, kust ja kuidas seda leida ning kõik, kes peavad kursis olema üksikute asjade ja kokkulepetega, saaksid nende muutustest koheselt ja täpselt teada.

Podcasti “Team Lead Will Call” viimases osas rääkisid Skyengi kutid Igoriga teadmiste juhtimisest mai-kass Tsupko on KnowledgeConfi programmikomitee isik ja Flanti "tundmatute direktor".

Täielik salvestis on saadaval kui YouTube'i video, ja allpool oleme kogunud huvitavaid näpunäiteid ja linke kasulikele materjalidele, mida helis mainitud või sellest saadavat teavet laiendada. Oleks tore, kui jagaksite kommentaarides ka oma meeskonna häkke ja nippe.

Esimene häkkimine: te ei pea enam teadma, millisesse süsteemi vaadata

„Võtsin meie teadmiste allikad ja tegin neile üldise otsingu: üks aken koos filtreerimissüsteemiga otsinguala vähendamiseks. Jah, samal ajal peate siiski jälgima selle kvaliteeti, täiendama teadmistebaasi ning võitlema dubleerimise ja eksliku teabe vastu.

Kuidas luua ettevõttes teadmistevahetust nii, et see ei teeks nii palju haiget
Üks paberitükk, et leida, see on kõik

Kuid juba praegu kasutab umbes 60% Flanti inseneridest seda otsingut vähemalt 1-2 korda päevas – ja tavaliselt leiavad vastused esimesel või teisel positsioonil. Ja kontseptsiooni tõestuseks on Google'i dokumentide indekseerimine: kõik dokumendid, kaustad, kaubikudraivid ja nii edasi – kõik see on hõlpsasti sisestatav ka siseotsingusse.

Teine häkkimine: kuidas vestluste hunnikus kriitiliselt olulisi asju mitte kahe silma vahele jätta

“Kui töötad hajutatud meeskonnas, siis ilmselt veedetakse oluline osa sinu päevast Slackis – ja sellisel juhul oled harjunud tegema midagi sellist: “@myteam, aita/vaata/sisesta õige... "." Kuid probleem on teabe rohkusega - ja eraldi mainimine võib teiste sõnumite hulgast puududa.


Skyengis aitab meid bot, mille kaudu saate kirjutada sõnumi ja märgistada suvalise arvu inimesi või gruppe. Kasutame seda juhtudel, kui on tõesti oluline, et inimesed loeksid või reageeriksid: see torkab lõputult, kuni vajutate nuppu "Ma loen" – te ei saa seda vahele jätta ega ignoreerida.

Küsimus, millele vastata: mida teha dokumentatsiooniga?

“Palju teadmisi tuleb tehnikameestelt, kuid mitte kõik ei oska neid hästi kirjeldada.
Lõppude lõpuks pole teil ühtegi kompilaatorit ega linterit, mis ütleks teile, kas teete seda õigesti või mitte – ja sageli on meie väljund arusaamatu, halvasti vormindatud ja mittetäielik tekst. Muidugi peate seda tegema normaalselt, mitte sellepärast, et keegi tuli ja ütles: "see on vajalik" - teete seda enda jaoks hästi: kuu või kahe pärast loete selle läbi ja saate aru. Ja teine ​​inimene, kes avab dokumendi, ei sulge seda kohe igaveseks, mõistes, et see on kasutu.


Osa podcastist, mis on pühendatud küsimusele "Kui palju inimesi on vaja hea dokumentatsiooni kirjutamiseks või tavalise demo tegemiseks"

Kuid küsimus jääb: kui palju aega selleks eraldada ja kuidas seda tõhusalt teha?
Ja kui siin on aus vastus: kui ei ole kaasatud ärimehi ja kui nad ei koge empiiriliselt hea dokumentatsiooni mõju, on oht, et pingutus ei anna suurt tulu. See on rohkem lugu kultuuri muutumisest.

Ülejäänud osas päästavad teid kogemused ja juhendamine. Siin võivad sobida paarisprogrammeerimise, edenemise jälgimise ja koodiülevaate analoogid – parimate tavade näitamine, vigade otsimine ja lõpuks igav.

Boonus: "Olgu, ma ütlen neile nii, nad saavad aru"

Küsimus "kui palju aega sellele kulutada ja millisel tasemel seda teha" on oluline mitte ainult dokumentatsiooni raames, vaid üldiselt igasuguste teadmiste edasiandmiseks. Demo on ka suurepärane näide teabe jagamisest. Kuid on nüansse: näiteks kuidas tagada, et need võtaksid minimaalselt aega.

Kuidas luua ettevõttes teadmistevahetust nii, et see ei teeks nii palju haiget
Teadmiste jagamise kanal arendustegevuse vahel: sisearuanded, kasulikud raamatud, artiklid jne. Struktureeritud väljavõte salvestatakse ka Notionisse.

Osaliselt saab neid probleeme lahendada sisearuannete praktikaga. Kord nädalas võetakse 40-60 minutit vähem kiirel ajal - ja poisid teevad videoreportaaži kolleegidele erinevatest projektidest. Võtmetoote – Vimbox – esiliidetiim rääkis teie kasutajaliidese komplekti kohta, mida saab teemastada mis tahes muu projekti jaoks. Turunduse arendusmeeskond rääkis päringute jälgimise ja logimise raamatukogust, mis äratas kohe huvi mitmete teiste projektide vastu. Matemaatika projektimeeskond jagas oma kogemust REST API-lt GraphQL-ile üleminekust. Rühmatundide meeskond kavatseb jagada, kuidas nad esimesena PHP 7.4-le üle läksid. Ja nii edasi.

Kuidas luua ettevõttes teadmistevahetust nii, et see ei teeks nii palju haigetNimekirja on peetud alates 2018. aasta maist ja selles on üle 120 kirje

Kõik koosolekud alustatakse ettevõtte Google Meeti kaudu, salvestatakse ja ilmuvad 1.5 tunni jooksul jagatud Google'i draivi kaustas ning salvestiste lingid dubleeritakse samas Slackis. See tähendab, et te ei pea tulema, kui on hädaolukord, vaid vaadake seda hiljem 20 kiirusel - tavaliselt kestab aruanne ise kuni XNUMX minutit ja arutelu - kuidas see välja tuleb. Kuid me ei lähe tunnist kaugemale)

PS Mis teie jaoks töötas ja mis mitte?

Kasulikud lingid:

Allikas: www.habr.com

Lisa kommentaar