Написание технического задания — один из первых этапов работы над проектом. Он предваряет разработку самой системы. В техническом задании мы описываем предметную область, существующую инфраструктуру Заказчика, требования к создаваемому функционалу, а также нефункциональные требования. Получившийся документ необходим как бизнес-пользователю для того, чтобы он убедился в том, что все его пожелания к будущей системе учтены, так и нам, чтобы оценить стоимость разработки системы.
Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document).
Однако здесь, чтобы не усложнять описание, мы будем использовать именно термин «Техническое задание». Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.
Главным фактором успеха при разработке технического задания является правильно выстроенная коммуникация с заказчиком. Ведь задача аналитиков состоит в том чтобы фактически произвести операцию brain-dump, и результаты расположить на бумаге в структурированном виде. При этом очень важно (1) разговаривать с заказчиком на одном языке, чтобы тому не приходилось разжевывать очевидные для специалиста понятия предметной области и (2) уметь правильно слушать.
Приведем ниже принципы, которыми мы руководствуемся при написании технического задания, и проиллюстрируем их выдержками из разработанного нами технического задания на многокомпонентную систему баннерной рекламы для крупной Интернет-компании.
Структура технического задания
Каждое техническое задание содержит несколько обязательных разделов. В них определяется назначение документа, терминология, общий контекст проекта. Обычно первая часть документа выглядит так:
1. Оглавление
2. История изменений документа
3. Участники проекта
4. Назначение документа
5. Терминология
6. Общий контекст
Если в начале документа даётся общая, концептуальная информация о разрабатываемой системе, то во второй, основной части документа, детально прописываются бизнес-требования и существенные для оценки стоимости разработки функциональные требования к системе.
В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.п, а в разделе «Общий контекст» — описываем основные бизнес-процессы компании-заказчика, относящиеся к размещению баннерной рекламы, а также — системное окружение, текущие роли менеджеров компании и права доступа. Стоит отметить, что в данном конкретном случае система строилась не на пустом месте. Ранее менеджеры компании использовали другую, отличную от нашей, систему размещения баннерной рекламы. В противном случае — анализ ролей и прав доступа был бы скорее всего вынесен в отдельную главу.
7. Система размещения баннеров
8. Взаимодействие с биллингом
9. Banner Engine
10. Техническое описание компонента Banner Engine
Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами. Учитывая специфику данного проекта, мы посвятили отдельный раздел взаимодействию баннерки с биллинговой системой. Также в отдельный раздел мы выделили требования к достаточно независимой компоненте сбора и отображения статистической информации, которая является для заказчиков рекламных кампаний и менеджеров рекламных агентств едва ли не основным компонентом системы.
Отдельный раздел технического задания описывает требования к компоненту Banner Engine, отвечающему за показ баннеров, учёт статистики, её обработку и сохранение в виде, пригодном для дальнейшего анализа и построения отчетов.
Это – технически самый сложный и самый высоконагруженный компонент баннерной системы. В ТЗ мы включили раздел, содержащий некоторые технические и архитектурные детали, связанные с работой Banner Engine. Прежде всего, это позволяет минимизировать риски при оценке стоимости разработки системы, ведь в зависимости от выбранной архитектуры трудоемкость может отличаться в разы.
Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.
Бизнес vs Функциональные требования
В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:
— Бизнес-требования представляют собой описание того, ЧТО должна делать система на языке бизнес-пользователя. Бизнес-требования, в частности должны быть понятны руководителю, не имеющему технической подготовки и опыта.
— Функциональные требования представляют собой описание того, КАК те или иные действия осуществляются в системе. На этапе разработки технического задания функциональные требования обычно фиксируются только для наиболее сложных блоков проекта. Углубление в сложные зоны позволяет снизить риски при последующей оценке проекта. Обычно функциональные требования включают блок-схемы, диаграммы состояний, потоковые диаграммы, и дополняются макетами наиболее сложных экранов.
«Для рекламной кампании важно максимально точно отслеживать лимит показов, чтобы избежать финансовых потерь, связанных с показом баннеров сверх оплаченного лимита. Помимо этого, возникает задача ограничить показ одного баннера одному пользователю, например — не больше N раз в день».
Пример функционального требования:
«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».
Обычно мы включаем
Техническое задание содержит описание ролей и основных пользовательских сценариев в разрабатываемой системе.
В случае с системой баннерной рекламы, мы выделим такой сценарий как создание рекламного места пользователем в роли Администратор.
Название сценария: Создание рекламного места
Пример функционального требования:
«После добавления новой площадки в системе, администратор должен создать связанные с ней рекламные места. При создании рекламного места должны указываться площадка, тип места, поддерживаемый формат баннеров, размер, частота показов (для статических мест). После создания рекламного места оно становится доступным для менеджеров, размещающих рекламу.
Каждое созданное рекламное место получает универсальный идентификатор, который используется системой управления сайтом в запросе на показ баннеров. Для этого требуется внести соответствующие изменения в код страницы сайта».
Техническое задание содержит требования к интеграции разрабатываемой системы с другими внешними и внутренними системами, используемыми заказчиком.
В контексте технического задания на баннерную систему, это – интеграция с системами управления сайтом компании, биллинга, аутентификации и хранения данных пользователей.
«Система баннерной рекламы связана с тремя внешними модулями, функционирующими в окружении компании: системой управления сайтом компании, системой биллинга и системой аутентификации и хранения данных пользователей». Каждый показ баннера сопровождается запросом от системы управления сайтом к баннерной системе. Эти системы, кроме того, используют общие идентификаторы площадок и рекламных мест, а также согласованные имена параметров таргетирования».
В техническое задание мы обычно включаем глоссарий , разъясняющий значения специальных терминов, используемых в документе. Очень важно точно определить значение терминов, которые в дальнейшем используются в документе.
« Размещение (единица размещения, строка медиаплана) – это сущность, объединяющая баннер, который необходимо показывать, рекламное место, на котором будет показан баннер, а также правила показа. Правила показа определяют период размещения, параметры таргетирования, лимиты размещения, веса и т.п. Фактически, все рекламные кампании состоят из размещений».
Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.
Основные принципы
При написании ТЗ мы стараемся максимально использовать графические материалы для наглядного и сжатого представления информации. Одна диаграмма зачастую в состоянии заменить несколько страниц текста. В данном контексте, мы видим своей целью т.н. рисование ТЗ, т.е. представление всех более-менее сложных фрагментов системы в графическом виде и использование текста в качестве комментариев к графическим материалам.
У руководителей предприятий обычно нет времени на изучение многостраничных технических требований. Просмотр изображений даёт наглядное представление об основных характеристиках разрабатываемой системы. Как следствие, улучшается коммуникация между бизнес-пользователем и нами и растет качество самих требований.
Cледующая схема, иллюстрирующая структуру рекламных кампаний и взаимосвязь между основными понятиями в рамках рекламных кампаний, сэкономила нам несколько страниц текста.
По необходимости, мы используем в ТЗ прототипы избранных экранов системы (functional wireframes), которые, не являясь окончательными, демонстрируют базовый блок функциональности пользовательского интерфейса.
Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.
Прототипы, уже на стадии разработки, дают заказчику понять, как именно будет выглядеть интерфейс системы.
Требования должны быть написаны «живым человеческим» языком, понятным бизнес-пользователю в т.ч. руководителю высшего звена, не обладающему техническими навыками; в них должен содержаться минимум технической терминологии. Чем быстрее пользователь «вникнет» в содержания технического задания, тем более эффективно будет выстраиваться наше с ним общение.
Опыт в предметной области
Большое значение при создании технического задания имеет опыт разработки похожих систем. Он помогает быстрее вникать в бизнес-процессы и потребности заказчика, делать «по аналогии» многие вещи, которые ранее казались бы нам сложными.
Накопленный опыт в области управленческих бизнес-систем, крупных интернет-проектов, финансовых систем, e-commerce систем позволяет нам применять свои знания в отношении каждого последующего проекта, которым мы занимаемся. До того, как получить заказ на систему баннерной рекламы, упомянутую выше, мы уже занимались разработкой нескольких баннерных систем. Мы хорошо знали, как работают баннерки, знали характерную терминологию этой предметной области. На основании нашего опыта работы с другими баннерными системами, мы предложили заказчику довольно много упрощений, оригинальных решений, не только в сфере технологий, но и бизнеса.
Источник: www.gramant.ru
Функциональные и бизнес-требования, что это и как собрать для техзадания на разработку сайта
До составления техзадания заказчик должен определить, какие задачи нужно заложить в основу проекта, какие способы взаимодействия с посетителями являются приоритетными, как сайт будет выглядеть. Речь идет о функциональных и бизнес-требованиях, позволяющих оценить стоимость, сроки и бюджет, необходимые для разработки. Чем четче условия, тем меньше будет доработок: рассказываем, как собрать требования, на что нужно обращать внимание в первую очередь.
Функциональные требования
Эта группа отражает принцип работы системы при взаимодействии с пользователями. Например, можно отобразить процесс регистрации, добавление товара в корзину и последующую покупку, подписку на новостную рассылку. Функционал – это логика работы и набор основных возможностей.
Если клиент заказывает создание интернет-магазина, то у разработчика появляются вопросы по поводу функционала: будет ли реализован личный кабинет, какие способы оплаты нужно подключить, доступность партнерских программ и т. д. Отдельным блоком идут нефункциональные возможности (с основным видимым функционалом не связаны):
- производительность. Определяет скорость взаимодействия: время реакции на действие или загрузку страниц;
- удобство для посетителей. Это интуитивно понятное меню, время, необходимое для поиска информации, иное;
- безопасность. Защита персональных данных пользователей – превыше всего, также важны устойчивость ко взломам, хакерским и вирусным атакам;
- адаптивность. Сайт должен корректно отображаться во всех браузерах и с любых типов устройств (планшеты, смартфоны, персональные компьютеры);
- география работы. Для компаний, ведущих сотрудничество с зарубежными клиентами, требуется перевод контента на иностранный язык, а также добавление других валют и т. д.
Нефункциональные требования затрагивают визуальную составляющую сайта, такую как картинки, дополнительные эффекты, шрифты и другие компоненты, отвечающие за внешний вид и удобство при взаимодействии.
Понять, что такое функциональные и нефункциональные требования, можно через пример. Функциональные – это классическая телега с местом для посадки и лошадьми, нефункциональные – внешний дизайн автомобиля, дополненный лампочками, табличками. Многие потребители переплачивают за лапочки и значки, например, эмблему Mercedes, но в это же время хотят, чтобы механизмы работали исправно. Примерно такой же принцип лежит в основе сайта: функциональность – содержимое, остающееся невидимым для пользователя, нефункциональные требования – внешняя оболочка.
Бизнес-требования
Касаются бизнес-составляющей, необходимы для определения ключевых коммерческих задач. Эти требования, что отличает их от функциональных, понятны владельцу компании, который не разбирается в технических особенностях разработки. К бизнес-требованиям относятся:
- сведения о компании: название, дата основания, направление деятельности, преимущества и отличия от конкурентов, айдентика;
- информация о целевой аудитории. Нужно определить, кто будет посещать сайт и выполнять целевые действия. Учитываются ключевые особенности: географические (место проживания, тип населенного пункта), социальные (возраст, пол, образование, семейное положение), психологические (боли, потребности). Разработчик должен понять, почему люди будут посещать сайт: покупка и выбор товара, получение расчета дизайн-проекта или прочтение свежих новостей;
- основные цели сайта: высокие продажи, информирование о компании, увеличение узнаваемости, прочие.
Любую задачу можно решить с привлечением нескольких способов, главное – правильная расстановка акцентов. Если компания хочет повысить продажи, то в приоритете – конверсионные элементы, желает подтвердить статус – фирменный стиль, комфорт и эргономичность.
Почему требования важны, какие задачи они решают
Наличие четких требований упрощает взаимодействие в цепочке клиент – команда разработчика – понимание технического задания. Они позволяют достигать следующие цели:
- предупреждение большого количества доработок;
- сокращение срока разработки;
- экономия не только времени, но и бюджета. Заказчик сокращает расходы за счет эффективного планирования. Непонятные требования влекут за собой размытые финансовые цели, а также увеличивают чек проекта;
- своевременное выявление ошибок, повышающее качество готового сайта и сокращающее затраты на его создание;
- возможность предвидеть результат. Разработчик определяет, что работает в правильном направлении. Заказчик выставляет условия, подрядчик – соблюдает их, что предупреждает «полет фантазии» и выход за рамки.
После завершения разработки сайт будет таким, каким его хотел видеть клиент. Он имеет возможность оценивать его по готовому набору критериев, а разработчик сможет защитить свои права, если возникнут дополнительные пожелания, не зафиксированные в техническом задании.
Кто осуществляет сбор данных
Сбор требований – ответственность заказчика, ведь именно он понимает, каким хочет видеть готовый проект. Кроме него никто не сможет определить, какие функции и визуальные элементы необходимы. Функциональные требования собирают IT-отдел и маркетологи подрядчика, а также другие специалисты, которые помогают сделать главную страницу конверсионной и дающей ответы на все текущие вопросы потенциальных клиентов.
Если компания подрядчика маленькая и не располагает маркетологами, аналитиками и другими специалистами, то лучше обратиться в стороннее агентство. Представители последнего выполнят конкурентное исследование и подготовят digital-стратегию, но лучше искать подрядчика, который работает по системе «все включено» – от анализа аудитории до разработки сайта.
Иногда заказчики занимаются сбором требований совместно с маркетологом, однако логика работы – задача клиента, этот вопрос не решить деньгами. До сбора требований необходимо:
- изучить сайта конкурентов;
- проанализировать собственный бизнес.
Данные изучает и разработчик, и клиент, последний на этапе сбора функциональных требований понимает, каким будет сайт, каково расположение элементов и какие процессы будут осуществляться. Если необходимо обращаться к сторонним специалистам, то проще привлечь маркетолога или аналитика на аутсорсе, что дешевле в отличие от приема сотрудника в штат. Заказчик должен предоставить данные о компании, продукте, клиентах и задачах, которые должен решать проект. Потребуются базовые маркетинговые навыки, которые можно получить как на краткосрочных курсах, так и после прочтения тематических статей.
Методы сбора требований
Для сбора требований привлекаются следующие методы:
- бриф на разработку, который заполняет заказчик;
- личное интервьюирование;
- работа с документацией – от брендбука до инструкций для продуктов;
- постоянное присутствие представителя компании-заказчика, коммуницирующего с командой подрядчика;
- общие совещания и мозговые штурмы.
На базе собранных требований формируется отдельный документ, ложащийся в основу технического задания. Он имеет форму брифа, лишен технической информации, разбит на разделы:
- бизнес-требования, определяющие цели проекта и задачи сайта;
- дизайнерские особенности: шрифты, цветовые решения, стилистика, совпадающие с фирменным стилем компании-заказчика;
- требования, выдвигаемые пользователями сайта (речь идет о правах доступа). Фиксируются сведения о том, какие данные смогут видеть, редактировать и добавлять разные группы пользователей. Например, бухгалтер видит счета и отчеты, менеджер по продажам – заказы, контент-менеджер – разделы для оформления страниц;
- требования посетителей, формируется визуализация пути CJM.
Функциональные требования составляют во время работы над проектом, заказчик может указать пример понравившегося сайта или описать возможности своими словами. В процессе беседы менеджер фиксирует все и выделяет главное, потом – составляет документ, который согласовывает заказчик, после чего он переходит на следующий этап разработки.
Еще один способ – заполнение брифа, где представлены распространенные вопросы и есть место для развернутых ответов клиента. Если собранной информации недостаточно, то будут подключены менеджер и программист, обеспечивающие получение дополнительных данных. Может оказаться, что клиенту нужен не сайт, а страница в социальных сетях.
Например, мастеру маникюра подходит локальная группа во ВКонтакте, а не многостраничник. Многие клиенты не слишком разговорчивые, другие – не могут сформулировать цели, поэтому полнота техзадания зависит от профессионализма команды разработчика. На этом этапе для сайтов, которые будут продвигаться в поисковых системах, формируется семантическое ядро: оно влияет на структуру и обеспечивает соответствие требованиям поисковиков.
Какие ошибки стоит предупредить, собирая требования
Требования должны быть корректными и емкими, лишенными сложных и непонятных формулировок. Чрезмерное погружение в детали может запутать разработчика, рассмотрим на примере:
- «Форма регистрации – красивая и удобная» – неправильно, «Форма регистрации содержит 2 поля: для имени и номера телефона, можно выбрать регистрацию через социальные сети Одноклассники или ВКонтакте» – правильно;
- «Хочется, чтобы все страницы загружались очень быстро» – неверно, «Время загрузки страницы – не более 2 секунд» – верно.
Окончательных требований не может быть: некоторые приходится постоянно тестировать, выбирая лучшие форматы. Нередко все не удается учесть сразу, например, менеджер не выполнил анализ других сайтов или не оценил специфику бизнеса – причины, влекущие за собой сложности. Некоторые моменты могут остаться упущенными: процессы и требования оговорены, а о бухгалтере, который будет просматривать отчеты, забыли. В этом случае создается дополнительное соглашение на доработку.
В заключение
Сбор функциональных и бизнес-требований выполняется до формирования технического задания на разработку, что позволяет определить четкие сроки и правильно рассчитать бюджет. Такой подход предупреждает разногласия между клиентом и подрядчиком, важна конкретизация требований, зафиксированных в техническом задании. Чем последнее точнее, тем меньше доработок потребуется в ходе реализации проекта. Заказчик должен принимать непосредственное участие – именно он лучше всех понимает специфику бизнеса и формирует концепцию финишного результата. Если подрядчик занимается только разработкой, то помощь в области маркетинговых и аналитических исследований лучше получить в стороннем агентстве или у специалистов на аутсорсинге.
Источник: vebrost.ru
BRD. Как написать идеальный документ
Исчерпывающая документация бизнес-требований четко определяет проект. Если документ составлен правильно, он сделает за проектную команду много тяжелой работы: будет управлять ожиданиями, устанавливать стандарты, отмечать достижения и обеспечивать успех.
Ниже приведены основные элементы, которые необходимо включить в документ бизнес-требований, а также лучшие практики, ограничения и соображения по объему.
Ключевые элементы документа бизнес-требований
Перед нами 10 элементов, которые необходимо включить в документ бизнес-требований и которые помогут обеспечить успех вашей команды.
Версионирование
Набор бизнес-требований — это живой организм. Он создается до начала проекта и может часто меняться и редактироваться, когда все остальное уже готово.
Поскольку на документ будут ссылаться снова и снова, важно, чтобы все изменения были отмечены в пределах разумного. Если изменились требования или даты, запишите это; если вы исправили опечатку, оставьте это без внимания.
Краткое изложение
Несмотря на то, что резюме обычно появляется первым в документе бизнес-требований, его рекомендуется писать последним. Это формулировка высокого уровня, которая должна описывать требования проекта и подводить итог остальной части документа.
Цели проекта
Изложите цели и задачи проекта, подробно описывая, что будет достигнуто в результате работы. Если проект поддерживает бизнес-процессы или потоки, это должно быть описано здесь.
Цели всегда должны соответствовать SMART: быть конкретными, измеримыми, достижимыми, реалистичными и ограниченными по времени.
Формулировка потребностей
Описание потребностей должно быть убедительным. Это — основной смысл проекта. Воспринимайте формулировку потребностей как обоснование, которое должно убедить заинтересованных лиц в правильности идеи и придать мотивацию команде проекта.
Объем проекта
Подробное описание объема проекта поможет установить границы выполняемой работы. В зависимости от вашего проекта, целей, команды и обстановки, иногда бывает проще определить элементы или модули, которые не будут обновляться или включаться в рамки проекта, вместо того, чтобы определять абсолютно все требования.
Стейкхолдеры
Необходимо определить все заинтересованные стороны, включая их должности. Полезно перечислить их должности в соответствующих организациях, а также их роли и обязанности, относящиеся к текущему проекту.
Финансовый отчет и анализ экономической эффективности
Финансовую информацию, включенную в документ бизнес-требований, не следует рассматривать как бюджет, она призвана показать влияние проекта на баланс компании.
Здесь должны быть указаны источники финансирования, но не забывайте, что любое лицо или организация, вносящие свой вклад, также могут считаться заинтересованными сторонами и должны быть включены в оба раздела.
График, сроки и основные этапы
В зависимости от масштаба проекта информация о графике, сроках и основных этапах может быть объединена в один раздел или выделена в отдельный. Важно четко определить ожидания и сроки, обязательно указав точки принятия решений, а также моменты, когда работа должна быть завершена.
Отслеживайте все действия, включая сроки подписания результатов проекта, привлечения внешних поставщиков и установки оборудования.
Для долгосрочных проектов определение четких этапов дает идеальную возможность для промежуточного выставления счетов, чтобы можно было расплатиться с поставщиками и подрядчиками.
Функциональные требования
Функциональные требования составляют основную часть хорошего документа с бизнес-требованиями. Чем подробнее требования, тем лучше результат.
Обязательно используйте четкий, лаконичный язык без жаргона или сленга. Избегайте аббревиатур, даже если они кажутся общепринятыми. По возможности добавляйте визуальные элементы, такие как скриншоты, прототипы и макеты. Отличная идея — сравнить текущее состояние с будущим, когда меняются бизнес-процессы или рабочие процессы.
Там, где это имеет смысл, разбивайте большие разделы на более мелкие и доступные части. А если требования носят опциональный характер или зависят от других зависимостей, разбейте их на обязательные, необходимые и «будет приятным бонусом».
Нефункциональные требования
Задокументируйте в этом разделе любые требования к отчетности, аналитике и интеграции. Помните, что некоторые виды деятельности, например, проверка безопасности, могут потребовать пересмотра других разделов документа с бизнес-требованиями, поэтому необходимо предусмотреть в бюджете соответствующее время.
Лучшие практики работы с документацией по бизнес-требованиям
Существует ряд лучших практик, которые могут гарантировать успех вашей документации и проекта в целом. Вот 8 из них, которые следует учитывать при планировании проекта.
- Получите вклад и перспективы. Представьте документ бизнес-требований на экспертную оценку.
- Установите разумные сроки. Дважды и трижды проверьте даты и сроки, чтобы убедиться, что они достижимы: лучше завысить оценку и выполнить работу раньше, чем срывать сроки.
- Предусмотрите время для исследований. Если необходимо привлечь подрядчиков или поставщиков, убедитесь, что время и затраты на это включены. Если исследование необходимого поставщика или стороннего продукта является частью проекта, определите это как риск, который необходимо снизить в случае, если подходящее решение не будет найдено, займет больше времени, чем ожидалось, или превысит бюджетные ассигнования.
- Помните о нормативных требованиях. Не забудьте учесть все нормативные и законодательные акты, которые могут повлиять на проект.
- Подробно опишите необходимые технологии. Включите подробную информацию об инструментах и технологиях, которые будут использоваться и применяться.
- Запланируйте постоянную поддержку. Если ваш проект потребует постоянного обслуживания и поддержки после внедрения, укажите план поддержки, перечислите мероприятия и лиц, которые будут задействованы.
- Оставьте время для документации. Помните, что документирование должно быть частью любого проекта. Необходимо включить мероприятия, отведя время на подготовку документации и учебных материалов.
- Будьте гибкими. Будьте открыты для определения и изменения функциональных требований, но помните о том, что изменения могут повлиять на другие виды деятельности, временные рамки или сроки.
Ограничения документов бизнес-требований
Несмотря на то, что документы бизнес-требований являются источником истины и надежным советником для проекта, они имеют свои ограничения. Вот некоторые из ограничений, связанных с рамками документа, и как их обойти.
- Не всегда нужно знать, как что-то делается. Функциональные требования должны отвечать на вопросы «что» и «почему», но не «как». Хотя это различие может показаться тонким, знание того, как разработчик выполнит ту или иную задачу, выходит за рамки этих документов.
- Не оставляйте вопросы без ответа. Документы бизнес-требований всегда должны отвечать на вопросы, а не задавать их. Если есть вопросы, которые нужно задать, или неизвестные, которые нужно исследовать, сделайте это во время создания документа, а затем включите в него результаты.
- Включите всю предысторию и детали. Каждый документ бизнес-требований должен быть самостоятельным. Предположите, что все, кто его читает, понятия не имеют о том, что происходило в прошлых проектах. Если есть детали, которые необходимо включить для контекста, включите их, но убедитесь, что они уместны и необходимы.
- Планируйте задержки. Хотя немногие документы по бизнес-требованиям включают раздел по снижению рисков, целесообразно найти способы определения областей, где сроки или деятельность могут быть нарушены и каким образом. Эмпирическим правилом является добавление 20-процентного буфера времени для управления неопределенностью, но корректируйте его по мере необходимости и необходимости.
Документация вдохновляет на командную работу
Если документация составлена и оформлена тщательно и продуманно, она способствует укреплению доверия и прозрачности между проектными группами и другими сотрудниками. Улучшается коммуникация, уменьшается количество ошибок, снижается или устраняется двусмысленность и неопределенность, а результаты могут быть практически гарантированы.
Также по теме:
- Пост на вечную тему, который должен написать каждый
- SLA — это «живой» документ
- Идеальный (IDEal) работник и консультант
- Документы и практика
- Разработка и эксплуатация
Источник: cleverics.ru
