Loading...

Menu

Воркшопы по выявлению требований к IT-проектам: как и зачем их проводить?

Воркшопы по выявлению требований к IT-проектам: как и зачем их проводить?

by Станислав Тимофеев, 06.06.2016

Зачем вообще писать о каких-то воркшопах? Ведь требования можно собрать более простыми способами, например, организовав несколько звонков по скайпу или серию интервью. Но всегда ли это сработает?

Представим себе создание информационной системы для государственной организации. У такой организации, как правило, сложная иерархическая структура со множеством подразделений: департаменты, управления, всяческие отделы — юридический, финансово-экономический, отдел кадров, отдел по работе с общественностью и т.д. У всех этих подразделений есть устоявшиеся процессы, которые, максимально оптимизировав, нужно перенести в создаваемую систему.

Какие здесь могут возникнуть трудности?

На сбор требований отдельно с каждого подразделения уйдет масса времени. И вряд ли можно будет сделать это посредством звонков по скайпу.
При попытке соединить требования разных подразделений в одну общую картину непременно возникнут конфликты: у каждого отдела свое видение интерфейса и бизнес-процессов.
Требования не уместятся в заранее обговоренный бюджет, придется уменьшить объем работ, и, конечно же, ни одна из заинтересованных сторон не захочет убрать функционал, который был бы полезен ей.

Что делать?

Из всего разнообразия техник по сбору требований стоит выделить одну, которая нацелена на решение подобных проблем (проблем масштабных проектов со множеством заинтересованных лиц и конфликтующих требований), — это воркшоп по сбору требований, о нем мы и хотим вам рассказать.

Что такое воркшоп?

Воркшоп — одна из стандартных практик сбора требований, которой в литературе уделяется незаслуженно мало внимания, вероятно, ввиду сложности формализации процесса. Из самого названия “Workshop” понятно, что в его рамках происходит активная деятельность. Соответственно, присутствующие по определению не могут принимать пассивное участие в происходящем. Смысл заключается в том, что заинтересованные лица собираются вместе для того, чтобы определить требования для конечного продукта. На воркшопе обязательно присутствуют представители исполнителя и заказчика. Как правило, воркшоп занимает не менее половины рабочего дня.

Воркшоп отличается от обычного совещания тем, что его цель — не обсуждение разных вопросов, а произведение конкретного результата — в нашем случае это документ с выявленными требованиями.

Практика разработана компанией IBM в конце 70-х. Тогда они назывались JAD-сессии (Joint Application Development) и позднее легли в основу методологии Joint Application Development. В том или ином виде воркшопы применяются во многих процессах разработки, но могут рассматриваться и как отдельная техника, без привязки к какому-либо процессу.

Когда и зачем их проводить?

Если речь идет о разработке очередного клона Candy Crash или стартапа, где требования формируете вы сами и пользователи, воркшоп будет пустой тратой времени – это точно.

Воркшоп может быть полезным, если выполняются несколько условий:

  • Вы разрабатываете сложную систему с нетривиальными бизнес-процессами. Это, пожалуй, главное условие. Например, система предназначена для определенной области промышленности или не имеет готовых аналогов.
  • В проекте много противоречивых требований, для разрешения которых необходимо коллективное обсуждение.
  • Критичные для бизнеса проекты. Заказчику сложно увидеть пользу от подобных воркшопов, особенно учитывая их трудоемкость. Поэтому чем критичнее проект, тем больше заказчик будет заинтересован в его успешности, а значит, охотнее будет уделять ему время.
  • Проект достаточно большой. Согласно статистике(C. Jones. Software assessments, benchmarks, and best practices. Addison- Wesley Longman Publishing Co., Inc. Boston, MA, USA, 2000) воркшопы чаще всего используются на проектах размером более 100 функциональных точек (Functional points).
  • В конечном продукте заинтересовано несколько групп пользователей. Например, ERP-системой будут пользоваться специалисты разных профилей.
  • Необходимость быстро обозначить требования. Например, в ситуациях, когда рынок уже завоевывают конкурирующие решения.

