Выбери любимый жанр

Выбрать книгу по жанру

Фантастика и фэнтези

Детективы и триллеры

Проза

Любовные романы

Приключения

Детские

Поэзия и драматургия

Старинная литература

Научно-образовательная

Компьютеры и интернет

Справочная литература

Документальная литература

Религия и духовность

Юмор

Дом и семья

Деловая литература

Жанр не определен

Техника

Прочее

Драматургия

Фольклор

Военное дело

Последние комментарии
оксана2018-11-27
Вообще, я больше люблю новинки литератур
К книге
Professor2018-11-27
Очень понравилась книга. Рекомендую!
К книге
Vera.Li2016-02-21
Миленько и простенько, без всяких интриг
К книге
ст.ст.2018-05-15
 И что это было?
К книге
Наталья222018-11-27
Сюжет захватывающий. Все-таки читать кни
К книге

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


35
Изменить размер шрифта:
Пример из практики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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