Вы тоже, когда планируете получить результат, рисуете в голове картину того, как он будет выглядеть, и начинаете ждать? В этом случае возможны три варианта развития событий:
1. Ваши ожидания оправдались, получили то, что хотели, – вы довольны.
2. Реальность превзошла ожидания, получили даже больше того, что задумывали – вы удивлены.
3. Ожидания не оправдались, результат не совпадает с нарисованной в голове картиной, – вы разочарованы.
Самый выгодный вариант – первый, когда картина, которую вы себе нарисовали, совпала с реальностью. Почему не второй? Получив больше, будете ли вы уверены, что состояние удивления будет приятным? Поскольку могут возникнуть вопросы: нужно ли оно вам и не придется ли за это доплачивать. Соблюсти баланс между ожиданием и реальностью сложно, но вполне осуществимо. Надо научиться управлять ожиданиями – не только своими, но и окружающих. Как добиться максимально возможного соответствия картины мира пользователей, заказчика и других заинтересованных лиц реальности на примере IT-проекта рассказывает руководитель QA-отдела SimbirSoft Марина Тарасова.
В статье автор разбирает типичный случай из практики, объясняет, какие действия нужно предпринять, чтобы все остались довольны.
Ожидания заказчика
Заказчик обратился за услугой по разработке продукта и озвучивает пожелания: «Необходимо разработать веб-приложение – сайт для поиска любого товара. Пользователь должен иметь возможность найти его, посмотреть, в каком магазине он продается, перейти по ссылке на сторонний сайт этой торговой точки и оформить покупку»
Функциональные требования:
Для поиска использовать API магазина, при его отсутствии – Selenium.
Обеспечить поиск по названию товара.
Предоставить пользователю возможность сортировки выдачи списка по цене.
Показывать наименование товара, цену, его изображение и ссылку на сайте магазина.
Внедрить режим переключения на карту для отображения на карте всех торговых точек, где продается найденный товар.
На первый взгляд, приблизительно понятно, какой продукт хочет заказчик. Можно наметить план работ, провести оценку, согласовать и приступать к аналитике и разработке сайта. Но уверены ли мы, что описывая свои пожелания к продукту, клиент хочет именно этого?
Чтобы понять реальную цель клиента, необходимо задать вопросы:
– Зачем заказчику этот продукт, какова его бизнес-цель?
– Какую проблему он хочет решить и чего достичь с помощью этого веб-приложения?
Давайте вместе порассуждаем, какую бизнес-цель может ставить заказчик, описывая перечисленные выше требования.
Если веб-приложение предполагает использование API магазинов с товарами, можно сделать вывод, что заказчик будет брать определенный процент при покупке товара после перехода по ссылке с его сайта. Можно размещать рекламу с товарами выгодной для магазина категории – это также может быть дополнительным источником дохода. Соответственно, основная бизнес-цель ПО – прибыль. Вы можете сказать, что она всегда ставится при реализации того или иного программного продукта. Да, не спорю. Но она может быть не основной, как в нашем случае, а второстепенной.
Вторая бизнес-цель – обеспечить конкурентное преимущество. Поскольку таких сайтов с поиском достаточно много, нам и заказчику хочется, чтобы приложение охватило как можно больше потребителей. Можно и дальше выдвигать гипотезы, но лучше это обсудить с клиентом напрямую, что мы и сделали.
Чтобы попасть в ожидания, важно помнить о том, какую бизнес-цель ставит заказчик программного продукта и в зависимости от этого выстраивать или корректировать дальнейший план действий.
Ожидания пользователей
Мы задали верные вопросы, узнали ожидания заказчика, но это не гарантирует того, что после выпуска в релиз продукт будет пользоваться популярностью. У любого ПО есть потенциальные потребители. Поэтому наша вторая цель – попасть в ожидания будущих пользователей, которые не совпадают с целями заказчика.
Чтобы понять, чего они хотят, необходимо знать:
Целевую аудиторию продукта (возрастной диапазон, пол и др.), ее интересы и ценности.
Какую проблему пользователь хочет решить с помощью веб-приложения.
Далее надо составить его портрет. Как это можно сделать? Хорошо, если до момента реализации продукта можно пообщаться с ними, выяснить интересы и потребности потенциальных пользователей. Например, если заказчик хочет переписать корпоративное приложение, сделать его более простым и удобным, повысить эффективность работы сотрудников, рекомендуем посетить компанию и вживую понаблюдать за работой будущих пользователей ПО. Представление заказчика и реальность могут не совпадать.
Если такой возможности нет, портрет пользователя придется составлять, исходя из требований, которые описал заказчик, и его-бизнес-целей. Также можно проанализировать аналоги продукта, собрать статистику его потребителей или заказать исследование.
Давайте на примере вышеупомянутых требований опишем потенциальную целевую аудиторию будущего сайта.
Целевая аудитория. В условиях доступности мобильных устройств и интернета почти каждый житель планеты может быть нашим потенциальным пользователем. Но наша цель – охватить наиболее активную аудиторию. Товары ищут и мужчины, и женщины. Это уверенные пользователи ПК и смартфонов. Также нам важна их платежеспособность, исходя из этого, выбираем возрастную категорию – 25-55 лет. Если пользователей с другими критериями заинтересует наше приложение, это будет плюсом, но ориентироваться будем на основную аудиторию.
Причины использования. Для пользователя важно в одном месте быстро, просто и удобно закрыть свою потребность, либо решить проблему. Поэтому если он откроет сайт, введет запрос и быстро получит необходимый список товаров, выберет, что понравилось, сравнит цены и перейдет в магазин для покупки, значит мы смогли помочь ему. Чтобы это получилось, в первую очередь стоит обратить внимание на такие характеристики продукта, как функциональность, производительность (быстрый отклик на запрос) и удобство использования.
Ценности пользователя. Каждого из нас отличает внутреннее и внешнее окружение, которые и формируют наши ценности. Здесь, конечно, сложно учесть все моменты. В нашей ситуации было необходимо взять в расчет интересы пользователя и ценовой диапазон товаров (по акции или премиум-класса).
Чем точнее и конкретнее вы опишете пользователя, какие потребности им движут и какую проблему он хочет решить, тем выше вероятность того, что попадете в его ожидания. Если продукт будет востребован, то и бизнес-цель заказчика будет достигнута.
Ожидания команды
В контексте управления ожиданиями многие думают, что это находится только в зоне ответственности ролей менеджмента (руководителя проекта, тимлида и т.п.), а команда разработки никак не может повлиять. Но это не так!
Разработчик, QA, аналитик и другие роли при подключении на проект всегда должны спрашивать у заинтересованных лиц, чего ждут от них. Нужна ли оценка по задачам, отчет о проделанной работе и в каком формате? Что входит в их зону ответственности? В какой срок нужно выполнить поставленную задачу? Ответы на эти и другие вопросы помогут команде не только узнать ожидания заказчика, но и скорректировать свои, поняв, что предстоит делать и сможет ли она выполнить озвученные задачи.
Наша цель – не только попасть в ожидания заказчика и потребителей, чтобы они остались довольны, но и самим не выгореть. Может случиться так, что специалист хотел получить одно, а от него ждали совершенно иного.
Пример. На проект подключается специалист. Идет этап онбординга, сотрудник со всей ответственностью подошел к процессу, изучает функциональность системы и смежных, с которыми она интегрируется. Проходит месяц и руководитель проекта выходит с обратной связью о том, что специалист не обладает нужными компетенциями и долго погружается в проект. Как итог, его ожидания не оправдались.
Очень важно всегда уточнять сроки выполнения той или иной задачи, если их не сообщили. Даже если временные рамки не установлены, хотя это очень редкий случай, советуем самостоятельно оценить поставленную задачу и согласовать время на ее выполнение. Это поможет специалисту не только улучшить навык планирования, но и узнать ожидания от его работы.
Формирование плана работ
Итак, все нужные вопросы заданы, ответы проанализированы, можно переходить к следующему этапу – формированию списка наиболее важных функций для реализации в первую очередь и тех, которые должны работать всегда. Приоритеты определяем на основе бизнес-целей заказчика и ожиданий пользователей.
Разберем на примере. Исходя из ожиданий наших пользователей (быстро, просто, удобно) и бизнес-целей заказчика (прибыль и конкурентное преимущество), расставим приоритеты. Так как на рынке есть много аналогов, надо понять, насколько наш продукт будет конкурентоспособен. Поэтому для начала советуем реализовать MVP-версию.
Самая важная функциональность – поиск. Без него смысл всего ПО теряется. Он должен быть реализован в первую очередь, иметь определенную функциональность (поиск по частичному совпадению данных, вывод подсказки и т.п.) и быть быстрым. Будем использовать готовые API магазинов, чтобы на данном этапе не тратить много времени.
Вторая по важности функция – отображение товара: наименование, цена, вывод изображения, описание и ссылка на сайт магазина.
Третья – сортировка по цене: покупатель всегда хочет сэкономить.
Четвертым поставим дополнительную фильтрацию. Мы предполагаем реализацию MVP-версии, значит фильтр на первом этапе не должен быть сложным и громоздким. Проанализировав аналогичные магазины и потребности пользователя, можно выявить часто используемые и наиболее важные поля: диапазон цен, категория товаров и расстояние.
На последнее место по приоритетности поставим режим переключения на карту и отображение на ней магазинов, в которых продается найденный товар. При наличии доставки расположение торговой точки может быть менее приоритетным.
Наш предварительный план готов, осталось декомпозировать его на более мелкие задачи и приступить к процессу разработки. Но это не значит, что мы больше не будем задавать вопросы о целях и ожиданиях. При появлении каждой новой фичи всегда необходимо спрашивать, какую цель нужно достичь и какую проблему решить с помощью реализации этой задачи.
Ответы на эти вопросы можно получить напрямую от постановщика задачи или путем внедрения продуктовых метрик и аналитики использования продукта. Советуем фиксировать соотношение задачи и цели, которую она помогает достичь.
Если задача не несет в себе улучшения, не помогает в решении какой-либо проблемы, вы вправе сказать «нет» ее реализации. Главное – грамотно и четко приведите аргументы, почему этого не стоит делать. Заказчик скажет только «спасибо», если благодаря этому удастся сэкономить его деньги.
Коммуникации как инструмент управления ожиданиями
О том, как выстраивать коммуникации на проектах, рассказывали здесь. В этой статье поделимся рекомендациями, как с помощью этого инструмента эффективно управлять ожиданиями.
Не молчать
Главное правило – активно взаимодействовать с командой и заказчиком, избегать долгих пробелов в коммуникациях. Информация должна доноситься постоянно, но ненавязчиво. Лучше сразу договориться о том, какие виды коммуникаций будут использоваться. Например, статус-митинги для контроля процесса разработки, как правило, проводятся ежедневно в определенное время.
Каждый проект может иметь свои особенности работы над задачами. При подключении все специалисты должны ознакомиться с тем, кто ставит задачи, проводит ревью и закрывает их. Это поможет понять, что необходимо делать в том или ином случае, к кому обратиться с вопросом.
Говорить о рисках и учитывать их при оценке задач
Важно озвучивать возможные проблемы или сложности, особенно если они не зависят от вас. Например, при замене одного корпоративного приложения на другое сотрудникам необходимо время, чтобы перестроиться, скорость работы при этом может упасть. За это, как правило, отвечает заказчик, но опытная команда должна подсветить риски и предложить способы их сокращения.
3. Говорить о том, что мы не делаем
При согласовании требований мы всегда описываем то, что будет реализовано, и согласовываем с заказчиком. Также рекомендуем озвучивать то, что не будете делать.
Например, при разработке очень часто используются тестовые серверы, которые предоставляет сама компания-разработчик. По большей части его окружение отличается от промышленного. Это может сказаться на производительности продукта после релиза. Поэтому на промежуточной демонстрации опытный подрядчик должен сообщить об этом заказчику: «Обратите внимание, что система работает не очень быстро. Также будет и в продуктивном окружении. У нас нет технической возможности решить эту проблему, поскольку она не входит в содержание проекта. Вам будет некомфортно работать с этим в будущем, поэтому, пожалуйста, подумайте о назначении ответственного за ее решение в отделе инфраструктуры»
Снижать градус восторга
Каждый из нас хочет получить ожидаемый результат и в запланированные сроки. Но они должны быть реальными. Поэтому необходимо сообщать заказчику о том, какие результаты будут и когда.
Рассмотрим на примере процесса внедрения автоматизации. Когда мы слышим, что процесс будет автоматизирован, в нашей голове появляется картинка, что ручной труд сразу и полностью заменяется роботизированным. Но это ошибочное суждение. Чтобы внедрить автоматизацию на проекте, необходимо провести предварительные мероприятия – подготовить окружение, выбрать инструменты, проанализировать, какие тесты могут быть автоматизированы, а какие нет. Потом идет сам процесс написания тестов, настройка их запуска и сбор отчетности. Все это занимает достаточно много времени. В дальнейшем автотестам нужна постоянная поддержка и актуализация.
Если проект еще в стадии разработки, не стоит полностью исключать ручное тестирование. При принятии решения о внедрении процесса автоматизации на проекте, необходимо проинформировать заказчика о том, что результаты будут, но не сразу.
Избегать общих сравнений без детализации
Чем конкретнее вы опишете требования в задаче, тем точнее она будет реализована и цель будет достигнута.
Например, при постановке задачи «Добавить в форму авторизации возможность авторизации по номеру телефона» возникает множество вопросов: Номер телефона какой страны допустим для ввода? Нужна ли маска для ввода номера? Будет ли приходить какое-то уведомление на телефон после ввода номера в форме? Если да, то это будет смс с кодом или push-уведомление? Хорошо, если эти вопросы будут заданы. Если нет, появляется риск, что задача будет реализована не так, как планировал ее постановщик. Да и время на уточнение требований увеличивает сроки разработки.
Повышать прозрачность работы
Чем прозрачнее работа команды, тем меньше вопросов к ней возникает. Когда заказчик видит, чем занят каждый специалист, это помогает ему не только управлять процессом разработки, но и понять, в каком состоянии находится проект, куда вкладываются его деньги.
Например, задача по реализации требования «Для поиска использовать API магазина, при отсутствии – Selenium» была оценена в 44 часов разработки. Специалист оставил подробный комментарий о том, что именно он делал:
Реализован поиск товаров. Поиск работает при частичном совпадении данных – 4 часа.
Подключение API первого магазина – 10 часов
Подключение API второго магазина – 14 часов
Подключение API третьего магазина – 12 часов
Взаимодействие с командой разработки API третьего магазина для адаптации под параметры приложения – 4 часа
Из такого описания видно, на какие активности и сколько времени ушло. Все понятно и прозрачно.
Регулярно запрашивать обратную связь
Обратная связь – это отличный инструмент, чтобы понять, все ли хорошо на проекте, продолжает ли команда двигаться к цели либо отклонилась от нее и необходимо внести корректировки. На проекте для этого чаще всего используется демонстрация реализованных функций и ретроспектива.
Предположим, что команда реализовала две функциональности – поиск и отображение карточки товара. Далее рекомендуем провести демонстрацию заказчику. Вы покажете то, что сделано (прозрачность вашей работы), зададите вопросы, которые у вас возникли при реализации требований, а заказчик даст обратную связь, так ли он представлял продукт на начальном этапе. На основании полученной информации, можно скорректировать план работ. После показа клиенту можно провести внутреннюю демонстрацию команде, чтобы каждый увидел итоги своей работы и ознакомился с фидбэком заказчика.
Что будет, если не управлять ожиданиями
Есть такие понятия, как риски проекта (возможные события, которые препятствуют достижению целей проекта) и риски продукта (возможное несоответствие системы потребностям пользователей и заинтересованных сторон). Если не управлять ожиданиями, можно столкнуться со всеми возможными рисками:
Неточное определение требований
Неверная реализация задачи, поскольку каждый видит ее по-своему
Проблемы с командой, которые могут привести к конфликтам
Увеличенный срок реализации
Негативные отзывы пользователей, поскольку их ожидания от продукта не оправдались
Финансовые и имиджевые потери со стороны заказчика и компании-разработчика
Наши ожидания и ожидания окружающих могут отличаться. Чтобы встреча с реальностью была менее болезненной – управляйте ими. Вопросы, которые помогут:
Чего ожидает заказчик и его бизнес?
Чего хотят получить пользователи продукта?
Что ждет заказчик от каждого специалиста и команды в целом?
Является ли план работ актуальным и верным?
Вы все еще движетесь к цели или стоит внести корректировки в цель / план?
Принцип «Бритва Оккама» гласит: «Не следует привлекать новые сущности без крайней на то необходимости», Михаил Калашников говорил: «Все нужное – просто, все сложное – не нужно», а у нас в IT любят повторять: «Не надо изобретать велосипед».
А чтобы наши ожидания и ожидания окружающих оправдались и все были довольны, необходимо управлять ожиданиями с помощью простого инструмента – коммуникации!
Больше полезных материалов – в наших каналах:
