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/ — он поможет тем, кто пойдёт нелёгкой дорогой создания и применения шаблонов.

Размышлений на бумаге пост
У меня есть привычка "думать на бумажке", т.е. записывать в блокнотик все ключевые действия того, что ты сделал и плана того, что ты собираешься сделать. Это очень помогает систематизировать мысли, когда сталкиваешься с Непознанным, с качественно новым классом задач. Плюс защищает от потери контекста в случае отвлечений: даже если голова после выходных полностью очистится ты всегда знаешь на чём остановился и что предполагал делать дальше.
Это здорово помогает потом проводить postmortem-ы и вытаскивать успешный опыт.

Раньше я вёл свои записи в google docs: всегда можно пошарить записи с коллегами (если ВДРУГ нужна такая необходимость) + всё хранится в облаке. Для быстрого создания гугл-документа всегда можно ввести урлик http://docs.new — это такой специальный домен от Гугла (аналогичные есть для всех видов документов в гугл-диске).

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

🧙‍♂️ self-improvement message

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

👻 Чудовищного онбординга пост

Однажды наблюдал, как всем новичкам в качестве онбординга предлагалось "посмотреть лабы". Лабы — это 3 видео по 2-3 часа, где техдир, с шутками, прибаутками, оффтопиками и попытками отладить ошибки, сбивчиво объяснял достаточно сложные темы. У техдира за плечами было пару лет предподавания в ВУЗе, поэтому он был очень уверен в своих силах.
Очень удобно: отдаёшь видосы новичку и пару-тройку дней он тебя не трогает: типа учится. К счастью, сотрудники постепенно начали саботировать просмотр лаб и те отмерли естественным путём.

Позже подвиг был повторён другим человеком: он записал штук 8 видосов минут по 40 про то, как устроены те или иные процессы и внутренние сервисы. На этот раз без шутеек, но зато во всех подробностях. Работало это примерно с тем же успехом.

Ваш покорный слуга тоже отжигал: я делал "курс молодого бойца", где пытался научить людей практическим навыкам по типовым задачам. Этот КМБ делался до того, как человек попадал в команду и приступал к реальной практике и, по логике, должен был ускорить решение реальных задач.

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

Примерно такой же подвиг можно совершить, если тупо скопировать себе куски онбординга из GitLab Handbook.
Старайтесь быть краткими, но не более необходимого.

🧙‍♀️ список экспертов

Круто, когда ты знаешь, кого в компании спросить по каким вопросам. Но составление такого списка может занять недели.
Как сделать это максимально быстро?
Попробовал ответить: https://pragmatic-km.guide/wins/know-experts

🎁 знаний пост

Когда нет систематического обмена опытом — людям приходится переизобретать велосипеды, создавать дублирующие документы, решения и бизнес-процессы.
И ладно бы дело было в "общеизвестных" сведениях, но ведь часто речь идёт о бизнес-специфике, которую просто неоткуда взять.
Специалистам некогда заниматься рассказами о своих открытиях. Особенно, если им не хватает навыков: формулирования мыслей, написания статей, структурирования опыта.

Как бы это пофиксить?

Рассказал о своих исследованиях на этот счёт на DevOpsLive и оформил материалы в виде статьи: https://habr.com/ru/company/oleg-bunin/blog/525110/

🧟‍♀️ legacy

Я сталкивался с legacy-проектами на разных ролях, и каждый раз это было больно. И самое обидное заключается в том, что из-за отсутствия информации о какой-нибудь одной мелочи, тратятся часы и дни усилий. А человек, который знал об этой мелочи в это время находился в доступности для 30-40 минутного разговора.

Но легаси на то и легаси, что люди уходят, да и не набегаешься по всем с вопросами. Было бы здорово собраться с силами и превентивно выгрузить информацию куда-то "на бумагу".
Но как это сделать максимально эффективно?
Делюсь своим опытом тут: https://pragmatic-km.guide/wins/feature-mindmap