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