Пролог

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

В своей статье «О качестве требований в ИТ проектах, начистоту (с позиции команды разработки)», я попытался более конкретно подойти к решению этих проблем и рассказал на своем опыте, как можно преобразовать собранные требования для автоматизации в ИТ проекте так, чтобы максимально повысить результативность команды, воплощающую их в целевой продукт. Повысить именно за счет качественно сформулированных заданий на разработку продукта, покрывающую весь процесс.

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

I Вступление

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

Для кого и для чего предназначена эта публикация:

На заре своей карьеры я работал программистом, руководил группой разработки, кодил, кодил и кодил. Но через 18 лет я принял решение сменить вид своей деятельности, окунувшись в сферу системного анализа и управления проектами. Поскольку так сложилось, что предприятия, на которых мне посчастливилось трудиться, не предусматривали должностей: аналитика, руководителя проектов, руководителя продукта и прочих экзотических на тот момент для меня специальностей, программистам приходилось самим, так или иначе, управляться с проектными активностями перечисленных специализаций. Естественно, эти самые активности выполнялись не совсем профессионально, на все не хватало ни времени, ни фундаментальных знаний. Чтобы восполнить эти пробелы, я добросовестно засел за изучение курсов по разработке функциональных требований, методологий RUP, SADT, языка UML и т.п. И через некоторое время, мне посчастливилось получить работу в одной из ведущих софтверных фирм на должности с пафосным названием: «ведущий специалист по работе с заказчиками». Работодатель, зная, что у меня нет опыта работы профессиональным аналитиком, а есть лишь: желание, багаж теоретических знаний и большой практический опыт разработчика, выдал мне две книги [1], [3] и “велел” через пару месяцев быть готовым писать качественные спецификации требовании для разработки ПО. Из моей практики программиста, ближе и роднее всего для меня были диаграммы классов. И естественно это первое, за что я попытался зацепиться. Параллельно попробовал написать Варианты использования по Коберну [3], уж очень «сладко» он излагает свои мысли, так и хочется попробовать приготовить нечто подобное. Варианты получились громоздкими и заумными, сначала надо было разбираться с формой этих Вариантов, а уже потом с содержанием. Работать с ними было неудобно. Более удачными, на мой взгляд, получились спецификации требований, созданные по подсмотренным в RUP шаблонам.

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

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

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

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

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

Основные цели данной книги:

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

Итак, поехали…

II Введение

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

1. Предоставление теоретической информации, описывающей ту или иную фундаментальную «тяжёлую» методологию, например: RUP или SADT. Эти методологии чрезвычайно эффективны и полезны, применительно к крупным проектам. Но их использование требует длительного процесса обучения, включая тренинги либо практику в компаниях, в которых они уже успешно применяются. Классическим произведением для аналитиков, из этой группы можно считать [1], [2].
2. Изложение академической точки зрения на процессы из области управления требованиями. Лично мне очень помогли книги [4], [5].
3. Экскурс в различные технологии в виде сравнительных обзоров. На мой взгляд, книга [6], самое удачное произведение для аналитиков из этой группы, хотя ее можно отнести и к группе академических произведений. О выборе методики для использования в различных проектах, компактно и доходчиво описано в статье [9].
4. Практические идеи, представленные в виде «лёгких» методологий, чаще всего предназначенных для небольших проектов, например: ICONIX, процесс Экстремального программирования (eХtreme Рrogramming) [7], [10] и т.д. Такие методологии можно относительно быстро начать эффективно использовать в небольших командах.

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

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

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

Также на протяжении всего изложения, мы будем вместе с Вами, рассматривать вполне реальный проект: «Автоматизация процесса управления требованиями».

III Готовим ландшафт для работы команды

«Любой ландшафт — идеальное тело для выражения определенного строя мысли».
Новалис

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

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

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

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

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

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

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

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

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

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

На рисунке 3.1 изображена модель взаимодействия команды проекта в процессе формирования и использования контента проекта («области проблем» и «области решений»).


Рисунок 3.1 — модель процесса взаимодействия команды проекта

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

Оформлять список удобно в виде таблиц, в которых помимо наименования заинтересованного лица, необходимо уточнить его цели, классифицировать его компетенцию и роль в проекте.
Ниже приведен пример использования таблиц, для формирования списка Заинтересованных лиц проекта:



Еще один целесообразный шаг для формирования ландшафта проекта, это публикация на его «витрине» — словаря (глоссария), который послужит вашей команде инструментом достижения консенсуса в толковании объектов и явлений предметной области. Это позволит заказчикам и разработчикам общаться на диспутах на «одном языке». Опыт показывает, что использование глоссария экономит массу времени, а главное нервов, так как часто заказчики и исполнители тратят их на споры “каждый о своем”, возникающие только из-за разницы в понимании одного и того же термина. Например, использованное в заголовке слово “Ландшафт” может трактоваться, в зависимости от области применения, очень по-разному. Но в контексте нашего проекта добавим в Глоссарий такое определение:



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

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

Китайская народная мудрость: «Скажи мне – и я забуду. Покажи мне – и я запомню. Вовлеки меня – и я научусь»»

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

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

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

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

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