Евгений Подтеребков | Управление ИТ проектами

В прошлом посте я сказал, что половину проблемы решает пауза
Сегодня покажу, что с ней делать дальше
Так же рекомендую заглянуть в комментарии к предыдущему посту, там есть психологическое обоснование истории про паузу

Главное заблуждение, с которым я жил: отказ - это выбор из двух вариантов.
Либо сказать «да» и страдать, либо сказать «нет» и испортить отношения.
На самом деле между ними пять шагов, и проскакивать их было ошибкой.

1️⃣ Пауза. «Дай сверюсь с планом и вернусь».
Она нужна, чтобы выйти из ситуации и вернуть себе право решать.
2️⃣ Уточнение. «Что для нас сейчас важнее: это или то, что я уже делаю?»
Вы не отказываете, вы просите расставить приоритеты.
Иногда этого достаточно: заказчик сам видит, что его просьба не главная.
3️⃣ Торгуемся. «Если беру это, сдача сдвигается на неделю».
Вы показываете цену, и дальше решаете не в одиночку.
4️⃣ Условие. «Сделаю, если снизим объём или добавим ресурс».
Это тоже согласие, но на ваших условиях.
5️⃣ Прямой отказ. «Нет, и вот почему».
До него доходишь редко, если прошёл первые четыре.

Три принципа, которые меня не подводили:
- Начинать всегда с самой мягкой ступени
- Каждая ступень - не ультиматум, а фильтр: вы вместе отсеиваете то, что не влезает.
- Чем раньше взята пауза, тем реже дело доходит до жёсткого «нет».

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

В следующих двух постах разберу ступени подробнее, с готовыми фразами и кейсами.

#projectmanager #pm #менеджмент

Когда книжки не работают, а реальность вставляет палки в колеса 📚➡️🔥
Знакомо? Читаешь умные книги про Scrum, OKR, метрики, а на практике все идет уж совсем не по плану. Теория красивая, а в жизни только хаос, люди, сроки и политика.

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

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

Особенно зашли посты:
- Про ML и техническую грамотность для менеджера
- Про OKR и KPI в СНГ как не запутаться
- Про метрики, что реально смотреть, а что просто шум
- Про PBR и совместное планирование

Если хотите управлять без иллюзий подписывайтесь.

Как менеджеру проектов говорить „нет" и не чувствовать вину

Начинаю серию постов про то, как менеджеру проектов говорить «нет» и не чувствовать за это вину или стыд.

Однажды заказчик позвал меня на встречу, чтобы обсудить новую небольшую фичу.
За неделю до сдачи очередного проекта я работал по 10-12 часов, а он пришёл ко мне с этой мелкой задачей и попросил взять её прямо сейчас.
Я раздражённо ответил, что мне сейчас не до этого.
Ему это не понравилось. Мне, честно говоря, тоже.

Справедливости ради, отреагировал я и правда плохо. Но дело было не в самой задаче.
А в том, что я копил эту злость.
До этой встречи я был мальчиком "всегда говори да", соглашался на всё, что просили: молчал, злился про себя, а на просьбе - кивал.
И в какой-то момент меня порвало. Не на эту задачу. На всё то «да», которое я говорил месяцами.

Тогда я ещё не понимал главного: я не выбирал говорить «да». Я делал это на автомате.

Это рефлекс, а не решение. Такой же, как отдёрнуть руку от горячего.
Страх конфликта, желание нравиться, привычка быть удобным - всё это срабатывает быстрее, чем мы успеваем подумать.

Поэтому советы в духе «просто скажи нет» не работают.
Проблема не в том, что вы не знаете нужного слова.
Проблема в том, что между просьбой и ответом у вас нет паузы.

Вот с чего я предлагаю начать.
Когда приходит новая просьба, а внутри всё сжимается - возьми паузу.
«Дай сверюсь с планом и вернусь с ответом».
Или проще: «Мне нужно проверить приоритеты». Или совсем коротко: «Вернусь с ответом завтра».

Это не отказ. Это право подумать. Но именно оно решает половину проблемы.

