📚Закончил книгу Психология влияния Роберта Чалдини.

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

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

Вот 6 ключевых принципов влияния, которые описывает автор:

1️⃣ Взаимный обмен
Если нам что-то дали — мы чувствуем обязанность ответить.
Даже маленький «плюс» (помощь, подарок, внимание) резко повышает шанс согласия.

2️⃣ Последовательность и обязательства
Если человек публично или письменно с чем-то согласился, он будет стремиться быть последовательным.
Маленькое «да» → большое «да».

3️⃣ Социальное доказательство
Мы считаем правильным то, что делают другие, особенно «похожие на нас».
Отзывы, кейсы и «все так делают» часто работают сильнее логики.

4️⃣ Симпатия
Мы легче соглашаемся с теми, кто нам нравится:
— внешне
— по стилю общения

5️⃣ Авторитет
Форма, титул, статус, уверенный тон — и мы склонны подчиняться. Даже если экспертность мнимая.

6️⃣ Дефицит
То, что ограничено или «скоро закончится», кажется более ценным, даже если по факту таким не является.

Основную мысль автор хорошо подводит в конце книги:
инструменты влияния — повсюду, и сами по себе они не плохие и не хорошие.
Вопрос в том, как и зачем человек ими пользуется.

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

Ещё одна мысль, которая мне особенно откликнулась: люди, которые подверглись влиянию, чаще всего активно отрицают, что на них вообще можно повлиять. Мы склонны считать себя более рациональными и «непробиваемыми», чем есть на самом деле.

Книгу точно советую — как минимум для того, чтобы лучше понимать, как на нас влияют каждый день.

💬 А вы считаете себя подверженными влиянию 💯 — или «со мной такое не работает» 😈?

🧌Чужой против Хищника: бизнес против ИТ

Когда я только начинал путь в ИТ, мой руководитель (CPO) не общался с руководителем разработки (CTO). Для меня это тогда было дико: два топ-менеджера, от которых зависит продукт, просто не могут договориться.

В итоге мы с ПМом разработки синхронизировались в курилке, пытаясь понять, как вообще выпуститься в срок. Забавное было время 🙃

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

Немного статистики:

1️⃣ больше 50% стейкхолдеров недовольны результатом (Gartner);

2️⃣ 45% требований меняются уже после старта разработки (PMI);

3️⃣ только 1 из 3 руководителей считает взаимодействие ИТ и бизнеса эффективным (McKinsey).

Мягко говоря, так себе картина.

Почему так происходит? Где ломается взаимодействие?
Как и в любом конфликте — виноваты обе стороны.

Моё непопулярное мнение:

1️⃣ ИТ живёт в настоящем, бизнес — в будущем
Бизнес думает, как фича повлияет на метрики.
ИТ — как встроить её в систему и ничего не сломать.

2️⃣ Нет общего понимания цели
Говорят о решении, но не о проблеме.

3️⃣ Раздувание фичи

4️⃣ Изменение требований по ходу проекта

Чаще всего — всё сразу.

Типичный сценарий:

Заказчик подробно описывает фичу, добавляет детали, идеи льются рекой. Хотя по факту нужно быстро проверить одну гипотезу. Разработка, не задавая вопрос «какую проблему мы решаем», берёт задачу и называет срок.
По дороге заказчик понимает, что 80% не нужно, убирает их и добавляет «всего пару деталей». В его голове это −60% работы.
В голове разработки — половину выкинули, новые 20% сложнее старых 80%, итого +20% к объёму.
Результат — недовольны все.

Я работал по обе стороны баррикад и точно знаю: все хотят сделать хорошо.
Просто «хорошо» в этих мирах означает разное:

для бизнеса — прибыль и рост 📈

для ИТ — стабильность и надёжность 🔒

Объединять эти миры обычно должен менеджер проекта.

В следующем посте расскажу, какие есть способы это сделать.

Чужой против хищника: бизнес против ИТ. Часть 2

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

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

1️⃣ Диалог

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

2️⃣ Взаимное уважение

Мы не обесцениваем работу друг друга и признаём её важность.
ИТ без бизнеса не имеет смысла, как бизнес без ИТ.
Как только одна из сторон начинает считать себя «главнее», всё ломается.

3️⃣ Сначала Discovery, потом Delivery

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

4️⃣ Регулярная обратная связь

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

5️⃣ Прозрачное ведение проекта

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

Жена еще сказала, что можно просто жениться и не париться. Но это, как говорится, на любителя🙃

Резюмируя:
Чтобы между ИТ и бизнесом были рабочие отношения, в этом должны быть заинтересованы обе стороны.
Все должны понимать, что работают на одну цель, и быть готовыми вкладываться в диалог и доверие.

Как и в любом конфликте: если хотя бы одна сторона не готова разговаривать — ничего не получится.

💬 А у вас в компании налажено взаимодействие бизнеса и ИТ?

🔥 - да, все гуд
😭 - никак не можем договориться
😈 - послушаю лучше совета твоей жены

Эта картинка напомнила мне себя пару лет назад.

Так вышло, что я совмещал роли ПМа и ТЛ. Команда только строилась, процессы были, мягко говоря, не идеальны, и иногда это приводило к техническим сбоям.

Должен признаться: техничка — точно не моя сильная сторона, а на тот момент тем более.
Но я был ТЛ и ПМом, а значит — нёс ответственность за команду и нужно было принимать сложные решения.

Прекрасно помню моменты, когда девопсы спрашивают:
— Что будем делать?

А я в душе не ебу представить не мог, но ситуацию нужно исправлять — и быстро.

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

Если вы не понимаете, что происходит:

1️⃣ Привлекайте команду

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

2️⃣ Включайте логику

Узнайте: когда начались проблемы, был ли в это время релиз (у вас или у соседней команды), были ли изменения в инфраструктуре или сети.
Ищите закономерности. Случайности случаются редко.

3️⃣ Смотрите на графики

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

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

4️⃣ Перезагрузка

Если можно что-то безопасно перезапустить — попробуйте. Иногда решение гораздо проще, чем кажется.

5️⃣ Думайте наперёд

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

6️⃣ Сомнительно, но окей

Иногда можно ничего не делать.Порой проблемы рассасываются сами собой.

Редкий случай. Использовать осторожно. Не является инвестиционной рекомендацией.

Мораль:

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

P.S.
Обязательно — и ещё раз обязательно — после инцидента:
• разобраться, почему он произошёл;
• сформировать план, как этого избежать в будущем;
• внедрить изменения.

Без этого такие ситуации станут вашей реальностью.

💬 А вы как часто оказывались в подобных ситуациях?
Что ещё, по вашему опыту, стоит делать?

Матрица рисков 💣

Как-то я быстро забросил постоянные рубрики — исправляюсь.

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

В прошлом году я пошёл повышать квалификацию по «Управлению проектами», и там мне наконец показали матрицу рисков, которую реально удобно применять.

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

Логичный вопрос — зачем это вообще нужно?

Часто слышу мнение: «С очевидными рисками мы и так знаем, что делать, а остальные всё равно не предскажем».
И это правда для типовых проектов. Но если проект новый или отличается от привычных — матрица рисков становится отличным помощником.

Основные элементы матрицы:

1️⃣ Рисковое событие — событие, которое может оказать негативное или позитивное влияние на проект.

2️⃣ Причина риска — почему это событие может произойти. Иногда эффективнее работать с причиной, а не с самим риском.

3️⃣ Последствия — влияние риска на проект, обычно оценивается через сроки и стоимость.

4️⃣ Уровень влияния — оценка от 1 до 6, где 1 — незначительное влияние, 6 — угроза срыва проекта.

5️⃣ Вероятность возникновения — оценка от 1 до 6, где 1 — менее 5%, 6 — более 90%.

6️⃣ Уровень риска — произведение влияния и вероятности для сравнения рисков между собой.

7️⃣ Проактивный план — действия до наступления риска для его предотвращения или снижения влияния/вероятности.

8️⃣ Пассивный план — действия на случай, если риск реализуется (желательно несколько сценариев).

9️⃣ Стратегия работы с риском — выбранный подход: принятие, передача, снижение, уклонение или эскалация.

Как с ней работать:

1️⃣ Соберите максимум рисков (подключайте команду, заказчика, используйте GPT)
2️⃣ Оцените влияние и вероятность
3️⃣Перемножьте и отранжируйте — риски с высоким значением попадают в красную зону
4️⃣ В первую очередь проработайте планы для красной зоны
5️⃣ Выберите стратегию и начинайте действовать по проактивному плану

