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

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

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

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

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

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

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