Den gennemsnitlige it-virksomhed har krav, en historie med opgavesporere, kilder (måske endda med kommentarer i koden), instruktioner til typiske, vigtige og komplekse sager i produktionen, en beskrivelse af forretningsprocesser (fra onboarding til "hvordan man tager på ferie ”), kontakter, adgangsnøgler, lister over personer og projekter, beskrivelser af ansvarsområder – og en masse anden viden, som vi nok har glemt, og som kan opbevares de mest fantastiske steder.
Viden =/= dokumentation. Dette kan ikke forklares, det skal huskes
Hvordan man sikrer sig, at de, der skal vide noget herfra, forstår, hvor og hvordan man finder det, og alle, der skal være opmærksomme på individuelle ting og aftaler, kan øjeblikkeligt og præcist finde ud af ændringer i dem.
I det sidste afsnit af "Team Lead Will Call"-podcasten talte fyrene fra Skyeng om videnledelse med Igor Tsupko er en person i KnowledgeConf-programudvalget og "direktøren for det ukendte" hos Flant.
Den fulde optagelse er tilgængelig som , og nedenfor har vi samlet nogle interessante tips og links til nyttige materialer, der blev nævnt i lyden eller udvider informationen fra den. Det ville være fantastisk, hvis du også deler dit holds hacks og tricks i kommentarerne.
Første hack: du behøver ikke længere at vide, hvilket system du skal kigge i
“Jeg tog vores videnskilder og lavede en generel søgning efter dem: et enkelt vindue med et filtreringssystem til at reducere søgeområdet. Ja, på samme tid skal du stadig overvåge dens kvalitet, genopbygge videnbasen og bekæmpe dobbeltarbejde og fejlagtig information.
Et stykke papir for at finde det er alt
Men allerede nu bruger omkring 60 % af Flant-ingeniørerne denne søgning mindst 1-2 gange om dagen – og finder normalt svar i første eller anden position. Og i form af proof of concept er indeksering af Google-dokumenter: alle doxs, mapper, varevognsdrev og så videre – alt dette er også nemt drevet ind i den interne søgning.”
Andet hack: hvordan man ikke går glip af kritisk vigtige ting i en masse chats
“Hvis du arbejder i et distribueret team, så bliver nok en væsentlig del af din dag brugt i Slack – og i så fald er du vant til at gøre sådan noget: “@mitteam, hjælp/se/indtast den rigtige... "." Men der er et problem med overfloden af information - og en separat omtale kan mangle blandt andre beskeder.
Hos Skyeng bliver vi hjulpet af en bot, hvorigennem du kan skrive en besked og tagge et vilkårligt antal personer eller grupper. Vi bruger det i tilfælde, hvor det er virkelig vigtigt, at folk læser eller reagerer: det vil stikke uendeligt, indtil du trykker på "Jeg læser"-knappen - du vil ikke være i stand til at springe over eller ignorere det."
Spørgsmål at besvare: hvad skal man gøre med dokumentationen?
"Meget viden kommer fra teknologer, men ikke alle ved, hvordan man beskriver det godt.
Når alt kommer til alt, har du ikke nogen compiler eller linter, der kan fortælle dig, om du gør det rigtigt eller ej - og ofte er det output, vi har, uforståelig, dårligt formateret og ufuldstændig tekst. Selvfølgelig skal du gøre det normalt, ikke fordi nogen kom og sagde "det er nødvendigt" - du gør det godt for dig selv: om en måned eller to vil du læse det og forstå. Og en anden person, der åbner et dokument, vil ikke øjeblikkeligt lukke det for evigt og indse, at det er ubrugeligt.
En del af podcasten dedikeret til spørgsmålet "Hvor mange mennesker skal der til for at skrive god dokumentation eller lave en normal demo"
Men spørgsmålet er stadig: hvor meget tid skal der afsættes til dette, og hvordan gør man det effektivt?
Og hvis der er et ærligt svar her: Medmindre erhvervsfolk er involveret, og med mindre de empirisk oplever virkningen af god dokumentation, er der en risiko for, at indsatsen giver ringe udbytte. Dette er mere en historie om at ændre kultur.
For resten vil erfaring og vejledning redde dig. Analoger af parprogrammering, fremskridtssporing og kodegennemgange kan være velegnede her - viser bedste praksis, stikker i fejl og keder i sidste ende."
Bonus: "Okay, jeg fortæller dem på denne måde, de vil forstå"
Spørgsmålet "hvor meget tid at bruge på dette og på hvilket niveau at gøre det" er vigtigt ikke kun inden for rammerne af dokumentation, men generelt for overførsel af enhver viden. Demoen er også et godt eksempel på deling af information. Men der er nuancer: for eksempel hvordan man sikrer sig, at de tager minimal tid.
Vidensdelingskanal mellem udvikling: interne rapporter, nyttige bøger, artikler mv. Det strukturerede ekstrakt gemmes også i Notion.
Til dels kan disse problemer løses ved at praktisere interne rapporter. En gang om ugen bliver der taget 40-60 minutter på et mindre travlt tidspunkt – og fyrene laver en videoreportage for kolleger fra forskellige projekter. Frontend-teamet af nøgleproduktet - Vimbox - om dit UI-sæt, som kan have et tema til ethvert andet projekt. Marketingudviklingsteamet talte om et bibliotek til sporing og logning af forespørgsler, som straks tiltrak interessen fra flere andre projekter. Matematik-projektteamet delte deres erfaringer med at skifte fra REST API til GraphQL. Gruppetimersteamet overvejer at dele, hvordan de var de første til at skifte til PHP 7.4. Og så videre.
Listen er blevet vedligeholdt siden maj 2018 og har over 120 poster
Alle møder startes gennem virksomhedens Google Meet, optages og vises inden for 1.5 timer i en mappe på et delt Google-drev, og links til optagelserne duplikeres i samme Slack. Det vil sige, at du ikke behøver at komme, hvis der er en nødsituation, men se den senere med 20 hastighed - normalt varer selve rapporten op til XNUMX minutter, og diskussionen - hvordan det bliver. Men vi går ikke ud over timen)
PS Hvad virkede og virkede ikke for dig?
Nyttige links:
- Rodion Nagornov fra Kaspersky Lab om og hvorfor dette ikke er dokumentation (tak til Igors kanal for linket , der er meget mere af den slags).
- Igor Tsupko fra Flant om det i mit firma
- Alexey Kataev fra Skyeng (videnshuller i teknologier og specifikke områder) i et distribueret team.
- Sergey Goncharuk fra Flant om at formidle information - , hvis du støder på et problem i et distribueret team.
Kilde: www.habr.com