Привет, Хабр! На связи команда Рунити. Мы решили разобраться, каким должно быть хорошее бизнес-требование, чтобы разработка понимала задачу, менеджер мог контролировать результат, а заказчик получал нужную функциональность.
«Нужно сделать удобно», «должно работать быстро», «сделаем примерно как сейчас, только лучше». Знакомые формулировки? Для менеджера задача может выглядеть понятной, а разработчик после такого описания вынужден выяснять, что именно требуется реализовать, какие сценарии предусмотреть и как проверить результат.
Иногда команда добросовестно выполняет требования, выпускает функциональность, а заказчик остается недоволен. Причем проблема может обнаружиться уже после релиза, когда исправления требуют дополнительных ресурсов.
Посмотрим на требования с двух точек зрения: тех, кто формулирует задачи, и тех, кому предстоит их реализовывать. Разберем реальные примеры из облачной разработки, типичные ошибки в описании бизнес-требований и вопросы, которые лучше закрыть до старта работ.
Для этого поговорили с тремя экспертами наших компаний. В роли заказчиков:
-
Александр Фикс — директор по продуктам Рег.облака;
-
Александр Бабий — директор по развитию цифровых продуктов Рег.ру.
Со стороны разработки:
-
Роман Доморацкий — руководитель разработки облачной платформы Рег.облака.
Навигация по тексту
1. Начните с проблемы, которую нужно решить
2. Избегайте двусмысленных формулировок
3. Разделяйте технический и бизнесовый результаты
4. Учитывайте ошибки и границы релиза
5. Не проектируйте решение за разработчиков
6. Сохраняйте фокус на сути требований
7. Найдите скрытые ограничения
8. Обсуждайте требования с командой
Чек-лист: что проверить перед передачей бизнес-требований в разработку
1. Начните с проблемы, которую нужно решить
Представим задачу: заказчик хочет добавить мониторинг баз данных. Можно сразу составить список метрик, описать интерфейс и передать требования разработчикам. Но сначала хорошо бы разобраться, зачем именно заказчику новый мониторинг.
Возможно, он хочет поддерживать SLA пользователей. А может, ему нужно повысить наблюдаемость инфраструктуры. Или своевременно обнаруживать проблемы, которые часто приводят к простою. От ответа зависит, какую функциональность нужно реализовать.
Так, одно из главных правил при подготовки бизнес-требования — объяснить, зачем и для кого создается фича. Хорошее требование должно содержать User Story, цитаты заказчика, описание его проблемы и сценарии использования. Важно выяснить, как решают задачу сейчас, почему нынешние инструменты не устраивают и какого результата ожидают.
Дело в том, что иногда при погружении выясняется, что первоначальный запрос не соответствует реальной потребности. Проблему можно решить быстрее и проще другим способом.
Разберем пример из практики Рег.облака.
При работе с PostgreSQL накопление WAL-файлов может привести к нехватке дискового пространства и ошибкам в работе базы данных. Общий мониторинг загрузки диска при этом не всегда позволяет определить, сколько места занимают WAL-файлы и с чем связан рост их объема.
Вместо запроса на добавление конкретных метрик можно описать саму задачу:
«Помочь заказчику вовремя замечать рост WAL-файлов, находить его причины и предотвращать заполнение диска».
Уже после этого команда поможет выбрать подходящие инструменты:
-
отслеживать объем WAL-файлов и скорость их роста;
-
показывать состояние replication slots и задержку репликации;
-
отправлять уведомления при достижении критических значений;
-
прогнозировать, когда закончится место на диске.
Запускать все четыре функции сразу необязательно. Возможно, заказчику хватит мониторинга WAL-файлов и уведомлений. Остальные сущности можно добавить, если появится такая необходимость.
Как отличить бизнес-требование от технического решения
2. Избавьтесь от формулировок, которые можно понять по-разному
«Я хочу, чтобы было классно» — это не требование. Как и формулировки вроде «добавить необходимые возможности», «предусмотреть все сценарии» или «обеспечить корректную работу системы». В реальности такие тезисы мало помогают разработчикам: каждый участник команды понимает их по-своему. В итоге менеджер ожидает один результат, разработчик реализует другой, а тестировщик не знает, по каким критериям проверять задачу.
Чтобы избежать разночтений, описывайте конкретные действия, условия и ожидаемый результат. Если требование можно понять двумя способами, уточните его до начала разработки.
Рассмотрим пример из практики Рег.облака.
В облаке действует почасовая оплата по модели pay-as-you-go. При этом расчетная стоимость услуги за месяц зависит от количества календарных дней, а технические ограничения на число знаков после запятой влияют на округление. Если не прописать правила вычислений заранее, итоговая сумма может отличаться от ожидаемой.
Чтобы команда одинаково понимала логику работы системы, каждый сценарий стоит описывать через три вопроса:
-
кто или что действует? Пользователь либо сервис;
-
при каких условиях? Например, в каком состоянии находится система;
-
что должно произойти? Какой результат ожидается после выполнения действия.
Так разработчики получат понятные условия для реализации, а тестировщики смогут подготовить тест-кейсы и проверить, правильно ли работает функциональность.
3. Разделяйте технический и бизнесовый результаты
Допустим, разработчики выполнили задачу, тестировщики не нашли ошибок, а новую функцию выпустили в продакшен. Но бизнес-показатели остались прежними. Значит ли это, что команда плохо справилась с работой? Вовсе нет.
Техническая готовность и бизнесовый успех — разные результаты. Команда может реализовать функциональность в полном соответствии с требованиями, но это не гарантирует, что продуктовая гипотеза подтвердится.
Поэтому в требовании стоит заранее зафиксировать:
-
критерии приемки: что должна делать новая функция и как проверить ее работу;
-
бизнес-цель: какую проблему планируем решить;
-
целевые показатели: какие метрики должны измениться после релиза;
-
защитные метрики: какие показатели не должны ухудшиться из-за обновления.
Если разработчики выполнили критерии приемки, техническую часть задачи можно считать завершенной. Но если бизнес-показатели не изменились, стоит выяснить почему. Возможно, пользователи редко обращаются к новой функции, она не решает исходную проблему или охватывает слишком небольшую аудиторию.
По результатам анализа команда сможет решить, что делать дальше: доработать функциональность, изменить пользовательский сценарий или пересмотреть продуктовую гипотезу.
4. Продумайте негативные сценарии и обозначьте границы релиза
В бизнес-требовании часто подробно описывают успешные сценарии: пользователь выполняет действие, система обрабатывает запрос и возвращает ожидаемый результат. Но что, если на одном из этапов возникнет ошибка?
Например, в облачной платформе создание услуги состоит из нескольких шагов. Даже если пользователь правильно заполнил форму и отправил запрос, операция может завершиться неудачно из-за проблем с инфраструктурой или внешними системами.
Поэтому еще до разработки стоит ответить на несколько вопросов.
-
Что произойдет, если у пользователя отрицательный баланс? Система отклонит запрос или предложит пополнить счет?
-
Как обработать нехватку инфраструктурных ресурсов? Пользователь получит сообщение об ошибке или сможет повторить попытку позже?
-
Что делать, если вендор не отвечает? Как система сообщит о сбое и что произойдет с незавершенной операцией?
Ситуации выше называют негативными и граничными сценариями. Для каждого нужно определить, как поведет себя система, что увидит пользователь и сможет ли он продолжить работу.
Если не продумать обработку ошибок заранее, разработчикам придется принимать решения уже в процессе реализации. А это может потребовать дополнительных согласований, увеличить объем работ и сдвинуть сроки релиза.
Что происходит, когда сценарий идет не по плану
5. Не пытайтесь спроектировать техническое решение за разработчиков
Иногда заказчик приходит с готовым решением: предлагает использовать конкретный сервис, добавить API или изменить архитектуру. Но выбранный подход может оказаться слишком дорогим, сложным в поддержке или небезопасным.
Разберем пример из практики Рег.облака.
Одному из заказчиков требовалось автоматизировать обмен данными между двумя системами. Информация раз в сутки приходила по электронной почте, после чего менеджер обрабатывал ее вручную.
Заказчик предложил реализовать роут в знакомом ему бэкенд-сервисе. Однако такой подход потребовал бы серьезных доработок и создавал риски безопасности. При этом задача была гораздо проще: избавить менеджера от ручной обработки и наладить автоматическую синхронизацию данных.
Поэтому в требовании стоит описывать, что должна делать система, а выбор способа реализации обсуждать с разработчиками. Для этого достаточно зафиксировать:
-
задачу — какую операцию нужно автоматизировать или улучшить;
-
ожидаемое поведение — как система должна работать с точки зрения пользователя;
-
ограничения — какие условия нужно учесть при выборе решения.
К ограничениям относятся, например, бюджет, сроки, требования 152-ФЗ, а также критичные показатели производительности, доступности и безопасности.
Конкретные API, структуру базы данных и архитектуру лучше прорабатывать вместе с технической командой. Разработчики смогут сравнить варианты, оценить трудозатраты и выбрать подход, который не создаст лишних проблем при дальнейшей поддержке продукта.
6. Сохраняйте фокус на цели и сути требований
Чем подробнее описана задача, тем проще разработчикам? Не всегда. Если собрать в одном документе бизнес-цели, пользовательские сценарии, архитектурные схемы, макеты и технические спецификации, команде придется тратить время на поиск информации.
При этом слишком короткие бизнес-требования тоже могут создать проблемы. Например, если менеджер ограничится описанием новой функции, но забудет указать ограничения и ожидаемый результат, разработчикам придется самостоятельно выяснять детали.
Чтобы не перегружать документ, оставьте в нем основные сведения:
-
Бизнес-контекст: какую проблему решаем и для кого.
-
Цель и результат: чего хотим добиться после запуска.
-
Пользовательские сценарии: как должна работать новая функция.
-
Ограничения и зависимости: что может повлиять на разработку.
-
Открытые вопросы: какие детали еще предстоит уточнить.
Какие сведения включать в бизнес-требования, а какие выносить в отдельные документы
Макеты, архитектурные схемы и подробные технические спецификации лучше хранить отдельно, добавив на них ссылки. Так специалисты смогут быстро найти нужные материалы, а основной документ останется удобным для чтения и обновления.
Не стоит и одинаково подробно описывать все будущие изменения. Для ближайшего релиза нужны конкретные требования, по которым команда сможет оценить объем работ. Для следующих этапов достаточно обозначить планы и ключевые ограничения. Иначе есть риск потратить время на проектирование функций, которые к моменту разработки успеют измениться.
7. Найдите неизвестные и скрытые ограничения
Даже если документы выглядят подробными, в них могут остаться пробелы. Например, команда начинает разработку, а через месяц выясняется, что новая функция должна работать с дополнительной legacy-системой или выдерживать гораздо большую нагрузку, чем предполагалось. Приходится пересматривать архитектуру, заново оценивать трудозатраты и переносить сроки.
Иногда о недостающей информации известно заранее. Допустим, проект зависит от формата данных внешнего партнера, но спецификацию еще не прислали. Без нее разработчики не могут завершить техническое проектирование.
Чтобы такие вопросы не тормозили работу, фиксируйте:
-
Что пока неизвестно: например, формат данных или ограничения стороннего сервиса.
-
На что это влияет: можно ли оценить задачу и приступить к разработке.
-
Кто отвечает за уточнение: какой специалист должен получить недостающие сведения.
-
Когда нужен ответ: к какому сроку информация должна появиться.
-
Что делать при задержке: какие работы можно продолжить, а какие придется отложить.
Но есть и менее очевидные риски. Заказчик может не упомянуть важное условие, поскольку считает его само собой разумеющимся. Поэтому до старта работ полезно провести Discovery: поговорить с пользователями, изучить существующие процессы и проверить предположения, на которых строится задача.
Закрывать каждый вопрос заранее необязательно. В первую очередь разберитесь с теми, от которых зависят архитектура, стоимость и сроки проекта.
8. Обсуждайте требования с командой, прежде чем передавать их в работу
Даже подробные бизнес-требования могут вызвать вопросы у разработчиков. Например, менеджер согласовал с заказчиком новую функцию, но не обсудил ее с технической командой. Уже после постановки задачи выясняется, что для запуска нужно изменить несколько связанных сервисов. Первоначальная оценка оказывается неверной, а сроки приходится пересматривать.
Чтобы избежать таких ситуаций, подключайте специалистов еще на этапе обсуждения идеи. Разработчики помогут оценить сложность задачи, дизайнеры — продумать взаимодействие с интерфейсом, а тестировщики — найти спорные моменты в пользовательских сценариях. Так команда сможет обсудить возможные решения до начала работ.
При этом важно не ограничиваться одной встречей. Например, если в ходе разработки решили изменить поведение функции, новую договоренность нужно сразу внести в БТ. Иначе часть специалистов продолжит работать по старой версии, а остальные будут ориентироваться на обсуждение в чате.
Перед передачей задачи полезно спросить разработчиков, какой информации им не хватает и какие детали стоит уточнить. У разных команд могут быть свои требования к постановке задач, поэтому лучше согласовать удобный порядок работы заранее. А после старта — следить, чтобы принятые решения попадали в документацию и были доступны всем участникам проекта.
Чек-лист: что проверить перед передачей бизнес-требований в разработку
-
Цель понятна. Описано, какую проблему заказчика решаем, для кого создаем функциональность и почему существующие инструменты не подходят.
-
Пользовательские сценарии определены. Понятно, кто действует, при каких условиях и какое поведение системы ожидается.
-
Результат можно проверить. Зафиксированы критерии приемки, целевые показатели и защитные метрики.
-
Границы релиза согласованы. Команда понимает, что реализует сейчас, а какие возможности оставляет на следующие этапы.
-
Негативные сценарии учтены. Рассмотрены ошибки, ограничения ресурсов, сбои внешних систем и другие критичные случаи.
-
Технические ограничения известны. Выявлены зависимости и нефункциональные требования, которые могут повлиять на архитектуру, стоимость или сроки.
-
Открытые вопросы зафиксированы. У критичных неизвестных есть ответственные и сроки принятия решений.
-
Команда участвовала в обсуждении. Разработчики, дизайнеры и другие специалисты могли уточнить требования до старта работ.
-
Договоренности актуальны. Последние изменения отражены в документации, доступной всем участникам.
А какие формулировки в бизнес-требованиях больше всего раздражают вас? Делитесь в комментариях.
Источник: habr.com