Дальше в серии расскажу про пять ступеней отказа, про то, как правильно соглашаться с условиями и как говорить «нет», не портя отношения.

А пока вопрос на подумать: вспомните последний раз, когда вы сказали «да» и пожалели.
Вы согласились, потому что это было правильное решение, или потому, что не успели ничего решить?

#projectmanager #pm #менеджмент

Сгенерил картинку на тему поста в nano banana и прифигел от качества 😱
Ну да ладно, вернемся к теме урока

В моей текущей компании очень любят старую добрую оффлайновую работу (ну да, все таки это старая красная огромная компания).
Знаете, вот эти бесконечные отчеты, тяжеловесные презентации, аналитика в экселе на тысячи строк. Когда тебе говорят: проанализируй пять тысяч задач и составь рейтинг сотрудников. Раньше от таких вводных начинал дергаться глаз, а сейчас я иду вайбкодить.

Да, я наверное один из немногих, кто на эту тему еще не писал, пора исправляться =)

Недавно прилетела задача: каждую неделю собирать статус по сотне самых важных проектов. Десять исполнителей уровня директоров департаментов, куча разрезов: проблемы, сроки, зависания, комментарии. На выходе должно быть 10-15 красивых слайдов.
Директор - визуал, таблички и дашборды - не для него. Ну, что ж поделать.

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

Или вот еще пример. Нужно было сделать рейтинг руководителей по тому, как они пользуются Кайтеном. Как ставят задачи, как делегируют, как контролируют. Тысячи тикетов, десятки людей. Руками это считать - увольте. Я написал подробное ТЗ для ИИ: откуда брать данные, какие формулы использовать. Два-три часа возни с кодом, и ежемесячный рейтинг по семи показателям для генерального готов.

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

Я уже молчу про написание регламентов, инструкций, фоллоуапов и расшифровок встреч. Без этого сейчас вообще никуда.

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

А какие менеджерские кейсы вы решаете с помощью вайбкодинга?

#вайбкодинг #автоматизация #продуктивность

Сижу как-то на собеседовании. Кандидат - хороший парень, но мимо. Вообще мимо. Предметная область не та, инструментов не знает, да и по глазам вижу: ему самому некомфортно. Прошло двадцать минут. Я выключаю ноутбук и говорю: «Давайте честно, дальше мучить друг друга смысла нет». И объясняю почему.

А потом мне звонит HR. Оказывается, так нельзя. Надо довести до конца. Надо дать «нейтральную» обратную связь через неделю. Надо, чтобы кандидат «не расстроился».

Я не понимаю этой логики. Если человек не подходит, он не подходит. Это не приговор. Он просто работал в другой среде, не копал глубоко в нужную нам тему. Ничего страшного. Найдёт своё место. Но зачем тратить его время и свои нервы?

Ладно, отзеркалим. Я сам собеседовался в компанию, где на встрече нанимающий менеджер начал упарываться в математику спринтов и velocity, а на вопрос про health check команды посмотрел на меня как на идиота. Классика: технарь вышел в руководители, но people management для него - пустое место. Я сказал прямо: «Ребята, мне кажется, у нас разный взгляд на управление, я не ваш кандидат». Знаете, что случилось? Ничего. Мы пожали руки и разошлись.

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

Но правда в том, что если позиция линейная, решение принимается сразу. Вы выходите за дверь, а собеседующие уже всё обсудили. Да, иногда вас откладывают «в рейтинг». Но если случился полный мэтч - вас захотят оторвать с руками в тот же день. Если тишина - не ждите чуда.

И ещё. Не надо успевать подогнать свои знания под вакансию между звонком HR и собеседованием. Если вы чего-то не знаете - это нормально. Потом это отсутствие знаний придётся применять. Каждый день. И вот тогда станет по-настоящему больно.

Короче. Не ссыте давать обратную связь прямо на собесе. С любой стороны стола. Тем более негативную. Вы сэкономите время, деньги и нервные клетки всем участникам процесса. А через час у вас следующий собес.