Обобщив вышесказанное, воркшопы — это инструмент, позволяющий одновременно разрешить конфликтующие требования, проанализировать потребности заинтересованных лиц и убедиться, что требования учитывают эти потребности.

Немного статистики

Сложность проведения данного мероприятия вкупе с количеством времени, которое уйдет на воркшоп, может отпугнуть любого энтузиаста. Но если верить цифрам, приведенным компанией EBG Consulting, воркшопы:

  • Уменьшают количество дефектов в конечном продукте на 20-50%
  • Снижают риск неконтролируемого увеличения объема работ на 10-80%; при этом максимальный результат достигается при применении прототипирования наряду с воркшопами
  • Экономят 5-15% времени и трудозатрат на сбор требований в течение всего проекта

 

С чего начать?

Хорошей практикой считается начинать все с планирования, в случае с воркшопами это актуально как никогда. Для этого в первую очередь необходимо определиться с тем, чего мы хотим от воркшопа, какие цели преследуем? Это может быть улучшение бизнес-процесса, выявление функциональных требований (например, в виде сценариев использования, пользовательских историй), уточнение архитектурно значимых требований и т.д. Кроме того, целью воркшопа может быть создание как черновой, так и окончательной версии документа с требованиями.

Когда известны цели, понятен масштаб работ, можно прикинуть, сколько таких мероприятий понадобится под ваши задачи. Если в один воркшоп уложиться не получается, то нужно спланировать расписание всех сессий и документов, которые должны быть созданы.

Ниже приведены сводные данные, описывающие применение воркшопов в западных компаниях. Можно смело ориентироваться на них при организации собственного воркшопа.

Количество участников В среднем 4-12, не более 25
Длительность сессии От 3 до 8 часов
Частота сессий 2-3 раза в неделю
Количество воркшопов на проект 1-8
Время на подготовку В 2 раза больше, чем на саму сессию

Существует несколько различных техник проведения воркшопов по сбору требований. Мы решили подробно остановиться на технике, описанной в рамках методологии ACDM. ACDM (Architecture Centric Design Method) — это подход к разработке программного обеспечения, его особенность — упор на архитектуру. Это далеко не самая популярная методология (недавно кто-то даже удалил страничку с ее описанием на Википедии), однако именно в ней приводится наиболее детальное описание техники проведения воркшопа, которое (дополнив своими замечаниями и наблюдениями) мы здесь и приведем.

Итак, воркшоп состоит из трех основных частей: планирование, проведение и заключительная часть.

1. Планирование

Исход воркшопа во многом определяется тем, насколько тщательно к нему подготовились. Не подумали про транспортировку — половина участников опоздало; поздно отправили документы по проекту — половина воркшопа уйдет на их прочтение; забыли пригласить нужного человека — всю работу нужно будет переделать. Одним словом, нужно понимать, что вы занимаете время многих людей (как правило, руководителей, а, значит, их время наиболее ценно), и нужно сделать все возможное, чтобы получить от действа максимальную отдачу.
На этапе планирования нужно определиться со следующими основными моментами:

  • Место
  • Участники
  • Программа
  • Обзорная презентация проекта>
  • Материалы
  • Питание
  • Транспортировка

Место. Очень важно, чтобы все главные действующие лица физически присутствовали на воркшопе, потому что, как показывает опыт, людей, присутствующих виртуально, трудно вовлечь в процесс, а также задержки и сбои связи мешают остальным участникам сконцентрироваться.
Если это возможно, то лучше выбрать нейтральное место — такое, где участников воркшопа не будут дергать коллеги по работе.

Участники. Для начала нужно определиться, кто является заинтересованными в проекте лицами. Потенциальные участники воркшопа — это заказчики, конечные пользователи, разработчики, аналитики, интеграторы, тестировщики, системные администраторы…словом, все, кто имеет отношение к проекту. Причем если проект объединяет несколько компаний-заказчиков и/или несколько компаний-исполнителей, то, разумеется, присутствие представителей всех этих компаний на мероприятии обязательно. Помимо заинтересованных лиц на воркшоп могут быть приглашены эксперты в предметной области.

