Компьютерра (№255) - Журнал «Компьютерра» № 14 от 11 апреля 2006 года

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

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

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

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

Разбор перед полетом

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

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

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

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

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

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

Как брать анализ

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

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

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

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

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

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

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

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

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

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

Рабочая группа должна разработать соглашения, определяющие:

— полномочия членов группы;

— шаблоны будущих документов;

— порядок взаимодействия между заказчиком и исполнителем;

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

Выделение одного или нескольких ответственных, в чьи функции будут входить:

— координация взаимодействия специалистов исполнителя с членами рабочей группы;

— решение потенциально возможных организационных и коммуникационных проблем;

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

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

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

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

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

Быстро, удобно, неправильно

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

Что подписано пером

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

А касательно применения подписи в качестве инструмента давления на заказчика ситуация абсолютно аналогична аудиозаписям.

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

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

Спустя некоторое время, во время опытной эксплуатации системы, заказчик заявил, что функционал, о котором говорилось выше, «не соответствует заявленному». Начали разбираться. Выяснили, что то, что хочет заказчик, соответствует тому, что написано в документе требований. Тогда стали вспоминать, на основании чего реализовали не так. Подняли переписку. Нашли то самое письмо с финальной постановкой задачи. Продемонстрировали заказчику. В ответ получили формулировку: «У нас есть подписанный документ, а рабочая переписка документом не является. Поэтому вы не должны были на ее основании проводить разработку». Вот так. Некоторое время спустя выяснилась причина такого поведения. Дело в том, что не до конца отлаженные бизнес-процессы заказчика постоянно изменялись. На момент постановки задачи было одно видение, потом эта позиция была пересмотрена, так родилось злополучное письмо. А впоследствии заказчик все-таки решил вернуться к первоначальной схеме работы. Если бы исполнитель сразу объяснил заказчику правила игры, а именно, что каждое изменение в требованиях должно согласовываться, оцениваться и оформляться строго определенным образом, то заказчик трижды подумал бы, прежде чем писать письмо об изменении системы, как только эта мысль пришла ему в голову.

Письмоносец: Финальное заключительное вступление

Автор: Илья Щуров Voyager

Здравствуйте! Являюсь вашим читателем около года, но уже много чего освоил и понапридумывал. Вот например, если бы в смартфонах не один слот для карт памяти был, а несколько. Про CeBIT: жалко, вы с собой не взяли Голубицкого и Козловского, тогда бы выставка продолжалась круглый год. Спасибо.

С уважением, ваш читатель Павел Дегтяренко

ОТ РЕДАКЦИИ: Мысль интересная. Надо бы связаться с Deutsche Messe и спросить, что они думают о проведении круглогодичного CeBIT’а силами Козловского и Голубицкого…

Уважаемая «Компьютерра»!

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

Это заводит, честно. Но иногда с классикой и сольфеджио вы перебарщиваете. Хорошо, что я математик и знаю, как описывается гомологический образ группы в высшей алгебре, но на кого рассчитано предложение в статье Владимира Гуриева, звучащее как «Иерархия создателей мобильных телефонов изоморфна фокусу потребительского внимания»? Это же надо сначала дать определение иерархии, изоморфизма и т. д. Ну будьте проще, ближе к народу. Красота не в мудрености фраз, а в красоте стиля и слога и в интересных материалах. А вы это можете.

С уважением,

ОТ РЕДАКЦИИ: Спасибо за теплые слова, Кирилл. Кажется, к року неравнодушна большая часть редакции, так что все вполне объяснимо. Насчет необходимости определений согласен, исправляемся: изоморфизм — биективное соответствие между группами, являющееся гомоморфизмом. А вот что такое «гомологический образ группы», я, честно сказать, так и не понял.

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

То есть, к примеру, если любовь продвинутых в информационных технологиях супругов достаточно сильна и друг другу муж и жена доверяют, то они могут за некоторую плату (скажем, три сотни рублей в месяц) взаимно «наняться» на удаление спама ближнего. Так как деньги из семейного бюджета никуда в этом случае не исчезают, все остается в плане финансов по-старому. Но вдумайтесь — теперь за удаление спама вам платят деньги! Неплохой повод постараться, а?

В случае с обычными, но верными друзьями ситуация почти аналогична: в качестве платы за работу можно предложить «уборщику» бутылку чего-нибудь крепкого. В день «выдачи зарплаты» нанявшие друг друга «компаньоны» собираются — и опять-таки ничего не пропадает впустую. Ну как? Кстати, с Первым Апреля!

С уважением, Александр Ч. М.

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

"Читаю и люблю КТ давно. Ловлю себя на том, что поиски журнала стали у меня сравнимы с поиском сигареты курящим (увы, грешу этим).

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

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

ОТ РЕДАКЦИИ: Нам тоже подобные идеи в голову приходили, но до практической реализации они еще не дозрели. Ждем-с.

Наушниками Zalman ZM-RS6F награждается Александр Ч. М. — за оригинальное решение проблемы спама. Приз предоставлен компанией allmart.