Эпиграф: Верблюд — это лошадь, сделанная по всем требованиям заказчика.
Если вы когда-либо участвовали в интернет-проектах — любой сложности и в любой роли — вы наверняка знаете, что определение целей и границ будущей системы — это фундамент решения любой проектной задачи. Сбор, анализ и управление требованиями — та часть проекта, в которой опыт команды и методология играют определяющую роль: цена ошибки на этом участке очень высока.
Опытные и слаженные команды в России есть, а вот методологии управления требованиями — единой, прозрачной и удобной в использовании — до сих пор нет. Даже в одной организации от проекта к проекту меняются инструменты и методы управления требованиями, роли участников процесса, и, как следствие, нашим организациям не хватает «зрелости» — гарантии повторяемости проектных процедур со стабильно высоким качеством выдаваемых результатов.
Перед любым организатором «цеха» или проектного офиса в интернет-компании возникает соблазн использования довольно четких и проработанных методологий управления требованиями, заимствованных из инженерии программного обеспечения. Однако, на практике нередки ситуации, когда эти методологии оказываются избыточно сложны и не учитывают специфику именно интернет-проектов. Ведь помимо очень похожих на разработку ПО сборки и внедрения в интернет-проектах есть еще и дизайн, и проектирование, и аналитика. Конечно, в том или ином виде все это присутствует и в построении программных систем, но все-таки есть множество нюансов: одно дело — сборка ясной и определенной системы для оператора, и совсем другое — создание сайта для произвольного набора совершенно разнородных пользователей.
К тому же, далеко не во всех студиях-разработчиках есть экспертиза системного анализа, необходимая для использования инструментов из программной инженерии (например, семейства IBM Rational), да и для представителей заказчика эти инструменты, как правило, попросту непонятны, поэтому ни о какой эффективной совместной работе (например, SCRUM) при таком подходе речи быть не может.
По факту, большинство заказных интернет-проектов делается «по старинке» — с написанием быстро устаревающего ТЗ, длительным и мучительным его согласованием, фантастически изощренными способами внесения изменений в скоп работ на поздних этапах реализации, и, как следствие, с плохо прогнозируемым результатом и полнейшим отсутствием управления рисками.
Поскольку необходимость в удобной и относительно универсальной методологии управления требованиями к интернет-системам назрела давно, в текущий момент времени необходимо решить три стратегически важных задачи:
- Разработать и отшлифовать на практике удобную, прозрачную и простую в использовании методологию управления требованиями;
- Научить заказчиков и подрядчиков работать по этой методологии, объясняя, чем подход с осознанным управлением требованиями привлекателен для бизнеса;
- При удачном решении задач 1 и 2 — зафиксировать методологию в качестве отраслевого стандарта.
В компании ADV/web engineering co. в течение нескольких лет проводились практические исследования различных инструментов и методов управления требованиями, и к настоящему моменту у нас сложилось четкое понимание того, как наиболее эффективно следует управлять требованиями в заказной разработке интернет-систем.
В основе методологии лежит системный подход, который рассматривает все описание будущей функциональности как единую систему понятий, разделенную на два больших кластера: кластер бизнес-требований и кластер функциональности. При этом в фундаменте всей системы управления требованиями лежат общие цели, задачи и миссия проекта, описанные в универсальных терминах, понятных и маркетологам, и инженерам.
Более глубокие уровни детализации, оставаясь в единой системе, не смешиваются между собой по языку и форматам описания, что позволяет бизнес-пользователям сосредоточиться на бизнес-целях и смысловых ограничениях системы, а проектировщикам и разработчикам — на способах достижения этих целей с учетом заявленных ограничений. При таком подходе очень важна роль системного аналитика, чья экспертиза помогает увязать два кластера между собой, не нарушая целостности системы.
Более подробное описание методологии будет рассмотрено в следующих статьях цикла, а также на мастер-классе «Управление требованиями», который beeos будет вести на РИКе 28-29 июля.
Задача 1) видится нам решенной, и мы приступаем к решению задачи 2) — вынесению методологии на суд общественности и постепенной ее «доводке» в качестве более универсального инструмента отраслевого уровня.
