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