Версия для печати

Программный инструмент аналитика          Ключевые инструменты аналитиков          Облачный сервис Битрикс24

 

Требования к автоматизированной системе.
Формализм - блажь или осознанная необходимость?

 

Настольная книга аналитика. Практическое руководство по проектированию бизнес-процессов и организационной структуры
Видео-курс "Ключевые инструменты аналитиков: описание и оптимизация бизнес-процессов с целью внедрения информационной системы (ИС)"
Программный инструмент аналитика "Бизнес-инженер"

Сергей Длужневский -
ведущий менеджер проектов
по проектированию, разработке
и внедрению информационных систем

Сергей Длужневский - ведущий менеджер проектов по проектированию, разработке и внедрению информационных систем

"Помилуйте, -
уверенно ответил человек, -
как же так, без документа?"

Михаил Булгаков. "Собачье сердце"

Зачем и как нужно разрабатывать требования к автоматизированной системе? Ответ на этот вопрос, столь очевидный для одних, является совершенно неочевидным для других. Особенно для тех, кто по роду своей деятельности достаточно далек от всего того, что именуется IT-индустрией. А ведь именно таким людям и приходится порой принимать самое активное участие в разработке этих требований - как представителям класса бизнес-пользователей будущей системы. И если отсутствует понимание важности этой задачи и методов ее решения (а, как правило, это понимание в должном виде отсутствует), то результатом кропотливой многодневной работы будет разочарование пользователей системы, получивших совсем не тот продукт, который они ожидали увидеть, и досада разработчиков, осознавших, что все то, над чем они трудились последние N месяцев, оказалось впустую.

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1. Основные участники процесса разработки требований

Рисунок 1. Основные участники процесса разработки требований

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

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

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

Пример из практики.

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

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

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

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

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

Сделать это можно по-разному. Начиная от личного 5-10-минутного мини-семинара с каждым интервьюируемым сотрудником компании заказчика, и заканчивая изданием распорядительного документа на уровне всей компании, регламентирующего процесс взаимодействия между специалистами заказчика и исполнителя на период разработки требований к системе. Зависит от объема, сложности, политической ситуации и т.д. каждого конкретного проекта. Универсального рецепта здесь нет.

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

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

Хочется сказать отдельно несколько слов по поводу переписки посредством электронных средств коммуникации - e-mail, MSN , ICQ и им подобных. В настоящее время такой способ общения очень распространен, и не случайно. Удобно, быстро, оперативно. Позволяет исполнителю работать, находясь за тысячи километров от заказчика и не чувствовать этого расстояния. Позволяет обмениваться мгновенными сообщениями, передавать файлы, устраивать целые конференции. В общем, можно было бы сказать, что использование этих программ существенно упростило жизнь при работе над проектами (остальных сфер использования вышеуказанных продуктов я сейчас не касаюсь), если бы не одно «но». А именно, очень часто посредством электронной почты (или других средств электронной коммуникации) решаются вопросы, которые решаться таким способом не должны в принципе. В данном конкретном случае я говорю о ситуации, когда после подписания документа требований заказчик по каким-то причинам принимает решение об изменении (добавлении, удалении) требований. Эта процедура должна оформляться в соответствии с довольно жестко прописанным регламентом управления изменением требований, который учитывает все возможные нюансы влияния этого события на проект в целом. Если же этим пренебречь, то можно получить ситуацию, которая описана в примере.

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

Несколько слов по поводу подписи.

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

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

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

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

Рисунок 2. Взаимодействие между исполнителем и заказчиком при разработке требований

Рисунок 2. Взаимодействие между исполнителем и заказчиком при разработке требований

Для успешного выполнения работ требуется:

Версия для печати
Яндекс.Метрика Rambler's Top100

Copyright © 2001-2024 БИТЕК (Бизнес-инжиниринговые технологии)