Системный подход в управлении требованиями



    Эпиграф: Верблюд — это лошадь, сделанная по всем требованиям заказчика.


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

    Опытные и слаженные команды в России есть, а вот методологии управления требованиями — единой, прозрачной и удобной в использовании — до сих пор нет. Даже в одной организации от проекта к проекту меняются инструменты и методы управления требованиями, роли участников процесса, и, как следствие, нашим организациям не хватает «зрелости» — гарантии повторяемости проектных процедур со стабильно высоким качеством выдаваемых результатов.


    Перед любым организатором «цеха» или проектного офиса в интернет-компании возникает соблазн использования довольно четких и проработанных методологий управления требованиями, заимствованных из инженерии программного обеспечения. Однако, на практике нередки ситуации, когда эти методологии оказываются избыточно сложны и не учитывают специфику именно интернет-проектов. Ведь помимо очень похожих на разработку ПО сборки и внедрения в интернет-проектах есть еще и дизайн, и проектирование, и аналитика. Конечно, в том или ином виде все это присутствует и в построении программных систем, но все-таки есть множество нюансов: одно дело — сборка ясной и определенной системы для оператора, и совсем другое — создание сайта для произвольного набора совершенно разнородных пользователей.

    К тому же, далеко не во всех студиях-разработчиках есть экспертиза системного анализа, необходимая для использования инструментов из программной инженерии (например, семейства IBM Rational), да и для представителей заказчика эти инструменты, как правило, попросту непонятны, поэтому ни о какой эффективной совместной работе (например, SCRUM) при таком подходе речи быть не может.

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

    Поскольку необходимость в удобной и относительно универсальной методологии управления требованиями к интернет-системам назрела давно, в текущий момент времени необходимо решить три стратегически важных задачи:
    1. Разработать и отшлифовать на практике удобную, прозрачную и простую в использовании методологию управления требованиями;
    2. Научить заказчиков и подрядчиков работать по этой методологии, объясняя, чем подход с осознанным управлением требованиями привлекателен для бизнеса;
    3. При удачном решении задач 1 и 2 — зафиксировать методологию в качестве отраслевого стандарта.


    В компании ADV/web engineering co. в течение нескольких лет проводились практические исследования различных инструментов и методов управления требованиями, и к настоящему моменту у нас сложилось четкое понимание того, как наиболее эффективно следует управлять требованиями в заказной разработке интернет-систем.

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

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

    Более подробное описание методологии будет рассмотрено в следующих статьях цикла, а также на мастер-классе «Управление требованиями», который beeos будет вести на РИКе 28-29 июля.

    Задача 1) видится нам решенной, и мы приступаем к решению задачи 2) — вынесению методологии на суд общественности и постепенной ее «доводке» в качестве более универсального инструмента отраслевого уровня.
    • +5
    • 14,7k
    • 6
    Поделиться публикацией

    Комментарии 6

      +1
      Интересно, жду продолжения.
        +3
        «который beeos будет вести на РИКе 28-29 июля» — а может это всё-таки в «Я пиарюсь?» а то тема не раскрыта (подобные общие фразы можно найти во многих стандартах, например том же CMMI), а есть только реклама события, или я не прав?
          +1
          в я пиарюсь это тоже запостили.
          все-таки, тут будет логическое продолжение с контентом. плюс, на семинаре могут появиться интересные вопросы и ответы на них — это тоже можно будет раскрыть.
          0
          Кар Вигерс, например, кроме бизнес и функциональных требований выделяет еще нефункциональные. Короче, ваши мысли конечно же не «открытие» какое-то. Хотя, возможно, будет что-нибудь интересное из жизни. В любом случае, вы, явно правы в том, что анализ требований — наиболее рискованная часть разработки, которая требует особого внимания.
          Интересен так же каким будет ваш взгляд на «специфику» интернет-проектов.
            0
            Тема интересная, но в статье вообще нет смысла. Можно было заменить на одно предложение «Мы придумали универсальную методологию и расскажем ее за деньги там-то.»
              0
              Управление требованиями — это:
              1) управление рамками проекта и релиза — что в него включать, что не включать
              2) управление статусом готовности продукта — трекинг состояния отдельных требований
              3) управление трассировками требований между собой
              4) управление трассировками требований на другие учётные единицы проекта — тесты, архитектурные модели, задачи, код

              Зачем тут нужна методология? Что тут методологировать?

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое