Сбор требований – процесс определения и документирования потребностей заинтересованных сторон проекта для достижения целей проекта. На успех проекта напрямую влияет тщательность сбора и управления требованиями к проекту и продукту.
Требования включают в себя количественно определенные и задокументированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон проекта. Данные требования должны быть выявлены, проанализированы и зарегистрированы с достаточной степенью детализации так, чтобы их можно было измерить после начала исполнения проекта.
Сбор требований представляет собой определение ожиданий заказчика и управление ими. Требования становятся базой для ИСР. Планирование стоимости, расписания и качества строится на основе этих требований. Разработка требований начинается с анализа информации, содержащейся в Уставе проекта (раздел 4.1.3.1) и в Реестре заинтересованных сторон проекта (раздел 10.1.3.1).
Многие организации разделяют требования на категории «требования к проекту» и «требования к продукту». Требования к проекту могут включать в себя бизнес-требования, требования к управлению проектом, требования к доставке и т. д. Требования к продукту могут содержать информацию о технических требованиях, требованиях к безопасности, производительности и т. д. На рис.
СБОР ТРЕБОВАНИЙ У ЗАКАЗЧИКОВ ПО: ошибки, проблемы, решения | Василиса Акашева — LivreCon 2019
5-2 показаны входы, инструменты и методы и выходы процесса сбора требований, а на рис. 5-3 представлена общая схема основных связей и взаимодействий в рамках данного процесса. 
Рис.5-3. Блок-схема данных при сборе требований
5.1.1 Сбор требований: входы
.1 Устав проекта Устав проекта используется для предоставления требований к проекту высокого уровня и описания продукта высокого уровня, позволяющих разработать подробные требования к продукту. Устав проекта описан в разделе 4.1. .2 Реестр заинтересованных сторон проекта Реестр заинтересованных сторон проекта используется для определения заинтересованных сторон проекта, которые могут предоставить подробную информацию о требованиях к проекту и продукту. Реестр заинтересованных сторон проекта описан в разделе 10.1.
5.1.2 Сбор требований: инструменты и методы
.1 Интервью Интервью представляют собой формальный или неформальный способ получения информации от заинтересованных сторон проекта путем непосредственного общения с ними. Обычно в ходе интервью задают подготовленные и неподготовленные вопросы и записывают ответы.
Интервью часто проводятся «один на один», но иногда в них могут участвовать несколько интервьюеров и/или интервьюируемых. Проведение интервью с опытными участниками проекта, заинтересованными сторонами проекта или экспертами по отдельным вопросам может помочь в выявлении и определении характеристик и функций желаемых результатов проекта.
Project Management: составление требований проекта
.2 Фокус-группы Фокус-группы позволяют собрать вместе заранее выбранные заинтересованные стороны проекта и экспертов по отдельным вопросам, чтобы они изложили свои ожидания и отношения к предложенному продукту, услуге или результату. Подготовленный ведущий управляет группой во время многостороннего обсуждения, которое является более свободным по форме, чем интервью «один на один».
.3 Семинары с участием модератора Семинары для определения требований представляют собой собрания по конкретным вопросам, в которых участвуют заинтересованные стороны проекта разного профиля для определения требований к продукту. Семинары используются в качестве основного метода, позволяющего быстро определить требования различного профиля и урегулировать различия между требованиями заинтересованных сторон проекта.
В силу особенностей формата групповой работы, хорошо проведенные собрания с участием модератора помогают развить доверие, выстроить отношения и наладить общение между участниками, что может привести к повышению уровня согласия между заинтересованными сторонами проекта. Другое преимущество данного метода состоит в том, что проблемы могут быть обнаружены и разрешены гораздо быстрее, чем при встречах один на один.
Например, в области разработки программного обеспечения используются семинары с участием модератора под названием «Совместная разработка (или проектирование) приложений» (Joint Application Development (or Design), JAD). Такие собрания с участием модератора направлены на предоставление пользователям возможности встретиться с командой разработчиков для улучшения процесса разработки программного продукта.
В производственных отраслях существует «Развертывание функции качества» (Quality Function Deployment, QFD) – это еще один пример семинара с участием модератора, который помогает определить критически важные характеристики для продвижения нового продукта. QFD начинается со сбора потребностей заказчика, что также называется «мнением заказчика» (Voice of the Customer, VOC).
Затем эти потребности объективно сортируются, и между ними расставляются приоритеты, а также устанавливаются цели для их достижения. .4 Групповые творческие методы Для выявления требований к проекту и продукту могут организовываться различные групповые мероприятия. Ниже представлено несколько групповых творческих методов: • Мозговой штурм.
Метод, применяемый для генерации и сбора разнообразных идей, связанных с требованиями к проекту и продукту. • Метод номинальных групп. В данном методе к мозговому штурму добавляется процесс голосования, используемый для ранжирования наиболее полезных идей для будущего мозгового штурма или расстановки приоритетов. • Метод Дельфи.
Выбранная группа экспертов отвечает на вопросы анкет, а также высказывает мнение относительно ответов, полученных в течение каждого раунда сбора требований. Для обеспечения анонимности доступ к ответам имеет только координатор. • Составление интеллект-карт.
Идеи, возникшие во время отдельных сессий мозгового штурма, объединяются в единой интеллект-карте с целью отражения сходства и различия в понимании и формирования новых идей. • Диаграмма сходства. Данный метод позволяет рассортировать по группам большое количество идей для их обзора и анализа.
.5 Методы группового принятия решения Групповое принятие решений – это процесс оценки различных альтернатив с ожидаемыми результатами в форме разрешения будущих действий. Данные методы могут быть использованы для создания, классификации требований к продукту и расстановки приоритетов между ними.
Существует множество методов принятия группового решения, например: • Единогласие. Все соглашаются с определенным направлением действий. • Большинство голосов. Поддержка со стороны более 50 % членов группы. • Относительное большинство голосов. Выбирается решение самого многочисленного блока в группе, даже если не достигнуто большинство голосов. • Диктатура.
Один человек принимает решение за всю группу. Практически любой из описанных выше методов принятия решений может быть применен в групповых методах, используемых в процессе сбора требований. .6 Анкеты и опросы Анкеты и опросы представляют собой наборы вопросов в письменной форме, предназначенные для быстрого получения информации от большого числа респондентов.
Опросы и/или анкеты лучше всего подходят для работы с широкими аудиториями, когда требуется быстрый сбор информации, и где допускается применение статистического анализа. .7 Наблюдения Наблюдения дают возможность непосредственного наблюдения за людьми в их окружении, за тем, как они выполняют свою работу или задания и осуществляют процессы.
Наблюдения особенно полезны для детализированных процессов, когда люди, пользующиеся продуктом, не могут или не желают озвучивать свои требования. Наблюдение, также называемое «наблюдение за работой», обычно осуществляется внешним наблюдателем, следящим за тем, как пользователь выполняет свою работу.
Также оно может осуществляться «наблюдателем-участником», который фактически осуществляет процесс или процедуру, чтобы узнать, как они выполняются, и выявить скрытые требования. .8 Прототипы Создание прототипов представляет собой метод раннего получения обратной связи по требованиям путем создания рабочей модели ожидаемого продукта до его фактического производства. Некоторые прототипы являются материальными, что позволяет заинтересованным сторонам проекта экспериментировать с моделью своего конечного продукта, а не только беседовать об абстрактных представлениях своих требований. Прототипы поддерживают концепцию последовательной разработки, потому что они используются в итеративных циклах создания экспериментальных моделей, проведения экспериментов пользователем, подготовки обратной связи и пересмотра прототипа. После проведения достаточного числа циклов обратной связи, требования, полученные с помощью прототипа, оказываются в достаточной мере полными для перехода к фазе разработки или создания.
Источник: studfile.net
Как правильно составить задание на разработку и каким оно должно быть
Допустим, у вас есть свой бизнес и вы успешно дошли до фазы «Нам нужен сайт» или даже «Нам нужно автоматизировать важный бизнес-процесс». Вы даже нашли ребят, которые с удовольствием готовы реализовать любые смелые затеи, но есть один нюанс: команда разработки просит сформулировать задание на проект (обычно это называется «Дайте-нам-ТЗ»). И с этого момента 99% заказчиков начинают делать и писать совсем не то, что просит подрядчик.
В этой статье мы расскажем, как самостоятельно составить действительно полезный документ, который поможет понять задачу, а не наоборот.
Что такое техническое задание (и почему на самом деле вам нужно не оно)
Для начала пора бы разобраться в терминологии: в процессе разработки проекта мы постоянно пишем какие-то документы, у всех них разное назначение и пишутся они для разных участков проекта и разной аудитории.
На старте проекта команде важно понять бизнес-задачу:
- каким бизнес-целям должен служить разрабатываемый продукт?
- какие задачи продукт должен решить?
- кто и в каких ситуациях будет пользоваться продуктом?
- какие есть ограничения в части реализации?
- какие конкуренты у бизнеса и у продукта?
Заказчик же, пытаясь донести суть задания до команды разработки, привык оперировать одним емким понятием — техническое задание.
Что есть ТЗ?
Это документ, на основании которого команда разработки реализует проект, и который описывает:
- назначение системы, которую надо разработать;
- перечень функций и алгоритмов, которые должны быть реализованы в рамках проекта;
- требования к интерфейсам;
- требования к интеграциям (включая техническое описание API или любого другого формата обмена данными, который предполагается использовать);
- требования к архитектуре системы;
- бизнес-процессы;
- пользовательские сценарии;
- методологию разработки;
- технологический стек (какие технологии будут использованы и почему);
- и много чего еще.
То есть ТЗ содержит исчерпывающие знания о назначении системы, функциональности и методах реализации и отвечает на вопросы:
- Какие компоненты включает система и как они будут взаимодействовать?
- Какие функции и алгоритмы нужно разработать, как именно и при помощи какого стека технологий?
- Как должен вести себя интерфейс
Очевидно, что разработка такой документации требует, во-первых, специализированных знаний (поэтому ТЗ пишут, как правило, системный аналитик или ведущий разработчик), во-вторых, понимания бизнес-целей и задач.
Вывод: на старте проекта нам нужно не ТЗ, описывающее, как делать систему, а документ, отвечающий на вопрос «Зачем и для кого мы делаем эту систему?»
Как сформулировать бизнес-требования
Документ, описывающий бизнес-цели и бизнес-требования к системе, называется Business Requirements Document, или BRD, или бизнес-и-функциональные требования к системе.
Составить такой документ можно самостоятельно, если следовать определенным алгоритмам.
Рассмотрим на примере: у клиента есть некий бизнес и ощущение (возможно, подкрепленное статистикой), что бизнес начал или продолжает стагнировать.
Бизнес: магазин виниловых пластинок, представленный в Москве несколькими точками оффлайн-продаж.
Проблематика с точки зрения владельца бизнеса: коллекционеры винила не имеют возможности регулярно посещать магазин, мониторить новинки и оперативно заказывать интересующие товары, а поскольку бизнес не автоматизирован — все предзаказы делаются только по телефону, что неудобно и бизнесу, и покупателю.
В итоге магазин упускает потенциальную прибыль, увеличивает нагрузку на продавцов и консультантов, имеет скудное представление о портрете своего покупателя и не может коммуницировать с аудиторией в объеме, необходимом для выстраивания дальнейшей маркетинговой стратегии. Плюс на складе постоянно оказываются какие-то неучтенные остатки, что искажает статистику товарооборота.
Решение: разработать интернет-магазин, в котором покупатель сможет посмотреть весь каталог, сделать предзаказ и отследить его исполнение, а продавец — обеспечить своевременное исполнение заказа, получить отчет о состоянии склада, по пути сняв статистику о пользовательских интересах и пользовательском поведении.
Итак, у нас есть понимание бизнес-проблемы и ее решения. Тут важно не начать писать ТЗ, а все же написать Бизнес-требования (невзирая на творческий зуд, стимулирующий к написанию детального задания на разработку).
Начинаем документ с пункта «Бизнес-цель». Наши бизнес-цели следующие:
- Увеличить оборот товара на складе.
- Собрать данные о целевой аудитории для дальнейшего использования в разработке маркетинговых стратегий.
- Снизить нагрузку на персонал магазинов за счет автоматизированности функций заказа / оплаты / доставки.
- Увеличить процент повторных продаж.
Если понятны цели — становятся ясны и задачи проекта:
- Обеспечить функции предзаказа товаров, оплаты и доставки.
- Настроить систему сбора статистики по продажам.
- Настроить систему учета остатков на складах.
- Обеспечить функции возврата покупателей.
Промежуточный результат: сформулирован перечень задач, где каждая задача привязана к определенной (или нескольким) целям.
Теперь уточняем, что должна уметь делать система, чтобы каждая задача в разрезе каждой цели была успешно решена. То есть фиксируем основные функции системы.
На выходе должна получиться вот такая матрица
Теперь команде разработки понятно, зачем заказчику нужен интернет-магазин, какими базовыми функциями он должен обладать и по каким параметрам будет оцениваться успешность проекта.
Но обычно интернет-магазины не эффективны, если у них нет интерфейса.
А как же требования к дизайну?
Формулируя эти требования, многие скатываются в формат «я хочу / мне нравится», проецируя таким образом личное чувство прекрасного на систему, которая в первую очередь должна быть функциональной и удобной.
Важно понимать, что дизайн — не изобразительное искусство, в отношении которого каждый имеет право на мнение «нравится / не нравится», а интерфейс — не просто какая-то интерактивная картинка, раскрашенная в разные цвета.
Интерфейс (экраны, страницы) — это как раз тот набор элементов (картинки, тексты, кнопки, галочки, интерактивные формы и т.д.), при помощи которого пользователи будут взаимодействовать с вашей системой. И требования к нему должны быть обоснованы функциональным назначением системы и сценариями использования.
Чтобы нарисовать качественный дизайн, нужно понимать, каким целям он будет служить (на эти вопросы отвечает BRD), какой контент будет публиковаться, какие есть технические ограничения по реализации и поддержке.
Требования к интерфейсу
Скажем сразу — ничто так не радует сердце UI/UX-проектировщиков и дизайнеров интерфейсов, как референсы. То есть примеры уже реализованных похожих проектов.
Референсы просят не потому, что каждый творец в душе плагиатор и хочет облегчить себе жизнь, а потому, что восприятие у всех разное и трактовать формулировки вида «хочется чего-то травянисто-зеленого и вызывающего ощущение летнего пикника на даче у бабушки» в разрезе конкретной задачи на дизайн — заведомо игра в гадание на гороскопах, потеря смысла задания и времени.
Добавить же в BRD ссылку на уже работающий проект — явно проще, чем детально описать каждую страницу, рискуя быть неправильно понятым.
Вывод: команде будет намного проще понять задачу по дизайну, если в ее описании присутствует:
- Описание пожеланий в сочетании с описанием реальных возможностей заказчика (например: «у нас есть отличные фото продукции в высоком качестве, поэтому хотелось бы использовать это в дизайне»; «у нас красивый логотип и мы хотели бы использовать его цвета и в дизайне сайта»; «у нас много хороших текстов, описывающих преимущества нашего магазина, и было бы хорошо их разместить»).
- Перечень ограничений (например: «не использовать черный цвет»; «нет качественных фото продукции»).
- Ссылки на нравящиеся сайты близкой тематики с кратким описанием, почему нравится тот или иной компонент.
Держаться в рамках, соблюдать границы
Итак, выше мы договорились, каким целям будет служить наша система, каким требованиям будет соответствовать интерфейс. Следующий важный момент — определить границы системы и рамки проекта.
Границы системы — это набор компонентов системы, взаимодействующих друг с другом в рамках выполнения соответствующих бизнес-процессов.
Например, мы понимаем, что интернет-магазин будет интегрирован с некой системой товарооборота, откуда интернет-магазин получает данные о товарных остатках и их стоимости (допустим, у нас 1С УТ), следовательно 1С — это важный компонент всей системы, который принимает участие в таких бизнес-процессах, как «Публикация товарного каталога на сайте» и «Оформление товара покупателем».
Рамки проекта — это набор функций системы, которые должны быть реализованы в рамках проекта «Разработка интернет-магазина».
Если обращаться к примеру с интеграцией 1С — то задачи по интеграции с 1С в рамки проекта укладываются, а вот задачи по возможным доработкам 1С — будут относиться к другому проекту.
- При формировании требований на разработку пишем не техническое задание, а бизнес-и-функциональные требования.
- По возможности — описываем основные процессы, характерные для вашего бизнеса.
- При формировании требований к дизайну — оперируем референсами, а не личными эстетическими настройками.
- Определяем границы системы и проекта, явно обозначаем их команде разработки и не выходим за эти рамки, пытаясь реализовать Систему-В-Широком-Смысле-Слова.
Практика показывает, что при соблюдении этих правил работоспособные системы выходят в релиз в должном качестве и в срок.
Источник: www.agima.ru
Как собрать бизнес-требования (с иллюстрациями)
Сбор бизнес-требований — это шаг в решении проблемы, который происходит после выявления потенциальной проблемы, но до разработки решения. Его цель — собрать, обобщить и сообщить факты о существующих условиях. Эти факты затем используются для дальнейшего определения, количественной оценки и прогнозирования последствий и воздействия сохранения статус-кво.
Шаги
Часть 1 из 4: Определение бизнес-требований
Шаг 1. Проанализируйте выявленную проблему
Прежде чем собирать бизнес-требования, компании нужно сосредоточить внимание на проблеме. Как только проблема обнаружена, компания, в свою очередь, ищет оптимальное решение для ее решения. Бизнес-требования содержат схему обоснования проекта и детали, необходимые для определения оптимального решения.
- Это означает, что компания должна постоянно собирать данные о своих клиентах, чтобы иметь возможность выявлять проблемы и иметь данные для обоснования новых проектов. После принятия решения о новом проекте вы можете переходить к сбору бизнес-требований.
- Чтобы прояснить проблему, начните с постановки проблемы. Формулировка проблемы, по сути, заключается в том, почему вы начинаете проект. Вы увидели проблему внутри компании или у своих клиентов, которую необходимо решить. В формулировке вашей проблемы должно быть точно указано, в чем проблема.
- «Проблема» также может быть в потребности компании или в возможности для роста.
Шаг 2. Соберите команду
Поскольку бизнес-требования сосредоточены на конкретном проекте, вы можете проводить встречи с соответствующими людьми из проекта. Команда будет состоять из людей, выполняющих различные роли, связанные с элементами, затронутыми или влияющими на проблему. Возможно, вам придется встретиться несколько раз, чтобы собрать необходимую информацию.
- На собрании команды обсудите, в чем проблема и на кого она влияет. Убедитесь, что у людей на собрании есть номера, подтверждающие проблему.
- Например, для решения проблемы качества потребуются производственные и инспекционные люди, такие как промышленные инженеры и мастера, а также любые сотрудники отдела кадров, если есть потенциальные вовлеченные элементы (профсоюзы).
Шаг 3. Рассмотрите все аспекты проблемы
То есть, формулировка проблемы, конечно, должна охватывать суть проблемы, но также должна указывать на то, кого она затрагивает, где и когда это происходит. Кроме того, следует обратить внимание на то, на что влияет проблема, помимо людей. Помните, что команда определяет не проблемы, а причины, последствия и следствия ранее разработанной формулировки проблемы.
- Вместе с группой начните определять различные затронутые отделы, как они затронуты, и существующее влияние существующего положения вещей. Пусть кто-нибудь напишет на доске или экране, который будет виден всем. Запишите формулировку проблемы вверху. Позвольте людям высказывать идеи и записывать их на доске.
- Убедитесь, что люди приходят подготовленными; если вы уже составили формулировку проблемы, они должны были ее прочитать и подумать над ней самостоятельно.
- Не осуждайте идеи. Когда люди выкидывают идеи, не выносите суждений, по крайней мере, во время мозгового штурма. Люди будут более нерешительно говорить что-то, если думают, что их будут судить.
- Поощряйте всех высказаться. Если кто-то что-то не сказал, позовите этого человека, чтобы узнать, есть ли у него что-то, что можно сказать.
Шаг 4. Сузьте идеи
После мозгового штурма пришло время сузить круг вашего решения. Обсудите, какое из решений кажется лучшим. По сути, вы собираетесь решить, что ваша компания будет делать для решения проблемы. Возможно, вы решили, что хотите вернуться к некоторым из ваших оригинальных дизайнов с некоторыми обновлениями.
Часть 2 из 4: Разработка плана проекта
Шаг 1. Разработайте план проекта для завершения проекта сбора данных
Это должно включать определение ролей, обязанностей и полномочий, участвующих в проекте сбора данных. Укажите задействованные отделы и данные, которые необходимо собрать и проанализировать. Прежде чем двигаться вперед, убедитесь, что все члены команды находятся на одной волне и привержены плану и его возможному успеху.
Шаг 2. Определите, что именно должно произойти
Чтобы реализовать этот проект, вам нужно будет определить, что именно нужно делать компании. Например, если проблема в том, что стоимость продукта слишком высока, охватываемые области будут включать закупку, производство, упаковку, доставку и бухгалтерский учет, среди прочего, для определения текущих и прошлых тенденций в стоимости материалов, производственных циклах и т. Д. и стоимость.
Шаг 3. Определите результаты
Ваш единственный результат в проекте сбора данных — это отчет о текущей ситуации с прошлыми тенденциями, а также прогнозируемые последствия, если статус-кво сохранится. Если для бизнес-задачи, переданной команде, требуются данные о предполагаемых решениях, они также будут включены в ваши результаты.
Шаг 4. Работа с необходимыми инстанциями
Для этой части проекта вам необходимо поработать с руководителями нескольких отделов, чтобы решить, что требуется для конечных результатов. Настройте способ работы с необходимыми органами и процессами для сбора информации. Как правило, руководители отделов неохотно предоставляют доступ тем, кто находится снаружи, поэтому необходимо заранее согласовать полномочия и доступ.
Шаг 5. Составьте расписание
Определите основные этапы и последовательность задач. Этой частью вы могли бы заняться еще в небольшой группе или команде. По сути, вы хотите указать, когда будут выполняться определенные части проекта. Основывайте свои оценки на том, сколько времени занимали эти типы проектов в прошлом. Это также означает определение того, когда проект начнется и когда он закончится.
Шаг 6. Создайте бюджет
У каждого проекта должен быть бюджет. Бюджет будет основан на оценках, сделанных бухгалтерией. Обсудите цифры с бухгалтерией, чтобы определить, каким будет бюджет для каждой части проекта.
Шаг 7. Задокументируйте объем продукта или услуги
Разработайте подробное описание того, каким будет продукт или услуга. Вы можете работать с командой дизайнеров, чтобы придумать это описание. Он должен включать результаты, ресурсы, график и затраты.
Часть 3 из 4: Сбор и документирование данных
Шаг 1. Установите процесс
Необходимо установить существующий процесс производства продуктов или предоставления услуг для ваших клиентов. Очевидно, что процессы будут установлены целыми отделами, работающими вместе над поиском решения. Однако ваша задача — определить процесс в бизнес-требованиях. Определите, как изучаемые процессы влияют на проблему, будь то причина или следствие. Изучите процесс:
- Составление наблюдений за процессом.
- Проведение интервью с сотрудниками, выполняющими процесс.
- Анализ количественных показателей процесса, таких как объем, время цикла, стоимость, качество.
Шаг 2. Создайте блок-схему процесса
Один из способов показать процесс — использовать блок-схему. Вы используете фигуры для каждого шага процесса со стрелками, чтобы показать, как движется товар или услуга. По сути, это карта того, как работает процесс. Он может показать, где могут возникнуть проблемы с процессом, если продукт окажется узким местом в определенной области.
Например, если одна область может производить 40 продуктов за один час, а на следующем этапе процесса может быть произведено только 20 продуктов за час, то процесс необходимо отрегулировать
Шаг 3. Определите количество элементов процесса
Анализ вашего процесса показывает, как каждый шаг повлияет на другой шаг. Следовательно, процесс вашего проекта не следует автоматизировать, пока вы не получите полное представление о процессе посредством анализа. Включите объяснение входов и выходов с физическими счетчиками, временем цикла и другими соответствующими данными. В частности, обратите внимание, когда процесс перемещается из одного отдела в другой, поскольку это часто является источником наибольшей неэффективности.
Часть 4 из 4: Отчетность о результатах
Шаг 1. Вставьте информацию в отчет
После того, как вы собрали информацию по каждой части и записали ее, вам нужно собрать все в один большой отчет. Разделите его на основные процессы и подпроцессы, чтобы его было легко читать. По возможности используйте наглядные материалы, чтобы прояснить понимание. Кроме того, будьте как можно более краткими, так как этот отчет потребуется прочитать как можно большему количеству людей.
Шаг 2. Будьте лаконичны
Это заявление не должно быть длинное на страницах. Это может быть параграф или два, поскольку он просто выражает проблему. Фактически, основная часть проблемы должна быть выражена в одном предложении.
Шаг 3. Общайтесь с членами вашей команды
Подтвердите свои выводы с членами команды и источниками в отделе. Этот шаг представляет собой проверку качества, чтобы убедиться, что ничего не было упущено или искажено. Спросите, нужно ли внести какие-либо изменения.
Шаг 4. Внесите необходимые изменения
Если вам нужно внести исправления, измените документ. После того, как вы внесли изменения, вам нужно отправить его снова, не забудьте выделить различия, чтобы вашим читателям не нужно было снова читать весь документ.
Шаг 5. Обобщите свои выводы
Напишите краткое изложение основных выводов, чтобы читатели могли их легко понять. В большинстве случаев резюме не должно превышать двух страниц. Не забудьте включить ссылки или ссылки, если вы создали электронный отчет.
Шаг 6. Представьте свой отчет спонсору
Создайте презентацию и презентационные материалы, чтобы вы могли показать свои выводы спонсирующей стороне. Если необходим устный отчет, подготовьтесь к встрече, проанализировав свои выводы.
Источник: ru.how-what-finance.com