Agile *

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

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

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

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

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

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

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

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

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

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

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

• 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, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Какие цифры считать победой?

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

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

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

Key Results: как измерить то, что действительно важно?

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

• функции и свойства Key Results — чем они отличаются от обычных KPI?

• как помогают достигать целей?

• как избежать ошибок при формулировке?

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

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

Как не завалить целеполагание в самом начале?

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

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

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

OKR — это вам не ОКР: как ставить цели без навязчивых состояний

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

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

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

Здесь кто-нибудь есть?

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

Поехали!

Большие деньги - большая ответственность, я еще немного поучусь и можно ходить на собеседования

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

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

Убейте в себе внутреннего "отличника", который хочет всё идеально знать. Начните действовать как можно раньше, ведь главный наш ресурс - это время. Если не начнете ходить по собеседованиям сейчас, то потом может стать поздно!

Я слишком стар/молод/у меня нет профильного образования

Это миф. В IT реально можно войти в любом возрасте и с любым бэкграундом. Большинство компаний смотрит на твои навыки и то, как ты решаешь задачи, а не на диплом. Например у меня еще ни разу не спрашивали про мой диплом и про моё образование, но при этом огромное кол-во людей верит в то, что реально нужен крутой бэкграунд, а не опыт. Важно показывать интерес к профессии, прокачивать навык прохождения собеседований, учиться продавать себя на рынке труда и тогда у Вас всё получится! Как говорил Олег Тинькофф: "Продай свои мозги дорого". Это очень хорошо описывает в целом текущее состояние рынка.

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

Я не найду работу без опыта От каждого второго человека слышу это. Мол я не могу найти работу без опыта, всё дело в опыте! А потом я открываю его резюме и вижу, что там полная каша и оказывается, что дело не в опыте, а в резюме или же в чём-то другом. Не бойтесь искать любую возможность попробовать реальные проекты. На старте важно показывать свою мотивацию и учиться командной работе. Не стесняйся писать в компании напрямую, предлагать свою помощь за отзыв или за опыт — так много кто стартует.

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

• Разделяй путь на маленькие задачи и радуйся каждому шагу.

• Найди ментора, чтобы не оставаться один на один с вопросами.

• Веди дневник успехов — записывай даже маленькие победы.

• Не сравнивай свой путь с другими, особенно в соцсетях — у каждого свой старт и темп.

• Признай: страх — это нормально. Его испытывали все, кто сегодня работает в IT.

Понравился пост? Тогда переходите ко мне в телеграмм канал, там находится много полезного материала, для входа в IT!

🔥 Agile умирает - и его убийца уже здесь. Имя ему - искусственный интеллект!
Заметили ли вы что многие Agile визионеры активно перетекают в сторону AI-консалтинга?

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

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

Может, Agile - это как Nokia в мире проектного менеджмента? Собственно у Nokia был замечательный Agile

Теперь думаю: это трагедия или естественный отбор? Agile ещё жив или уже пора хоронить?

Недавно прочитал, что идеальная Agile-команда -- как повара в кафе: подберут ингредиенты, приготовят блюдо персонально для клиента. Самое вкусное для конкретного гостя.

Представляете такую команду в реальном ресторане?

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

И вот вы начинаете говорить, что хотели бы: соляночку на первое, чтобы по всем правилам; ну и, раз сами спросили, на второе -- стейк и картофель с розмарином и соусом. Вроде бы не бюджет бизнес-ланча, но команда записывает, активно обсуждают, подсказывают. Кто-то уже побежал готовить -- круто!

1. Приносят первую порцию, небольшую и жидкую - MVP пока что. На тарелку решили не тратиться, ведь главное не в упаковке. Пей, значит, из ладошки!

2. Высказываете замечания:
-- Вроде как картошку то стоило поварить..
-- На анчоусы (откуда?!) у вас аллергия,
-- Посуду бы конечно добавить.
Команда соглашается, но посуду решили добавить только в 3 спринт -- ресурсов не хватало и между идеей убрать анчоусы (да зачем вообще?!) и добавить посуду выбираете здоровье в ущерб брезгливости.

3. ...

4. ...

5. Итерации к 5 это уже будет солянка. В тарелке для супа. В чистой. Жаль только не доварили (спринта не хватило, затянули с нарезкой мяса). А как удалось объяснить, что 5 видов разного мяса в одном блюде и одинаково готового (тут промашка, обещали исправить) -- это не баг, а фича, -- это ваш, как заказчика, отдельный повод для гордости.

