Agile *

Варианты старта: тимлид в новой или существующей команде

Продолжаем серию постов о переходе из роли старшего инженера в трек начинающего технического менеджера — тимлида.

Как это случается

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

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

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

Стартовые позиции

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

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

Тимлид в новой команде

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

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

Тимлид в существующей команде

Второй сценарий — приход на замену прежнему руководителю (например, после его повышения или ухода). Чистого листа здесь нет: новому тимлиду достаются незакрытые «хвосты», настрой команды, уровень развития людей, процессы и метрики. Всё это нужно быстро оценить.

Ключевой показатель — зрелость команды или Team Maturity Model (TMM): развитая, базового уровня или незрелая. С развитой можно работать на длинную дистанцию, с незрелой — сначала закрывать базовые пробелы.

Акцент смещается на быстрые победы, укрепляющие доверие, и «north stars» для долгосрочного развития.

Сложности вступления в роль

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

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

Онбординг тимлида длится около полугода. За это время необходимо: 

• показать профессиональный авторитет; 

• сделать прозрачными границы роли; 

• быстро погрузиться в боли команды и продукта; 

• обеспечить быстрые победы и план работы со сложными проблемами; 

• системно развивать все три направления: метрики, процессы и людей.

Выводы

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

Что дальше?

В следующей статье поговорим о целеполагании и планировании: как планировать, когда всё горит и ничего не понятно.

Теперь ты тимлид: роль, майндсет и границы ответственности

Сегодня мы начинаем серию постов о переходе из роли старшего инженера в трек начинающего технического менеджера — тимлида.

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

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

Три направления работы тимлида

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

Второе направление — процессы. Оно предполагает системный подход к развитию на основе метрик и данных. Универсальный план работы: определение метрики, её фиксация, изменение процесса, контроль метрики, коррекция плана и продолжение при необходимости.

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

Границы ответственности и принятие решений

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

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

• discovery составляющая — продакт-оунер, дизайнер, аналитик, редакторы и т. д.;

• техническое руководство — руководители разработки и функциональные руководители направлений; 

• delivery-составляющая — инженеры команды различных функциональных направлений;

• смежники: соседние команды, партнеры, HR-функция, административный персонал и т.д.

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

От теории к практический кейсам

В следующих статьях мы рассмотрим наиболее распространённые ситуационные кейсы:

• Варианты старта: тимлид в новой команде или в существующей.

• Целеполагание: как планировать, когда всё горит и ничего непонятно.

• Команда и люди: офферы, лоу-перформинг, увольнение, друзья, лояльность.

• Процессы: «и так нормально», бюрократия, эксперименты.

• Менеджерские кейсы: приоритеты, риски, разделение команд.

• Сложные ситуации: конфликты, смена продукта, откат обратно в инженеры, микроменеджмент.

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

Как выживают разработчики Госуслуг на защите квартального плана

У каждого, кто работает с госсектором, есть обязательная процедура — защита квартального плана. Что там происходит на самом деле и почему даже сильные команды «сыпятся» под вопросами заказчика?

Разбирались вместе с заместителем технического директора РТЛабс Виктором Редровом на OKR Russia

В докладе о том:

• Почему защита — это диалог, а не отчёт (и как к этому подготовиться)

• Типичные ошибки, которые превращают встречу в «допрос»

• Конкретные приёмы для сохранения контроля в любой ситуации

👉 Презентация и запись доступны по ссылке

Ускорили разработку в 2 раза за счет AI? Понятно.
Вот только релизы не стали быстрее, time-to-market не сократился.

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

Agile создавался как ответ на высокую сложность разработки, но AI эту сложность уже снизил. А значит, текущая модель команд начинает устаревать.

В апреле на Product Focus Club наш CPTO Саша Бондаренко поделился своим видением трансформации команд. 

Он рассказал:
— почему инвестиции в AI не дают эффекта без пересборки процессов (на данных Klarna и DORA)
— как появляется новая роль Product Engineer вместо набора узких специалистов
— почему команды из 7-9 человек трансформируются в компактные поды из 2-3 инженеров
— как Platform Engineering становится системой контроля и масштабирования, а не поддержкой
— как выглядит Team Topologies 3.0 и с чего начать переход

Запись выступления доступна для просмотра на YouTube и VK Видео. 

Кстати, в рамках эксперимента мы запустили три pod-команды у нас в Garage Eight. И у ребят уже есть крутые результаты! Обязательно поделимся ими в нашем телеграм-канале.

7 способов убить проект в длииинной Excel-таблице — и один, чтобы спасти

1. Создайте таблицу с 15 вкладками

Сначала все логично: «Общее», «Январь», «Февраль», «Последняя версия»... Через полгода никто не помнит, куда смотреть.

2. Используйте «В работе» как универсальный статус. 

Пусть все, что не упало в «Готово», автоматически числится в процессе. Когда на самом деле задача будет выполнена? Неизвестно. Пора вмешаться? Не понятно.

3. Храните переписку, файлы и задачи порознь

Telegram, облачное хранилище, таблицы, почта — проявите фантазию, чтобы каждый поиск занимал не меньше 20 минут.

4. Собирайте статусы раз в неделю вручную

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

Еще три способа упереться в край возможностей Excel и приблизить конец игры, а также о роскошном минимуме для управления проектами — в новой статье, здесь на Хабре.

Синхронизация хранилища в Obsidian

1. Простой и платный способ

Оплатить встроенный Obsidian Sync и включить синхронизацию. Картами российских банков оплатить не получится

2. Относительно простой и бесплатный

Использовать облачные хранилища: Гугл Диск, Яндекс Диск, iCloud. 

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

3. Бесплатный способ посложнее

Использовать инструменты для прямой синхронизации между устройствами. Самый известный - SyncThing. 

Способ подойдёт тем, кому важно, чтобы их данные не передавались на сторонние сервера. 

Я сейчас синхронизирую хранилище между ПК и iPhone через iCloud. 

Раньше была необходимость синхронизировать 3 устройства: домашний ПК, Android-смартфон и рабочий ПК. Тогда файлы передавались с домашнего ПК на смартфон, а когда я приходил на работу - со смартфона на рабочий ПК. 

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

Матрица Эйзенхауэра в Obsidian

Это инструмент планирования, в основе которого два критерия: срочность и важность. Все задачи делятся на четыре квадранта: важное и срочное (делай сейчас), важное и несрочное (запланируй), неважное и срочное (делегируй), неважное и несрочное (удали).

Я нашёл способ сделать матрицу Эйзенхауэра в Obsidian. 

1. Устанавливаем плагин Kanban

2. В папке .obsidian/snippets внутри вашего хранилища добавляем css-сниппет:

/* 
Author:  TfTHacker - more info  https://tfthacker.com/eisenhower-matrix-kanban
Date:    2024-02-27
LICENSE: Permission is granted to modify and distribute copies of this CSS file, that credit is given to TfThacker (https://tfthacker.com/) 
         and the source (https://tfthacker.com/eisenhower-matrix-kanban) remains linked and credited.  
*/

.kanban-plugin__board > :has(* > div > div[data-hitboxid*="e-matrix"]) {
  width: 100%;
  display: grid;
  grid-template-columns: repeat(2, 1fr);
  grid-template-rows: repeat(2, 1fr);
  gap: 15px;
  height: 100%;
  overflow-y: auto; /* constrols the vertical scrolling, which is usually disabled in the kanban board */

  .kanban-plugin__lane-wrapper {
    grid-column: span 1;
    grid-row: span 1;
    height: 100%;
  }

  .kanban-plugin__lane-wrapper:nth-child(1) > div {
    background-color: rgba(var(--color-red-rgb), 0.2);
  }

  .kanban-plugin__lane-wrapper:nth-child(2) > div {
    background-color: rgba(var(--color-blue-rgb), 0.2);
  }

  .kanban-plugin__lane-wrapper:nth-child(3) > div {
    background-color: rgba(var(--color-green-rgb), 0.2);
  }

  .kanban-plugin__lane-wrapper:nth-child(4) > div {
    background-color: rgba(var(--color-yellow-rgb), 0.2);
  }
}

