📥 Банк идей

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

На мой взгляд есть несколько важных проблем:

— Часть идей объективно плохая, но лишь потому, что сотрудники не обладают кругозором и не понимают бизнес. И не начнут, если им не рассказывать. Будут приходить с идеями про то, как поменять круглые кнопки на квадратные, как поменять favicon или сделать мобильное приложение потому что теперь все пользуются мобильными приложениями.
Хорошие идеи рождаются из понимания реальности пользователей, понимания их сложностей и получения фидбэка. Для корпоративного софта могут быть нафиг не нужны мобильные приложения и супер-красивые интерфейсы.

— Часть идей поднимают важные проблемы, но переусложнены, так как формулируются в хайп-терминах. Давайте запилим бота, который будет отвечать на вопросы — не надо, достаточно написать инструкцию. Давайте автоматизируем работу с релизами — не надо, для начала хотя бы разберитесь, что у вас происходит и донесите до людей!

— Часть идей объективно хороши, но те, у кого они в голове, не способны их сформулировать и/или обосновать. Что-то вроде давайте пилить деревья пилой, а не валить топорами. У использования топоров могут быть глубокие традиции и причины. Настолько глубокие, что никто не может их сформулировать. А тот, кто предлагает пилу — не может внятно объяснить все достоинства пилы. В итоге вполне годная мысль отправляется в мусорку: невозможно сравнивать две невнятно сформулированных вещи или дополнить идею с пилами тем хорошим, что хранят в себе топоры.

— Идеи не будут рождаться, если нет фидбэка. Даже на самую дурацкую идею должен быть внятный фидбэк. Либо обучающий (если проблема плохая), либо дающий внятное понимание перспектив. Писать в пустоту бессмысленно и люди быстро это прохавают.

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

И, наверное, для того, чтобы запустить "банк идей" нужен какой-то специализированный софт, который можно купить, а ещё лучше - написать самому?

Запуститься можно и с приёма писем на электронную почту, лишь бы на эти письма людям отвечали и общались по-человечески.

📥 Онбординга пост