Но за 5 попыток наверно уже и наелся.

И ведь все как ты хотел! Что недоволен то?!

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

Освойте инструменты креативных методологий для применения в проектах и рабочих задачах 💡

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

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

Кому будет полезен курс:

• руководителям больших и маленьких команд, которые хотят освоить новые инструменты, чтобы улучшить рабочие процессы;

• тем, кто хочет находить уникальные решения для развития проектов и получить практический опыт в их реализации;

• всем, кому интересны креативные методики.

Желаем успехов!

Не умею работать с руководством: отстаивать границы впихуемости по порученным задачам.

Бизнес всегда будет желать напихать задач полную панамку.

Первым рубежом в обороне и систематизации задач будет оценка и группировка, — это Твоя ответственность. Важно понимать границу между оценкой (примерное представление о размере задачи) и декомпозицией (уже полноценная работа над ней). Процесс уточнения и детализации задач называют грумингом (или backlog refinement), а оценка задач проводится в рамках планирования или специальных встреч. Оценивают задачи в крокодилах, бананах, бутылках — или по классическим методам, например, покеру планирования с использованием последовательности Фибоначчи.

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

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

Держать бэклог в приоритезированном состоянии — это только полдела. Надо ещё понять, сколько задач команда может физически осилить. Надо понять широту размаха челюсти команды - velocity :) Для этого существует несколько способов оценки, включая оценку в человеко-часах, сторипоинтах, T-shirt sizes и другие.

Velocity — это не просто количество задач за спринт, а сумма их оценок (например, в сторипоинтах) за спринт, а совокупная способность команды выполнять задачи, включая багфиксы, тестирование, митинги и прочую обвязку. В реальности бОльшая часть времени может уходить на поддержку, рефакторинг и другие технические нужды. Поэтому рассчитывать, что 100% ресурсов пойдут на новые задачи, — полный фейл. Не попадись на эту удочку!

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

Теперь можно чётко отстаивать границы впихуемости. Если бизнес диктует, что "завтра всё должно быть в 100 раз масштабируемо", CTO не кидается в бой с криками "сейчас запилим!", а чётко объясняет, какие ресурсы потребуются, какие риски возникнут и какие альтернативные варианты возможны. Главное — не просто говорить "нет", а предлагать реалистичные варианты решения проблемы.

Видишь? Мы отстроили процесс груминга, приоритезации, декомпозиции и оценки задач, взятие в работу только реального объёма бэклога спринта, и внезапно — у нас резко наладились отношения с бизнесом. Бизнес больше не ждёт чудес, команда работает без авралов, CTO перестаёт быть мальчиком на побегушках.

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

• Затраты на поддержку вырастут → Дороже обслуживать.

• Продукт становится нестабильным → Клиенты уйдут к конкурентам.

• Отток специалистов → Потери на найме и онбординге.

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

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

П.С. объявляю конкурс на иллюстрацию к этому посту!

Не хотелось бы попасть в зону стресса. А в зону паники - тем более. Поэтому закладывайте время достаточно на случай, если всё пойдёт не по плану.

Как повысить свою ценность в ИТ: в поиске новых компетенций. Новый выпуск Sravni Podcast

Поговорили с Левоном Гончаровым, экспертом в области Agile и построении команд. Обсудили, как разносторонность и насмотренность помогают в ИТ (и в целом в карьере), об успешном планировании, делегировании и самых ценных сегодня софт-скиллах.

Также в этом выпуске:

• Как меняются требования к разработчикам

• Везде ли эффективен SCRUM

• Что важно знать о психологии при работе с командами

• Путь от айтишника до владельца баскетбольного клуба и кинопродюсера

Подкаст доступен здесь:

• YouTube

• RUTUBE

• Яндекс Музыка

Оперативно узнавать о наших новых подкастах, докладах, лекциях и других полезных ИТ-материалах можно в тг-канале Sravni Tech.

На этой неделе у нас два отличных вебинара:

⚡️ 31 октября в 15:00 начнется вебинар «Нейросети без галлюцинаций: миф или реальность?». Недавно нейросети часто ошибались, создавая рисунки с аномалиями и  документы с несуществующими законами. Сегодня результаты стали более корректными, однако галлюцинации продолжают встречаться. На вебинаре обсудим, как промпты могут снижать влияние галлюцинаций, добавлять качественные данные в контекст и организовывать автоматическую проверку результата.

👨‍🎓 Спикер: Брейман Александр — эксперт Учебного центра IBS, кандидат технических наук, доцент департамента программной инженерии ФКН ВШЭ.

✍️ Записаться

⚡️ 1 ноября в 15:00 стартует эфир «Оценка задач в Agile-проектах». Рассмотрим, как особенности Agile-проектов влияют на выбор инструментов оценки. Участники узнают о таких методах, как Story Points, Planning Poker и T-shirt Sizing, и их роли в управлении проектами.

👨‍🎓 Спикер: Политыко Сергей — архитектор информационных систем в IBS.

✍️ Записаться

Приоритезируем бэклог по методу WSJF 

Регулярные внутренние воркшопы — важная часть непрерывного улучшения гаражистов. Так, недавно Саша Липин, лид одной из наших продуктовых команд, провел вебинар по методологии приоритезации задач WSJF (Weighted Shortest Job First — Сначала Более Ценная и Короткая Работа). 

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

А если интересно разобраться и научиться, то листай карточки в посте. На них рассказали, по каким параметрам оценивать эпики/фичи/задачи и по какой формуле выявлять самые важные для бизнеса ;-)

Метод 5S для планирования задач по проекту

 Большая часть работы проджекта состоит в постановке задач и планировании загруженности команды. Кто-то прибегает к доске Канбан, кто-то выстраивает спринты. Но сегодня хотела бы обсудить 5S-метод по планированию задач. Этот метод помогает справиться с авралом, когда кажется, что дел навалилось куча, и за что хвататься в первую очередь – непонятно.

Sort – сортировать задачи по степени их важности для текущего проекта / спринта. Удалять (или переносить в архив) лишние задачи, оставляя только самое необходимое

Set in order – выстраивать задачи в приоритетном порядке.

Shine – прозвучит неожиданно в данном списке, хотя и очевидно: состояние рабочего места также влияет на производительность труда. Уберитесь на столе, чтобы ничто вас не отвлекало, а также разберите открытые вкладки в браузере (я точно этим грешу).

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

Sustain – обсудите с командой алгоритм, отшлифуйте его. Внедрите и первое время контролируйте, что алгоритм используется всеми членами команды (включая вас).

Светская беседа в деловой переписке: вымысел или реальность?

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

Кто вообще пишет такие письма?

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

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

Исследование показало, что процент отказов в Agile-проектах по разработке ПО на 268% выше. Оно было проведено по заказу консалтинговой компании Engprax. Неясно, откуда взялся именно такой процент.

Исследование проходило с 3 по 7 мая, в нём приняли участие 600 инженеров-программистов (250 в Великобритании и 350 в США). Выяснилось, что проекты с чёткими требованиями, задокументированными до начала разработки, имели на 97% больше шансов на успех. При этом введение спецификации до начала разработки может увеличить успешность реализации на 50%, а обеспечение точности требований — на 57%.

Авторы исследования утверждают, что исследованные ими Agile-проекты проваливались в 65% случаев. При этом они продвигают новую методологию Impact Engineering, которая якобы позволит сократить количество неудач в проектах в 6,5 раз (до 10%). 

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

Результаты исследования вызвали возмущение у сторонников Agile-подхода.

Story Map может стать более углубленной и проработанной, если добавить форматы "Jobs Story", "System Story", "Изменение", "Описание изобретения".

Jobs Story
Когда <ситуация, контекст>, Я хочу <мотивация>, так что <ожидаемый результат>
Пример:
Когда сбоят системы отправки, выгружаю уведомление в формате XLS, чтобы отправить клиенту и регулятору вовремя

System Story
Способ описания требований к разрабатываемому решению с точки зрения разработчиков. Формат напоминает User Story, только с фокусом на процессе взаимодействия пользователей с разрабатываемым решением:
<Глагол действия> <Субъект>, чтобы <Кто> получил <Что> (или чтобы <Цель>).
Пример:
Установить уровень давления в системе в соответствии с типом пива, чтобы покупатель смог наполнил бутылку пива без пены за 30 секунд.

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

Описание изобретения
<Полезное действие/ Отрицание нежелательного эффекта> в <контекст> за счёт <принцип работы>
Пример:
Быстрее нахожу какой статус выбрать в колонке-фильтре статусов за счёт вывода их в идеальном хронологической последовательности

Подсмотрено тут:
https://medium.com/serious-scrum/unheralded-alternatives-to-user-stories-f1d787fc2278
https://speakerdeck.com/ashapiro/mastier-klass-po-user-story-mapping?slide=17