Интересно, а вы хоть раз прерывали собеседование на середине?

#собеседование #карьера #обратнаясвязь

После жаркой недели хочется немного расслабиться и поржать
Всем классных выходных 🥳

Замечаю одну штуку всё чаще, особенно сейчас в большой компании

Руководители, иногда уровня директоров департаментов, ставят задачу и искренне удивляются, когда получают не то, что ожидали. Или не получают вообще.

Начинаются разборки, поиск виноватых. Хотя проблема обычно возникла в самом начале, в момент постановки задачи.

Я не говорю, что они плохие руководители. Просто большинство из нас никто никогда не учил нормально ставить и принимать задачи. Это как-то подразумевалось само собой.

Кивок - это не подтверждение понимания. Это вежливость. Или страх.

Когда человек говорит «понял», он понял что-то своё. В его голове своя картина мира, свой контекст, ещё пара таких же срочных задач от других людей.

Синхронизировать эти картины - это и есть главная работа при постановке задачи.

Вот простой чек-лист для любой задачи, которую собираетесь делегировать:
1️⃣ Сформулировали результат, а не процесс что должно получиться на выходе?
2️⃣ Обозначили критерии — как поймём, что всё сделано правильно?
3️⃣ Объяснили дедлайн почему именно эта дата?
4️⃣ Попросили пересказать задачу своими словами, не для проверки, а чтобы услышать, что человек понял
5️⃣ Договорились о контрольных точках заранее

Когда получаете задачу:

1️⃣ Уточнили цель: зачем это нужно, какую проблему решаем?
2️⃣ Уточнили результат - что конкретно должно получиться?
3️⃣ Декомпозировали и прикинули сроки реалистично
4️⃣ Если путь неочевиден, согласовали подход до начала, а не после
5️⃣ Договорились о формате промежуточной обратной связи

В процессе:

1️⃣ Есть короткие регулярные синки не ради галочки, а чтобы вовремя заметить отклонение
2️⃣ Есть что показать: черновик, статус, промежуточный результат
3️⃣ Изменения в задаче фиксируются явно: не «ну я же говорил»

Всё это звучит очень просто. Но именно поэтому этим и пренебрегают.

Попробуйте заблокировать в календаре отдельный слот на постановку сложной задачи. Не пять минут на бегу, а осознанные 20-30 минут. Это те самые минуты, которые потом экономят недели.

Я регулярно слышу одну и ту же историю. Предприниматель или руководитель, у которого в подчинении несколько директоров, физически не может выйти из операционки. Согласовывает всё. Решает всё. Устал.
Просит меня помочь ему выстроить процессы.

Начинаешь копать и быстро выясняется: процессы тут ни при чём.

Проблема в том, что делегирование пугает. Не абстрактно, а конкретно:

«Ошибутся и всё рухнет»
«Поменяю, придут такие же»
«Проще самому, чем объяснять»

Это не отговорки. Это реальный страх реальных людей.

Когда руководитель не отпускает контроль, происходит несколько вещей одновременно:
- Команда перестаёт думать. Зачем? Всё равно переделают или не одобрят.
- Люди начинают ждать указаний вместо того, чтобы решать.
- Скорость падает. Любое решение висит в очереди к одному человеку. Чем больше компания - тем длиннее очередь.
Сейчас в компании, где я работаю, очередь на решение простого вопроса 3-5 недель
- Сильные уходят. Хорошие специалисты не терпят микроменеджмент долго. Остаются те, кому комфортно ничего не решать.
И тогда тезис «все одинаковые» становится самосбывающимся пророчеством.

Выход не в том, чтобы «научиться доверять», это слишком абстрактно.

Что делать

- Делегировать не задачу, а зону ответственности с понятным результатом. Не «сделай отчёт», а «ты отвечаешь за то, чтобы мы понимали финансовую картину каждую неделю. Формат и процесс - твои».
- Договориться о точках контроля заранее, а не контролировать процесс постоянно. Раз в неделю статус - достаточно. Остальное - доверие плюс ответственность.
- Дать право на ошибку явно. Буквально сказать: «Ты можешь ошибиться. Критичные решения согласуй со мной, остальное - твоя зона». Без этого люди будут перестраховываться и всё равно тащить всё наверх.

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

