Kniga-Online.club
» » » » Компьютерра - Журнал «Компьютерра» № 14 от 11 апреля 2006 года

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

Читать бесплатно Компьютерра - Журнал «Компьютерра» № 14 от 11 апреля 2006 года. Жанр: Прочая околокомпьютерная литература издательство неизвестно, год 2004. Так же читаем полные версии (весь текст) онлайн без регистрации и SMS на сайте kniga-online.club или прочесть краткое содержание, предисловие (аннотацию), описание и ознакомиться с отзывами (комментариями) о произведении.
Перейти на страницу:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перейти на страницу:

Компьютерра читать все книги автора по порядку

Компьютерра - все книги автора в одном месте читать по порядку полные версии на сайте онлайн библиотеки kniga-online.club.


Журнал «Компьютерра» № 14 от 11 апреля 2006 года отзывы

Отзывы читателей о книге Журнал «Компьютерра» № 14 от 11 апреля 2006 года, автор: Компьютерра. Читайте комментарии и мнения людей о произведении.


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

  • 1. Просьба отказаться от дискриминационных высказываний. Мы защищаем право наших читателей свободно выражать свою точку зрения. Вместе с тем мы не терпим агрессии. На сайте запрещено оставлять комментарий, который содержит унизительные высказывания или призывы к насилию по отношению к отдельным лицам или группам людей на основании их расы, этнического происхождения, вероисповедания, недееспособности, пола, возраста, статуса ветерана, касты или сексуальной ориентации.
  • 2. Просьба отказаться от оскорблений, угроз и запугиваний.
  • 3. Просьба отказаться от нецензурной лексики.
  • 4. Просьба вести себя максимально корректно как по отношению к авторам, так и по отношению к другим читателям и их комментариям.

Надеемся на Ваше понимание и благоразумие. С уважением, администратор kniga-online.


Прокомментировать
Подтвердите что вы не робот:*
Подтвердите что вы не робот:*