La averaĝa IT-kompanio havas postulojn, historion de taskospuriloj, fontojn (eble eĉ kun komentoj en la kodo), instrukcioj por tipaj, gravaj kaj kompleksaj kazoj en produktado, priskribo de komercaj procezoj (de enŝipiĝo ĝis "kiel iri al feriado". ”) , kontaktoj, alirklavoj, listoj de homoj kaj projektoj, priskriboj de respondecaj kampoj - kaj amaso da aliaj scioj, pri kiuj ni verŝajne forgesis, kaj kiuj povas esti konservitaj en la plej mirindaj lokoj.
Scio =/= dokumentado. Ĉi tio ne povas esti klarigita, ĝi devas esti memorita
Kiel certigi, ke tiuj, kiuj bezonas ion el tio scii, komprenas kie kaj kiel trovi ĝin, kaj ĉiuj, kiuj bezonas konscii pri individuaj aferoj kaj interkonsentoj, povas tuj kaj precize ekscii pri ŝanĝoj en ili.
En la fina epizodo de la podkasto "Team Lead Will Call", la uloj de Skyeng parolis pri scio-administrado kun Igor. Tsupko estas persono en la programo-komitato de KnowledgeConf kaj la "direktoro de la nekonataĵo" ĉe Flant.
La plena registrado disponeblas kiel , kaj ĉi-sube ni kolektis kelkajn interesajn konsiletojn kaj ligilojn al utilaj materialoj, kiuj estis menciitaj en la audio aŭ pligrandigi la informojn el ĝi. Estus bonege, se vi ankaŭ dividas la hakojn kaj lertaĵojn de via teamo en la komentoj.
Unua hako: vi ne plu bezonas scii en kiu sistemo serĉi
“Mi prenis niajn scifontojn kaj faris ĝeneralan serĉon por ili: ununura fenestro kun filtra sistemo por redukti la serĉareon. Jes, samtempe, vi ankoraŭ bezonas kontroli ĝian kvaliton, replenigi la scion kaj batali duobligon kaj erarajn informojn.
Unu papero por trovi, tio estas ĉio
Sed jam ĉirkaŭ 60% de Flant-inĝenieroj uzas ĉi tiun serĉon almenaŭ 1-2 fojojn tage - kaj kutime trovas respondojn en la unua aŭ dua pozicio. Kaj en la formo de pruvo de koncepto estas la indeksado de Guglo-dokumentoj: ĉiuj doksoj, dosierujoj, kamionetoj, ktp - ĉio ĉi estas ankaŭ facile movita en la internan serĉon."
Dua hako: kiel ne maltrafi kritike gravajn aferojn en amaso da babilejoj
"Se vi laboras en distribuita teamo, tiam verŝajne grava parto de via tago estas pasigita en Slack - kaj tiukaze vi kutimas fari ion tian: "@mia teamo, helpu/rigardu/enigu la ĝustan... ”.” Sed estas problemo pri la abundo de informoj – kaj aparta mencio povas manki inter aliaj mesaĝoj.
Ĉe Skyeng nin helpas bot, per kiu vi povas skribi mesaĝon kaj etikedi ajnan nombron da homoj aŭ grupoj. Ni uzas ĝin en kazoj kie vere gravas, ke homoj legu aŭ reagas: ĝi pikos senfine ĝis vi premos la butonon "Mi legas" - vi ne povos preterlasi aŭ ignori ĝin."
Demando por respondi: kion fari kun la dokumentado?
“Multaj scio venas de teknikistoj, sed ne ĉiuj scias kiel bone priskribi ĝin.
Post ĉio, vi ne havas ajnan kompililon aŭ linter kiu dirus al vi ĉu vi faras ĝin ĝuste aŭ ne - kaj ofte la eligo kiun ni havas estas nekomprenebla, malbone formatita kaj nekompleta teksto. Kompreneble, vi devas fari ĝin normale, ne ĉar iu venis kaj diris "ĝi estas necesa" - vi faras ĝin bone por vi mem: post unu aŭ du monatoj vi legos kaj komprenos. Kaj alia homo, malfermante dokumenton, ne tuj fermos ĝin por ĉiam, konsciante, ke ĝi estas senutila.
Parto de la podkasto dediĉita al la demando "Kiom da homoj necesas por skribi bonan dokumentadon aŭ fari normalan demonstraĵon"
Sed restas la demando: kiom da tempo asigni por tio kaj kiel fari ĝin efike?
Kaj se estas honesta respondo ĉi tie: krom se komercistoj estas implikitaj, kaj krom se ili empirie spertas la efikon de bona dokumentado, ekzistas risko ke la peno donos malmulte da rendimento. Ĉi tio estas pli rakonto pri ŝanĝado de kulturo.
Por la resto, sperto kaj mentorado savos vin. Analogoj de parprogramado, progreso-spurado kaj kodo-recenzoj povas esti taŭgaj ĉi tie - montrante plej bonajn praktikojn, piki erarojn kaj enuigi finfine."
Gratifiko: "Bone, mi diros al ili tiel, ili komprenos"
La demando "kiom da tempo pasigi por ĉi tio kaj je kia nivelo fari ĝin" gravas ne nur en la kadro de dokumentado, sed ĝenerale por translokigo de ajna scio. La demo ankaŭ estas bonega ekzemplo de kunhavigo de informoj. Sed estas nuancoj: ekzemple, kiel certigi, ke ili okupas minimuman tempon.
Kanalo de interŝanĝo de scio inter evoluo: internaj raportoj, utilaj libroj, artikoloj, ktp. La strukturita eltiraĵo ankaŭ estas konservita en Notion.
Parte, ĉi tiuj problemoj povas esti solvitaj per la praktiko de internaj raportoj. Unufoje semajne, 40-60 minutoj estas prenitaj en malpli okupata tempo - kaj la uloj faras videoraporton por kolegoj de malsamaj projektoj. Frontend-teamo de la ŝlosila produkto - Vimbox - pri via UI-kompleto, kiu povas esti temo por iu ajn alia projekto. La merkata disvolva teamo parolis pri biblioteko por spurado kaj registradaj petoj, kiu tuj altiris la intereson de pluraj aliaj projektoj. La Matematika projektteamo dividis sian sperton pri ŝanĝo de REST API al GraphQL. La teamo de grupaj lecionoj pensas dividi kiel ili estis la unuaj, kiuj ŝanĝis al PHP 7.4. Kaj tiel plu.
La listo estas konservita ekde majo 2018 kaj havas pli ol 120 enskribojn
Ĉiuj renkontiĝoj estas komencitaj per kompania Google Meet, registritaj kaj ene de 1.5 horoj aperas en dosierujo sur komuna Google-disko, kaj ligiloj al la registradoj estas duobligitaj en la sama Slack. Tio estas, vi ne devas veni se estas krizo, sed rigardu ĝin poste je 20 rapideco - kutime la raporto mem daŭras ĝis XNUMX minutoj, kaj la diskuto - kiel ĝi rezultas. Sed ni ne preterpasas la horon)
PS Kio funkciis kaj ne funkciis por vi?
Utilaj ligoj:
- Rodion Nagornov de Kaspersky Lab pri kaj kial ĉi tio ne estas dokumentado (dankon al la kanalo de Igor pro la ligo , ekzistas multe pli da tia).
- Igor Tsupko el Flant pri tio en mia kompanio
- Alexey Kataev el Skyeng (sciomankoj en teknologioj kaj specifaj areoj) en distribuita teamo.
- Sergey Goncharuk el Flant pri transdono de informoj - , se vi renkontas problemon en distribuita teamo.
fonto: www.habr.com