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