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

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

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

Таким образом, онбординг следует по смыслу разделять на две части:
- минимальную информацию, которую нужно донести за 2..3 дня максимум.
- общие меры, направленные на улучшение обмена знаниями в команде, которые будут помогать онбордящемуся в первые 2..3 месяца.

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

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

Есть альтернативный подход к уменьшению времени онбординга. Радикальный.
Я его не пробовал, но на митапе делились своими соображениями:
нужно как можно быстрее выявлять "проблемных" и "не способных" людей и увольнять их.
Сюда входит:
- приём "тестового дня"
- более лучшая проработка требований к вакансии вместе с HR-ом
- как можно более раннее принятие решения о прохождении испытательного срока
Формально, так тоже можно уменьшить среднее время онбординга.

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

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

Ускорение принятия решения об испытательном
Есть ощущение, что на самом деле тимлиды с опытом способны достаточно точно понять есть толк от человека или нет задолго до окончания испытательного. Если они действительно зададутся такой целью, вылезет и осознается много нюансов касательно требований и онбординг естественным образом начнёт проистекать гораздо шустрее, ибо пятки начнут подгорать.
Однако, вопрос о том, как действительно поставить такую цель остаётся открытым и зависит от специфики компании.

Первый эпизод по новостному поводу, про nginx! 90% эпизода — про технологии: что такое Nginx, почему и где он используется, что в нем нравится, а что — бесит. 10% — эмоции, получилось жарко и даже немного стыдно.

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

Гости: Данила Штань, технический директор Яндекс.Вертикалей (Авто.ру, Яндекс.Недвижимость и Яндекс.Работа) и Дима Столяров — технический директор крупного русского devops аутсорсера Фланта.

Го слушать, мы создали: Apple, Google, Castbox, Spotify, Яндекс, Overcast, веб-версия.

Родион на пальцах объяснил, что такое управление знаниями и почему это не дока
https://www.youtube.com/watch?v=CZnuwrFIEi4
👍

Воспользовался выходными, чтобы перечитать закладки со статьями и наткнулся на прекрасное.
https://vc.ru/hr/95754-razvitie-i-proval-regulyarnogo-menedzhmenta-v-it
Статья Максима Цепкова с очень хорошим историческим обзором и аналитикой. Даже проглядывание её по диагонали даёт вам +10 к интеллекту и +5 к выносливости.

​​Смотрите, что у нас получилось: https://imagineui.github.io

Рисовалка мокапов из кода работает в браузере, есть несколько примеров и можно что-то новое задизайнить. Есть и CLI-приложение, пока что не упакованное, но можно собрать и запустить из кода, инструкция там же. Есть базовая документация на английском и русском.

Пробуйте, пишите фидбек, присылайте исходники своих мокапов :)

А ещё, если вам проект понравился, поставьте нам звезду на гитхабе: https://github.com/imagineui/imagineui

Mobile Page: "Landing"
Block: Navigation
    One row
    "ImagineUI"
    Link to Sandbox
    Link to GitHub
    Link to Docs
Main Block: Demo
    Header "ImagineUI"
    One row
    Image example source code
    Image example mockup
Block: Subnoscription
    Header Subscribe to our newsletter
    Input "full name"
    Input e-mail
    Button "Subscribe"
    "or try out the alpha-version:"
    One row
    Button Sandbox
    Button CLI

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

Я мечтал о такой утилите более пяти лет. Спасибо @docops!

Выступлений на конференциях пост

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

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

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

А тех, кто съел пуд соли, понимает границы своей компетентности и приходит с докладом — единицы.
Если вы из таких — не сидите ровно на попе, пожалуйста. Сейчас как раз начинается новый сезон конференций. Вы нужны программным комитетам.

Не принятых докладов пост

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

В некоторые года случается бум публикаций и выступлений на определённую тему. Например, в 2018 и 2019 я заметил бум публикаций про Performance Review и про OKR. А значит к 2020-му про эти темы сказано настолько много, что сложно добавить что-то новое, о чём ещё не слышали. И у программных комитетов скорее всего будет скепсис к таким докладам.

Эти тренды так или иначе чувствуют члены каждого ПК и могут дать комментарии. Мало кто пользуется опцией "зайти на сайт конференции, посмореть кто в ПК и потом просто постучаться к человеку на посоветоваться на 20 минут", а она вполне себе существует.

KnowledgeConf в прошлом году публиковала (https://habr.com/ru/company/oleg-bunin/blog/440746/) информацию о трендах на Хабре. В этом году мы проводим уже более глубокий анализ и уже очевидно, что информации об онбординге очень много, а вот о реальном опыте привития культуры обмена знаниями, технологиях и инструментах (кроме попсовых чатботов), вытаскивании команд и проектов из тяжёлых ситуаций (отсутствие каких-либо знаний в "прилетевших" легаси-проектах, жуткая разобщённость подразделений, победа безопасников паранойиков над здравым смыслом и т.п.) или банальном решении истории вида "у нас есть вики, но в неё никто не пишет" — почти нет.

Что делать, если твой доклад опоздал с трендом?
- Можно попробовать податься на другую конференцию. Всегда есть люди, которые опоздали, не услышали, были заняты или находятся в другом информационном поле. В 2020 году по-прежнему есть люди, которые не знают про модели "Родитель-Взрослый-Ребёнок" и люди, для которых является откровением аутотренинг. И про Domain Driven Development многие, кому это нужно, не знают. Это нормально.
- Можно успокоиться и попробовать блестнуть с чем-то другим. Возможно для этого понадобится поменять что-то в своей работе и добиться новых результатов, а текущие достижения зафиксировать и просто использовать как хорошую часть резюме.
- Можно копнуть реально глубоко, изучить существующую матчасть, и попробовать достичь выдающихся результатов. Быть может вы — будущий Лобачевский, который изогнёт ткань привычного пространства.

Увидел меткий пост в ФБ, пошарю его тут частично

Я тоже увлекался темой мотивации персонала. Развешивал по офису плакаты, выбирал фикусы, придумывал сложные схемы KPI и вознаграждений. Геймификация, финансовая мотивация, конкурсы, молодой дружный коллектив, навязшие на зубах печеньки в офисе и вот это все.
Но все намного проще мотивация не так важна, как отсутствие ДЕМОТИВАЦИИ.
Не важно, какую ты разработал продуманную и взвешенную систему грейдов и процентов, если при этом ты орешь на сотрудников. Не важно, сколько работник может получить коинов-монеток во внутрикорпоративной валюте, если ты не ценишь работу, которую он для тебя выполняет. Не важно, есть ли у тебя ДМС в компании, если ты сидишь с видом человека страдающего несварением желудка, когда сотрудник тебе рассказывает о своих идеях. Если ты опаздываешь, забываешь о договоренностях, пересматриваешь условия – то никакие мотивационные схемы не помогут.
Относитесь к людям по-человечески и не косячьте. Это важнее зарплаты, бонусов, грамот и почетных кубков.
[..]

https://www.facebook.com/litvin.petr/posts/2925840524122055

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

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

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

Практика 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
Вот прямо перечень приёмов с объяснением что это такое и с какой стороны подступиться. Зачастую даже со ссылками на ютуб и источники.

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

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

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

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

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

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

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

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

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

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

📥 Банк идей

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

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

— Часть идей объективно плохая, но лишь потому, что сотрудники не обладают кругозором и не понимают бизнес. И не начнут, если им не рассказывать. Будут приходить с идеями про то, как поменять круглые кнопки на квадратные, как поменять 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