Az átlagos IT-cégnek vannak követelményei, a feladatkövetők története, a források (talán megjegyzésekkel a kódban is), a tipikus, fontos és összetett termelési esetekre vonatkozó utasítások, az üzleti folyamatok leírása (a beépítéstől a „hogyan menjünk nyaralni” ”), névjegyek, hozzáférési kulcsok, személyek és projektek listái, felelősségi körök leírása - és még egy csomó olyan tudás, amiről valószínűleg megfeledkeztünk, és amelyeket a legcsodálatosabb helyeken tárolhatunk.
Tudás =/= dokumentáció. Ezt nem lehet megmagyarázni, emlékezni kell rá
Hogyan lehet elérni, hogy akinek tudnia kell ebből valamit, az megértse, hol és hogyan találja meg, és mindenki, akinek tisztában kell lennie az egyéni dolgokkal, megállapodásokkal, azonnal és pontosan értesüljön az ezekben bekövetkezett változásokról.
A „Team Lead Will Call” podcast utolsó epizódjában a Skyeng srácai a tudásmenedzsmentről beszélgettek Igorral. Tsupko a KnowledgeConf programbizottság tagja és a Flant „ismeretlen igazgatója”.
A teljes felvétel elérhető: , az alábbiakban pedig összegyűjtöttünk néhány érdekes tippet és linket olyan hasznos anyagokhoz, amelyekről szó esett a hanganyagban, vagy bővítjük az abból származó információkat. Jó lenne, ha a csapatod trükkjeit és trükkjeit is megosztanád kommentben.
Első feltörés: többé nem kell tudnia, melyik rendszerben keressen
„Kivettem tudásforrásainkat, és általános keresést végeztem bennük: egyetlen ablak szűrőrendszerrel a keresési terület csökkentése érdekében. Igen, ugyanakkor továbbra is figyelemmel kell kísérnie a minőségét, fel kell töltenie a tudásbázist, és le kell küzdenie a megkettőzéseket és a hibás információkat.
Egy darab papír, hogy megtalálja, ennyi
De már most is a Flant mérnökeinek körülbelül 60%-a használja ezt a keresést legalább napi 1-2 alkalommal – és általában az első vagy a második helyen találja meg a választ. A koncepció bizonyítékaként pedig a Google-dokumentumok indexelése szerepel: minden dox, mappa, furgon meghajtó, és így tovább – mindez könnyen beépíthető a belső keresésbe is.”
Második feltörés: hogyan ne hagyjunk ki kritikusan fontos dolgokat egy csomó csevegés során
„Ha elosztott csapatban dolgozol, akkor valószínűleg a napod jelentős része a Slackben telik – és ilyenkor szoktál ilyesmit csinálni: „@csapatom, segíts/nézz/add be a megfelelőt... ”.” Csakhogy gond van az információbőségtel – és egy külön említés elmaradhat a többi üzenet közül.
A Skyengnél egy bot segít nekünk, amelyen keresztül üzenetet írhatsz és tetszőleges számú embert vagy csoportot megjelölhetsz. Olyan esetekben használjuk, amikor nagyon fontos, hogy az emberek olvassák vagy reagáljanak: a végtelenségig piszkál, amíg meg nem nyomod az „Olvastam” gombot – nem tudod kihagyni vagy figyelmen kívül hagyni."
Megválaszolandó kérdés: mi a teendő a dokumentációval?
„Sok tudás a technikusoktól származik, de nem mindenki tudja, hogyan írja le jól.
Végtére is, nincs olyan fordítóprogramja vagy linterje, amely megmondaná, hogy jól csinálja-e vagy sem – és gyakran érthetetlen, rosszul formázott és hiányos szöveget kapunk. Természetesen normálisan kell csinálni, nem azért, mert valaki jött, és azt mondta, hogy „szükséges” - jól csinálod magadnak: egy-két hónap múlva elolvasod és megérted. És egy másik személy, aki kinyit egy dokumentumot, nem zárja be azonnal örökre, mert rájön, hogy haszontalan.
A podcast egy része a következő kérdésnek szentelve: „Hány ember kell egy jó dokumentáció megírásához vagy egy normál demó elkészítéséhez”
De a kérdés továbbra is fennáll: mennyi időt kell erre szánni, és hogyan lehet ezt hatékonyan megtenni?
És ha van itt őszinte válasz: hacsak üzletemberek nem vesznek részt, és ha nem tapasztalják meg empirikusan a jó dokumentáció hatását, fennáll a veszélye annak, hogy az erőfeszítés kevés megtérülést hoz. Ez inkább a kultúra megváltoztatásáról szól.
A többit a tapasztalat és a mentorálás fogja megmenteni. A páros programozás analógjai, az előrehaladás nyomon követése és a kódok áttekintése megfelelőek lehetnek itt – a legjobb gyakorlatok bemutatása, a hibák kiszúrása és a végén unalmas.”
Bónusz: "Rendben, így elmondom nekik, meg fogják érteni"
A „mennyi időt és milyen szinten kell erre fordítani” kérdés nem csak a dokumentáció keretein belül, hanem általában bármilyen tudás átadása szempontjából fontos. A demó az információ megosztásának is remek példája. De vannak árnyalatok: például, hogyan lehet megbizonyosodni arról, hogy ezek minimális időt vesznek igénybe.
Tudásmegosztási csatorna a fejlesztések között: belső jelentések, hasznos könyvek, cikkek stb. A strukturált kivonatot a Notion is tárolja.
Ezek a problémák részben megoldhatók a belső jelentéskészítés gyakorlatával. Hetente egyszer 40-60 percet vesznek el egy kevésbé elfoglalt időben - a srácok pedig videóriportot készítenek a különböző projektekből származó kollégáknak. A kulcstermék frontend csapata - Vimbox - a felhasználói felület készletéről, amely bármely más projekthez tematikus lehet. A marketingfejlesztő csapat a kérések nyomon követésére és naplózására szolgáló könyvtárról beszélt, amely azonnal több más projekt érdeklődését is felkeltette. A Mathematics projekt csapata megosztotta tapasztalatait a REST API-ról a GraphQL-re való váltásról. A csoportos órák csapata azon gondolkodik, hogy megosszák, hogyan váltottak először PHP 7.4-re. Stb.
A listát 2018 májusa óta vezetik, és több mint 120 bejegyzést tartalmaz
Minden megbeszélés a vállalati Google Meeten keresztül indul, rögzítésre kerül, és 1.5 órán belül megjelenik egy mappában egy megosztott Google-meghajtón, a felvételekre mutató hivatkozások pedig ugyanabban a Slackban duplikálódnak. Vagyis nem kell jönni, ha vészhelyzet van, hanem nézd meg később 20 sebességgel - általában maga a riport legfeljebb XNUMX percig tart, és a megbeszélés - hogyan alakul. De nem megyünk túl az órán)
PS Neked mi működött és mi nem?
Hasznos linkek:
- Rodion Nagornov a Kaspersky Lab-tól kb és ez miért nem dokumentáció (köszönet Igor csatornájának a linkért , van még sok hasonló).
- Igor Tsupko Flantból erről a társaságomban
- Alexey Kataev a Skyengtől (tudáshiányok a technológiákban és meghatározott területeken) egy elosztott csapatban.
- Sergey Goncharuk, Flant az információ továbbításáról - , ha problémába ütközik egy elosztott csapatban.
Forrás: will.com