Det gjennomsnittlige IT-selskapet har krav, en historie med oppgavesporere, kilder (kanskje til og med med kommentarer i koden), instruksjoner for typiske, viktige og komplekse saker i produksjonen, en beskrivelse av forretningsprosesser (fra onboarding til "hvordan dra på ferie" ”) , kontakter, tilgangsnøkler, lister over personer og prosjekter, beskrivelser av ansvarsområder – og en haug med annen kunnskap som vi sikkert har glemt og som kan lagres på de mest fantastiske steder.
Kunnskap =/= dokumentasjon. Dette kan ikke forklares, det må huskes
Hvordan sørge for at de som trenger å vite noe fra dette forstår hvor og hvordan de finner det, og alle som trenger å være klar over enkeltting og avtaler kan kjapt og nøyaktig finne ut om endringer i dem.
I siste episode av "Team Lead Will Call"-podcasten snakket gutta fra Skyeng om kunnskapsledelse med Igor Tsupko er en person i KnowledgeConf-programkomiteen og "direktøren for det ukjente" på Flant.
Hele opptaket er tilgjengelig som , og nedenfor har vi samlet noen interessante tips og lenker til nyttig materiale som ble nevnt i lyden eller utvidet informasjonen fra den. Det ville være flott om du også deler teamets hacks og triks i kommentarfeltet.
Første hack: du trenger ikke lenger vite hvilket system du skal se i
«Jeg tok kunnskapskildene våre og gjorde et generelt søk etter dem: et enkelt vindu med et filtreringssystem for å redusere søkeområdet. Ja, samtidig må du fortsatt overvåke kvaliteten, fylle på kunnskapsbasen og bekjempe duplisering og feilaktig informasjon.
Ett stykke papir for å finne det er alt
Men allerede nå bruker omtrent 60 % av Flant-ingeniørene dette søket minst 1-2 ganger om dagen – og finner vanligvis svar i første eller andre posisjon. Og i form av proof of concept er indeksering av Google-dokumenter: alle doxs, mapper, varebilstasjoner og så videre – alt dette blir også enkelt drevet inn i det interne søket.»
Andre hack: hvordan ikke gå glipp av kritisk viktige ting i en haug med chatter
"Hvis du jobber i et distribuert team, tilbringes sannsynligvis en betydelig del av dagen din i Slack - og i så fall er du vant til å gjøre noe som dette: "@mittteam, hjelp/se/skriv inn den rette... "." Men det er et problem med overflod av informasjon - og en egen omtale kan gå glipp av blant andre meldinger.
Hos Skyeng får vi hjelp av en bot der du kan skrive en melding og tagge et hvilket som helst antall personer eller grupper. Vi bruker det i tilfeller der det er veldig viktig at folk leser eller reagerer: det vil pirke uendelig til du trykker på "Jeg leser"-knappen - du vil ikke kunne hoppe over eller ignorere det."
Spørsmål å svare på: hva skal jeg gjøre med dokumentasjonen?
"Mye kunnskap kommer fra teknologer, men ikke alle vet hvordan de skal beskrive det godt.
Tross alt har du ingen kompilator eller linter som kan fortelle deg om du gjør det riktig eller ikke - og ofte er utdataene vi har uforståelig, dårlig formatert og ufullstendig tekst. Selvfølgelig må du gjøre det normalt, ikke fordi noen kom og sa "det er nødvendig" - du gjør det bra for deg selv: om en måned eller to vil du lese det og forstå. Og en annen person som åpner et dokument, vil ikke umiddelbart lukke det for alltid, og innser at det er ubrukelig.
En del av podcasten dedikert til spørsmålet "Hvor mange mennesker skal til for å skrive god dokumentasjon eller lage en vanlig demo"
Men spørsmålet gjenstår: hvor mye tid å bevilge til dette og hvordan gjøre det effektivt?
Og hvis det er et ærlig svar her: med mindre forretningsfolk er involvert, og med mindre de empirisk opplever virkningen av god dokumentasjon, er det en risiko for at innsatsen gir lite utbytte. Dette er mer en historie om å endre kultur.
For resten vil erfaring og veiledning redde deg. Analoger av parprogrammering, fremdriftssporing og kodegjennomganger kan være passende her – som viser beste praksis, ser etter feil og kjeder til slutt.»
Bonus: "Ok, jeg skal fortelle dem på denne måten, de vil forstå"
Spørsmålet "hvor mye tid å bruke på dette og på hvilket nivå å gjøre det" er viktig ikke bare innenfor rammen av dokumentasjon, men generelt for overføring av all kunnskap. Demoen er også et godt eksempel på å dele informasjon. Men det er nyanser: for eksempel hvordan sørge for at de tar minimalt med tid.
Kunnskapsdelingskanal mellom utvikling: interne rapporter, nyttige bøker, artikler, etc. Det strukturerte utdraget lagres også i Notion.
Til dels kan disse problemene løses ved praktisering av interne rapporter. En gang i uken blir det tatt 40-60 minutter på et mindre travelt tidspunkt – og gutta lager en videoreportasje for kolleger fra ulike prosjekter. Frontend-teamet til nøkkelproduktet - Vimbox - om UI-settet ditt, som kan være tema for alle andre prosjekter. Markedsutviklingsteamet snakket om et bibliotek for sporing og logging av forespørsler, som umiddelbart vakte interesse fra flere andre prosjekter. Matematikk-prosjektteamet delte sin erfaring med å bytte fra REST API til GraphQL. Gruppetimeteamet tenker på å dele hvordan de var de første som byttet til PHP 7.4. Og så videre.
Listen har blitt opprettholdt siden mai 2018 og har over 120 oppføringer
Alle møter startes gjennom bedriftens Google Meet, tas opp og vises innen 1.5 timer i en mappe på en delt Google-stasjon, og lenker til opptakene dupliseres i samme Slack. Det vil si at du ikke trenger å komme hvis det er en nødsituasjon, men se den senere med 20 hastighet - vanligvis varer selve rapporten i opptil XNUMX minutter, og diskusjonen - hvordan det blir. Men vi går ikke lenger enn timen)
PS Hva fungerte og fungerte ikke for deg?
Nyttige lenker:
- Rodion Nagornov fra Kaspersky Lab om og hvorfor dette ikke er dokumentasjon (takk til Igors kanal for lenken , det er mye mer slikt).
- Igor Tsupko fra Flant om det i mitt selskap
- Alexey Kataev fra Skyeng (kunnskapshull i teknologier og spesifikke områder) i et distribuert team.
- Sergey Goncharuk fra Flant om å formidle informasjon - , hvis du støter på et problem i et distribuert team.
Kilde: www.habr.com