Чем любят грешить менеджеры
Здравствуй, дорогой читатель. Это пост про фундаментальное правило управления изменениями и внедрениями, которое часто игнорируют руководители
В целом проджекты/коучи/продакты и любый IT-менеджеры достаточно часто жалуются что внедрения буксуют, команды сопротивляются чему-то правильному и очевидно нужному. Меня давно раздражает ситуация, когда человек сходил на курс, посмотрел вебинар, словил инсайт, а затем через день несёт его как новый порядок жизни: теперь у нас OKR, переходим на Kanban, ИИ агент для логов и вообще всем курсор! И классика провести через ретро под соусом "tech excellence/улучшения инструментов/команда не знала о таком"
Правило простое: не внедрять в команду то, что хотя бы минимально не пощупал сам. Не "прочитал", не "было на прошлом месте", не "знаю, как должно быть", а попробовал, пожил внутри и понял где бесит
Первые пару лет бытности проджектом почти все мои внедрения и улучшения проваливались. Спасибо большое Жене из Яндекс Денег с позицией "ну ты сам научись дашборды делать в повербиай, а потом команде затирай как правильнее". Отсюда выросло огромное количество разных инициатив, которые я предварительно тестировал на себе. Вот несколько примеров
1) Когда я хотел больше прозрачности и нормальной гигиены задач, я сначала несколько месяцев кошмарил самого себя в Notion: цели, инициативы, месячные планы, задачи, статусы, прогресс, декомпозиция и связи задач
2) С OKR было так же: несколько лет связки годовые->квартальные->месячные цели, с полным трекингом и всеми OKR ритуалами
3) С ИИ безопасностью я несколько раз жестко косячил, собрал ai-repo-safety-skill и внедрял сканеры скиллов
4) С быстрым фронтом через ИИ я пошёл в OpenDesign, сделал несколько прототипов, а потом на внутреннем демо Twinby с автономными целями
/goal и админкой на Angular знатно облажался. Полезная лужа, после которой я перестал лезть к разработчикам с советами в зоне, где сам ещё не прожил достаточно боли5) С Text2SQL история такая же. Можно красиво сказать “давайте сделаем агента, чтобы менеджеры и аналитики сами спрашивали базу”, но потом приходят вопросы: как актуализировать метаданные, как объяснить агенту бизнесовый смысл полей, как ограничить доступы, как понять что ответ не бред и тп. Я поковырял VannaAI (царствие ему), сделал семантическую разметку и CLI на Rust. На скрине тот самый "txttsql" : агентик RAG, файловый семантический слой и защищённый read only SQL исполнитель для аналитики. Только после этого у меня появился сильный голос по таким вопросам
Я не верю в менеджера, который должен уметь всё лучше команды. Если ПМ пишет код за разработчиков, дизайнит за дизайнеров, считает за аналитиков и ещё модерирует все созвоны, то он не молодец, а узкое место с конечной емкостью календаря
Я уже писал про то что хороший менеджер должен хотя бы один раз зайти в чужую реальность ногами: хочешь понять разработчиков, сделай маленькую инженерную задачу; хочешь понять аналитиков, сам достань ответ из данных. Я поднимал вопрос вопрос нужны ли менеджеры, аналогичный тому что пишет Аня https://t.me/proproduct/1585 и поднимал вопрос какие менеджеры нужны https://t.me/junior_pm/464. Но тут про другое
Если ты хочешь внедрить и что-то изменить, например OKR, поживи квартал со своими OKR; хочешь требовать прозрачности, стань прозрачным сам. Проживание и непосредственный опыт кроме большего погружения и понимания дают еще одно фундаментальное преимущество - тебя больше уважают сотрудники, это наиболее полно демонстрирует что тебе не все равно и тебе важна их работа
Любое внедрение должно начинаться с руководителя не потому, что руководитель умнее всех, а потому что он первым платит маленькую цену: пробует, ошибается, показывает где было больно и только потом приходит к людям с предложением что-то менять. Не “я придумал, теперь вы живите”, а “я попробовал, вот что понял, давайте проверим вместе”