Если вы хотите, чтобы люди начали обмениваться знаниями — не начинайте с документации. Корректное, экологичное внедрение документации — это задача уровня advanced, а никак не beginner.
Мало написать документацию (что само по себе сложная задача) — её должны читать и обновлять. Мало её написать один раз — ей должны заниматься постоянно.
Насилие не решает проблемы: документация превратится в пустую филькину грамоту и профанацию. Жизнь меняется и формат зафиксированных знаний тоже должен будет эволюционировать, самодурством этого не добьёшься — нужна культура.

Начните лучше с того, чтобы люди начали разговаривать. Чтобы не боялись задать вопрос кому угодно о чём угодно. Чтобы рассказывали о том, о чём важно рассказать.

Автоматизации пост

Наткнулся на штуку https://n8n.io/ — она позволяет по событию в одном сервисе делать события в других сервисах.

Это что-то вроде https://ifttt.com/, но опенсорсная и, кажется, более прокачанная по логике составляемых сценариев.
Количество триггеров пока не особенно большое, но по моему опыту их всё равно приходится дописывать. А вот возможность хостить штуку у себя бесценна.

В 19:30 по Москве ваш покорный слуга с коллегами будут говорить (скорее всего) о

- менеджменте знаний
- документации
- проведении онлайн-конференций
- культуре и взаимопомощи в айти-компаниях

где-тотут https://www.youtube.com/channel/UCWjbphptoLgEyUWKUpaiWRA будет онлайн-трансляция и возможность задать вопросы.

Для того, чтобы люди обменивались знаниями очень важно, сочетание нескольких факторов:

Не должно быть предубеждений, которые бы мешали сотрудникам задавать вопросы
* Любой, даже кажущийся глупым, вопрос — хороший вопрос!
* Вопрос можно задать кому угодно, на любую тему, любым, даже матерным, языком.

Новых сотрудников должны учить не держать в себе, а задавать вопросы. И, с одной стороны, они должны получать поддержку в этом стремлении, а с другой — они должны помнить про ответственность думать своей головой.

Должна быть поддерживаемая всеми и понятная модель принятия решений — где задавать вопросы в какой ситуации. Особенно это важно для удалённой команды.
* В каких каналах в каких мессенджерах задавать вопросы по каким темам?
* Когда нужно отвлекать коллег и требовать немедленного ответа, когда можно использовать асинхронные механики задавания вопросов, а когда можно просто подождать со своим вопросом до удачного случая?

В идеале — должны быть ответственные за отвечание на вопросы по темам/в каналах, а также какие-то внятные сроки ответа на вопрос.
Последнее, разумеется, ни в коем случае не означает необходимость создания "законов" и "регламентов". Главное — чтобы люди верили, что получат ответ вовремя.

неожиданных тулзов для knowledge management пост

Разработчики и инженеры зачастую хранят "набор волшебных командочек", которые надо запустить в той или иной ситуации. Хранят в текстовом файлике или гуглодоке. А в случае необходимости — копируют и вставляют команду в консоль.

https://shellnotebook.com/
Это записняк для таких "командочек" с возможностью мгновенного их выполнения, не выходя из хранилища.
У приложения, конечно, нет никакой коллаборации и хватает шероховатостей, но сама будем надеяться, что разработчики будут его развивать.
В любом случае — Shell Notebook действительно закрывает локальную проблему управления знаниями и прокачивает пользователя 👍

https://obsidian.md/
Вселенная услышала мольбы и добрые люди начали создавать умную IDE для работы с markdown.

👋 тем, кто тоже просыпается ночью, чтобы доделать интересную задачу.

Прекрасное, ёмкое и короткое (5 минут) видео о том, с какой стороны подступиться к изменению культуры в организации:
https://www.youtube.com/watch?v=ojQT6U-gRAM

22 июля с 14:30 до 16:00 мы проводим мозговой штурм. Будем искать "Быстрые выигрыши" — дешёвые, но выгодные для компании, изменения в области Управления Знаниями.

Мы хотим сформулировать приёмы, которые можно внедрить просто договорившись, поменяв какую-то настройку в софте, написав инструкцию на два абзаца и т.п.. Приёмы, которые могут быть восприняты даже скорее как "хорошие идеи", но влекут за собой много позитивных последствий.

Ждём всех, кому не безразлична тема управления знаниями и кто хочет изменить что-то к лучшему в своей компании. Уверены, что идеи, которые мы сформулируем, помогут вам в вашей работе.

Запись обязательна: https://tsupko-tech.timepad.ru/event/1357069/

Я встречал руководителей, которые искренне верили в то, что "сотрудников надо пиздить" и в важность негативной обратной связи. Равно как и тех, кто блеял, как барашек вместо обратной связи.
При этом, как ни удивительно, что у одних, что у других были выдающиеся результаты. Как так?
Ютуб принёс интересное видео от проекта Veritasium, которое даёт пищу для размышлений — какая обратная связь лучше и всё ли так вообще просто с измерением эффективности от неё?

