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

Подкаст "Тимлид позвонит" об управлении знаниями Поговорили с ребятами из 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 за помощь в проведении митапа.

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

Не принятых докладов пост В предудыщем посте я чуток слукавил: типа всё так просто, подайся с докладом и тебя оторвут с руками и ногами. На самом деле есть одна важная фигня: тренды. Слово "тренды" граничит с матерным, поэтому сейчас поясню. В некоторые года случается бум публикаций и выступлений на определённую тему. Например, в 2018 и 2019 я заметил бум публикаций про Performance Review и про OKR. А значит к 2020-му про эти темы сказано настолько много, что сложно добавить что-то новое, о чём ещё не слышали. И у программных комитетов скорее всего будет скепсис к таким докладам. Эти тренды так или иначе чувствуют члены каждого ПК и могут дать комментарии. Мало кто пользуется опцией "зайти на сайт конференции, посмореть кто в ПК и потом просто постучаться к человеку на посоветоваться на 20 минут", а она вполне себе существует. KnowledgeConf в прошлом году публиковала (https://habr.com/ru/company/oleg-bunin/blog/440746/) информацию о трендах на Хабре. В этом году мы проводим уже более глубокий анализ и уже очевидно, что информации об онбординге очень много, а вот о реальном опыте привития культуры обмена знаниями, технологиях и инструментах (кроме попсовых чатботов), вытаскивании команд и проектов из тяжёлых ситуаций (отсутствие каких-либо знаний в "прилетевших" легаси-проектах, жуткая разобщённость подразделений, победа безопасников паранойиков над здравым смыслом и т.п.) или банальном решении истории вида "у нас есть вики, но в неё никто не пишет" — почти нет. Что делать, если твой доклад опоздал с трендом? - Можно попробовать податься на другую конференцию. Всегда есть люди, которые опоздали, не услышали, были заняты или находятся в другом информационном поле. В 2020 году по-прежнему есть люди, которые не знают про модели "Родитель-Взрослый-Ребёнок" и люди, для которых является откровением аутотренинг. И про Domain Driven Development многие, кому это нужно, не знают. Это нормально. - Можно успокоиться и попробовать блестнуть с чем-то другим. Возможно для этого понадобится поменять что-то в своей работе и добиться новых результатов, а текущие достижения зафиксировать и просто использовать как хорошую часть резюме. - Можно копнуть реально глубоко, изучить существующую матчасть, и попробовать достичь выдающихся результатов. Быть может вы — будущий Лобачевский, который изогнёт ткань привычного пространства.

Выступлений на конференциях пост Общался со старым знакомым тему конференций и услышал интересный тезис: "Ой, мы пробовали, но как-то не вдохновило. Всё время одни и те же лица, а большая часть выступлений - ни о чём". Меня тоже когда-то бомбило по похожему поводу, но потом я попал в программный комитет KnowledgeConf и узнал много нового "с другой стороны баррикад". Чтобы выступления получились хорошими - нужно, чтобы спикер обладал хорошей компетенцией и хотя бы чуть-чуть умел связно выстраивать мысли. Причём второе не так критично, так как: - крупные конференции помогают коучинговой поддержкой - на рынке есть тренеры, которые за не такую большую деньгу помогают довести презентацию до ума - есть море тренеров по публичным выступлениям, это сформировавшийся рынок - даже если просто рассказать свою историю раз 5-10 разным группам людей и услышать их фидбэк - само собой меняешься к лучшему Проблема, конечно, с компетентными людьми. Много потраченного времени не означает компетентность. И заёбанность тоже не равна опыту. Не мало приходящих выступать обладают энергией и желанием блестнуть, но при этом если копнуть "вглубь" — не способны по существу ответить или даже признать свою некомпетентность в этом разрезе. И мне особенно больно такое видеть. А тех, кто съел пуд соли, понимает границы своей компетентности и приходит с докладом — единицы. Если вы из таких — не сидите ровно на попе, пожалуйста. Сейчас как раз начинается новый сезон конференций. Вы нужны программным комитетам.

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

​​Смотрите, что у нас получилось: 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: Subscription
    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

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

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

Первый эпизод по новостному поводу, про nginx! 90% эпизода — про технологии: что такое Nginx, почему и где он используется, что в нем нравится, а что — бесит. 10% — эмоции, получилось жарко и даже немного стыдно. А ещё это первый эпизод, в котором два гостя, с которыми до записи я не был знаком даже шапочно. Гости: Данила Штань, технический директор Яндекс.Вертикалей (Авто.ру, Яндекс.Недвижимость и Яндекс.Работа) и Дима Столяров — технический директор крупного русского devops аутсорсера Фланта. Го слушать, мы создали: Apple, Google, Castbox, Spotify, Яндекс, Overcast, веб-версия.

Есть альтернативный подход к уменьшению времени онбординга. Радикальный. Я его не пробовал, но на митапе делились своими соображениями: нужно как можно быстрее выявлять "проблемных" и "не способных" людей и увольнять их. Сюда входит: - приём "тестового дня" - более лучшая проработка требований к вакансии вместе с HR-ом - как можно более раннее принятие решения о прохождении испытательного срока Формально, так тоже можно уменьшить среднее время онбординга. Тестовый день Коллеги поделились впечатлением, что в условиях, когда ты не можешь дать человеку доступ к инфраструктуре, хорошо заходит исследовательское задание в качестве оплачиваемого "тестового дня". То есть потенциальному сотруднику даётся общая, толком не изученная проблема, и предлагается разобраться самостоятельно и написать решение. Это удобно, так как результаты работы в такой ситуации не жалко выкинуть (если они плохие), и в то же время можно найти человека-сокровище. Проработка требований Казалось бы, очевидный совет, но на самом деле ноги многих проблем с онбордингом, похоже, растут из-за отстустствия нормального взаимодействия произвоства и найма. Проработка требований к вакансиям, обсуждение источников и подходов к найму, поиски способов улучшить жизнь HR-а - это хороший повод начать дружить во имя общей цели. Конечно, бывают ситуации беспросветные, когда конфликт на уровне руководства. Мне кажется, что в таких ситуациях надо искать другую компанию для строительства карьеры, но это не точно. Ускорение принятия решения об испытательном Есть ощущение, что на самом деле тимлиды с опытом способны достаточно точно понять есть толк от человека или нет задолго до окончания испытательного. Если они действительно зададутся такой целью, вылезет и осознается много нюансов касательно требований и онбординг естественным образом начнёт проистекать гораздо шустрее, ибо пятки начнут подгорать. Однако, вопрос о том, как действительно поставить такую цель остаётся открытым и зависит от специфики компании.

Технологический онбординг - это погружение в проекты, технологии и специфические соглашения, которые приняты в команде: как писать код, почему используется PostgreSQL вместо MySQL, какие сервисы используются в проекте и как они связаны между собой и другое. Есть компании, в которых делают полноценный курс новичка: наборы видеозаписей, отвечающих на самые частые вопросы, статьи, обучалки - но как бы то ни было, поддерживать подобный курс очень дорого и тяжело. Все задают вопрос "как принять решение - стоит какую-то информацию фиксировать в виде доки или нет?" - но внятного ответа мне пока неизвестно. И есть впечатление, что хорошего ответа ни у кого нет. Есть и ключевая проблема с подобным "курсом новичка" - большой объём материала невозможно запихнуть в голову мгновенно. Всего лишь какие-то 6 часов видео убьют любой мозг, как ни крути. Таким образом, онбординг следует по смыслу разделять на две части: - минимальную информацию, которую нужно донести за 2..3 дня максимум. - общие меры, направленные на улучшение обмена знаниями в команде, которые будут помогать онбордящемуся в первые 2..3 месяца. Минимальная информация - это строго то, что вызывает реальную боль у новичков. Выявить её очень просто - вести их в течение первой недели-полутора, присутствовать на всех ключевых встречах с человеком, работать в режиме парного программирования и проверять его прогресс. Общие меры - это, прежде всего, наставничество и создание правильной культуры, подразумевающей качественный фидбэк, свободу в задавании вопросов и другое - но это сами по себе обширные темы, которые надо рассматривать отдельно.

Конечно, я совсем не коснулся вопросов работы с кодом, сборки и доставки. Потыкаюсь ближе к выходным, но поверхностно выглядит функционально.

Отдельного внимания заслуживают чаты. "Зачем делать чаты в 2019-ом году?" - задавался я вопросом, когда читал описание Space. А вот зачем: на статьи автоматом создаются чаты, на мердж реквесты создаются чаты, и вообще выглядит, как будто коммуникации грамотно разруливаются на те предметы, которые появляются в базе знаний. Отдельно доставило автоматически созданный чат "Absense" - для оповещения людей об отсутствии. У нас есть нечто подобное, но мы работаем с отсутствиями вручную. Для распределённой команды, например, такой чат весьма необходим, здорово, что такие мелочи сразу идут продуманными из коробки.

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

Интересная фича - чек-листы выведенные как корневая вещь в проекте. Чек-листы - это самый простой и быстрый способ начать обеспечивать качество и синхронизировать знания о том, как и что делать. 👍

Вот так выглядит работа с файлами в гит-репе. Интерфейсы, на мой вкус, не очень няшненькие, но вполне функциональные. и продуманные. При редактировании файла открыватся доступ к истории, blame-у всему, что нужно. Есть подсветка кода (насколько глубокая - не исследовал), вебхуки и вот это всё.

JetBrains Space Мне пришёл доступ в Space. Если вы ещё не слышали про него - посмотрите https://www.jetbrains.com/space/ - там весьма неплохо описан концепт. Далее - мои субъективные впечатления. В главном меню есть пункты: единый поиск (открывающийся по хоткею, не умеет в русскую морфологию и уж тем более семантику), чаты и плюс-минус "стандартный" набор для управления проектами: гит репы, issues, работа над merge request-ами и отдельно вынесенные Checklists проекта.

Онбординга пост В субботу днём буду на DevOpsDays, общаться про технологический онбординг. Кроме организационного онбординга (посадить на рабочее место, дать технику, познакомить с нужными людьми, придать ускорение в нужном направлении) есть ещё технологическая составляющая. Потому что, как ни крути, у всех есть своё легаси, свои особенные практики, свои соглашения о том как писать код, описывать задачи и участвовать в движухе типа планирования. И HR-ы, которые зачастую занимаются онбордингом, ничего в этом не понимают и по сути ответить на вопросы не могут. А ещё веселее становится, когда все эти практики-технологии быстро эволюционируют и, например, физически невозможно нанять человека знающего весь необходимый набор технологий и инструментов. Надо людей прокачивать как можно быстрее, но как? Окей, в теории всё просто: чек-листы, наставничество, парное программирование, ревью, записанные видео и статьи - но что из этого действительно работает на практике и почему? А что - не работает? Я, например, пробовал организовывать в командах учебные задачи для новичков в рамках "курса молодого бойца". Идея казалась прекрасной: снять нагрузку с тимлида, чтобы инженер в "учебных", "лайтовых" условиях мог освоить базовые вещи и затем идти в одну из команд и доучиваться "в бою". Но на практике: а) снятие нагрузки с тимлидов оказалось порочной затеей, так как они полностью отстранились и стали рассчитывать на чудо, не желая даже участвовать в детализации курса; б) базовые, фундаментальные вещи и приёмы в разных командах оказались разными. И команды отстранялись от попыток их синхронизировать. в) оказалось, что курса молодого бойца даже в одну неделю не хватает на ощутимый результат: объём информации и знаний слишком большой. А тащить человека дольше без погружения в реальную практику выглядело полным бредом. 🤔 возможно, вы знаете как обойти эти проблемы. У меня, в свою очередь, есть другие истории, которые взлетели и дали отдачу, не смотря на встреченные подводные камни. Не хочется превращать пост в простыню. Лучше поделимся своей болью интерактивно на митапе в субботу или в канале @KnowledgeConfChannel.