analyst.by

Белорусское сообщество бизнес и системных аналитиков

Старт проекта: что, когда и как делать. Часть 2

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

 

 

Как мы и договаривались, сегодня будут рассмотрены следующие вопросы:

  1. Как составить повестку командировки.
  2. Какие проектные материалы и документы нужно готовить к командировке.
  3. Как «прокачать» свои навыки общения для успешного проведения командировки.

 

Для начала определимся с той информацией, которая уже есть у аналитика после завершения подготовки к первой фазе перед стартом проекта – фазе изучения входной информации.

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

  1. Список функциональных блоков (групп требований) и перечень вопросов к ним.
  2. Интеграционные точки продукта в виде контекстной диаграммы или mind map.

 

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

 

Составление повестки командировки.

Основные цели составления повестки:

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

 

Как подойти к составлению повестки?

При составлении повестки я обычно руководствуюсь принципом от in depth analysis к in width analysis, который заключается в том, что

  1. сначала нужно определить основные темы для обсуждения и определить всех участников со стороны заказчика и компании вендора;
  2. затем выделить пункты, подтемы или вопросы для их обсуждения;
  3. подготовить рабочие материалы по каждой теме или подтеме;
  4. определить время обсуждения каждого пункта или подтемы.

 

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

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

 

Какие основные темы нужно обсудить?

К ним относятся:

  1. Бизнес-контекст и бизнес-позиционирование продукта: проблемы и цели продукта, заинтересованные стороны проекта, взгляд заказчика на сроки проекта (= один из критериев успеха), профили пользователей для фронт-энда и бэк-энда, среда пользователей.
  2. Основные результаты работы (deliverables) над проектом в целом.
  3. Основной выходной материал (deliverables) командировки.
  4. Обзор текущего решения или его аналогов.
  5. Текущие и будущие бизнес процессы.
  6. Функциональные требования на основе списка подготовленных функциональных блоков и требований к ним.
  7. Интеграционные требования на основе уже составленной контекстной диаграммы или mind map.
  8. Требования по миграции данных.
  9. Нефункциональные требования: требования к операционным системам, поддерживаемым браузерам, требования по производительности, доступности и безопасности системы.

 

Шаблон повестки

Заметки:

  1. Руководством по составлению повестки командировки всегда может служить шаблон документа о видении и границах продукта, используемый в Вашей компании. Если такого нет, то книга Карла Вигерса «Разработка требований к программному обеспечению»  с уже имеющимся там шаблоном данного документа всегда поможет.
  2. Стадия изучения входной информации всегда является маятником , предоставляющим основной материал для повестки, т.к. она сразу укажет, какие темы нужно обязательно обсудить и прояснить.

 

 

Проектные материалы и документы для  командировки

Цель их подготовки – удобное использование во время бизнес визита; структуризация материала и более глубокое понимание продукта.

Основные виды документов и материалов

Независимо от предметной области проекта я обычно готовлю следующие материалы

1. Список вопросов: основные вопросы по образу и границам продукта, вопросы по нефункциональным требованиям, др. вопросы.

 

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

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

 

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

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

 

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

3. Уточненная контекстная диаграмма

На этапе подготовки к командировке уже составленную нами на предыдущей стадии контекстную диаграмму или mind map можно уточнить путем добавления вопросов касательно механизма взаимодействия разрабатываемой системы с другими:

  • Автоматическая или ручная загрузка данных предполагается? Или будет общение систем через веб-сервисы?
  • Периодичность загрузки данных и их объем
  • Формат загружаемых данных: .csv, .xml, др.

 

4. BPMN модели бизнес-процессов, если их можно построить на основе имеющихся данных, или шаблон таблицы для выяснения требований по бизнес-процессам, если на данный момент нет достаточной информации для их описания.

 

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

 

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

 

Как «прокачать» свои навыки общения для успешного проведения командировки

Говорить про необходимость чтения книг не буду J. Могу перечислить несколько практических советов, которыми пользовалась сама:

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

 

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

  1. Развернутая повестка к командировке.
  2. Набор рабочих материалов и заготовок, на основе которых можно будет строить продуктивную работу во время визита к заказчику. Основными материалами тут, конечно же, являются список требований, перечень вопросов по продукту в целом и по требованиям.
  3.  Моральная подготовленность в нескольким неделям командировки ;)

 

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

Автор: Виктория Отставная

Бизнес-аналитик

EPAM Systems

 


18 Февраля, 2013


Комментарии к “Старт проекта: что, когда и как делать. Часть 2”
  1. Спасибо за статью. После прочтения статьи у меня сложилось впечатление, что это Вы собираетесь управлять заказчиком в процессе сбора требований/старта проекта, а не он Вами (кто же платит деньги? :-) ).
    Хочу спросить на самом деле следующее. Насколько гладко (по приведенному выше плану) в реальном жизни у Вас получается действовать? И какая степень обновления плана/недостижения поставленных результатов.
     

    • И Вам спасибо за отзыв :) 
      По поводу выполнения плана,  то действовать согласно ему получается всегда. Конечно, если сроки очень сжатые, то нужно расставить приоритеты: повестка должна присутствовать всегда, но среди же рабочих материалов нужно выделить самые необходимые (список требований и перечень вопросов) и готовить их. Иногда и поовертаймить нужно, если времени на подготовку к workshop ну ооочень мало, но это все с лихвой себя окупит в самой командировке, когда все, что Вам требуется, будет под рукой. Тут главное — дисциплина :) 
      Что касается повестки и ее изменений во время командировки, то да, вероятность незначительных корректировок  есть всегда и они, действительно, будут. И из-за неточных эстимаций на тему обсуждения, и из-за того, что тот, кто был нужен для обсуждения темы, не пришел, др.  В данном случае обычно незавершенные дискуссии продолжаются на след. день и это всегда закладывается в повестку как «continue discussion of a previous day». + По итогам каждого дня воркшопа всем участникам всегда сообщается о результатх текущего дня и планах на следующий. а также с главным человеком от заказчика каждый день нужно обсуждать, продолжаетет ли Вы все успевать или нет (подробно обо всем этом расскажу в след статье).

      А по поводу управления заказчиком, то да — у  Вас сложилось верное впечатление :) Ведь заказчик платит деньги именно за то, что вендор пердоставляет профессионала, который сможет выстроить процесс сбора требований, являясь специалистом в этом деле (заказчик обычно не структурирует информацию для предоставления вендору или структурирует не в таком виде и не в таком объеме, как надо проектной команде). Просто благодаря четкому плану вы задаете курс и сможете направлять заказчика к действительно важным вещам :) А сам заказчик уже будет перечислять все нужные требования по каждой обозначенной Вами теме. Есть даже такие термины как manage customers and their expectations. Вот :)

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

    • Спасибо за отзыв :) Скоро будет продолжение =)
      Касательно документа с границами проекта, то очень хорошо об этом написал Карл Вигерс в книге «Разработка требований к программному обеспечению» (http://www.amazon.com/Software-Requirements-2-Karl-Wiegers/dp/0735618798). Там этому посвящена целая глава + есть шаблон документа. Поделиться реальным, к сожалению, не могу, т.к. это production документы. Но могу помочь какими-то советами или ответами на конкретные вопросы. Пишите, если нужно :)

Добавить комментарий
Также Вы можете войти используя: Facebook Google