Archivy — софтинка для организации личных знаний, основанная на поиске и быстром вбрасывании интересного.
https://github.com/Uzay-G/archivy
Написана на Python, страшная как моя жизнь, но, похоже, весьма продуманная.

Управления знаниями пост

Автор канала с коллегами потратил больше полугода своей жизни на то, чтобы сделать внятный учебник по управлению знаниями и, похоже, пришло время презентовать его общественности.

Мы хотим сделать хорошую, структурированную базу знаний, которая поможет вам и вашим IT-компаниям систематически поправить онбординг, внедрить фиксацию и обмен знаниями, сформировать профессиональные сообщества и разрушить стены между людьми и командами.
И, конечно, мы много внимания хотим уделить вещам, которые дают эффект сразу.

Далеко не всё ещё оформлено, у нас огромный бэклог с полезным контентом, но уже сейчас можно посвятить время изучению гайда, поделиться с коллегами и положить сайт в закладки.

📚 Сформулировать проблему — это уже половина дела

Но как её формулировать? "У нас плохой онбординг" — выглядит не очень хорошей формулировкой. Ну плохой и плохой, что делать-то?
Эта формулировка неконкретная, она подразумевает как будто бы большие вложения ("сделать хороший онбординг" — практически бесконечная задача), она вызывает у каждого слушающего свои ассоциации и мысли и не направляет беседу в конструктивное русло.

Можно пойти путём продумывания глобальной темы "хорошего онбординга", а можно — сфокусироваться на быстром выигрыше, на локальной ситуации. Например, сформулировать, что новичкам сложно настраивать окружение для разработки и это отнимает много сил и внимания у команды.
И это выглядит как хороший подход.

Подробнее о быстрой и меткой формулировке проблем — читайте заметку в Прагматичном Гайде:
https://pragmatic-km.guide/wins/whats-the-problem

📈 Высокой культуры пост

Если вы хотите привнести что-то новое в компанию — вы всегда будете сталкиваться с сопротивлением.
Одним из них может быть сказка про якобы уже существующую "высокую культуру", которой нет на самом деле. Некоторые топ-менеджеры, с которыми вам предстоит общаться, к месту и не к месту включают режим защиты своих решений, своего кода и своего наследия — даже не вникая в то, что вы им говорите. При этом на практике свою "высокую культуру" применить они не способны и их собственное поведение идёт полностью в разрез с декларируемым.
Вам говорят про открытость — но цели и причины остаются в головах. Вам говорят про agile и гибкость — но жить нужно по заранее определённому плану и сбор обратной связи игнорируется. Вам говорят про инновации и идеи — но каждая секунда времени должна трекаться в задачи. Вам говорят про высокую культуру обмена знаниями — но запрещены попытки формулировать best practice.
Подобный абсурд смешно звучит тогда, когда вы его осознали, но если у вас не так много опыта — легко поверить рассказам про высокую культуру на серьёзных щах.
Старайтесь избегать дутых щёк в себе и окружающих, смотрите вокруг и задавайте неудобные вопросы.

💣 бомбит от проблем? это шанс что-то исправить!

Есть интересный формат мероприятий — Fuckup Nights. Его однозначно стоит попробовать, если чувствуете, что важные проблемы не двигаются, а в среди сотрудников есть потенциально сильные лидеры.

unix timestamp преодолел 1600000000.

📖 записных книжек пост

Я регулярно записываю интересные мысли, полезные ссылки и логгирую, как решаю те или иные задачи — так лучше запоминается, и легче разобраться, если что-то пошло не так.

Хорошая идея — найти тех, кто делает так же, и обсудить содержимое ваших записных книжек. Это может стать прекрасным началом для запуска документирования и обмена знаниями!

🏋️‍♀️ перегруженных людей пост

Если ваша компания больше 50 человек, то скорее всего мало кто знает всех специалистов по узким темам. А для новичка квест под названием "кого спросить" превращается в аттракцион редиректов с непонятным финалом.
Составили простой алгоритм, как можно разгрузить утомлённых вопросами людей (раскидав запросы на чуть больший круг), потратив буквально пару дней.

🗺 Хороших вводных пост

Сформировалась подборка хороших "роадмапов", учебников по входу в профессии.

- Роадмап тимлида (ссылка)
- Прагматичный гайд по управлению знаниями (ссылка)
- Карта компетенций HR в IT (ссылка) + соц-плюшки (ссылка)

знаешь ещё что-то? помоги, пожалуйста, @i_tsupko составить полный список

в догонку к прошлому посту @ilyoff прислал роадмапы для разработчиков

📋 шаблонный пост

Шаблоны — это прекрасно, они позволяют не тратить силы на обдумывание. Можно не думать, как донести информацию о задаче — а просто заполнить поля в Jira. Или не выдумывать понятный формат резюме — а заполнить шаблон.

Но разработка шаблонов — не тривиальная задача, причём основная сложность даже не в создании шаблона. Сложность в том, чтобы все корректно поняли задумку и не скатывались в формализм при заполнении.

Сегодня хочу поделиться с вами хорошим опенсорс-проектом: https://thegooddocsproject.dev/ — он поможет тем, кто пойдёт нелёгкой дорогой создания и применения шаблонов.