L'azienda IT media ha requisiti, uno storico di task tracker, fonti (magari anche con commenti nel codice), istruzioni per casi tipici, importanti e complessi in produzione, una descrizione dei processi aziendali (dall'onboarding a "come andare in vacanza" ”) , contatti, chiavi di accesso, elenchi di persone e progetti, descrizioni di aree di responsabilità - e un sacco di altre conoscenze di cui probabilmente ci siamo dimenticati e che possono essere archiviate nei posti più sorprendenti.
Conoscenza =/= documentazione. Questo non si può spiegare, bisogna ricordarlo
Come assicurarsi che coloro che hanno bisogno di sapere qualcosa da questo capiscano dove e come trovarlo, e tutti coloro che hanno bisogno di essere a conoscenza delle singole cose e degli accordi possano scoprire immediatamente e con precisione i cambiamenti in essi contenuti.
Nell'episodio finale del podcast “Team Lead Will Call”, i ragazzi di Skyeng hanno parlato con Igor della gestione della conoscenza Tsupko è una persona del comitato del programma KnowledgeConf e il "direttore dell'ignoto" di Flant.
La registrazione completa è disponibile come e di seguito abbiamo raccolto alcuni suggerimenti interessanti e collegamenti a materiali utili menzionati nell'audio o che ampliano le informazioni da esso. Sarebbe fantastico se condividessi anche gli hack e i trucchi del tuo team nei commenti.
Primo trucchetto: non è più necessario sapere in quale sistema guardare
“Ho preso le nostre fonti di conoscenza e ho fatto una ricerca generale: un'unica finestra con un sistema di filtraggio per ridurre l'area di ricerca. Sì, allo stesso tempo, è ancora necessario monitorarne la qualità, ricostituire la base di conoscenza, combattere la duplicazione e le informazioni errate.
Un pezzo di carta per trovarlo, tutto qui
Ma già circa il 60% degli ingegneri Flant utilizza questa ricerca almeno 1-2 volte al giorno e di solito trova le risposte in prima o seconda posizione. E sotto forma di prova di concetto c'è l'indicizzazione dei documenti di Google: tutti i dox, le cartelle, i furgoni e così via - tutto questo può essere facilmente inserito nella ricerca interna."
Secondo trucchetto: come non perdere cose di fondamentale importanza in un mucchio di chat
"Se lavori in un team distribuito, probabilmente trascorri una parte significativa della tua giornata in Slack - e in tal caso sei abituato a fare qualcosa del genere: "@myteam, aiuta/guarda/inserisci quello giusto... ”.” Ma c'è un problema con l'abbondanza di informazioni e una menzione separata può mancare tra gli altri messaggi.
A Skyeng siamo aiutati da un bot attraverso il quale puoi scrivere un messaggio e taggare un numero qualsiasi di persone o gruppi. Lo usiamo nei casi in cui è davvero importante che le persone leggano o reagiscano: continuerà a premere all'infinito finché non premi il pulsante "Leggo" - non potrai saltarlo o ignorarlo."
Domanda a cui rispondere: cosa fare con la documentazione?
“Molta conoscenza proviene dai tecnici, ma non tutti sanno come descriverla bene.
Dopotutto, non hai alcun compilatore o linter che ti dica se lo stai facendo bene o no - e spesso l'output che abbiamo è un testo incomprensibile, mal formattato e incompleto. Certo, devi farlo normalmente, non perché qualcuno sia venuto e abbia detto "è necessario" - fallo bene per te stesso: tra un mese o due lo leggerai e capirai. E un'altra persona, aprendo un documento, non lo chiuderà immediatamente per sempre, rendendosi conto che è inutile.
Parte del podcast dedicata alla domanda “Quante persone ci vogliono per scrivere una buona documentazione o realizzare una normale demo”
Ma la domanda rimane: quanto tempo dedicare a questo e come farlo in modo efficiente?
E se c’è una risposta onesta qui: a meno che gli uomini d’affari non siano coinvolti e a meno che non sperimentino empiricamente l’impatto di una buona documentazione, c’è il rischio che lo sforzo produca poco ritorno. Questa è più una storia sul cambiamento della cultura.
Per il resto, l'esperienza e il tutoraggio ti salveranno. Analoghi della programmazione in coppia, del monitoraggio dei progressi e della revisione del codice potrebbero essere adatti qui: mostrano le migliori pratiche, colgono gli errori e alla fine risultano noiosi."
Bonus: “Va bene, glielo dico così, capiranno”
La domanda "quanto tempo dedicare a questo e a quale livello farlo" è importante non solo nell'ambito della documentazione, ma in generale per il trasferimento di qualsiasi conoscenza. La demo è anche un ottimo esempio di condivisione delle informazioni. Ma ci sono delle sfumature: ad esempio, come assicurarsi che richiedano il minimo tempo.
Canale di condivisione della conoscenza tra lo sviluppo: rapporti interni, libri utili, articoli, ecc. Anche l'estratto strutturato viene archiviato in Notion.
In parte, questi problemi possono essere risolti mediante la pratica dei rapporti interni. Una volta alla settimana, vengono dedicati 40-60 minuti in orari meno impegnativi e i ragazzi realizzano un reportage video per i colleghi di diversi progetti. Team frontend del prodotto chiave - Vimbox - sul tuo kit UI, che può essere tematizzato per qualsiasi altro progetto. Il team di sviluppo marketing ha parlato di una libreria per il tracciamento e la registrazione delle richieste, che ha subito attirato l'interesse di numerosi altri progetti. Il team del progetto Mathematics ha condiviso la propria esperienza nel passaggio dall'API REST a GraphQL. Il team delle lezioni di gruppo sta pensando di condividere come è stato il primo a passare a PHP 7.4. E così via.
L'elenco è stato mantenuto da maggio 2018 e conta oltre 120 voci
Tutte le riunioni vengono avviate tramite Google Meet aziendale, registrate ed entro 1.5 ore appaiono in una cartella su un Google Drive condiviso, e i collegamenti alle registrazioni vengono duplicati nello stesso Slack. Cioè, non devi venire in caso di emergenza, ma guardalo più tardi alla velocità 20 - di solito il rapporto stesso dura fino a XNUMX minuti e la discussione - come va a finire. Ma non andiamo oltre l’ora)
PS Cosa ha funzionato e cosa non ha funzionato per te?
Link utili:
- Rodion Nagornov di Kaspersky Lab a proposito e perché questa non è documentazione (grazie al canale di Igor per il collegamento , ce ne sono molti altri del genere).
- Igor Tsupko di Flatt a riguardo nella mia compagnia
- Alexey Kataev di Skyeng (lacune di conoscenza in tecnologie e aree specifiche) in un team distribuito.
- Sergey Goncharuk di Flatt sulla trasmissione delle informazioni - , se riscontri un problema in un team distribuito.
Fonte: habr.com