Het gemiddelde IT-bedrijf heeft eisen, een geschiedenis van taaktrackers, bronnen (misschien zelfs met commentaar in de code), instructies voor typische, belangrijke en complexe cases in de productie, een beschrijving van bedrijfsprocessen (van onboarding tot ‘hoe ga je op vakantie’) ”), contacten, toegangssleutels, lijsten met mensen en projecten, beschrijvingen van verantwoordelijkheidsgebieden - en een heleboel andere kennis die we waarschijnlijk zijn vergeten en die op de meest verbazingwekkende plaatsen kunnen worden opgeslagen.
Kennis =/= documentatie. Dit kan niet worden verklaard, het moet onthouden worden
Hoe zorg je ervoor dat degenen die hier iets van moeten weten, begrijpen waar en hoe ze het kunnen vinden, en dat iedereen die op de hoogte moet zijn van individuele dingen en overeenkomsten, direct en nauwkeurig de veranderingen daarin kan opvragen.
In de laatste aflevering van de podcast “Team Lead Will Call” spraken de jongens van Skyeng met Igor over kennismanagement Tsupko is lid van de KnowledgeConf-programmacommissie en de ‘directeur van het onbekende’ bij Flant.
De volledige opname is beschikbaar als , en hieronder hebben we enkele interessante tips en links verzameld naar nuttig materiaal dat in de audio werd genoemd of die de informatie daaruit uitbreidt. Het zou geweldig zijn als je ook de hacks en trucs van je team deelt in de reacties.
Eerste hack: je hoeft niet meer te weten in welk systeem je moet kijken
“Ik heb onze kennisbronnen gepakt en er algemeen naar gezocht: één enkel venster met een filtersysteem om het zoekgebied te verkleinen. Ja, tegelijkertijd moet u nog steeds de kwaliteit ervan bewaken, de kennisbasis aanvullen en dubbel werk en foutieve informatie bestrijden.
Eén vel papier om te vinden, dat is alles
Maar nu al gebruikt ongeveer 60% van de Flant-ingenieurs deze zoekopdracht minstens 1-2 keer per dag - en vindt antwoorden meestal op de eerste of tweede positie. En in de vorm van proof of concept is het indexeren van Google-documenten: alle doxs, mappen, bestelwagenschijven, enzovoort - dit alles kan ook gemakkelijk in de interne zoekopdracht worden meegenomen.”
Tweede hack: hoe je cruciale belangrijke dingen in een heleboel chats niet mist
“Als je in een gedistribueerd team werkt, breng je waarschijnlijk een aanzienlijk deel van je dag door in Slack – en in dat geval ben je gewend om zoiets als dit te doen: “@mijnteam, help/kijk/voer de juiste in... .” Maar er is een probleem met de overvloed aan informatie - en een aparte vermelding kan tussen andere berichten gemist worden.
Bij Skyeng worden we geholpen door een bot waarmee je een bericht kunt schrijven en een willekeurig aantal mensen of groepen kunt taggen. We gebruiken het in gevallen waarin het echt belangrijk is dat mensen lezen of reageren: het blijft eindeloos prikken totdat je op de knop ‘Ik lees’ drukt – je kunt het niet overslaan of negeren.”
Vraag om te beantwoorden: wat te doen met de documentatie?
“Veel kennis komt van techneuten, maar niet iedereen weet dit goed te omschrijven.
Je hebt tenslotte geen enkele compiler of linter die je kan vertellen of je het goed doet of niet - en vaak is de output die we hebben onbegrijpelijke, slecht opgemaakte en onvolledige tekst. Natuurlijk moet je het normaal doen, niet omdat iemand kwam en zei "het is nodig" - je doet het goed voor jezelf: over een maand of twee zul je het lezen en begrijpen. En een andere persoon die een document opent, zal het niet onmiddellijk voor altijd sluiten, in het besef dat het nutteloos is.
Onderdeel van de podcast gewijd aan de vraag “Hoeveel mensen zijn er nodig om goede documentatie te schrijven of een normale demo te maken”
Maar de vraag blijft: hoeveel tijd moet je hiervoor uittrekken en hoe doe je dat efficiënt?
En als er hier een eerlijk antwoord is: tenzij er zakenmensen bij betrokken zijn, en tenzij zij empirisch de impact van goede documentatie ervaren, bestaat het risico dat de inspanning weinig rendement zal opleveren. Dit is meer een verhaal over het veranderen van de cultuur.
Voor de rest zullen ervaring en mentoring je redden. Analogen van pair programming, voortgangsregistratie en code-reviews kunnen hier geschikt zijn – het tonen van best practices, het opsporen van fouten en uiteindelijk saai.”
Bonus: “Oké, ik zal het ze op deze manier vertellen, ze zullen het begrijpen”
De vraag “hoeveel tijd hieraan te besteden en op welk niveau dit te doen” is niet alleen belangrijk in het kader van documentatie, maar in het algemeen voor de overdracht van welke kennis dan ook. De demo is ook een mooi voorbeeld van het delen van informatie. Maar er zijn nuances: hoe u er bijvoorbeeld voor kunt zorgen dat ze zo min mogelijk tijd in beslag nemen.
Kanaal voor kennisuitwisseling tussen ontwikkeling: interne rapporten, nuttige boeken, artikelen, enz. Het gestructureerde uittreksel wordt eveneens in Notion opgeslagen.
Gedeeltelijk kunnen deze problemen worden opgelost door de praktijk van interne rapportages. Eén keer per week wordt er 40-60 minuten besteed op een minder druk tijdstip - en maken de jongens een videoverslag voor collega's van verschillende projecten. Frontendteam van het belangrijkste product - Vimbox - over uw UI-kit, die voor elk ander project een thema kan krijgen. Het marketingontwikkelingsteam sprak over een bibliotheek voor het traceren en loggen van verzoeken, wat meteen de belangstelling trok van verschillende andere projecten. Het Wiskunde-projectteam deelde hun ervaringen met het overstappen van REST API naar GraphQL. Het groepslessenteam denkt erover om te vertellen hoe zij als eersten overstapten naar PHP 7.4. Enzovoort.
De lijst wordt sinds mei 2018 bijgehouden en telt ruim 120 vermeldingen
Alle vergaderingen worden gestart via Google Meet, opgenomen en verschijnen binnen 1.5 uur in een map op een gedeelde Google Drive, en links naar de opnames worden gedupliceerd in dezelfde Slack. Dat wil zeggen dat je niet hoeft te komen als er sprake is van een calamiteit, maar later op 20 snelheid bekijkt – meestal duurt de reportage zelf maximaal XNUMX minuten, en de discussie – hoe het afloopt. Maar we gaan niet verder dan het uur)
PS Wat werkte wel en niet voor jou?
Nuttige links:
- Rodion Nagornov van Kaspersky Lab over en waarom dit geen documentatie is (met dank aan Igor's kanaal voor de link , zo zijn er nog veel meer).
- Igor Tsupko van Flant daarover in mijn bedrijf
- Alexey Kataev uit Skyeng (kennislacunes op het gebied van technologieën en specifieke gebieden) in een gedistribueerd team.
- Sergey Goncharuk uit Flant over het overbrengen van informatie - , als u een probleem tegenkomt in een gedistribueerd team.
Bron: www.habr.com