Демо по ходу разработки: что показывать до готовности и как не получить новое ТЗ
Показали заказчику промежуточную версию — и получили двадцать замечаний, половина из которых — новые пожелания. Через пару недель демо уже никто не хочет проводить: «опять расширят задачу».
Промежуточный показ существует для одного: найти расхождение между тем, что строится, и тем, что нужно, пока исправление стоит дёшево. Не для одобрения, не для отчёта о прогрессе и не для сбора новых идей. Когда цель подменяется, демо начинает работать против задачи: собирает пожелания, раздувает объём и через пару итераций становится встречей, которую все хотят отменить.
Что показывать
Тянет показать то, что уже красиво. Полезнее показать то, где выше риск ошибиться.
- Сценарий целиком, а не идеальный кусок. Грубо собранный путь от начала до конца проверяет понимание лучше, чем отполированный первый экран.
- Места, где постановка опиралась на допущения. Демо — лучший момент проверить их на людях, которые знают ответ.
- Исключения, а не только основной поток. «А вот что будет, если склад не ответил» вызывает больше полезных реакций, чем пятый показ удачного пути.
- Данные, похожие на настоящие. На «Тест Тестович» и трёх записях не видно ни длинных названий, ни пустых полей, ни того, что список на тысячу строк нечитаем.
Как подготовить
Хорошее демо готовится вопросами, а не слайдами. До встречи стоит записать два-три вопроса, на которые нужен ответ: «правильно ли мы поняли, что возврат по частям — редкость?», «этих полей достаточно, чтобы оператор принял решение?». Тогда после показа видно, получен ответ или нет.
И стоит заранее сказать, что не готово: оформление, тексты, скорость. Иначе половина времени уйдёт на замечания о том, что и так будет сделано.
Как вести
- Пусть пользователь нажимает сам. Когда показывает разработчик, все видят, как система работает в руках того, кто её знает. Когда кнопку ищет пользователь, видно, как она работает на самом деле.
- Записывайте реакции, а не только слова. Пауза, переспрос, «а где здесь…» — такие же находки, как прямое замечание.
- Не спорьте и не обещайте. Возражение «так написано в постановке» на демо бесполезно, а «сделаем» — опасно: согласие, данное на встрече, потом приходится выполнять.
На демо решений не принимают. Любое «хорошо бы ещё…» записывается и разбирается после встречи. Работает одна фраза: «Записали, разберём и вернёмся с решением до пятницы». Она не отказывает и не обещает — и даёт время понять, что именно попросили.
Разбор замечаний
После демо у аналитика список. Каждое замечание попадает в одну из четырёх корзин, и у каждой свой путь.
| Корзина | Признак | Что делаем |
|---|---|---|
| Расхождение с постановкой | Постановка говорит одно, система делает другое | Дефект в текущей задаче, без обсуждения |
| Ошибка постановки | Сделано как написано, но написано не то | Правка постановки по правилам изменения по ходу |
| Новое пожелание | Раньше этого не было ни в просьбе, ни в потребности | Отдельная задача в очередь, с решением владельца продукта о приоритете |
| Вкус и оформление | «Цвет другой», «кнопку бы левее» | Владельцу продукта; чаще всего — после выпуска, по данным |
Граница между второй и третьей корзиной — та же, что в разборе границ задачи: имеет ли смысл выпустить то, что есть, без этого изменения. Если да — это новая работа.
Результат разбора отправляется участникам демо: что берём в текущую задачу, что выносим и почему. Без этой рассылки участники уходят с уверенностью, что их услышали и всё сделают.
Когда демо вредит
- Слишком рано. Если показывать нечего, воображение зрителей заполняет пустоту — и каждый видит свою систему.
- Слишком часто. Еженедельный показ одного экрана превращает заказчика в дизайнера, а аналитика — в секретаря.
- Не та аудитория. Только руководители, без тех, кто будет работать с системой, — одобрение есть, проверки понимания нет.
Признак, что демо подменило цель: после него задача стала больше, а вопросов к постановке не появилось.
Проверка за пятнадцать минут
Возьмите замечания с последнего демо и разложите по четырём корзинам. Если больше половины — новые пожелания, показывали либо слишком поздно, либо без согласованной границы. Если пусто в первых двух — либо всё действительно верно, либо показывали то, где ошибиться было негде.
Что дальше
Демо ловит расхождения, которые видны глазами. Остальные доходят до тестирования, и там начинается спор, знакомый каждой команде: это дефект, или постановка просто не договорила?