Det genomsnittliga IT-företaget har krav, en historia av uppgiftsspårare, källor (kanske till och med med kommentarer i koden), instruktioner för typiska, viktiga och komplexa fall i produktionen, en beskrivning av affärsprocesser (från onboarding till "hur man åker på semester" ”) , kontakter, åtkomstnycklar, listor över personer och projekt, beskrivningar av ansvarsområden – och en massa annan kunskap som vi säkert glömt bort och som kan förvaras på de mest fantastiska platser.
Kunskap =/= dokumentation. Detta kan inte förklaras, det måste kommas ihåg
Hur man säkerställer att de som behöver veta något från detta förstår var och hur man hittar det, och alla som behöver vara medvetna om enskilda saker och avtal kan omedelbart och korrekt få reda på förändringar i dem.
I det sista avsnittet av "Team Lead Will Call"-podcasten pratade killarna från Skyeng om kunskapshantering med Igor Tsupko är en person i KnowledgeConf-programkommittén och "direktören för det okända" på Flant.
Hela inspelningen finns tillgänglig som , och nedan har vi samlat några intressanta tips och länkar till användbart material som nämndes i ljudet eller utökar informationen från det. Det skulle vara bra om du också delar ditt teams hacks och tricks i kommentarerna.
Första hacket: du behöver inte längre veta vilket system du ska titta i
”Jag tog våra kunskapskällor och gjorde en allmän sökning efter dem: ett enda fönster med ett filtreringssystem för att minska sökområdet. Ja, samtidigt måste du fortfarande övervaka dess kvalitet, fylla på kunskapsbasen och bekämpa dubbelarbete och felaktig information.
En bit papper för att hitta det är allt
Men redan nu använder cirka 60 % av Flants ingenjörer den här sökningen minst 1-2 gånger om dagen – och hittar vanligtvis svar i första eller andra positionen. Och i form av proof of concept är indexeringen av Google-dokument: alla doxs, mappar, skåpbilsenheter och så vidare - allt detta kan också enkelt drivas in i den interna sökningen."
Andra hacket: hur man inte missar kritiskt viktiga saker i ett gäng chattar
"Om du arbetar i ett distribuerat team så spenderas förmodligen en betydande del av din dag i Slack - och i så fall är du van vid att göra något i stil med detta: "@mitt team, hjälp/titta/skriv in rätt... ”.” Men det finns ett problem med överflöd av information - och ett separat omnämnande kan missas bland andra meddelanden.
På Skyeng får vi hjälp av en bot genom vilken du kan skriva ett meddelande och tagga valfritt antal personer eller grupper. Vi använder det i de fall där det är väldigt viktigt att folk läser eller reagerar: det kommer att peta oändligt tills du trycker på "Jag läser"-knappen - du kommer inte att kunna hoppa över eller ignorera det."
Fråga att besvara: vad ska man göra med dokumentationen?
"Mycket kunskap kommer från tekniker, men inte alla vet hur man beskriver det bra.
När allt kommer omkring, du har ingen kompilator eller linter som skulle tala om för dig om du gör det rätt eller inte - och ofta är utdata vi har obegriplig, dåligt formaterad och ofullständig text. Naturligtvis måste du göra det normalt, inte för att någon kom och sa "det är nödvändigt" - du gör det bra för dig själv: om en månad eller två kommer du att läsa det och förstå. Och en annan person som öppnar ett dokument kommer inte omedelbart att stänga det för alltid och inse att det är värdelöst.
En del av podden tillägnad frågan "Hur många människor krävs för att skriva bra dokumentation eller göra en vanlig demo"
Men frågan kvarstår: hur mycket tid att avsätta för detta och hur man gör det effektivt?
Och om det finns ett ärligt svar här: om inte affärsmän är inblandade, och om de inte empiriskt upplever effekten av bra dokumentation, finns det en risk att insatsen ger liten avkastning. Det här är mer en berättelse om att förändra kultur.
I övrigt kommer erfarenhet och mentorskap att rädda dig. Analoger av parprogrammering, framstegsspårning och kodgranskning kan vara lämpliga här - visar bästa praxis, petar på fel och tråkigt i slutändan."
Bonus: "Okej, jag ska berätta för dem så här, de kommer att förstå"
Frågan "hur mycket tid man ska lägga på detta och på vilken nivå man ska göra det" är viktig inte bara inom ramen för dokumentation, utan generellt för överföring av all kunskap. Demon är också ett bra exempel på att dela information. Men det finns nyanser: till exempel hur man ser till att de tar minimal tid.
Kunskapsdelningskanal mellan utveckling: interna rapporter, användbara böcker, artiklar, etc. Det strukturerade utdraget lagras också i Notion.
Delvis kan dessa problem lösas genom att använda interna rapporter. En gång i veckan tas 40-60 minuter vid en mindre hektisk tid – och killarna gör en videoreportage för kollegor från olika projekt. Frontend-teamet för nyckelprodukten - Vimbox - om ditt UI-kit, som kan ha ett tema för alla andra projekt. Marknadsutvecklingsteamet pratade om ett bibliotek för spårning och loggning av förfrågningar, vilket omedelbart väckte intresse från flera andra projekt. Mathematics-projektgruppen delade med sig av sin erfarenhet av att byta från REST API till GraphQL. Grupplektionsteamet funderar på att dela hur de var först med att byta till PHP 7.4. Och så vidare.
Listan har underhållits sedan maj 2018 och har över 120 poster
Alla möten startas genom företagets Google Meet, spelas in och visas inom 1.5 timmar i en mapp på en delad Google-enhet, och länkar till inspelningarna dupliceras i samma Slack. Det vill säga, du behöver inte komma om det är en nödsituation, utan se den senare i 20 hastighet - vanligtvis varar själva rapporten upp till XNUMX minuter, och diskussionen - hur det blir. Men vi går inte längre än timmen)
PS Vad fungerade och inte fungerade för dig?
Användbara länkar:
- Rodion Nagornov från Kaspersky Lab om och varför detta inte är dokumentation (tack vare Igors kanal för länken , det finns mycket mer sådant).
- Igor Tsupko från Flant om det i mitt företag
- Alexey Kataev från Skyeng (kunskapsluckor i teknologier och specifika områden) i ett distribuerat team.
- Sergey Goncharuk från Flant om att förmedla information - , om du stöter på ett problem i ett distribuerat team.
Källa: will.com