Если команда привыкла ждать решений сверху, никакой регламент это не исправит.

Бережливое производство - это не только про заводы

Один менеджер прочитал книгу про Lean и сказал: "Интересно, но к IT не применимо"

Окей, давай продумаем

Начальник выездных монтажников в крупном телекоме прочитал ту же книгу. Первое, что сделал - навёл порядок в рабочих газельках. Полочки, крючочки, каждый инструмент на своё место после каждого выезда. Скучно звучит, да? Результат - ускорение подключения новых объектов больше чем на 10%.

Монтажники не стали умнее. Просто перестали тратить время на поиск того, что и так было с собой.
У нас в ИТ те же потери. Просто невидимые.

В бережливом производстве есть понятие - муда. Потери. Действия, которые жрут время и ресурс, но не создают ценности.

На заводе это видно физически: лишние движения, ожидание, брак.

В ИТ это прячется за словами «мы разбираемся», «уточняю», «сейчас найду».

Вот где реально утекает время в проектах:

1️⃣ Поиск информации
«Где финальная версия ТЗ?» - и начинается квест. Почта, confluence, личка, «спроси у Лены». Лена в отпуске. По моим наблюдениям, в командах без нормальной структуры хранения документов разработчик тратит 30-40 минут в день только на поиск нужного. Это два часа в неделю с человека. Умножьте на команду.

2️⃣ Онбординг как броуновское движение
Новый человек в команде. Неделя уходит на вопросы: где задачи, как называется репозиторий, у кого просить доступы, где смотреть архитектуру. Каждый раз - разные люди, разные ответы. Это потери не только нового сотрудника, но и всех, кого он дёргает.

3️⃣ Задачи без definition of done
«Ну в целом готово» - любимая фраза, после которой задача возвращается трижды. Нет чёткого критерия готовности - нет предсказуемости. Нет предсказуемости - нет нормального планирования.

4️⃣ Контекстные переключения
Задача живёт в Jira, обсуждается в Telegram, решение принято в Zoom, зафиксировано в почте. Через месяц никто не помнит почему так сделали. Это не коммуникация - это рассеивание информации.

Что реально работает

1. Одно место для каждого типа информации
Не «используйте confluence» - это абстракция, а конкретно: договоритесь, что решения по архитектуре только там-то, статусы задач только там-то, договорённости из звонков фиксируются там-то в течение часа после встречи. Запишите это. Повесьте на видное место. Нарушение - не трагедия, но повод вернуться к договорённости.

2. Онбординг-карта за один день
Документ на две страницы: где что лежит, к кому по каким вопросам, как устроен типичный рабочий день, какие инструменты используем и зачем. Пишется один раз, обновляется раз в квартал. Экономит 3-4 часа опытных коллег на каждого нового человека.

3. Definition of done на уровне команды, а не здравого смысла
«Готово» это не ощущение. Это чеклист. Тесты написаны, ревью пройдено, документация обновлена, задача задеплоена на нужный стенд. Всё. Без этого задача не закрывается. Поначалу будет скрип - это нормально.

Почему это не приживается

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

Работает только то, что встроено в процесс. Не «помни про документацию», а «задача не закрыта без документации».

Lean придумали для заводов. Но беспорядок он везде.

🔥 PM Playbook #2 v.1.0

Наконец выпустил второй гайд
Тема: Как перестать быть пожарным и стать стратегом

Этот дался чуть тяжелее первого, тк тема оказалась немного глубже, чем казалась на старте. "Просто напиши про тайм-менеджмент" - ага, щас 😅

Зато теперь понимаю, почему про это пишут целые книги. Я уложился в 15 страниц.

