Een gemiddeld IT-bedrijf heeft eisen, een geschiedenis van taaktrackers, broncodes (mogelijk zelfs met opmerkingen in de code), instructies voor typische, belangrijke en complexe gevallen in de productie, een beschrijving van bedrijfsprocessen (van onboarding tot 'hoe ga ik op vakantie'), contactpersonen, toegangssleutels, lijsten met personen en projecten, een beschrijving van verantwoordelijkheidsgebieden - en een hoop andere kennis waar we waarschijnlijk niet meer aan denken en die op de meest verrassende plekken kan worden opgeslagen.
Kennis =/= documentatie. Het kan niet worden uitgelegd, het moet worden onthouden.
Hoe kunnen we ervoor zorgen dat degenen die iets uit deze informatie moeten weten, weten waar en hoe ze dat kunnen vinden? En dat iedereen die op de hoogte moet zijn van afzonderlijke zaken en afspraken, direct en nauwkeurig op de hoogte kan zijn van wijzigingen.
In de laatste aflevering van de podcast “Teamlead Will Call” spraken de mannen van Skyeng met Igor over kennismanagement Tsupko is lid van het programmacomité van KnowledgeConf en de “directeur van het onbekende” bij Flant.
De volledige opname is beschikbaar als , en hieronder hebben we een aantal interessante tips en links verzameld naar nuttig materiaal dat in de audio werd genoemd of dat de informatie daarin verder uitdiept. Het zou geweldig zijn als je ook de hacks en rakes van je team in de reacties zou willen delen.
Hack 1: Je hoeft niet meer te weten in welk systeem je moet zoeken
"Ik heb onze kennisbronnen genomen en er een algemene zoekopdracht naar uitgevoerd: één venster met een filtersysteem om het zoekgebied te verkleinen. Ja, tegelijkertijd moet je de kwaliteit ervan bewaken, de kennisbanken vullen en duplicatie en foutieve informatie bestrijden.
Eén clip om dit allemaal te vinden
Maar nu al gebruikt ongeveer 60% van de Flant-engineers deze zoekfunctie minstens één à twee keer per dag - en vindt antwoorden meestal op de eerste of tweede positie. En als proof of concept is er de indexering van Google-documenten: alle documenten, mappen, schijven, enzovoort - dit alles kan ook eenvoudig in de interne zoekfunctie worden geplaatst.
Hack 2: Hoe je belangrijke informatie niet mist in een menigte chats
Als je in een gedistribueerd team werkt, breng je waarschijnlijk een aanzienlijk deel van je dag door in Slack. Als er dan iets gebeurt, ben je gewend om zoiets te doen als: "@myteam, help/bekijk/voer het benodigde in...". Maar er is een probleem met de overvloed aan informatie, waardoor een aparte vermelding tussen andere berichten kan ontbreken.
Bij Skyeng hebben we een bot waarmee je een bericht kunt schrijven en een willekeurig aantal mensen of groepen kunt taggen. We gebruiken hem in gevallen waarin het echt belangrijk is dat mensen hem lezen of reageren: hij blijft eindeloos doorlezen totdat je op de knop 'Ik heb hem gelezen' klikt. Je kunt hem niet overslaan of negeren.
Lastige vraag: wat doen we met de documentatie?
“Veel kennis komt van technici, maar niet iedereen is goed in het beschrijven ervan.
Je hebt immers geen compiler of linter die je kan vertellen of je het goed doet of niet – en vaak is de output onbegrijpelijk, slecht opgemaakt en onvolledig. Natuurlijk moet je het niet goed doen omdat iemand komt en zegt "dat moet" – je doet het goed voor jezelf: over een maand of twee zul je het lezen en begrijpen. En iemand anders die het document opent, zal het niet meteen voorgoed sluiten, beseffend dat het waardeloos is.
Een deel van de podcast gewijd aan de vraag: "Hoeveel mensen zijn er nodig om goede documentatie te schrijven of een fatsoenlijke demo te maken?"
De vraag blijft echter: hoeveel tijd moeten we hiervoor uittrekken en hoe kunnen we dit efficiënt doen?
En als er een eerlijk antwoord op deze vraag is, bestaat het risico dat de inspanning weinig oplevert, tenzij er zakenmensen bij betrokken zijn en tenzij ze empirisch het rendement van goede documentatie ervaren. Het is meer een verhaal over cultuurverandering.
Anders zullen ervaring en mentorschap je redden. Hier kunnen analogen van pair programming, voortgangsbewaking en code review geschikt zijn: best practices laten zien, fouten aankaarten en uiteindelijk saai zijn.
Bonus: “Kom op, ik zal het ze zo vertellen, dan zullen ze het begrijpen.”
De vraag "hoeveel tijd moet hieraan besteed worden en op welk niveau moet dit gebeuren" is niet alleen belangrijk binnen het kader van documentatie, maar in het algemeen voor de overdracht van kennis. Demo's zijn ook een goed voorbeeld van informatie-uitwisseling. Maar er zijn nuances: bijvoorbeeld hoe je ze zo min mogelijk tijd laat kosten.
Kennisdelingskanaal binnen het ontwikkelteam: interne rapporten, nuttige boeken, artikelen, enz. De gestructureerde samenvatting wordt ook in Notion opgeslagen.
Deze problemen worden deels opgelost door interne rapportages te gebruiken. Eenmaal per week wordt er op een rustig tijdstip 40-60 minuten tijd vrijgemaakt en maken de mannen een videoverslag voor collega's van verschillende projecten. Het frontendteam van het belangrijkste product - Vimbox - over hun UI-kit, die voor elk ander project een thema kan hebben. Het marketing development team — over een bibliotheek voor het traceren en loggen van verzoeken, die meteen de interesse wekte van verschillende andere projecten. Het projectteam "Wiskunde" deelde hun ervaringen met de overstap van REST API naar GraphQL. Het team van de groepslessen overweegt te vertellen hoe zij de eersten waren die overschakelden naar PHP 7.4. En zo verder.
De lijst wordt sinds mei 2018 bijgehouden en bevat ruim 120 vermeldingen.
Alle vergaderingen worden gestart via Google Meet, opgenomen en binnen 1.5 uur in een map op een gedeelde Google Drive gezet. Links naar de opnames worden gedupliceerd in dezelfde Slack. Dat wil zeggen dat je niet hoeft te komen als je haast hebt, en dat je het vervolgens op 20-speed kunt bekijken. Meestal duurt de presentatie zelf maximaal XNUMX minuten, en de discussie ook, zoals blijkt. Maar we gaan niet langer dan een uur.
PS Wat werkte voor jou wel en wat werkte niet?
Nuttige links:
- Rodion Nagornov van Kaspersky Lab vertelt over en waarom is dit geen documentatie (bedankt voor de link naar Igor's kanaal , er zijn er nog veel meer).
- Igor Tsupko uit Flant over in mijn bedrijf
- Alexey Kataev uit Skyeng (kennislacunes in technologieën en specifieke gebieden) in een verspreid team.
- Sergey Goncharuk uit Flant over het verstrekken van informatie — , als u een probleem tegenkomt in een gedistribueerd team.
Bron: www.habr.com