Команда — организатор (это может быть команда аналитиков или архитекторов, в зависимости от процесса) должна крайне тщательно подходить к выбору участников воркшопа. Нужно оценить роль каждого участника в организации, которую он представляет, его отношение к разрабатываемому продукту — недостающий участник, также как и лишний, может доставить массу неприятностей. Поэтому в каких-то случаях стоит вежливо отказаться от присутствия потенциального участника или, наоборот, не проводить воркшоп, пока не удастся договориться с нужным человеком.

Как правило, собрать всех нужных людей вместе — непростая задача, особенно если не все участники понимают, зачем вообще сдался этот воркшоп. Поэтому идеально иметь на стороне клиента “своего” человека, чаще в лице менеджера, — он будет координировать участников, назначит дату и убедит их, что воркшоп — приоритетная задача.

Автор методологии ACDM рекомендует ограничиться 25 участниками, большее количество координировать очень сложно.

Также до воркшопа важно определить роли. Условно все участники воркшопа разбиваются на представителей заказчика и представителей исполнителя. Первые являются основным источником требований, вторые же — пассивные слушатели, цель их присутствия — погрузиться в контекст проекта, а также делать заметки по ходу встречи. Однако, между ними необходимо распределить минимальный набор ролей:

  • Координатор. (ведущий воркшопа) Это должен быть опытный человек, способный вести воркшоп и координировать дискуссию. Как правило, в этой роли выступает ведущий аналитик.
  • Таймкипер. Следит за временными рамками воркшопа (каждый пункт в плане встречи должен иметь определённую продолжительность) и подсказывает координатору, если он выходит за их пределы.
  • Секретарь. Очень важная роль, этот человек будет записывать все принятые решения и открытые вопросы. Так как это занятие очень утомительное, стоит подумать о чередовании роли.

Также команде исполнителя рекомендуется провести предварительное собрание, где участников формально представят друг другу, введут в курс дела, назначат роли.

Программа воркшопа. Координатор должен подготовить черновую версию программы и заранее разослать ее всем участникам, так, чтобы у них появилось представление о плане мероприятия и они могли внести свои изменения.

Ниже мы приведем примерный шаблон программы. В том виде, который предлагается методологией ACDM, воркшоп занимает целый рабочий день, т.е. восемь часов.

Место: …
Дата: …
Время начала: …
Время окончания: …
NB: Внимание, выключите телефоны на время воркшопа

Активность Кто Время
Представление участников <Координатор> ~15 мин
Обзорная презентация проекта <Представитель заказчика> ~1 час
Перерыв Все ~15 мин
Выявление функциональных требований <Обсуждение под контролем координатора> ~2 часа
Обед Все ~1 час
Выявление качественных характеристик (нефункциональные требования) <Обсуждение под контролем координатора> ~2 часа
Перерыв Все ~15 мин
Выявление бизнес-ограничений и технических ограничений <Обсуждение под контролем координатора> ~1 час
Подведение итогов <Координатор> ~15 мин

Обзорная презентация проекта. Этап планирования — самое время попросить клиента подготовить такую презентацию. Зачем это нужно, если и так уже есть кипа документации по проекту?
Дело в том, что некоторые документы могут содержать ряд неясных моментов, другие могут и вовсе устареть, поэтому в процессе проведения презентации у участников часто возникают вопросы, которые выявляют проблемные места в проекте.

В идеале, клиент должен подготовить графическую презентацию (а не устную). Ниже приведем примерный шаблон презентации:

Тема Описание
Общий бизнес-контекст Опишите:
  • Краткую историю компании и рынка
  • Отличительные особенности
  • Текущие нужды и как проект поможет их удовлетворить
Заинтересованные лица Опишите тех, кто является ключевыми заинтересованными в проекте лицами (юр/физ), их роли и области ответственности. Если заинтересованные лица будут непосредственно пользоваться системой, объясните как.
Общий функционал Опишите примерный функционал системы.
Сконцентрируйтесь на главном, избегайте деталей
Технические ограничения Опишите:
  • Аппаратное и/или программное обеспечение, которое, разрабатываемая система должна в силу определённых причин использовать
  • Другие системы, с которыми нужно будет интегрироваться
  • Обязательные техстандарты, ГОСТы, протоколы
Бизнес-ограничения Опишите:
  • Временные рамки
  • Бюджетные ограничения
  • Юридические аспекты
Качественные характеристики Расскажите о качественных требованиях к системе, таких как производительность, доступность, безопасность. Дословно объясните, зачем и кому (из заинтересованных лиц) они нужны.

Презентация должна быть согласована с представителями исполнителя — кроме релевантности самого содержания нужно обратить внимание на размер презентации. Если она не укладывается в выделенное время, то надо попросить клиента уменьшить её объем, избавившись от ненужных деталей, или увеличить выделенное время. Кроме того, можно разбить воркшоп на несколько частей, однако надо понимать, что это оправдано только в случае с действительно очень большими проектами

По мере приближения воркшопа нужно будет разобраться и с логистикой:

Материалы. Все необходимые материалы должны быть на месте заранее. И это не только бумага и ручки. Нужно продумать рассадку людей, рассчитать количество флипчартов, проекторов, кабелей, подготовить шаблоны документов и т.д.

Организовать пространство можно следующим образом:

image

Питание. Голодное брюхо к работе глухо. Чтобы сэкономить время на обеде, лучше провести его неподалеку от места проведения воркшопа, например, в том же самом здании. В этом случае можно избежать ситуаций, когда обед затягивается из-за того, что кто-то слишком долго искал, где перекусить. Не забудьте заранее забронировать место, сделать заказ. Также, чтобы присутствующие не проголодались и не заскучали во время воркшопа, подумайте о небольшом перекусе: чай-кофе, снеки.

Транспортировка. Обычно команда исполнителей прибывает в офис к заказчикам, но могут быть и альтернативные варианты. Иногда имеет смысл организовать совместную транспортировку участников до места проведения воркшопа, а если это требует междугородних перелетов, необходимо заранее решить вопрос с билетами.

2. Проведение воркшопа

Для начала координатор представляет всем участникам программу воркшопа и объясняет основные правила:

  • Отключить телефон
  • Не критиковать идеи других участников
  • Не отвлекаться — от того, насколько вовлечены участники воркшопа, зависит полнота собранных требований

После объявления правил стоит кратко описать цели и процедуру проведения воркшопа.

Далее заказчик презентует проект (презентация, как мы помним, была подготовлена заранее заказчиком). Проводит ее менеджер проекта со стороны заказчика.

Далее начинается процесс сбора требований:

  • Функциональные требования. Здесь важно следить за тем, чтобы участники не начали описывать готовое техническое решение, а сконцентрировались на том, какие задачи система будет решать.
  • Качественные характеристики системы. Сначала определяется их полный список, это должно занять не более десяти минут, затем пишутся подробные сценарии для каждой из качественных характеристик.
  • Бизнес-ограничения, такие как сроки, бюджет, законодательные аспекты и прочее.
  • Технические ограничения включают необходимость использования какой-то определенной технологии (библиотеки, фреймворка, платформы, ОС и прочее).

Указанные категории специфичны для процесса ACDM. В вашем же случае это могут быть сценарии использования, пользовательские истории и прочие документы.

Для каждой категории требований мы рекомендуем заранее подготовить шаблон. Например, шаблон для сценариев использования можно посмотреть здесь. Так участникам будет проще сориентироваться и они смогут записывать свои идеи. К тому же шаблоны помогают добиться единообразия в оформлении требований. На запись предварительных идей участникам отводится некоторое время. Одним из описанных ниже способов координатор собирает предварительные варианты требования с каждого из участников. Когда участником озвучивается очередное требование, остальные помогают ему дополнить его, делают замечания, а координатор контролирует дискуссию. Когда требование полностью описано, его следует отобразить на проекторе или записать на доске — так можно избежать повторений.

image

