Тарас Шевченко MorliDots

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

Работаем с реальными сценариями: разработчик требует переписать легаси, пугая страшными графиками; менеджер давит дедлайнами; архитектор грозит «отставанием от Netflix»; аналитик молчит о рисках решения.

Три этапа. Признание проблемы — голосование и живые скетчи манипуляций с разных ролевых позиций. Анализ кейсов — работа в группах по ролям и анонимный разбор случаев из практики участников. Договор — участники вместе пишут «Манифест честной коммуникации в IT» с конкретными правилами и уносят его в свою команду.

Аудитория: тимлиды, техлиды, руководители направлений и команд; а также Middle+ разработчики, аналитики, продакт-менеджеры, архитекторы, скрам-мастера · страница мастер-класса · расшифровка доклада PROvoke

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

Нейросети выдумывают рейтинг с метриками и сотыми долями, которого не существует. Путают автора с поэтом-однофамильцем. Один и тот же запрос к одной модели в один день даёт два разных мира. Упоминания в ответах ИИ растут с нуля до пяти из 33 — и одновременно выясняется, что разброс между прогонами больше роста.

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

Слушатели уносят пять вопросов, которые стоит задать себе до того, как «быстро это измерить».

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

Подробнее о докладе

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

Разбираем рабочий набор инструментов переговорщика из разработки: приоритизацию по ценности и рискам, формулировку MVP и MVP+, технику «если — то», магию «и» вместо яда «нет», фиксацию договорённостей как броню команды. BATNA и ZOPA на понятных кейсах: срез бюджетов, перенос дедлайнов, рефакторинг, Black Friday, прод-инциденты, срочная хотелка ключевого клиента.

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

Аудитория: тимлиды, техлиды, DevOps, SRE, руководители групп разработки и эксплуатации, аналитики, архитекторы. Есть версия под аудиторию аналитиков и версия под корпоративный формат.

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

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

Как готовился доклад: полная расшифровка · разбор на Хабре · взгляд содокладчицы

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

Аудитория: системные и бизнес-аналитики, продакт-менеджеры, тимлиды.

Конфликты между бизнесом, продуктом, аналитикой и разработкой почти всегда начинаются с разного понимания задачи. Для бизнеса это «простая фича», для разработки — требования, ограничения и риски, а аналитик оказывается ровно посередине.

О том, как вытаскивать реальные ожидания, формулировать требования, работать с user story и помогать командам договариваться до того, как задача превратится в конфликт.