Уютный IT адочек

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📥 Банк идей

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

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

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

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

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

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

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

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

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

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

Так, «Финиковый Компот» — это заметный атрибут текущего поколения отечественных аналитических философов. Вместе с тем и главный редактор Евгений Логинов — яркий представитель этого «клана». Причём, не только как организатор, но и как действующий автор, исследователь прагматизма и попросту философ.

Специально для Insolarance Алексей Кардаш поговорил с Евгением Логиновым о множественных гранях современной философии и особенностях отечественного сообщества философов.

https://syg.ma/@insolarance-cult/ievghienii-loghinov-pro-finikovyi-kompot-i-sovriemiennuiu-filosofiiu

🤔 Философского журнала пост

Позволю себе отойти от уютной айтишечки. Я давно наблюдаю за деятельностью "Финикового Компота" и его редакции — они очень крутые ребята, бросающие вызов "старой гвардии".
Неподготовленному человеку понять философов понять очень трудно — слишком много специфической терминологии. Однако в статье, приведённой ниже, терминологии почти нет, а интересно то, как работает журнал, созданный "на коленке" небольшой инициативной командой студентов в 2009 году, и доросший до живого продукта.

Подкаст "Тимлид позвонит" об управлении знаниями

Поговорили с ребятами из SkyEng про хранение знаний в айти-компаниях, подходах к документированию и всяческих лайфхаках.
Я чуть больше рассказал про систему поиска и практику задавания вопросов, которые мы построили во "Фланте", а ведущие поделились своими историями.

52 минуты о реальной практике: https://www.youtube.com/watch?v=3X1SOZtVxcw

Практика Knowledge Management

Интернет принёс чудесную книгу "Knowledge Management. Tools ans Techniques Manual"
https://www.apo-tokyo.org/publications/wp-content/uploads/sites/5/KM-Tools-and-Texhniques-Manual.pdf
Вот прямо перечень приёмов с объяснением что это такое и с какой стороны подступиться. Зачастую даже со ссылками на ютуб и источники.

Хорошая штука, которая стоит того, чтобы её пошарить.

📚 Доки против знаний 🧠
На конференции TeamLeadConf провели холиварный митап , где попытались разобраться: что такое доки, что такое знания, в чём разница и как этим всем управлять?
Причесать конспекты к внятному виду сейчас некогда (работаем над большим проектом базы знаний, о котором — в другой раз), но зато есть аудиозапись мероприятия:
https://drive.google.com/open?id=1hlcBGFPBaFSM9D7gOaFboF3hphd72BWR

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

Спасибо @the_know_all и @MaximTsepkov за помощь в проведении митапа.