Что такое бизнес-требования и как с ними (не) бороться
Начало любого проекта — это идея заказчика или владельца продукта, сформулированная в виде бизнес-требований, ТЗ или записок на салфетке. Как был бы прекрасен процесс разработки, если бы важные детали прорабатывались уже на этом этапе!
К сожалению, зачастую эти самые важные детали обычно опускаются. Вместо них мы получаем противоречивые и запутанные описания, приводящие к противоположному от задуманного результату. Попутно образуется коллекция смешных (а иногда и не очень) перлов, которые впоследствии растаскиваются на мемы или становятся частью командного стикерпака.
Обо мне
Меня зовут Евгений Бондарчук, я руководитель команды разработки в Магните. Сегодня я бы хотел обсудить проблему коммуникации между бизнесом и ИТ в части постановки и понимания бизнес-требований, а также предложить решения, которые уже помогли в ряде проектов. Поехали?
Disclaimer: описанное ниже было собрано из разных компаний и проектов, так что все совпадения считать исключительно совпадениями.
Причина проблем, или Лирики vs Физики
Один из самых популярных конфликтов в истории человечества не мог не докатиться и до ИТ. Заказчик что-то хочет, но не может объяснить, что именно. Разработка старается понять пожелания заказчика, но в итоге понимает не то, делает не так и вообще «вы не понимаете, это другое». Где-то рядом бродит печальный менеджер, который пытается всем помочь, но в итоге получает с двух сторон свою порцию лучей добра и позитива и с дичайшим выгоранием отправляется лечить нервы в ближайшем доме с желтыми стенами.
По сути каждая сторона в чем-то права. Но как же тогда сформировать понятные требования, если у всех разное видение проекта?
Решение
Говорите на одном языке с заказчиком
А еще лучше создайте общий глоссарий с правильными названиями объектов, и тогда таблицы на фронте останутся таблицами, не превращаясь при этом в загадочные ящики (для вас) и непонятные гриды (для заказчика).
Создайте шаблон бизнес-требований
Соберите пожелания к формату и структуре требований от всех, кто участвует в процессе разработки: системных аналитиков, разработчиков, QA, сопровождения, РП.
Обсудите полученные предложения от команды с заказчиком, продумайте обязательные и дополнительные ингредиенты идеального бизнес-требования.
Совместно с заказчиком составьте шаблон для бизнес-требований так, чтобы заказчику было удобно его заполнять, а вам — читать и понимать написанное.
Определите цели проекта
Убедитесь что вы правильно поняли «боль», которую надо решить, а заказчик — что именно он получит на выходе. Объяснять можно хоть на кошечках и собачках, главное, чтобы вы нашли взаимопонимание. А дальше поможет глоссарий (я надеюсь, вы его уже используете?).
Только, пожалуйста, не следуйте советам из брошюры Simple Sabotage и не создавайте встречи ради встреч и комиссии по решению вопросов, которые можно было бы решить за пару минут.
Скажите «Нет!» технической реализации в бизнес-требованиях
Да, заказчики бывают с разным техническим бэкграундом, но если в руках молоток, то все начинает казаться гвоздями. А если человек долгое время работал в Битриксе — ничего кроме Битрикса зачастую он предложить не сможет, накладывая ограничения сторонней системы на тот продукт, который вы в итоге планируете сделать. Реальный пример из опыта — могут попросить «Выгрузить весь интернет в Excel».
Зафиксируйте ключевые показатели эффективности проекта
Если бизнес-требования не содержат однозначного способа измерить результаты внедрения проекта, то, скорее всего, у вас большие проблемы: заказчик не знает, как оценить полученный продукт, а команда не понимает реальной пользы проекта.
Внесите обязательность показателей в шаблон бизнес-требований, грабьте, воруйте, но критерии эффективности проекта должны быть зафиксированы.
Вовлекайте заказчика в весь цикл разработки ПО
Казалось бы, классика гибких методологий, но зачастую активная деятельность заказчика заканчивается на фразе: «Вот вам бизнес-требования». К моменту MVP или демо бывает уже трудно до чего-то договориться. Особенно это заметно на длинных проектах, где в ходе разработки может поменяться большая часть состава — как со стороны заказчика, так и со стороны разработки.
Лучшая битва — это та, которая не начиналась, поэтому можно заранее подстелить соломки и уточнить все на берегу.
Секреты шеф-повара, или что должно быть в бизнес-требованиях
Попробуем сформулировать основные разделы бизнес-требований:
Информация о заказчике (ФИО и функция)
Дорабатываемая система (если есть)
Приоритет проекта или доработки
Желаемая дата релиза проекта
Краткое описание цели проекта
Как работает сейчас?
Описание текущего бизнес-процесса
Какие системы задействованы в бизнес-процессе?
Какая информация используется в бизнес-процессе?
Какая информация передается в рамках бизнес-процесса?
Какая информация получается в рамках бизнес-процесса?
Какие текущие проблемы бизнес-процесса?
Как должно работать? (описание желаемых доработок без технических деталей)
Сценарии использования, включая негативные (Use Cases)
Текущие показатели эффективности (метрики)
Ожидаемые показатели эффективности (метрики)
Дополнительные заинтересованные стороны
На кого могут повлиять доработки?
Кому необходимо сообщить о планируемых доработках?
Какие дополнительные функции необходимо привлечь к анализу и разработке?
Ограничения и риски
Противоречие интересам других функций и систем компании
Законодательные риски
Etc, риск-менеджмент отдельная тема, но чем больше мы узнаем на этапе бизнес-требований, тем меньше возможных проблем получим потом
Пример плохих бизнес-требований
Сделайте, чтобы заработало. Вчера.
Еще пример
Happy end*
В качестве завершения хотел бы сказать, что эта статья не ставит перед собой цели придумать «серебряную пулю», которая решит все проблемы взаимодействия между заказчиком и разработкой, но, возможно, поможет наладить коммуникации и структурировать подходы к работе с бизнес-требованиями.
*При написании статьи ни один заказчик, менеджер и разработчик не пострадал)
