Принятия решения о задачах пост

В ответ на предыдущий пост @MargaritaAndrianova прислала мне описание подхода к ранжированию задач, который в некоторых ситуациях может помочь разгрести хвосты по техдолгу:
https://docs.google.com/presentation/d/1-DIhhQj4RaeMGfTCF0AhegHt2x6lIvVQr083RQRgHXM/edit

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

Расчётов пост

В одном из выпусков прекрасного комикса XKCD (https://xkcd.com/1205/, если быть точным) была чудесная таблица: сколько времени нужно, чтобы окупилась автоматизация.

Но она расчитана исходя из образа жизни автора (рабочие дни в году, рабочие часы, вот это всё).

Я сделал параметризованную версию этой таблицы для вас:
https://docs.google.com/spreadsheets/d/1YM0F7Fsviy5JWPqtfdZwCsyGYFJLT2umBsZ1SBu0ALM/edit?usp=sharing

Онбординга пост
В субботу днём буду на DevOpsDays, общаться про технологический онбординг.

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

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

Окей, в теории всё просто: чек-листы, наставничество, парное программирование, ревью, записанные видео и статьи - но что из этого действительно работает на практике и почему? А что - не работает?

Я, например, пробовал организовывать в командах учебные задачи для новичков в рамках "курса молодого бойца". Идея казалась прекрасной: снять нагрузку с тимлида, чтобы инженер в "учебных", "лайтовых" условиях мог освоить базовые вещи и затем идти в одну из команд и доучиваться "в бою".
Но на практике:
а) снятие нагрузки с тимлидов оказалось порочной затеей, так как они полностью отстранились и стали рассчитывать на чудо, не желая даже участвовать в детализации курса;
б) базовые, фундаментальные вещи и приёмы в разных командах оказались разными. И команды отстранялись от попыток их синхронизировать.
в) оказалось, что курса молодого бойца даже в одну неделю не хватает на ощутимый результат: объём информации и знаний слишком большой. А тащить человека дольше без погружения в реальную практику выглядело полным бредом.

🤔 возможно, вы знаете как обойти эти проблемы. У меня, в свою очередь, есть другие истории, которые взлетели и дали отдачу, не смотря на встреченные подводные камни.

Не хочется превращать пост в простыню. Лучше поделимся своей болью интерактивно на митапе в субботу или в канале @KnowledgeConfChannel.

JetBrains Space
Мне пришёл доступ в Space. Если вы ещё не слышали про него - посмотрите https://www.jetbrains.com/space/ - там весьма неплохо описан концепт. Далее - мои субъективные впечатления.

В главном меню есть пункты: единый поиск (открывающийся по хоткею, не умеет в русскую морфологию и уж тем более семантику), чаты и плюс-минус "стандартный" набор для управления проектами: гит репы, issues, работа над merge request-ами и отдельно вынесенные Checklists проекта.

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

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

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

Отдельного внимания заслуживают чаты.

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

Отдельно доставило автоматически созданный чат "Absense" - для оповещения людей об отсутствии. У нас есть нечто подобное, но мы работаем с отсутствиями вручную. Для распределённой команды, например, такой чат весьма необходим, здорово, что такие мелочи сразу идут продуманными из коробки.

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

Технологический онбординг - это погружение в проекты, технологии и специфические соглашения, которые приняты в команде: как писать код, почему используется 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: 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

Это божественная штука, которая позволяет описывать мокапы ямл-подобным синтаксисом. А значит - описание интерфейсов можно хранить в доке, в гите, и по-человечески с ним работать.
Утилиту можно как запускать локально, так и использовать онлайн-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 за помощь в проведении митапа.@the_know_all и @MaximTsepkov за помощь в проведении митапа.