🗣 Что внутри:
- Матрица Эйзенхауэра, но не абстрактная, а заточенная под реальный день PM с 5+ проектами
- Техника "2 часа стратегического времени в неделю" как найти, защитить и не слить
- Чек-лист из 20 ранних сигналов проблем
- Делегирование, что можно НЕ делать самому
- Готовые скрипты для тимлида и руководителя - когда они пытаются сорвать твои планы

📖 Минимум теории, максимум "скопировал и применил завтра"

👥 Целевая аудитория скорее middle и senior PM, руководители отделов
Те, кто уже знает как управлять проектами, но всё равно тонет в операционке
Джунам тоже зайдет, лучше привыкать к правильным привычкам сразу

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

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

🗣 Если прочитаете, напишите в комменты или в личку:
Узнали себя? Что уже применили? Что не зашло?

❌ ps долго редактировал, глаза замылены, если найдешь баги, буду благодарен за правки в личку

🆓 pps свободно распространяйте, давайте коллегам, копируйте, тк для этого и делалось

Бэклог на 500 задач, 5-10 стейкхолдеров и каждый уверен, что его задачи важнее. Что делать?

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

Вот как я подхожу к такому планированию на практике.

Шаг 1. Начни не с бэклога, а со стратегии

Прежде чем вообще смотреть на задачи, открой стратегию компании. Да, ту самую, которую все видели один раз на годовой страт. сессии и забыли.

Какие метрики бизнес хочет улучшить в этом квартале? Выручка, удержание, NPS, снижение костов? Задачи, которые напрямую двигают эти метрики идут в приоритет автоматически, без политики и переговоров. Это снимает половину конфликтов ещё до первой встречи.

Шаг 2. Дай стейкхолдерам самим расставить приоритеты, но по правилам

Не собирай всех сразу. Сначала индивидуально с каждым.
Задача: попросить каждого проранжировать свои задачи относительно бизнес-метрик. Не «это важно, потому что я так считаю», а «это двигает метрику X на Y».
Это дисциплинирует. Люди начинают думать, а не лоббировать.

Шаг 3. Выбери систему приоритизации

RICE (Reach, Impact, Confidence, Effort) даёт цифру, с которой сложно спорить
Weighted Scoring - когда критерии согласованы заранее со всеми стейкхолдерами
Opportunity Scoring, если есть данные о важности и удовлетворённости пользователей

Главное: метод должен быть согласован до того, как ты начал считать. Иначе тот, кто проиграл, скажет, что методика неправильная.

Шаг 4. Наложи реальность

После того как у тебя есть ранжированный список, смотришь на ресурсы, зависимости и что можно запараллелить.

Часто оказывается, что задача №1 по приоритету блокируется задачей №47. Или что две задачи от разных стейкхолдеров делает одна команда и физически не влезают в квартал.

Это не проблема, а исходные данные для следующего шага.

Шаг 5. Общая встреча, куда ты приходишь с готовым планом

Не «давайте вместе придумаем», а «вот что я предлагаю и почему».
На встрече показываешь: что попадает в квартал, что уходит во второй эшелон, где конфликты и какие варианты их решения: доп. ресурсы, перенос сроков, отказ от части задач.

Твоя роль здесь - фасилитатор с предложением, а не модератор дискуссии.

Итого

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

#управлениепроектами #projectmanagement #менеджмент #teamlead #тимлид

Я 5 раз говорил «да», когда надо было сказать «я подумаю»

И каждый раз это меняло мою карьеру.

1️⃣ Я увидел внутреннюю вакансию руководителя техподдержки.
Опыта управления ноль. Понимания, как это вообще работает ноль.
Зато амбиций через край.
Прошёл внутреннее собеседование. Взяли.

Первые недели я просто наблюдал за людьми и пытался понять, кто что делает и зачем. Читал всё подряд про менеджмент. Делал ошибки. Иногда неловко извинялся. Пробовал снова. За год команда выросла с 25 до 50 человек и я рос вместе с ней, буквально не успевая за собственным масштабом.

Тогда я понял первое правило своей карьеры: тебя никто не научит управлять до того, как ты сам начинаешь управлять.

