Как писать функциональные требования
Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.
На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.
Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.
В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.
Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.
В разных компаниях существуют различные подходы к написанию функциональных требований, но в Retail Rocket мы остановились на этом варианте и пока не жалеем.
Функциональные требования: что это такое и зачем они нужны
Для начала давайте разберемся, что такое функциональные требования.
Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.
Функциональные требования, как правило, состоят из:
User story
User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.
Как правило используется шаблон:
Существуют различные примеры применения этой методологии. Например, так это работает в Trello:
В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.
Например, так выглядит задача об отслеживании NPS для интернет-магазина:
Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.
Use cases
Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.
Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.
Если пользователь решает задачу на разрабатываемой странице несколькими путями, то на каждое решение должен быть написан свой use case. Например, если доступ к затрагиваемому функционалу находится на нескольких страницах, нужно написать отдельный use case на каждый способ перехода пользователя к функционалу.
Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.
Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.
Примеры use case’ов:
Почему функциональные требования так важны
Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.
Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.
Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:
Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
А как вы подходите к постановке задач разработчикам?
Как писать требования чтобы их понимали
В этой статье на примерах расскажу о том, как писать и оформлять требования, чтобы их было просто использовать команде разработки и их все-таки дочитывали до конца.
Здесь не будет базовой теории, что есть требование и что оно должно соответствовать SMART (надеюсь, вы это и так знаете). Скорее, я покажу некие best practice, как требования лучше оформлять в документации.
Начнем с обсуждения:
Если тема окажется интересной, то в следующей статье посмотрим на использование более продвинутых инструментов, таких как:
Требования это не роман и удивлять слогом тут никого не нужно. Я еще не раз это повторю в статье, но тот кто читает ваши требования, должен напрягаться по минимуму.
Здесь, как и в дизайне интерфейсов, отлично работает правило: «Не заставляйте меня думать», про которое писал Стив Круг в одноименной книге.
Ниже я привел рекомендации, которые призваны упростить восприятие ваших требований:
По сути, данное требование содержит два отдельных требования:
Такое разделение поможет не пропустить скрытое требование разработчику или QA и подскажет менеджеру, что здесь лучше завести две отдельные задачи.
Используйте средства, которые доступны вам в любом редакторе:
Например, если вы используете союз «и» (или несколько таких союзов), то лучше каждое условие написать с новой строки.
«Необходимо перевести заказ в статус «Доставляется», если заказ оплачен и весь товар есть в наличии на складе.»
Давайте упростим восприятие этого требования. Получим следующее:
«Необходимо перевести заказ в статус «Доставляется», если:
Что мы сделали? Мы сняли часть когнитивной нагрузки с того, кто будет изучать данное требование. Уже из форматирования становится видно, что:
На первый взгляд все это очевидно, но в процессе рабочей деятельности, я постоянно сталкиваюсь с подобными недочетами. Я намерено не пишу «ошибки», так как формально оба требования равнозначны, но на практике, второй вариант воспринимается гораздо проще.
Вы должны не только писать просто, но и оптимизировать свои требования, упрощать их. Этот принцип должен работать во всем. Когда вы пытаетесь передать информацию, она неизменно искажается, а часть ее теряется. И, чем больше передается информации, тем больше ее теряется в процессе передачи.
«Заказ отображается в личном кабинете пользователя, если заказ находится в одном из статусов: «Новый», «Ожидает оплаты», «Оплачен», «Доставляется». Заказ в статусе «Доставлен» не должен отображаться в личном кабинете.»
Как можно его упростить:
«Заказ отображается в личном кабинете пользователя, если его статус не равен «Доставлен» .
Во-первых, мы сделали само требование короче, а значит вероятность, что его прочитают стала выше.
Во-вторых, технические специалисты отлично считывают такие конструкции и вы, опять же, снимаете с них когнитивную нагрузку.
Таблицы позволяют хорошо структурировать информацию и не пропустить важное при изучении требований. Когда я пишу очередной блок требований я всегда задаю себе два вопроса:
Почему таблицы лучше работают:
Рассмотрим пример части из ТЗ на большую государственную систему из открытых источников:
«Успешно авторизованный пользователь, входящий в группу пользователей c ролью «Исполнитель», должен попадать на «UI-006 Главная страница личного кабинета», а пользователь, входящий в группу пользователей с ролью «Наблюдатель» – на «UI-092 Главная страница Мониторинга (дашборд)» подсистемы «Мониторинг». Если пользователь в личном кабинете настроил страницу по умолчанию, то открываемая страница должна определяться на основе выбранной настройки.»
Если прочитать это требование внимательно и сделать пару заметок, то ничего сложного в нем нет, разобраться можно. Но давайте упростим восприятие этого требования, с помощью таблицы. Получим следующее:
«После успешной авторизации в системе, пользователю должна открываться стартовая страница, согласно условиям ниже:»
Если в дальнейшем у нас появится новая роль, то нужно будет всего лишь добавить еще одну строку в таблицу.
Таблицы являются отличным инструментом для описания форм и пользовательских интерфейсов.
Пример формы редактирования из того же ТЗ:
Для описания требований к форме можно использовать таблицу ниже, в которой мы укажем для каждого поля:
Для описания действий на форме (Сохранить и Отмена) лучше использовать отдельную таблицу, так как описания действий и полей формы сильно отличаются.
Нарисованную схему можно дополнитель текстовым описанием для каждого блока и/или процесса. Это работает намного лучше, чем резкий переход к текстовому описанию, так как схемы имеют свойство заинтересовывать, ведь все мы любим рассматривать картинки.
Далее я поделюсь схемами, которые использую чаще всего.
Зачем нужна: Показывает как разрабатываемая система взаимодействует с внешними миром.
Внешний мир может быть представлен: другими ИТ-системами, пользователями или устройствами.
Когда использовать: На этапе проектирования системы, чтобы:
P.S. Еще эту диаграмму очень любят архитекторы.
Я не сторонник строгих правил разработки диаграмм, но стараюсь придерживаться следующих рекомендаций для контекстной диаграммы:
Пример контекстной диаграммы из книги «Разработка требований к программному обеспечению» (Джой Битти, Карл Вигерс):
Зачем нужна: Позволяет зафиксировать описание бизнес-процессов на этапе их дизайна и использовать это «знание» на этапе разработки и внедрения решения.
Когда использовать: Вообще, у BPMN довольно широкий спектр применения.
Качество ваших диаграмм будет зависеть от количества ранее созданных (волшебной пилюли, увы, здесь нет). На начальных этапах советую использовать базовые элементы:
Пример описания бизнес-процесса обработки инцидентов:
Если вам интересна отдельная статья про примеры построения BPMN-диаграмм на реальных примерах, напишите об этом в комментариях.
Зачем нужна: показывает как объект переходит из одного состояния в другое.
Как и схемы в BPMN, диаграмма состояний отлично читается и техническими специалистами, и бизнес-пользователями, и экспертами.
Пример диаграммы состояний для объекта «инцидент» из BPMN-диаграммы выше:
Функциональные и нефункциональные требования: полное руководство
Точно знать, какие функции и возможности клиент хочет от приложения, довольно сложно для команды разработчиков программного обеспечения. Во избежание недоразумений заказчику и команде разработчиков программного обеспечения необходимо определить требования к проекту: как функциональные, так и нефункциональные требования для будущего приложения. В этой статье мы объясним разницу между двумя типами требований и поделимся лучшими практиками их сбора.
Что такое функциональные требования?
При разработке программного обеспечения функциональные требования определяют функции, которые должно выполнять все приложение или только один из его компонентов. Функция состоит из трех шагов: ввод данных — поведение системы — вывод данных. Он может вычислять, манипулировать данными, выполнять бизнес-процессы, устанавливать взаимодействие с пользователем или выполнять любые другие задачи.
Другими словами, функциональное требование — это то, ЧТО приложение должно или не должно делать после ввода некоторых данных.
Функциональные требования важны, поскольку они показывают разработчикам программного обеспечения, как должна вести себя система. Если система не соответствует функциональным требованиям, значит, она не работает должным образом.
Что такое нефункциональные требования?
Нефункциональные требования определяют стандарты производительности и атрибуты качества программного обеспечения, например удобство использования системы, эффективность, безопасность, масштабируемость и т.д.
В то время как функциональные требования определяют, что делает система, нефункциональные требования описывают, КАК система это делает. Например, веб-приложение должно обрабатывать более 15 миллионов пользователей без какого-либо снижения производительности, или веб-сайт не должен загружаться более 3 секунд.
Если приложение не соответствует нефункциональным требованиям, оно продолжает выполнять свои основные функции, однако не сможет обеспечить удобство для пользователя.
Нефункциональные требования важны, поскольку они помогают разработчикам программного обеспечения определять возможности и ограничения системы, которые необходимы для разработки высококачественного программного обеспечения. Следовательно, нефункциональные требования так же важны, как и функциональные требования для успешного внедрения продукта.
Почему важна разница между функциональными и нефункциональными требованиями?
Четко определенные функциональные и нефункциональные требования помогают разработчикам программного обеспечения создавать продукт, точно соответствующий потребностям клиента. Однако действительно ли необходимо знать разницу между функциональными и нефункциональными требованиями?
Основная причина знать разницу между функциональными и нефункциональными требованиями заключается в том, что они определяют объем работ по проекту. Разработчики программного обеспечения должны идти в ногу с этим объемом, чтобы разработать приложение в рамках своих временных рамок и бюджета.
Если объем работ постоянно меняется, команде разработчиков приходится продлевать сроки, и затраты на разработку возрастают. Это может привести к неблагоприятным последствиям для проекта.
Важность различения двух типов требований имеет первостепенное значение при создании MVP. Команда разработчиков и заказчик должны обсудить, какие функции и функции следует реализовать в приложении в первую очередь. Заказчик может иметь собственное видение проекта и его требований. Если заказчик решает удалить или изменить какую-либо функцию, важно понимать, что это за требование. В большинстве случаев разработчики программного обеспечения могут просто изменить нефункциональные требования, в то время как функциональные требования потребуют дополнительной работы и серьезных изменений.
Когда заказчик и поставщик разработки программного обеспечения знают разницу между функциональными и нефункциональными требованиями, это помогает им более точно определять объем работ, более точно ранжировать требования по важности, оптимизировать затраты на проект и лучше удовлетворять потребности заказчика..
Как собираются функциональные и нефункциональные требования?
В идеале, прежде чем обращаться в компанию по разработке программного обеспечения, у клиентов уже должны быть под рукой все функциональные и нефункциональные требования. Поэтому их необходимо подготовить заранее самостоятельно или попросить стороннего поставщика.
Давайте посмотрим, что включает в себя каждый тип требований.
Функциональные требования можно разделить на три группы:
Нефункциональные требования подпадают под различные категории, в том числе:
Примеры и передовой опыт
Существует множество других форматов, которые могут помочь в выполнении требований проекта. Давайте посмотрим на самые эффективные.
Истории пользователей
Обычно требования формулируются в виде пользовательских историй. Пользовательские истории — это требования, предъявляемые пользователем. Обычно они имеют форму нескольких простых предложений, имеющих один и тот же образец:
Как (пользователь) я хочу (цель), чтобы (причина).
Пример пользовательской истории: как руководитель проекта я хочу понимать прогресс команды разработки программного обеспечения, чтобы я мог сообщить о результатах генеральному директору и заинтересованным сторонам проекта.
Разработчики программного обеспечения обычно составляют требования с использованием пользовательских историй, когда они хотят донести идеи о функциях и функциях продукта до участников, не являющихся техническими специалистами.
Сценарии использования
Сценарии использования шире, чем пользовательские истории. Они включают типы пользователей и все возможные действия, которые пользователь может выполнять в приложении. В отличие от пользовательских историй, описывающих конечную цель функции, варианты использования включают последовательность шагов, ведущих к цели.
Например, если вы хотите создать приложение для управления логистикой и цепочкой поставок, разработчики программного обеспечения должны подумать о следующих ролях: продавцы, покупатели, поставщики, менеджеры, диспетчеры и многие другие.
Действия для этих ролей могут выглядеть следующим образом:
Документ со спецификацией требований к программному обеспечению
Спецификация требований к программному обеспечению ( SRS ) — это документ, на который группа разработчиков программного обеспечения полагается при создании приложения. Он включает в себя все потребности и пожелания клиентов, переведенные на понятный для команды разработчиков язык — подробное описание всех функций и возможностей продукта.
Основные разделы, которые обычно включаются в документ SRS:
Создание SRS, пользовательских примеров и пользовательских историй имеет важное значение для эффективной разработки приложений.
Однако есть и другие документы, не менее важные для успешного запуска и развития проекта.
Заключение
С помощью специализированных программных услуг компании могут создавать приложения любого типа для эффективного развития своего бизнеса. Однако для того, чтобы приложение действительно соответствовало потребностям их бизнеса, оно должно иметь подробные функциональные и нефункциональные требования.
Чтобы сформировать функциональные и нефункциональные требования, вы можете обратиться за помощью к своей компании-разработчику программного обеспечения, сторонним компаниям или сделать это самостоятельно. Хорошо продуманные требования гарантируют, что ваш партнер по разработке программного обеспечения будет полностью понимать, как разработать цифровое решение, которое полностью соответствует вашим ожиданиям и удовлетворяет потребности вашего бизнеса.
Составление требований к разработке фичей: Курс «Создание программного продукта и управление его развитием»
Привет, Хабр! Продолжая серию публикаций по продуктовому менеджменту, сегодня мы обсуждаем требования к разработке. В этом посте речь пойдет о том, как продуктовый менеджер взаимодействует с разработчиками из R&D, зачем нужны требования, как правильно их сформулировать, и какие выводы из требований к разработке должны делать различные специалисты, включая самих разработчиков, менеджеров, QA и так далее. С другой стороны будущие и уже состоявшиеся разработчики узнают, что может (и вообще-то должен) предоставлять вам менеджер продукта. Все подробности — под катом.
Оглавление курса
Как читают Feature Description?
Каждая категория пользователей может почерпнуть из требований полезную информацию для себя. И поэтому очень важно иметь в виду, что требования будут читать разные люди:
При составлении документа нужно быть максимально краткими и не оставлять непонятных мест. Requirements в любом случае будут занимать несколько страниц. Его должны прочитать много человек, и нужно, чтобы он был читабельным.
Руководствуйтесь простым правилом: начинайте с главного и только потом добавляйте детали. Кроме этого нужно получить обратную связь от QA, Developers, DevOps и других заинтересованных лиц. Скорее всего, Feature Description обрастет новыми деталями после общения со стейкхолдерами.
Постарайтесь подумать над неочевидными сценариями. Желательно сразу определить, что должно делать ваше приложение в нештатных ситуациях. Подумайте, какие внешние компоненты влияют на вашу фичу. А когда все уже будет готово, еще раз задайтесь вопросом: “Что еще можно протестировать кроме шагов, описанных в пользовательских сценариях?”
Заключение
В следующем материале мы поговорим о бизнес-плане и ценообразовании для нового продукта.
А пока делитесь в комментариях вашим опытом работы с требованиями, как со стороны менеджера, так и исполнителя. Расскажите, был ли в вашей практике пример, когда функциональный заказчик хотел одного, а в итоге получилось совсем другое из-за непонимания?
Лекция про дорожную карту и требования для разработки:
Разговариваете со своими разработчиками на разном языке? Сроки все время едут? Качество продукта оставляет желать лучшего? Пишите в личку, обсудим что с этим можно сделать.
Разработка требований к ПО: общие понятия
Очень часто при внедрениях от клиента можно услышать фразы типа: “А как этого нет. Это же есть в ….. Я думал, что это само собой понятно. Я без этого не смогу нормально работать. Ваша система …..” Ну и дальше в таком роде. Справедливо ли это? Наверное нет. Каждая система (в данном случае я говорю про ERP ) содержит определенный функционал и может в себе не содержать некоторые “фичи” которые есть в других.
И когда начинается разработка или внедрение клиент должен озвучить все свои “хотелки” иначе существует риск, что что-то не будет реализовано и тогда пиши пропало.
Стадия сбора требований как правило предшествует стадии разработки и внедрения. И именно на ней формируется scope проекта.
Что же такое требование? Уровни и типы требований
Вдобавок к этому выделяют еще нефункциональные требования.
Давайте рассмотрим каждый уровень чуть более детальней.
Сплошные линии означают “содержатся в “, а пунктирные – “являются отправной точкой” или “влияют на”
Бизнес-требования (business requirements) описывают, почему организации нужна такая система, то есть цели, которые она планирует достичь с ее помощью. Как правило их высказывают те, кто финансирует проект. Пример бизнес-требования: “Есть необходимость вести учет взаиморасчетов с контрагентами в разрезе договоров”.
Пользовательские требования (user requirements) описывают цели и задачи, которые пользователь должен иметь возможность выполнять с помощью продукта. Они описывают то, что пользователь должен иметь возможность делать с системой. Это по сути user stories и сценарии. Например: “Я как пользователь системы хочу иметь возможность быстро посмотреть остатки конкретного товара на складе и посмотреть историю его перемещений”
Функциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях. Такие требования описывают в форме традиционных утверждений со словами должен или должна. Например – “система должна в момент проведения в системе документов по взаиморасчетам с контрагентами (инвойс, банковская выписка) дать возможность указать договор по которому ведутся взаиморасчеты” или “система должна давать возможность пользователю выбрать место хранения при закупке товара, куда он будет оприходован” или “должна быть возможность указать в карточке сотрудника дату его рождения и система за 2 дня до его наступления должна высылать директору по персоналу об этом уведомление”.
Как правило бизнес-требования и функциональные требования ложаться в основу технического задания на разработку ПО.
Нефункциональные требования это чёткие критерии того, как система должна работать, в отличие от функциональных, которые описывают, что система должна делать. Давайте посмотрим на пример.
“API метод должен возвращать список ресторанов в короткой форме: id, название, адрес”
Это функциональное требование, оно описывает поведение системы.
“API метод должен отдавать данные не более чем за 200ms на 95 перцентиле и не более чем за 500ms на 99 перцентиле.”
А это уже нефункциональное требование, которое описывает определённый атрибут качества – performance.
Разработка и управление требованиями
Область разработки технических условий разделяется на разработку требований и управление требованиями. И начинается все с выявления требований.
Выявление и сбор требований (elecitation)
Этот этап включает в себя все действия, связанные с выявлением требований, таких как интервью, совещания, анализ документов, создание прототипов и другие. К ключевым действиям относятся:
Анализ требований
Этот этап подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде. Основными действиями на этом этапе будут:
Документирование
Представление и хранение знаний о требованиях определенным способом. Например в письменные требования, диаграмы пригодные для дальнейшего использования.
Утверждение требований
На этом этапе подтвержается правильность имеющегося набора требований, которые позволят реализовать решение, удовлетворяющее бизнес-целям.
Нельзя создать идеальные требования. Если смотреть с практической точки зрения, то цель разработки требований – накопить общее понимание требований необходимое для разработки очередной порции продукта.
Управление требованиями
Это процесс, включающий идентификацию, выявление, документирование, анализ, отслеживание, приоритезацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего проекта разработки программного обеспечения.
Цель управления требованиями состоит в том, чтобы гарантировать, что организация документирует, проверяет и удовлетворяет потребности и ожидания её клиентов и внутренних или внешних заинтересованных лиц. Управление требованиями начинается с выявления и анализа целей и ограничений клиента. Управление требованиями, далее, включает поддержку требований, интеграцию требований и организацию работы с требованиями и сопутствующей информацией, поставляющейся вместе с требованиями.
Установленная таким образом отслеживаемость требований используется для того, чтобы уведомлять заинтересованных участников об их выполнении, с точки зрения их соответствия, законченности, охвата и последовательности. Отслеживаемость также поддерживает управление изменениями как часть управления требованиями, так как она способствует пониманию того, как изменения воздействуют на требования или связанные с ними элементы, и облегчает внесение этих изменений.
Управление требованиями включает общение между проектной командой и заинтересованными лицами с целью корректировки требований на протяжении всего проекта. Постоянное общение всех участников проекта важно для того, чтобы ни один класс требований не доминировал над другими. Например, при разработке программного обеспечения для внутреннего использования у бизнеса могут быть столь сильные потребности, что он может проигнорировать требования пользователей, или полагать, что созданные сценарии использования покроют также и пользовательские требования.
Основные проблемы при работе с требованиями
Выявление требований непростой процесс. Проблему усугубляет то, что заказчик может говорить о чем угодно, но только не о том, что ему действительно нужно. Основное следствие проблем с требованиями – переделка того, что вы думаете что уже готово (на это расходуется от 30 до 50% общего бюджета разработки). С ростом объема переделок растет и растрата ресурсов и разочарования.
Создание более качественных требований это инвестиции, а не затраты.
Недостаточное вовлечение пользователей
Заказчики зачастую не понимают всю важность этапа сбора требований и обеспечения их качества. Это влечет за собой обнаружение ошибок в требованиях на поздних стадиях проекта ну и соответственно к задержке завершения проекта.
Еще существует риск того, что бизнес-аналитик может не понять и неправильно задокументировать бизнес-требования или потребности клиента. Иногда бизнес-аналитик может идти по пути определения “идеальных” бизнес-требований, которые реализуют разработчики. Но потом этим решением не пользуются.
Небрежное планирование
Неопределенные, плохо понятые требования порождают слишком оптимистические оценки, которые возвращаются и не дают нам покоя, когда возникает перерасход.
“Разрастание” требований пользователей
В процессе разработки требований scope проекта может разрастаться невиданными темпами и соответственно это увеличивает бюджет проекта и его сроки завершения. Менеджер проекта должен предусмотреть “буферы планирования”. Если на проекте применяются гибкие методологии его ведения, то новые требования помещаются в резерв (беклог). Такие изменения могут быть важны, но они всегда имеют свою цену.
Двусмысленные требования
Признаком этого может быть то, что одно и тоже требование может пониматься по разному. Следствием этого является наличие разных ожиданий и удивление полученному результату.
Разработчики в процессе разработки могут добавлять функции, которые отсутствуют в спецификации и это может привести к проблемам. Задача команды реализующих требования – четко соблюдать требования спецификации, а не своевольничать.
Противоречивые требования
Бывает, что какие-то конкретные два или более требования противоречат друг другу. Иногда “совсем”, что никак нельзя совместить. Иногда всё-таки можно предусмотреть “разные режимы”, в каждом из которых одно требование удовлетворяется, а другое при этом оказывается недоступно. Или решить какую-то из задач другим способом — тогда противоречие исчезнет.
Чтобы продвинуться в сторону решения, нужно начать разматывать цепочку “для чего / почему”. По каждому из требований (как было описано в первой части статьи). То есть мы должны понять как можно глубже, из чего возникли именно такие требования, и что люди, пришедшие с этими требованиями, хотят “на самом деле”.
Выводы
Работа с требованиями может иногда казаться излишней и такой которая не повышает рентабельность проекта. Многие живут в реальности, что самое главное – это разработка и разработчики это самые нужные люди в компании (наверное поэтому у них такие большие зарплаты), но кому нужна разработка если она никому не нужна. Если неправильно сформирован scope проекта и возникают постоянные переработки, то кому от этого будет хорошо даже если за весь этот банкет платит заказчик. Та что тут говорить, если во многих компаниях даже нет такой позиции как бизнес-аналитик, его роль совмещает в себе проджект менеджер или разработчик.
Инвестиция в качественный сбор и оформление требований может принести следующие выгоды: