Средната ИТ компания има изисквания, история на инструментите за проследяване на задачи, източници (може би дори с коментари в кода), инструкции за типични, важни и сложни случаи в производството, описание на бизнес процесите (от onboarding до „как да отида на почивка ”), контакти, ключове за достъп, списъци с хора и проекти, описания на области на отговорност - и куп други знания, за които вероятно сме забравили и които могат да се съхраняват на най-невероятните места.
Знания =/= документация. Това не може да се обясни, трябва да се помни
Как да се уверите, че тези, които трябва да знаят нещо от това, разбират къде и как да го намерят и всеки, който трябва да е наясно с отделни неща и договорки, може моментално и точно да разбере за промените в тях.
В последния епизод на подкаста „Team Lead Will Call“ момчетата от Skyeng говориха за управление на знания с Игор Цупко е човек от програмния комитет на KnowledgeConf и „режисьор на неизвестното“ във Flant.
Пълният запис е достъпен като , а по-долу сме събрали някои интересни съвети и връзки към полезни материали, които са споменати в аудиозаписа или разширена информацията от него. Би било чудесно, ако споделите и хакове и трикове на вашия екип в коментарите.
Първи хак: вече не е необходимо да знаете в коя система да търсите
„Взех нашите източници на знания и направих общо търсене за тях: един прозорец с филтрираща система за намаляване на областта за търсене. Да, в същото време все още трябва да следите качеството му, да попълвате базата от знания и да се борите с дублирането и грешната информация.
Един лист хартия, за да намерите това е всичко
Но вече около 60% от инженерите на Flant използват това търсене поне 1-2 пъти на ден - и обикновено намират отговори на първа или втора позиция. И под формата на доказателство за концепцията е индексирането на документи на Google: всички доксове, папки, микробуси и така нататък - всичко това също лесно се въвежда във вътрешното търсене.
Втори хак: как да не пропуснете критично важни неща в куп чатове
„Ако работите в разпределен екип, тогава вероятно значителна част от деня ви прекарва в Slack – и в този случай сте свикнали да правите нещо подобно: „@myteam, помогнете/вижте/въведете правилния... ”.” Но има проблем с изобилието от информация - и отделно споменаване може да бъде пропуснато сред другите съобщения.
В Skyeng ни помага бот, чрез който можете да напишете съобщение и да тагнете произволен брой хора или групи. Използваме го в случаите, когато е наистина важно хората да прочетат или да реагират: ще се натиска безкрайно, докато не натиснете бутона „Четох“ – няма да можете да го пропуснете или игнорирате.“
Въпрос за отговор: какво да правя с документацията?
„Много знания идват от техничарите, но не всеки знае как да ги опише добре.
В края на краищата вие нямате никакъв компилатор или линтер, който да ви каже дали го правите правилно или не - и често резултатът, който имаме, е неразбираем, лошо форматиран и непълен текст. Разбира се, трябва да го направите нормално, а не защото някой дойде и каза „необходимо е“ - вие го правите добре за себе си: след месец-два ще го прочетете и ще разберете. И друг човек, отваряйки документ, няма веднага да го затвори завинаги, осъзнавайки, че е безполезен.
Част от подкаста, посветен на въпроса „Колко хора са необходими, за да напишат добра документация или да направят нормално демо“
Но остава въпросът: колко време да отделим за това и как да го направим ефективно?
И ако тук има честен отговор: освен ако не участват бизнесмени и ако не изпитат емпирично въздействието на добрата документация, съществува риск усилията да донесат малка възвръщаемост. Това е по-скоро история за промяна на културата.
За останалото опитът и менторството ще ви спасят. Аналозите на програмирането по двойки, проследяването на напредъка и прегледите на кода може да са подходящи тук - показване на най-добри практики, бъркане в грешки и накрая скучно.”
Бонус: „Добре, ще им кажа по този начин, те ще разберат“
Въпросът „колко време да отделим за това и на какво ниво да го направя“ е важен не само в рамките на документацията, но като цяло за предаването на всякакви знания. Демото също е чудесен пример за споделяне на информация. Но има нюанси: например как да се уверите, че отнемат минимално време.
Канал за споделяне на знания сред разработката: вътрешни отчети, полезни книги, статии и др. Структурираният екстракт също се съхранява в Notion.
Отчасти тези проблеми могат да бъдат решени чрез практиката на вътрешни доклади. Веднъж седмично се отделят 40-60 минути в по-малко натоварено време - и момчетата правят видео репортаж за колеги от различни проекти. Frontend екип на ключовия продукт - Vimbox - за вашия UI комплект, който може да бъде тематичен за всеки друг проект. Екипът за маркетингово развитие говори за библиотека за проследяване и регистриране на заявки, което веднага привлече интереса на няколко други проекта. Екипът на проекта Mathematics сподели опита си от преминаването от REST API към GraphQL. Екипът на груповите уроци обмисля да сподели как те първи преминаха към PHP 7.4. И така нататък.
Списъкът се поддържа от май 2018 г. и има над 120 записа
Всички срещи се стартират чрез корпоративния Google Meet, записват се и в рамките на 1.5 часа се появяват в папка на споделен Google диск, а връзките към записите се дублират в същия Slack. Тоест, не е нужно да идвате, ако има спешен случай, но го гледайте по-късно на 20 скорост - обикновено самият доклад продължава до XNUMX минути, а дискусията - как се оказва. Но ние не надхвърляме часа)
PS Какво работи и какво не работи за вас?
Полезни връзки:
- Родион Нагорнов от Kaspersky Lab около и защо това не е документация (благодарение на канала на Игор за връзката , има още много подобни).
- Игор Цупко от Flant за това в моята компания
- Алексей Катаев от Skyeng (пропуски в знанията в технологии и специфични области) в разпределен екип.
- Сергей Гончарук от Flant за предаване на информация - , ако срещнете проблем в разпределен екип.
Източник: www.habr.com