От продакта требуется адекватно оценивать загрузку, сложность, сроки решения целого комплекса задач.
Пожалуй, один из самых частых вопросов, который слышит в свой адрес PM: "Когда?" или "Сколько это по срокам?" или "О! А почему так долго?"
И наиболее частая ошибка, которую совершает продакт - когда спускает вопрос оценки непроработанной фичи на уровнень разработчика.
Давайте разберемся, почему это неэффективно, и не вносит ничего, кроме стресса и расшатывания команды между задачами. И как можно сделать по-другому.
Как создать проблему
Вброс фичи на оценку, как правило, происходит очень вдруг, по середине какого-то спринта, по которому сроки и так уже синим пламенем. Функция не обдумана, никакими метриками не померяна, просто интуитивно очень потенциальная.
Логика проста: сначала узнаем, сколько это стоит, и, в заивисимости от бюджета, решим делать или не делать.
Фича описана человеческим языком очень крупными мазками, или вообще представлена в виде ссылки на продукт конкурента с припиской: "Хочу как у них, только лучше. Когда запилите?"
По-хорошему, это задача для бизнес и системного аналитика. Но в цикле живого продукта, как правило, нет места неожиданностям. Что само по себе является проблемой. И переключить аналитиков на изучение фичи прямо означает не сделать того, подо что подписались.
Что обычно со вбросом делают продакты?
- Докидывают задачу на анализ в формате - "факультативно" и ставят сроки, когда аналитик посмотрит, пишут в отчетах, что аналитик поставил в план, сегодня откроет сайт / скачает приложение / начнет читать спецификацию, и прочий, простите, срам. Если коротко, то сливают ответственность на исполнителя.
- Собирают 15-ти минутную рабочую встречу с лидерами направлений, чтобы угадать стоимость реализации фичи. Тратят час и уходят с кучей вопросов на уточнение.
- Скидывают вопрос в чат и всячески сношают техлида.
Во всех выше перечисленных случаях получают результат весьма далекий от реальности без адекватной возможности аргументированно отстоять стоимость реализации перед заказчиком. Сопутствующие отягчающие последствия для каждого участника в связи с тем, что его выдернули из контекста текущей задачи, вообще трудно оценить.
Как решить задачу
В приведенном выше кейсе заказчик попросил дать оценку стоимости разработки какой-то фичи, которую подсмотрел у конкурентов. Запускать какой бы то ни было ресерч - это трата времени.
Мозг разработчика или аналитика требует для принятия решения максимум конкретики, он так работает, поэтому он хорош, когда его используют правильно.
Как можно решить задачу иначе?
Постройте вместе с командой матрицу весов тех или иных фич, не используйте техническую терминологию и непонятные сокращения. Стремитесь к тому, чтобы информация была понятна даже непосвященному.
Например, это может выглядеть следующим образом:
| Размер | UX/UI | Данные | Интеграция |
|---|---|---|---|
| S | 16 | 32 | 64 |
| M | 32 | 64 | 128 |
| L | 64 | 128 | 256 |
| XL | 128 | 256 | 512 |
| XXL | 256 | 512 | 1024 |
Далее:
- Берем наш вброс от заказчика: "Сделайте также, только лучше" и URL, ведущий куда-то: в стор, на сайт в google документ и так далее.
- Понимаем, что требуется Заказчику. Здесь не про фичу, а про то, "чтобы что она ему сдалась?" Фича - это про решение, чаще всего, не самое простое.
- Исходя из понимания потребности и простой реализации, выбираем вес, и отдаем Заказчику. Всегда оцениваем самый черновой вариант - самый простой способ достичь удовлетворения. Оценку сопровождаем понятными человеку пояснениями.
Например, мы понимаем, что Заказчик просит оценить разработку системы отзывов. При уточнении потребности выясняем, что Заказчик хочет понимать, что пользователю нравится, а что нет, отзывы на маркете не показательные для него.
В результате необходима оценка системы рейтингов внутри приложения: какой контент пользователи плюсуют, какой минусуют.
Прикидываем, что для простой версии у нам необходим функционал в приложении, счетчики и возможность выгрузить данные в csv любым способом.
Обращаемся к матрице мер и весов:
- Изменения интерфейса - S (16 часов)
- Внести изменения в БД + счетчики - S (32 часов)
- Доработать обратносовместимо API - S (64 часа)
Итого - категория задачи S - 112 часов.
Важно закладывать в мервы весов и тестирование, и информационное сопровождение, и работы по релизу и выкладке в сторы. Заказчика интересует результат в виде рабочей фичи в приложении, которое установлено у него на телефоне.
Я думаю, что одна из важных задач в роли продакта - это держать заказчика в рамках носителя идеи, фантазии, видения горизонта, понимания проблемы, и ни в коем случае не вынуждать в нем развитие компетенцию способов реализации. Это, очень вероятно, приведет к конфликту и отягощению коммуникаций.
