Воркшоп, поразивший меня

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

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

Место.Участники.

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

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

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

Обзорная презентация проекта.

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

Материалы. Питание. Транспортировка.

Как?

С точки зрения структуры проведения это выглядело следующим образом. У каждого ключевого проекта\направления есть свой лидер, который делает 20 минутную презентацию перед всеми участниками собрания. В конце презентации он озвучивает от 1-го до 3-х вопросов, которые для проекта крайне важны. Вопросы могут быть, как очень общие, так и вполне конкретные. Далее все участники делятся на несколько групп, и каждая группа штормит по всем этим вопросам. На словах ничего необычного, согласен. Классический брейншторминг и 5 минут «позора» у флипчарта после. Вся «фишка» в том, что менеджмент представляет абсолютно разные направления: коммерческая служба и маркетинг, финансы и hr, business development и digital. Не секрет, что в корпорациях абсолютно нормальная ситуация, когда одна функция понятия не имеет о работе другой. На собраниях подобного типа это отчетливо видно. На примере одного из коммерческих проектов, я увидел, как много могут придумать люди, которые к ней (коммерции) отношения не имеют. Понятно, что это очень общие, стратегические идеи, но их можно и нужно раскладывать на составляющие, которые уже станут реализуемыми.

Воркшоп, поразивший меня

Моя презентация перед 40 минутной сессией по моему проекту.

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

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

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

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

Участники

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

Это очевидно, но не стоит упускать этот момент.
Если несколько участников не смогут явиться — перенесите воркшоп. Обидно будет потратить столько времени и оставить больше вопросов, чем ответов.

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

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

Функциональные требования

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

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

Бизнес-ограничения, такие как сроки, бюджет, законодательные аспекты и прочее.

Технические ограничения включают необходимость использования какой-то определенной технологии (библиотеки, фреймворка, платформы, ОС и прочее).

здесь

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

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

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

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