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