Пять человек, шесть спринтов и AI-ассистент для продавцов маркетплейса. В бэклоге — архитектура, тестовый стенд, интеграция в чат, автономные ответы и оплата. Всё хочется получить за квартал.
Разбирая этот учебный кейс, я подготовил доску: выбрал первый пользовательский сценарий, разложил запуск на альфу и бету, посчитал доступную мощность команды, распределил ответственность и предложил метрики. Затем решил усилить тестирование, заменив одного backend-разработчика на QA-инженера.
Именно на этой замене хорошо видно, как в плане могут разойтись связанные решения. Численность команды не изменилась. Но расчёт мощности был сделан для прежнего состава, а перенос части работ между ролями остался недостаточно обоснованным.
Ниже — исходное решение и то, как я бы его доработал. Это разбор планирования на учебном кейсе, а не история запущенного продукта.
Условия задачи
Ассистент помогает продавцу отвечать покупателям в существующем чате. Начать можно с подсказок, которые продавец проверяет и отправляет сам. Следующий уровень — автоматические ответы в ограниченном наборе ситуаций. Переговоры о цене и самостоятельное совершение сделки требуют отдельного решения о допустимой автономности.
Внешний сервис по условиям кейса уже предоставляет LLM, цикл агента и базовый вызов инструментов. На нашей стороне остаются интеграция с продуктом, доступ к данным, ограничения на действия, проверки ответов, наблюдаемость и передача диалога человеку. Разработка универсальной агентной платформы с нуля в объём не входит.
В команде три backend-разработчика, один frontend-разработчик и один QA. Прежних обязательств у команды нет. Для расчёта принимаю квартал за шесть двухнедельных спринтов; праздники и персональные отсутствия нужно уточнять отдельно.
Оценки даны в человеко-спринтах соответствующей роли:
Работа | Backend | Frontend | QA |
|---|---|---|---|
Архитектура | 3 | 1 | 1 |
Тестовый стенд | 4 | 1 | 1 |
Интеграция в чат | 3 | 2 | 1 |
Автономная работа | 2 | 1 | 1 |
Оплата | 4 | 1 | 1 |
Регрессионное тестирование | 0 | 0 | 2 |
Всего | 16 | 6 | 7 |
Три человеко-спринта backend — не обязательно три календарных спринта одного разработчика и не обязательно один спринт трёх разработчиков. Возможность распараллеливания ещё предстоит проверить.
Первая версия решения
Я выбрал ассистента для продавца в режиме подсказок как основу первого запуска. Он позволяет проверить полезность ответов, сохраняя контроль у человека. При этом принятие подсказок ещё ничего не доказывает о безопасности автономного режима: для него понадобится отдельная проверка.
Архитектура, стенд и интеграция в чат стали основным объёмом. Автономные ответы — следующей ступенью, которую можно сократить при отставании. Оплату отложил: сначала хотелось проверить ценность сценария, а затем добавлять отдельную механику монетизации.
На доске появились и продуктовые вехи: первые сценарии на стенде, внутренняя альфа, ограниченная бета, расширение пилота и решение о дальнейшем развитии. Ответственных за архитектуру, интеграцию, стенд, фронтенд и регресс я тоже обозначил.
Исходная версия решения. Доска показывает общую структуру; расчёты и изменения разобраны ниже в текстовом виде.
У плана есть горизонт, последовательность и промежуточные результаты. Дальше нужно проверить, обеспечены ли они людьми, временем и выполнением зависимостей.
Сначала сводим объём и доступное время
Для первой оценки я использовал коэффициент доступной мощности 0,8. Это допущение для планирования, а не универсальная норма производительности.
Получилось:
Роль | Людей | Номинально за 6 спринтов | После коэффициента 0,8 | Весь бэклог |
|---|---|---|---|---|
Backend | 3 | 18 | 14,4 | 16 |
Frontend | 1 | 6 | 4,8 | 6 |
QA | 1 | 6 | 4,8 | 7 |
Полный объём не помещается ни по одной роли. Сумма всех человеко-спринтов здесь мало помогает: свободное время backend-разработчика не превращается автоматически во время frontend-разработчика или QA.
После исключения оплаты остаётся 12 / 5 / 6 человеко-спринтов backend, frontend и QA. Backend уже укладывается в предварительный лимит, но frontend и QA — ещё нет.
Если дополнительно убрать автономную работу, останется 10 / 4 / 5. И даже в этом варианте QA нужно 5 человеко-спринтов при доступных 4,8.
Разница небольшая, но её нельзя просто округлить в удобную сторону. Нужно выяснить, что входит в оценку, какая работа действительно обязательна и можно ли обоснованно изменить её распределение. При этом нельзя убрать проверки безопасности только потому, что они мешают сойтись таблице.
Есть и продуктовое условие: расчёт 10 / 4 / 5 применим к режиму подсказок, только если соответствующий интерфейс и ручное подтверждение уже входят в оставшиеся задачи. Новые требования требуют новой оценки.
Замена человека меняет весь расчёт
В исходном решении я предложил заменить одного backend-разработчика на сильного QA-инженера. Он мог бы отвечать за тестовый стенд и проверку качества ответов модели, а второй QA — за продуктовые сценарии и регресс. Основные сервисные интеграции оставались бы у backend.
Для AI-продукта такая конфигурация может быть полезной. Но пользу нужно подтвердить конкретным составом работ, а не только грейдом специалиста.
После замены получаем два backend-разработчика, одного frontend-разработчика и двух QA. При прежних допущениях доступная мощность становится 9,6 / 4,8 / 9,6.
Теперь вернёмся к варианту без оплаты, но с автономными ответами: ему нужны 12 / 5 / 6. У backend уже не запас, а дефицит 2,4 человеко-спринта.
Предположим для проверки, что часть backend-работ можно передать QA с одинаковой трудоёмкостью и без дополнительных расходов. Обозначим её через x:
Backend: 12 − x ≤ 9,6 → x ≥ 2,4 QA: 6 + x ≤ 9,6 → x ≤ 3,6
Даже в таком упрощении нужно найти от 2,4 до 3,6 человеко-спринта действительно переносимой работы. Frontend при этом всё ещё требует 5 вместо доступных 4,8.
В реальности равенство трудоёмкости тоже нельзя принять без проверки. QA может быстро собрать набор тестовых сценариев, но нуждаться в помощи с сервисной интеграцией. Время на эту помощь вернётся в загрузку backend. Подготовка и разметка данных могут потребовать участия продуктового эксперта, которого вообще нет в штатной таблице.
Поэтому передача «тестового стенда целиком» должна превратиться в перечень работ: окружение, интеграции, тестовые данные, запуск проверок, отчёты, поддержка. Для каждой части нужны исполнитель, оценка и зависимости.
Назначенный владелец отвечает за результат направления, но не обязан лично выполнять все работы внутри него. И наоборот: смена владельца сама по себе не снимает нагрузку с прежних исполнителей.
В моей первой версии именно этот пересчёт остался незавершённым. Замена могла оказаться удачной, но план ещё не показывал, за счёт чего она устраняет дефицит.
Коэффициент доступности и резерв нужно расшифровать
В исходном решении уже были два способа учитывать неопределённость: коэффициент 0,8 и возможность отказаться от автономных ответов. Это полезно, но отвечает не на все вопросы.
Что именно скрывается в оставшихся 20%? Встречи? Известный отпуск? Поддержка? Резерв на исправление дефектов? Если этого не определить, одну и ту же потерю времени легко учесть дважды — или не учесть вовсе.
Условный пример для одного QA на шесть спринтов:
6,0 — номинальное время 0,2 — известные отсутствия 0,6 — прочая запланированная работа 0,4 — резерв на неопределённость 6,0 − 0,2 − 0,6 − 0,4 = 4,8 человеко-спринта на основной объём
Это пример расшифровки 0,8, а не дополнительные вычеты после умножения на него. На реальном проекте значения берутся из календаря и состава работ. Известный регресс из бэклога тоже нельзя незаметно посчитать второй раз как «прочую работу».
Отдельно проверяется расположение отсутствий во времени. Отпуск единственного frontend-разработчика перед выпуском интерфейса может сдвинуть веху, даже если общая квартальная сумма выглядит приемлемо.
Сокращение автономного режима — ещё один, другой механизм: заранее согласованное изменение объёма при риске. Но оно сработает, только если высвобождает нужную роль до срыва критичной вехи. Отмена поздней backend-задачи не обязательно спасёт раннюю frontend-интеграцию.
От списка метрик к цели квартала
В первой версии у меня были и продуктовые показатели, и цели по процессу: сократить долю перенесённого объёма, повысить выполнение договорённостей, готовить задачи заранее. Сами по себе такие цели допустимы. Но они не заменяют ответа на вопрос, что должно измениться для пользователя к концу квартала.
Я бы сформулировал квартальную цель так:
Запустить для согласованной пилотной группы продавцов помощника в режиме подтверждаемых подсказок и проверить, сокращает ли он время ответа без ухудшения качества обслуживания. К концу квартала подготовить решение о расширении, доработке или продолжении эксперимента, основанное на заранее выбранных критериях.
В этой формулировке есть продукт, аудитория, проверяемая гипотеза и управленческий результат. До согласования плана ещё нужно определить размер пилота, минимально полезный эффект, ограничения по качеству и необходимую длительность наблюдения.
Я разделил бы четыре вещи:
Уровень | Пример в кейсе |
|---|---|
Цель | Сделать ответы продавца быстрее, не ухудшая качество обслуживания |
Результат поставки | Подсказки доступны пилотной группе, есть ручное подтверждение и отключение функции |
Критерии проверки | Изменение времени ответа, жалоб и исправлений относительно контроля |
Состояние процесса | Возраст заблокированных задач, переносы объёма, готовность ближайших работ |
Для режима подсказок важно измерять время до фактически отправленного ответа, а не только скорость генерации текста. Продавец всё ещё должен открыть чат и подтвердить сообщение. Обещать почти мгновенный ответ покупателю лишь за счёт быстрого LLM API здесь нельзя.
Конверсия диалога в сделку остаётся важным продуктовым показателем. Но сначала нужно определить, какие сделки платформа действительно наблюдает и как связывает их с диалогом. Иначе уверенное название метрики скрывает ненадёжные данные.
Как я доработал бы квартальный план
Дальше — доработка, а не описание того, что уже было посчитано в исходной версии.
Базовым кандидатом на обязательный объём я бы сделал режим подсказок, сохранив исходные три backend, одного frontend и одного QA. Это не утверждение, что такая команда всегда лучше. Здесь мы пока не подтвердили перенос большого объёма backend-работ на QA, поэтому не стоит строить обязательства на этой гипотезе.
Оплата остаётся за пределами квартала. Автономные ответы — отдельная возможность расширения, а не скрытая часть обязательного запуска.
Для базового варианта остаётся дефицит QA: 5 против 4,8. Его нужно закрыть до фиксации обязательств. Например, после декомпозиции может выясниться, что backend способен взять часть подготовки автоматизированных проверок. Но считать нужно эффект, а не намерение помочь.
Допустим, переоценка подтвердила, что дополнительные 0,6 человеко-спринта backend освобождают 0,6 QA, включая необходимые проверки и сопровождение. Только при этом условии новый объём будет 10,6 / 4 / 4,4 при доступных 14,4 / 4,8 / 4,8. Это иллюстрация пересчёта, не новая оценка исходного бэклога.
Если условие не подтверждается, остаются реальные решения: сокращать некритичный объём, согласовывать дополнительную помощь или менять срок. Нельзя просто объявить режим подсказок «минимальным» и считать, что он автоматически поместился.
После баланса по ролям нужен календарный план. Я бы разложил его через результаты и условия перехода:
Период | Проверяемый результат | Что необходимо для следующего шага |
|---|---|---|
Спринт 1 | Согласованы сценарий, границы действий, метрики и первая версия оценок; проверены критичные доступы и контракты | Подтверждены зависимости, доступное время и способ закрытия дефицита QA |
Спринт 2 | На стенде проходит один сквозной сценарий от сообщения до подтверждаемой подсказки | Работают сбор событий, проверки и возврат в обычный чат; это ещё не полный стенд |
Спринт 3 | Внутренняя альфа проходит согласованный набор сценариев | Выполнены требования безопасности, подготовлены пилотная группа и план эксперимента |
Спринт 4 | Начинается ограниченный пилот, если выполнены условия допуска | Нет блокирующих проблем, данные собираются корректно, назначены ответственные за реакцию на инциденты |
Спринт 5 | Продолжается наблюдение, устраняются дефекты, проверяются затраты и качество | Изменения не смешивают разные варианты продукта в одном анализе; расширение допускается по результатам проверки |
Спринт 6 | Стабилизирована пилотная версия и принято решение о следующем этапе | Данных либо достаточно для решения, либо явно зафиксировано, что и сколько ещё нужно наблюдать |
У этой таблицы намеренно нет обещания доказать продуктовый эффект ровно к последнему дню квартала. Нужный объём данных зависит от трафика, распределения основной метрики и минимально полезного эффекта; для конверсии дополнительно важна задержка до сделки. Если эксперимент требует больше времени, это ограничение нужно увидеть до начала пилота.
Таблица вех тоже не доказывает выполнимость сама по себе. Для критичных работ к ней нужна раскладка исполнителей и нагрузки по спринтам. Квартальный запас backend не поможет, если интеграция и помощь с тестами одновременно требуют одного и того же человека на второй неделе.
Здесь же я проверил бы доступность смежников: продуктового эксперта, дизайнера, аналитика, владельцев чата и данных. Если кто-то нужен к конкретной дате, это зависимость плана, а не бесплатный ресурс за рамками команды.
Как связать состав команды с задачами
При распределении людей важно объяснить не только «почему этот человек», но и «что позволит ему закончить работу в срок».
Сильному backend-инженеру можно отдать архитектурные решения и критичные интеграции, но отдельно учесть его время на ревью и помощь коллегам. Frontend-разработчику, которому не хватает продуктового контекста, нужны согласованные пользовательские состояния и критерии приёмки до старта интерфейса. QA должен участвовать в определении сценариев и условий допуска, а не получать весь продукт в последний спринт.
Для человека, склонного глубоко уходить в детали, полезны ограниченный первый результат и ранняя демонстрация: например, один воспроизводимый сценарий на стенде. Большой самостоятельный проект может использовать его сильную сторону, но без промежуточных проверок одновременно усилить риск позднего результата.
Если работа задерживается, я бы сначала выяснял, что изменилось: оценка, требования, доступы, зависимость или сложность реализации. После этого выбирал действие — уменьшить шаг, подключить помощь, убрать блокировку — и назначал ближайшую проверку результата. Одного напоминания «нужно ускориться» для управления планом недостаточно.
Как оценивать полезность запуска
В исходном плане предусмотрены исходные показатели, сравнение групп продавцов и решение по результатам. Доработка нужна в правилах эксперимента.
Сначала я бы зафиксировал основную гипотезу и критерии: что считаем полезным улучшением, какое ухудшение недопустимо и когда прекращаем пилот. Для этого кейса нужны время ответа, использование и редактирование подсказок, жалобы, ошибки в фактах, стоимость обработки и доступность чата. Конверсию в сделку добавляем в решение, если можем надёжно её измерить.
Затем — разделение групп. В качестве единицы распределения я бы рассматривал продавца, чтобы его работа с ассистентом не меняла поведение в собственных контрольных диалогах. В основном анализе нужно сравнивать продавцов по исходно назначенным группам, независимо от того, включили ли они ассистента. Если оставить только добровольно включивших помощника, в эффект продукта попадут различия между более и менее мотивированными пользователями.
Долю включивших ассистента и результаты активных пользователей тоже стоит смотреть, но как отдельные разрезы. Если влияние между группами остаётся существенным, дизайн эксперимента нужно пересмотреть.
И наконец — правила решения. Высокая доля принятых подсказок сама по себе не означает рост продаж. Снижение времени ответа при росте жалоб не означает успешный запуск. Недостаточная выборка не означает отсутствие эффекта. У этих ситуаций должны быть разные следующие действия.
Что можно и нельзя заключить из графиков команды
На исходной доске есть история выполнения спринтов: переносы объёма, выполнение обещанного, достижение целей, скорость и подготовка задач. Она полезна, чтобы поставить под сомнение оптимистичный план, но не объясняет причины отклонений автоматически.
Высокий перенос может быть связан с переоценённой мощностью команды, изменением приоритетов, блокировками или слишком крупными задачами. Нулевой показатель подготовки задач может означать как отсутствие подготовки, так и отсутствие нужных отметок в системе. Это разные проблемы с разными решениями.
Перед выводами я бы проверил определения метрик, качество заполнения и несколько конкретных задач из неудачных спринтов. Потом связал бы находки с планом: например, разбил длинную интеграцию на проверяемые части или закрепил договорённость со смежной командой.
Нельзя механически взять процент выполненного объёма и объявить его коэффициентом полезного времени. Выполнение обещаний зависит в том числе от того, сколько команда обещала и как менялся объём, а не только от её способности работать.
Проверки перед фиксацией плана
После этого разбора я бы проверял квартальный план по семи вопросам:
Какой пользовательский результат обязателен, а что допускается отложить?
Какие оценки и допущения относятся именно к выбранному объёму?
Сходится ли нагрузка по каждой роли после всех замен и передач работ?
Можно ли выполнить зависимости в нужной последовательности и в нужные даты?
Какие отсутствия и риски учтены, где находится резерв и кто решает его использовать?
По каким условиям мы переходим к пилоту, расширяем его или останавливаем?
Какое решение сможем принять по данным к концу квартала, а для какого понадобится больше времени?
Для меня главный вывод — проверять связи после каждого существенного изменения. Сократил сценарий — пересмотри критерии полезности. Заменил человека — пересчитай мощность и зависимости. Передал работу другой роли — уточни трудоёмкость и помощь. Сдвинул пилот — проверь, остаётся ли время на наблюдение.
Хороший квартальный план не устраняет неопределённость. Он делает понятным, на каких предположениях держится обещанный результат и что команда будет менять, если эти предположения не подтвердятся.