body:not(.is-mobile) {
  .kanban-plugin__board > :has(* > div > div[data-hitboxid*="e-matrix"]) {
    .kanban-plugin__lane-wrapper {
      width: 100%;
    }
  }
}

body.is-mobile {
  .kanban-plugin__board > :has(* > div > div[data-hitboxid*="e-matrix"]) {
    /* make the card one line on mobile to make the matrix compact */
    .kanban-plugin__item-title {
      line-height: 1.2;
      max-height: 1.2em;
      overflow: hidden;
      text-overflow: ellipsis;
      white-space: nowrap;
    }
  }
}

3. Включаем css-сниппет в настройках в разделе "Оформление" 

4. Создаём новую канбан-доску. Её имя обязательно должно содержать фразу "e-matrix"

5. Создаём на доске 4 карточки (можно сделать пятую карточку для бэклога)

6. Получаем матрицу Эйхенхауэра с возможностью перетаскивания задач между квадрантами!!!

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

Если все решаю сам — это, значит, плохо?

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

Если вы хотите, чтобы команда росла в ответственности, а вы постепенно переходили «из дирижёра в зрители» — забирайте в закладки статью.

Плагин Tasks. Часть 2

Запросы - еще одна мощная возможность плагина. Пишутся на нативно понятном языке. Позволяют: 

1. Отфильтровать задачи из вашего хранилища по срокам, папке, содержимому

2. Настроить отображение задач в заметке 

Например, чтобы отобразить все невыполненные задачи со сроком (due date) сегодня, достаточно прописать в блоке кода:

tasks 
not done 
due today

⚠️ Чтобы запрос заработал, прописываем его в блоке кода, выделяемом символами “```”

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

Продуктовая разработка с агентами, замена agile-команд и роль продакт-инженера — эти и другие темы я обсудил с Юрой Агеевым, основателем ProductSense, в новом выпуске подкаста make sense.

Слушайте на удобной платформе: 
> Telegram 
> Mave 
> Apple 
> Яндекс Музыка
> YouTube

Таймкоды:
00:00 — Введение
01:58 — Личный сетап агентов, эксперименты и первые сценарии
03:34 — Почему тема агентов — это про орг. модель, а не про игрушки
06:05 — Откуда взялся Agile: ответ на рост сложности продуктов
09:10 — Идея мини-команд для быстрого тестирования гипотез с агентами
11:10 — Риски одиночки: туннельность, критика, фактор автобуса
12:05 — Платформенная команда: стандарты, «золотой путь» и «ворота качества»
14:05 — Зависимость централизации от культуры компании
16:12 — Продакт-инженер: продукт и инженерия в одном цикле
17:32 — Схлопывание ролей: инженеры учат продукт, продукты учат технику
19:33 — Практика пайплайнов в работе с агентами: сначала документация, потом код
26:03 — Контекст как главная ценность и способ удержания клиентов
29:01 — Один в поле не воин: почему запуск и масштаб важнее кода
30:28 — Можно ли доверять агентам?
33:54 — Конкуренция заставит ускоряться: когда агенты станут нормой?
35:55 — Практика внедрения агентов: выделенные пилоты и команды добровольцев
37:35 — Главные риски: стоимость токенов и деградация навыков
42:09 — Как будут трансформироваться процессы и agile-роли?
50:57 — Как правильно строить эксперимент: задачи, команды, обучение и метрики

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

Плагин Tasks. Часть 1

Этот плагин лежит в основе моей системы планирования.

Представляет собой простой, но мощный инструмент для работы с задачами.

1. Создаём в заметке задачу:

- [ ] Задача

2. Появляется выпадающее меню, в котором можно назначить даты начала и завершения задачи, выбрать приоритет.

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

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

В продолжение темы Zero Links

Если не видели мой первый пост, то вот он.

В одном из чатов мне задали вопрос:

А как быть, если нужно экспортировать заметку и все ссылающиеся на неё файлы? 

Отвечаю: поставить плагин Linked Note Exporter, открыть нужный файл, нажать по вкладке правой кнопкой мыши и выбрать "Export Note & related Files".

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

Zero Links в Obsidian

Это способ организации файлов внутри вашего хранилища без использования папок.

Принцип работы:

1. Вы создаёте посадочные страницы для различных категорий заметок. Они могут быть пустыми.

2. Называете страницу, например, "00 Бизнес". Нули нужны для удобства навигации, чтобы файл всегда был вверху.

3. В заметки по теме бизнеса добавляете ссылку на заметку "00 Бизнес"

4. Включаете встроенный плагин "Обратные ссылки"

5. Результат! В заметке "00 Бизнес" в разделе "Упоминания со ссылкой" показаны все ваши заметки про бизнес

Преимущества подхода:

1. Простота и естественность организации файловой системы

2. Если заметка относится сразу к нескольким категориям - ставите несколько ссылок на посадочные страницы. А добавить один файл сразу в две папки невозможно.

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

Роль Agile Coach мертва… да здравствует агент изменений

TL;DR Роль Agile Coach должна умереть, чтобы переродиться в роль Change Agent (или Organizational Architect). И работать такие спецы должны не "вечно", а проектно - как спецназ внедрения изменений.

Здесь и далее: скрам-мастер и аджайл коуч тождественны.

1. Выделенная роль в команде — это кража ответственности

Постоянно приставленный к команде Agile Coach (или Scrum Master, или Delivery Manager в роли «няньки») - это прямое забирание ответственности у руководителей.

Зачем компания платит продактам и тимлидам хорошие деньги? Наверное, не для того, чтобы кто‑то другой создавал атмосферу безопасности, фасилитировал и работал с людьми.

Если руководитель не умеет управлять динамикой команды — значит, его надо учить, а не ставить ему «костыль» в виде коуча (ну и спрашивать с него соответственно). Соответственно, большая часть работы Agile Coach → Change Agent это обучение тем навыкам, которых не хватает руководителям. Скорее всего в больших организациях уже есть T&D‑отдел, который и занимается обучением. Наша задача состыковать системно прокачивание самых актуальных навыков.

2. Коуч для руководителей и архитектор среды

Роль трансформируется в коуча для руководителей и человека, который проводит изменения (зачастую проектно).

Чаще всего наболее активная часть работы - это движение системы к зрелости через работу с лидами. Агенты по изменениям - архитекторы среды обмена опытом. Даже на разборах ситуаций по хорошему (и когда получается) надо молчать и давать слово коллегам руководителя, даже если знаешь «правильный» ответ. Система должна уметь саморегулироваться, когда нас не будет. 

Тут еще есть научная обоснованность: в модели проведения изменений ADKAR доказательно видно как CLARC (people менеджеры) это те, через кого мы проводим изменения.

3. Тест на прочность: «А что, если я уйду?»

Agile Coach делает хорошую работу, если после его ухода система радикально не ломается. Посмотрите, как быстро команды откатываются назад и насколько (например, по метрикам), когда из них убирают скрам‑мастера.

Стабильная привычка, как известно, формируется около 3 месяцев. В зависимости от масштаба изменений вы можете работать 3-6 месяцев и довести команду до определенного целевого состояния.

Нет предела совершенству, но нам с вами не туда: доводить процессы и майндсет до идеальных состояний почти никогда не стоит. Команды после нашего ухода все равно откатятся (и это нормально, главное чтоб не до нуля). С точки зрения всей системы, нам важнее дотягивать другие команды, процессы, взаимодействия, целеполагание до базового и достаточного уровня (который каждая организация определяет сама). Это даст намного более сильный результат по всей организации.

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

4. Мы наняты бизнесом, а не командой

Прошли времена раздутых бюджетов, когда можно было плодить «аджайл ради аджайла» чтобы «оптимизировать процессы». В текущих реалиях (особенно с нынешними ставками ЦБ) каждая копейка на счету.

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

Балансировать перформанс и здоровье команды (например, удовлетворенность, отток, выгорание) - вот это реальная задача, с которой надо помочь руководителям справиться или продумать оркестрацию изменений.

Софт скилы - это новые хард скилы

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

PS: Больше об этих самых хардах и внедрении ИИ в моем телеграм‑канале.

Как проводить встречи эффективно

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

Подготовка
– Избегай звонков без необходимости – большинство вопросов решаются в чате
– Не дергай “на минутку” – если прод не упал, значит, не срочно
– Анонсируй: кто, когда, зачем. Иногда достаточно треда в чате
– Проверяй доступность участников через календарь
– Ограничивай время – 30 минут обычно хватает, 1 час — максимум
– Готовь повестку заранее: тема, пункты обсуждения, цель встречи, – уважай чужое время
– Рассылай материалы и документы до встречи
– Предупреждай об отмене или задержке как можно раньше
– Опаздываешь? Не опаздывай 🙂

Старт встречи
– Начинай вовремя – без «ждём ещё кого-то»
– Проверь комнату ожидания и список участников
– Напомни повестку – это фокусирует команду

Фасилитация
Модное слово для процесса организации групповой работы
– Держись повестки и возвращай к цели встречи
– Дай слово молчунам, притормози болтунов.
– Подводи итоги каждые 10–15 минут: «Итак, договорились, что…»
– Следи за чатом и поднятыми руками
– Делись экраном, глаза – тоже канал восприятия
– Включай камеру по возможности
– Не перебивай – сначала дослушай, потом задавай вопросы.
– Паркуй спорные темы после трёх заходов
– Уважай выделенный слот – если нужно больше времени, спроси
– Веди пост-мит в реальном времени

После встречи
– Напиши постмит, опубликуй до конца дня, тегнув участников

Оперативный постмит

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

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

Это оказалось супер удобно:

• Сразу видно, что записывается, а участники могут поправить, уточнить, добавить

• Все сразу понимают, кто на ком стоял, кто за что отвечает

• Не нужно тратить время после встречи и что-то дооформлять

• Шаблон постмита позволяет ускорить процесс ещё больше

Как мы собрали 500 человек на демо продукта

Привет! Это Владимир Князев, Agile-коуч трайба HR Tech в ОТП, и сегодня я расскажу о том, как мы организовали самое большое демо внутри компании и собрали на него 500 человек — максимум, возможный в Zoom.

Это было демо по продукту OTP Space — единому пространству HR-сервиса, в котором каждый сотрудник может оформить отпуск, поставить цели и посмотреть структуру компании. Поэтому нам важно было рассказать о нём на всю компанию. В этом посте я поделюсь, с помощью каких инструментов мы привлекли 500 человек и как удержали внимание. В прошлой статье я рассказал о приоритизации ICE и как её применять. 

Не рассылкой единой

Нашей целью было привлечь как можно больше участников. Поэтому мы обратились к коллегам из внутренней коммуникации и предложили сделать большую рассылку. Договориться удалось не сразу: нужно было доказать, что это будет полезная рассылка, а не очередное приглашение на внутреннюю встречу. Нам помогло то, что до нас в ОТП уже запускали похожие кампании — например, с приглашением на митап по искусственному интеллекту. Мы использовали это как прецедент: «Раз они смогли — почему не сможем мы?».

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

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

Как удержали интерес сотрудников

Демо на сотни человек ≠ просто рассказ. Здесь нужна полноценная фасилитация, с которой самому спикеру не справиться.

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

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

Что с обратной связью

ОТП Space — продукт масштабный, вопросов было много. После демо мы выгрузили весь чат, отсортировали вопросы, на которые не успели ответить, и постарались дать индивидуальный ответ каждому участнику. Это заняло время, но оно того стоило — обратная связь от сотрудников стала основой для следующих итераций в развитии продукта.

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

Советы для демо без лимитов

Вот что нужно учесть при подготовке демо на большую аудиторию:

- заранее продумываем инструменты для привлечения участников;

- приглашаем фасилитатора для модерации встречи;

- очерчиваем структуру демо в начале встречи: поясняем, о чём расскажем, на какие вопросы аудитории ответим сразу, а на какие — после демо;

- планируем демо как диалог с пользователями, чтобы собрать развёрнутую обратную связь у широкого круга сотрудников;

закладываем ресурс на обработку обратной связи.

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

Читайте, чем живёт IT в ОТП — в ТГ канале. А ещё я веду личный канал про Agile и изменения.

Приветствуем, уважаемые читатели! Самые внимательные любители нашей литературы давно замечают, что некоторые анонсы наших книг (прежде всего - переводных) делает коллега @sergbe в корпоративном блоге дружественной нам компании SSP-Soft. 22.10.25 там вышла публикация о книге "Паттерны коммуникации: руководство для ИТ-разработчиков и архитекторов", вот сама книга у нас на сайте. Это один из наших свежих заходов в тему "soft skills". Обязательно переходите и изучите анонс, желающие могут для начала посмотреть оглавление.

Аннотация:

Книга  представляет собой практическое руководство по эффективной коммуникации для  ИТ-специалистов, которым необходимо доносить свои идеи до целевой аудитории ясно и понятно.  Она охватывает ключевые аспекты визуальной, письменной, устной и невербальной коммуникаций, а также особенности удаленной работы. Рассмотрены основы создания наглядных диаграмм и документации,  включая работу с цветом и композицией, методы последовательной подачи информации  и повышения  ее  доступности, чтобы адаптировать визуальные материалы для разных аудиторий. Описана работа с языком, структурирование текста, применение языка тела и использование культурных различий с целью убеждения аудитории. Предложены подходы к организации и передаче знаний в командах, включая принципы DRY (Don’t Repeat Yourself). Рассмотрены  современные инструменты для управления знаниями, помогающие сделать информацию доступной и понятной для всех участников проекта. Рассмотрены средства для эффективной работы в распределённых командах, включая синхронные и асинхронные методы коммуникации и  управления временем.

Почему мы всегда опаздываем? Ошибки планирования в разработке.

Паттерн планирования, с которым часто встречаюсь: заказчик (или заказчики) приносит задачи. Обычно есть описание, что должно получиться на выходе. В определенный момент команда разработки смотрит на задачи, берет какие-то из них в работу на определенный срок (неделя, месяц, квартал и т.д.), подтверждая сроки доставки. Руководитель, ответственный за доставку задач, передает сроки в бизнес. Условно назовем его руководитель проектов (РП).

Что будет дальше со сроками? Сроки обязательно сдвинутся и кому-то придется за это оправдываться, а может быть и переподписывать документы. Кажется, что дело обычное и так сдаются подавляющее большинство задач. В какой-то момент РП начинает добавлять некоторую дельту ко времени сдачи. Часто это называется – заложить риски. Но сроки сдачи все равно сдвигаются, даже с учетом рисков.

Проблема не в планировании, а в том, как мы планируем. Традиционный подход с фиксацией сроков на старте проекта в условиях высокой неопределенности обречен на провал. Однажды я подумал в чем полезность планирования? Что будет если планирование не проводить? Как это повлияет на разработку? Очевидно, что заказчик чувствует некую уверенность, когда получает сроки реализации задачи. Но это очень условно и польза, на самом деле, не большая. Сроки, как мы уже знаем, все равно сдвинутся и, скорее всего, превратятся в инструмент давления на команду разработки и на самого РП.

Почему же так получается? Те, кто изучают Kanban метод знают, что относиться к процессу разработки нужно как к процессу накопления знаний по данной проблеме (задаче). В процессе реализации и сама команда и заказчик узнают много нового по этой задаче. Каждый в своей зоне ответственности. Получая новые знания вносятся правки как в постановку, так и в техническую реализацию. Получается, если проводить планирование в самом начале, то точность будет основана на почти нулевом знании о задаче. Виной тому очень высокая неопределенность. В самом конце разработки, когда задача уже почти готова к выкатке на прод, все участники уже довольно точно могут сказать, когда задача закроется. Неопределенность низкая и почти отсутствует.

Не менее важная проблема: в длительности процесса планирования. Он может занимать значимое время и быть растянутым по дням и неделям. На что лучше потратить время вместо планирования? Ответ простой: на устранение неопределенности. Угадывать сроки доставки не так полезно, как решить все неопределенности и накапливать знания о проблеме, чтобы срок разработки сократился. Возможно, мы не угадаем сам срок реализации, но можем быть уверенными, что он будет минимальный.

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

Практики работы с OKR: реальные примеры из команды Авито

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

Смотреть VK
Смотреть YouTube

Все серии курса для вашего удобства собрали здесь: можно повторить пройденное в любое время, а также поделиться советами с коллегами!

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.