Организовать процесс сбора требований можно несколькими способами:

  • По желанию. Каждый озвучивает требования, которые он написал, когда захочет. Это может сработать в коллективах с достаточно разговорчивыми людьми, иначе комментариев можно и не дождаться.
  • По кругу. Плюс этого метода в том, что все задействованы в процессе сбора требований. Однако после того, как человек озвучил свою идею, он может отвлечься от процесса. Стоит предусмотреть возможность пропуска круга на случай, если у участника закончились идеи.
  • Случайный опрос. Что-то среднее между двумя предыдущими подходами, но в этом случае координатор выбирает следующего спикера случайным образом. Основная прелесть этого механизма в том, что все следят за ходом событий.
  • По интересам. Каждый описывает ту часть системы, которая интересна ему. Этот способ эффективен, когда несколько пользователей используют систему с разной целью. Но, в отличие от предыдущего способа, велика вероятность, что участники потеряют нить событий. Кроме того, часть присутствующих и вовсе могут не высказать желания принимать участие в обсуждении.

По окончании каждого этапа расставьте приоритеты следующим образом: раздайте всем участникам голоса (по количеству они должны составлять от трети до половины количества требований). Каждый участник может отдать голоса требованиям так, как считает нужным. Таким образом, при голосовании участники могут определить относительную степень важности требований, в отличие от приоритизации в духе high-medium-low. Голосовать можно как открыто, так и закрыто.

Важные моменты:

  • Не переходите к следующему, пока не опишете текущее требование
  • Если возникают какие-то важные темы, не относящиеся к текущему обсуждению, или если для какого-то требования не хватает информации, отложите возникшие вопросы (например, запишите на стикере и повесьте на отдельную доску), чтобы вернуться к ним в дальнейшем после встречи.

На этом основная часть воркшопа заканчивается. Стоит предупредить участников, что их помощь может понадобиться на этапе обработки собранной информации.

3. Заключительная часть

image
Обработка полученной информации
После начального этапа сбора требований от заинтересованных лиц, команда исполнителя собирается отдельно для обработки полученной информации. Предполагаемый ход событий: секретарь предыдущей встречи показывает свои записи на проекторе, команда дополняет и вносит правки, сверяя со своими заметками. Этот этап — самое время для того, чтобы вернуться к отложенным ранее темам.
Финальная версия документа отправляется всем участникам воркшопа.

На схеме снизу представлен процесс обработки требований, собранных в рамках одного или нескольких воркшопов:
image

Секрет успеха

 

  • Подготовка. Все действия, которые можно сделать оффлайн, должны быть проделаны всеми участниками заранее.
  • Координатор. Успех проведения воркшопа во многом зависит от уровня организации, потому на роль координатора желательно поставить человека с опытом проведения подобных мероприятий. В крайнем случае, того, кто хоть раз присутствовал на воркшопе.
  • Участники. Важно собрать людей, способных самостоятельно принять решение за группу, которую они представляют. Кроме того, перед началом воркшопа стоит прояснить, что мнение всех участников одинаково важно.
  • Начинайте с требований и целей, вызывающих наибольшее количество противоречий. Это очевидно, но не стоит упускать этот момент.
  • Если несколько участников не смогут явиться — перенесите воркшоп. Обидно будет потратить столько времени и оставить больше вопросов, чем ответов.

 

Подведем итоги

Итак, воркшоп состоит из трех частей: планирование, проведение и обработка полученной информации. На этапе планирования все участники знакомятся с имеющейся документацией, в ходе проведения требования выявляются и уточняются, на этапе обработки на основе собранных требований формируется документация.

Конечно, воркшоп не решит все проблемы взаимодействия с заказчиком и при неумелом проведении окажется пустой и утомительной тратой времени. Однако при грамотной организации воркшоп — мощный инструмент для вовлечения заказчика в процесс разработки, позволяющий прийти к общему видению конечного продукта и максимально учесть все особенности разрабатываемой системы.

Материал был подготовлен программой MSIT-SE Университета Иннополис. Подробно аспекты сбора требований разбираются в курсе “Методы проектирования программного обеспечения”.

Статья на Хабре https://habrahabr.ru/company/innopolis_university/blog/302192/

CLOSE
CLOSE