У середньостатистичної ІТ-компанії є вимоги, історія таск-трекерів, вихідники (можливо, навіть із коментарями в коді), інструкції на типові, важливі та складні випадки на продажі, опис бізнес-процесів (від онбордингу до "як піти у відпустку") , контакти, ключі доступу, списки людей та проектів, опис зон відповідальності - і купа інших знань, про які ми напевно забули і які можуть зберігатися в найдивовижніших місцях.
Знання = / = документація. Це не можна пояснити, це треба запам'ятати
Як зробити так, щоб ті, кому знадобилося щось дізнатися, розуміли, де і як це знайти, а всі, кому потрібно бути в курсі окремих речей і домовленостей, миттєво і точно могли дізнатися про зміни в них.
У фінальному випуску подкасту “Тімлід зателефонує” хлопці зі Skyeng поговорили про управління знаннями з Ігорем Цупко - людиною з програмного комітету KnowledgeConf та "директором з невідомого" у Фланті.
Повний запис доступний у вигляді , а нижче ми зібрали кілька цікавих порад та посилання на корисні матеріали, які згадувалися в аудіо або розширюють інформацію з нього. Буде чудово, якщо ви теж поділітесь хаками та граблями своєї команди у коментарях.
Перший хак: вам більше не треба знати, в якій із систем шукати
“Я взяв наші джерела знань і зробив ними загальний пошук: таке єдине вікно із системою фільтрації, щоб зменшити область пошуку. Так, при цьому все ще потрібно стежити за його якістю, поповнювати бази знань, боротися з дуплікацією та помилковою інформацією.
Один скріпка, щоб знайти ось-це-все
Але вже зараз близько 60% інженерів Фланта користуються цим пошуком щонайменше 1-2 рази на день — і зазвичай знаходять відповіді на першій-другій позиції. А у вигляді proof of concept лежить індексування гугл-документів: усі докси, папки, ван драйви і так далі — це теж запросто вганяється у внутрішній пошук”.
Другий хак: як не прогаяти критично-важливе в купі чатів
“Якщо ви працюєте у розподіленій команді, то напевно помітна частина вашого дня проходить у Slack – і у разі чого ви звикли робити якось так: “@myteam, допоможіть/дивіться/вписати потрібне…”. Але є проблема великої кількості інформації — і окрему згадку можна пропустити серед інших повідомлень.
Нам у Skyeng допомагає бот, через якого можна написати повідомлення та тягти будь-яку кількість людей чи груп. Використовуємо у випадках, коли реально важливо, щоб люди прочитали чи відреагували: він нескінченно тикатиме, доки не натиснеш кнопочку “Я прочитав” — пропустити чи проігнорувати не вийде”.
Запитання на засипку: що робити з документацією?
“Дуже багато знань походить від технарів, але не всі вміють їх добре описувати.
Адже в тебе немає жодного компілятора чи лінтера, який би сказав, правильно ти робиш чи ні — і часто на виході ми маємо незрозумілий, погано оформлений і неповний текст. Звичайно, робити нормально треба не тому, що хтось прийшов і сказав "треба" - ти сам собі добре робиш: через місяць-другий прочитаєш і зрозумієш. Та й інша людина, відкриваючи доку, не відразу закриватиме її назавжди, розуміючи, що вона ніяка.
Частина подкасту, присвячена питанню "Скільки потрібно людина, щоб написати хорошу документацію або зробити нормальне демо"
Але залишається питання: скільки часу на це виділяти і як якісно робити?
І якщо є чесна відповідь: якщо не будуть залучені люди з бізнесу, і якщо вони емпірично не відчують віддачу від хорошої документації, є ризик, що спроби дадуть малу віддачу. Це більше історія про зміну культури.
А в іншому, вас врятують досвід та наставництво. Тут можуть підійти аналоги парного програмування, трекінгу прогресу і код-рев'ю — показ найкращих практик, тикання в помилки і нудіння зрештою”.
Бонус: "Та гаразд, я їм так розповім, зрозуміють"
Питання "а скільки часу на це витрачати і на якому рівні робити" важливий не тільки в рамках документації, а взагалі для передачі будь-яких знань. Демо теж чудовий приклад обміну інформацією. Але є нюанси: наприклад, як зробити так, щоб вони мінімально забирали час.
Канал обміну знаннями серед розробки: внутрішні доповіді, корисні книжки, статті тощо. Структурована вичавка також зберігається в Notion.
Частково ці проблеми допомагає вирішити практику внутрішніх доповідей. Раз на тиждень береться 40-60 хвилин у не навантажений час — і хлопці роблять доповідь про відео для колег з різних проектів. Команда фронтенду ключового продукту - Vimbox - про свій UI kit, який можна темізувати під будь-який інший проект. Команда маркетингової розробки — про бібліотеку для трасування та логування запитів, яка одразу зацікавила ще кілька проектів. Команда проекту «Математика» поділилася досвідом переходу із REST API на GraphQL. Команда групових уроків думає розповісти, як першою перейшла PHP 7.4. І так далі.
Список ведеться з травня 2018-го та налічує понад 120 записів
Всі зустрічі-заводяться через корпоративний Google Meet, записуються і протягом доби надають у папці на загальному гугл-диску, а посилання на записи дублюються в той же Slack. Тобто можна не приходити, якщо аврал, а подивитися потім на 1.5 швидкості — зазвичай сама доповідь триває до 20 хвилин, а обговорення — як вийде. Але за межі години не виходимо)
PS А що спрацювало та не спрацювало у вас?
Корисні посилання:
- Родіон Нагорнов з "Лабораторії Касперського" про те, і чому це не документація (дякую за посилання каналу Ігоря , там ще багато такого).
- Ігор Цупко з Фланту про те, у себе в компанії
- Олексій Катаєв із Skyeng (прогалини знань з технологій та специфічних областей) у розподіленій команді.
- Сергій Гончарук з Фланту про донесення інформації якщо зіткнувся з проблемою в розподіленій команді.
Джерело: habr.com