Какими бы мы ни были профессиональны, держать всё в голове невозможно. Матрица рисков помогает структурно подумать, зафиксировать и заранее закрыть до 90% проблем ещё на старте проекта — а значит, заметно повысить шансы на успех.

Кстати, в жизни она тоже отлично работает — например, при планировании отпуска или ремонта.

Дарю мой шаблон матрицы рисков

💬А как вы работаете с рисками?

#а_что_по_инструментам

Неидеальность 🩹

Читая каналы некоторых коллег, я часто замечаю, как красиво и уверенно они рассказывают про крутые практики, которые используют в работе.

Но по факту часть этих примеров сильно приукрашена, а иногда и вовсе не соответствует действительности.

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

Проблема начинается, когда ты постоянно читаешь про «идеальные практики» и успешный успех. В какой-то момент ловишь себя на мысли:
«Вокруг все такие умные и успешные, а со мной что-то не так».

Спешу успокоить, и с вами, и со мной всё нормально. Просто чаще всего люди показывают только хорошую сторону медали.

Мне хочется показать и другую. Мой личный топ неидеальностей:

1️⃣ Поставленная речь
Когда я нервничаю, слова-паразиты становятся моими лучшими друзьями, а мысли — кашей. Очков в общении с заказчиками это не добавляет.

2️⃣ Навыки презентации
Частично продолжение пункта выше — из-за волнения сложно чётко и эффектно доносить мысли.

3️⃣ Тайм-менеджмент
Я почти не организую своё время. Календарь есть, но его мало. Ведь дел, которые не успеваю, ещё больше — и это жёстко фрустрирует.

4️⃣ Внимание
Я ограничил соцсети до 30 минут, но всё равно регулярно отвлекаюсь на них или игры вместо важных дел.

5️⃣ Лень
Как же часто мне лениво что-то делать. Иногда кажется, будь во мне чуть больше трудолюбия — я бы уже в космос улетел. Пока максимум — пересмотрел все сезоны «Очень странных дел».

Делает ли это меня плохим? Однозначно нет. Это лишь говорит о том, что я живой человек со своим списком неидеальностей.

💬 А какие неидеальности есть у вас?

🚀 - я идеален/идеальна
✍️ - есть куда развиваться

Сериал «Внедрение нового проектного инструмента»

В начале года я писал о внедрении изменений и о том, что было сделано не так.

Не прошло и месяца, как мне выпал шанс самому внедрить новый инструмент в рамках компании. Предлагаю вам пройти этот путь вместе со мной.

Можете глянуть предыдущий пост — там я всё красиво разложил по полочкам. Забавно, что написал я все красиво, а на практике все равно совершил несколько ошибок.

Что за инструмент

Внедрение удобного инструмента визуализации проектов в контуре компании или в простонародье графика Ганта.

Что уже сделано:

1️⃣ Определил, зачем нужна трансформация

Нет единого удобного инструмента визуализации проектов и их зависимостей.

2️⃣Зафиксировал AS IS / TO BE и критерии успеха

AS IS:
Руководители используют либо технически сложный Гант, который трудно поддерживать, либо Excel, который у всех лежит локально, а это непрозрачно для руководства.

TO BE:
• Все руководители используют новый Гант и умеют с ним работать.
• Ганты разных команд синхронизируются между собой.
• Проведено обучение по использованию нового инструмента.
• У руководства и стейкхолдеров есть доступ к Ганту для отслеживания прогресса по проектам.

3️⃣ Нашел единомышленников

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

Я взял одного такого смельчака и попробовал продать ему свой Гант. Успешно.
Мы обсудили, что он закрывает большинство текущих запросов, при этом остаётся достаточно простым и визуально понятным.

4️⃣ Продал руководству

Когда есть проблема, понятный запрос и обратная связь от коллег, продавать такие решения становится сильно проще.

5️⃣ Провел тестовый запуск

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

И здесь я допустил ошибку:

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

Планирую исправиться и после этого этапа нормально презентовать все изменения фокус группе.

Пока я в этой точке.

Продолжение — в следующих сериях.

💬 Какой, на ваш взгляд, должен быть следующий этап?