2️⃣ Через пару лет я увидел, что один из продуктов компании разваливается на глазах. Классика жанра: нет владельца, нет ответственного, все всё знают, но никто ничего не делает.
На очередном совещании с исполнительным директором у меня внутри что-то щёлкнуло.
Я поднял руку.
Сердце билось где-то в районе горла. Я описал проблему и предложил себя как человека, который возьмётся это починить. Тишина секунды на три - это вечность, когда на тебя смотрит весь зал.
Директор кивнул.
Через пару месяцев я стал менеджером проектов. Hardware + software, клубок зависимостей, команды по факту нет, есть люди, которые номинально за что-то отвечают. Начал с того, что просто разговаривал с каждым. Рисовал на бумаге, что от кого зависит. Постепенно хаос начал приобретать форму.

3️⃣ Когда я более-менее разобрался с проектом, руководство пришло с новым предложением: возглавить мобильную разработку.
Я не понимал в разработке вообще ничего. Совсем. Я сисадмин, если вы забыли.
Сказал да.
Нанял первую команду, учился вместе с ней. Потом взял вторую. В итоге вырос отдел из 19 человек, который закрывал все потребности бизнеса в iOS и Android. Я до сих пор не умею писать код. Зато я умею создавать условия, в которых те, кто умеет, делают это хорошо.

4️⃣ Когда пришло время искать новое место, я открыл hh и откликнулся буквально на первую попавшуюся вакансию операционного директора в небольшой компании.
Без особых расчётов. Просто почему бы и нет.
Взяли. Почти два года я там проработал, мы вывели на рынок продукт, которым я горжусь. Потом пришёл ковид и аккуратно закопал все наши планы. Пришлось возвращаться на рынок.
Но это была одна из лучших школ в моей жизни.

5️⃣ Недавно мне написала девушка: ищет скрам-мастера.
Я удивился, тк это не совсем мой профиль. Но что-то меня остановило от быстрого «нет».
Потом выяснилось: один из крупнейших "ритейлеров" страны. Первая встреча сразу с замгендира по нетопливному бизнесу, без HR-прелюдий и стандартных вопросов «кем вы видите себя через пять лет».
Мы поговорили по делу. Он дал домашнее задание "как я вижу управление проектами в их компании". Потом встреча на 15 минут, чтобы сверить точки зрения.
И оффер прямо там, не отходя от стола.
Я опять мало что понимаю в таких масштабах. Буду разбираться. Как всегда.

Итого

Если вы ждёте момента, когда будете «достаточно готовы», я вас расстрою.

Этот момент не наступает.
Ловите возможности, идите за своими амбициями, бояться будете в процессе 😉

К теме предыдущего поста 😂🤣

Я потратил неделю на мотивирующую презентацию. Руководитель решил вопрос за пять минут.

Есть такая негласная традиция в IT: любое изменение нужно продать. Объяснить, показать ценность, найти индивидуальный подход, дать время привыкнуть. Мы читаем книги по мотивации, составляем профили сотрудников, ищем нужные слова, индивидуальный подход.

И чем опытнее аудитория, тем сложнее. Потому что они сами всё это читали.

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

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

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

Руководитель попросил подождать.
А потом просто ввёл штрафы.

✔️Проект не оцифрован → штраф.
✔️ Оцифрован, но не ведётся → штраф.
✔️Ведётся, но факапится → штраф.
✔️ Сроки сорваны → штраф.

Знаете, что произошло дальше?

Никто не обиделся. Никто не написал гневное письмо в HR. Ко мне выстроилась очередь. По 5-6 встреч в день. Проект цифровизации, который я месяц не мог сдвинуть с места, зацвёл за неделю.

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

Но я вынес для себя кое-что важное.

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

Мотивация через ценность работает. Но работает медленно и требует энергии с обеих сторон.

Мотивация через последствия работает быстро. И иногда честнее: все правила прозрачны, никто не угадывает ожидания.

Вопрос не в том «кнут или пряник?», а «что сейчас уместно и у кого есть право это применять?».