Собираем информацию по практикам Knowledge Management. Больше всего на данный момент набралось публикаций и материалов по онбордингу — в последние годы было много докладов и годных статей.
Кратко, о тех приёмах, которые получилось вычленить:
— очная лекция от тимлида — самый простой способ онбординга "на коленке". Как правило, этот способ граничит с методом "кинули в воду - выплывай сам".
— приветственное письмо / handbook — каждому новичку выдаётся письмо о том, куда он попал, что ему предстоит сделать в ближайшее время (от недели до года). Самые известные примеры - Valve New Employee Handbook и Gitlab Handbook.
— чек-листы для онбординга — наборы чек-листов, что должен сделать человек в процессе своего онбординга. Иногда - разбитые по срокам (первые пару дней, первые недели, первый год). Хороший доклад был у Глеба Декайло из Badoo, но есть и другие годные публикации.
— наставничество — закрепление за каждым новичком наставника. Практика, которая звучит просто, но, похоже, всерьёз о ней можно говорить только при систематическом найме и больших объёмах онбордящихся. Имеет много подводных камней, в основном связаных с подготовкой наставников. Меня больше всего вдохновила Школа Наставников у Яндекса (https://praktikum.yandex.ru/promo/mentors-school), но вообще про эту тему тоже много материала разной степени качества.
— курс молодого бойца — некоторые рискуют и организуют полноценные обучающие курсы для новичков. Тема сложная, прежде всего, с финансовой и организационной точки зрения — запустить качественное внутренее обучение с подготовленными материалами и предподавателями не просто дорого, а чудовищино дорого.

Если вы впервые столкнулись с удалёнкой, ПОЖАЛУЙСТА

* Если разговор в чатике длится дольше 2х минут - возможно пора перейти в общение голосом
* Если вам кажется, что с вами идут на конфликт/творят дичь - ТОЧНО пора перейти на общение голосом
* Видеть лицо собеседника, его невербалику — важно. Если не вам, то вашим коллегам. Совершенно точно если не видеть собеседников долгое время - начинает поднакрывать депрессией. Включайте камеру!
* Хорошая камера лучше плохой.
* Офисные помещения больше жилых, поэтому возможно вы не замечали важность проветривания.
* Хороший воздух это: температура, отсутствие посторонних запахов, уровень CO2, влажность. Важны все четыре.
* Вам будет тяжелее сконцентрироваться на одном деле. Не приучайте себя во время конференц-созвонов сидеть в чатиках, будьте уважительны к собеседникам!

Notion собирает вики по удаленной работе

Платформа для совместной работы и организации базы знаний Notion в свете последних событий начала на базе себя же собирать вики по инструментам, процессам и культуре удаленной и распределенной работы. Это политики, инструкции и советы от таких компаний, как GitLab, Figma, Loom, Slack и других.

В вики перечислены инструменты, про которые я даже не знала, например, Tandem и Spatial, которые позволяют команде взаимодействовать друг с другом в виртуальных комнатах и даже с элементами AR/VR.

Структура вики довольно проста: Популярное, Политики компаний, Ресурсы про здоровье, Инструменты и гайды, Тактические дискуссии со ссылками на твиттер-треды, Другие советы и посты.

Ссылка: https://www.notion.so/notion/Remote-work-wiki-1b21ef5501714fffa9f5c5c25677371f

Тулзов для удалёнки пост

Есть две удобные утилиты для организации созвонов

- doodle.com — помогает группе людей договориться о времени созвона. Организатор выбирает слоты, а участники голосуют в какое время им удобно.
Вам остаётся только напинать людей, чтобы все проголосовали.

- calendly.com — поможет договариваться о созвоне с другим человеком. Вы просто интегрируете его с гугл-календарём, настраиваете ограничения и любой человек может записаться к вам на встречу. Встреча сразу оказывается в вашем календаре и невозможна ситуация, когда два человека записались на одно время.

Knowledge Management на минималках

Занимаюсь созданием прагматичного гайда по knowledge management. Много контента в интернете по теме — абстрактные, оторванные от реальной жизни, рассуждения, хочется исправить эту ситуацию.

Часть прагматичного гайда — это ответ на вопрос "зачем это нужно и как начать внедрять Knowledge Management?"

Поделился имеющимися наработками на подкасте в The Art Of Programming
http://bit.ly/TAOP217share

По всем вопросам — в личку: @i_tsupko

Удалённой работы дефлопе

Если вы ещё не полностью приспособились к удалёнке - возможно вам помогут некоторые идеи из последнего подкаста DevOps Deflope: http://amp.gs/3l5D

Разгребания легаси пост

Допустим у вас есть незаменимый сотрудник, который обладает уникальным знанием, например, о легаси-проекте. Что делать?

1. Принять решение о том, кто конкретно будет выполнять часть обязанностей уникального человека. Лучше — нескольких человек. Это могут быть новые сотрудники или уже существующие. В процессе выполнения обязанностей по легаси-проекту человек будет погружаться в уникальные знания сам по себе, но на это потребуется время, много времени.
2. Если после пункта (1) остались уникальные знания — возможно есть ещё какие-то повседневные задачи, которые также надо распределить на новых людей.

Сценарий, описанный в (1) и (2) может занять годы. Поэтому ПОСЛЕ того, как вы начали их выполнять, можно применить практики Knowledge Management-а, например:
- писать техническую документацию для ускорения технического онбординга новичков.
- применять практики парного программирования
- проработать чек-листы со списками тем по проекту, в которые новички должны погрузиться, чтобы считаться компетентным (этакий roadmap по вниканию в проект, наподобие тех, что применяется в performance review)
- проводить демо-сессии
- прививать культуру свободного задавания вопросов, которые могут казаться глупыми, но необходимы для вникания
и т.п.

Сами по себе вышеописанные практики Knowledge Management-а не решают проблему легаси, но они предназначены, чтобы радикально ускорить решение этой проблемы.

Если вы хотите, чтобы люди начали обмениваться знаниями — не начинайте с документации. Корректное, экологичное внедрение документации — это задача уровня 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