Читать «Журнал «Компьютерра» № 14 от 11 апреля 2006 года» онлайн - страница 87
Компьютерра
И если отсутствует понимание важности этой задачи (а оно, как правило, отсутствует), то результатом будет разочарование заказчиков системы, получивших совсем не тот продукт, который они ожидали увидеть, и досада разработчиков, осознавших, что все, над чем они трудились последние N (по закону Мерфи — p*N) месяцев, оказалось впустую.
В бытность свою консультантом, аналитиком, руководителем проектов и пр. мне столько раз приходилось «наступать на различные грабли», что если хотя бы одному человеку, прочитавшему эту статью, удастся какие-то из «граблей» миновать, я буду считать, что поставленной цели достиг.
Работа «по жизни» и работа «как в книжке» отличаются, и порой очень сильно. Как-то в недавнем разговоре с одним специалистом, с которым проводилось собеседование при приеме на работу, я смоделировал очень нехорошую ситуацию, возникшую на проекте, и спросил, как он собирается из нее выкручиваться. В ответ услышал, что таких ситуаций быть не может, потому что это неправильно, противоречит тому, как все должно быть, и вообще, таких ситуаций у него еще не было. Тем не менее ситуация действительно имела место. А человек оказался не готов к такому повороту событий.
В конфликтах обычно виноваты обе стороны. Заказчик, как правило, стремится сэкономить, где только возможно (с его точки зрения). Однако не понимает, что есть работы, экономия на которых неизбежно приведет к возникновению рисков, а их компенсация может потребовать существенного увеличения бюджета проекта. Это непонимание вполне объяснимо, учитывая, что большинство заказчиков не являются специалистами в IT (и к тому же плохо представляют процесс разработки ПО).
В такой ситуации задача специалистов исполнителя заключается в том, чтобы разъяснить все эти моменты. Понятно, что разъяснения не всегда бывают успешными, а значит, где-то надо поступать в строгом соответствии с оговоренными правилами сотрудничества. При этом должны оформляться такие-то документы, а порядок взаимодействия такой-то. И это не обсуждается. Можно привести массу примеров, когда проекты не только сопровождались конфликтными ситуациями, но и заканчивались полным провалом из-за того, что должным образом не были формализованы отношения.
Что же представляют собой требования к автоматизированной системе? Это некий документ. Именно документ, поскольку пожелания к будущей системе, сформулированные в процессе общения между экспертами предметной области и аналитиками, собирающими требования, таковыми по сути своей не являются, а остаются всего лишь пожеланиями и личными мнениями тех, кто эти пожелания сформулировал.
Заказчик, думая об информационной системе, способной повысить эффективность его бизнеса, имеет некоторое видение ее функциональных и технических характеристик, которое (при весьма четком понимании целей создания системы) порой является очень туманным. Хуже того, в подавляющем большинстве случаев высказываемые пожелания не могут быть использованы даже в качестве исходных данных для проектирования. Процесс разработки требований представляет собой попытку формализации пожеланий заказчика к проектируемой системе в терминах, понятных как заказчику, так и исполнителю.
