Постоянно возникают неожиданные проблемы, рождаются идеи, меняются потребности рынка. Однако изменчивость требований — не самая большая проблема. Важнее организовать работу, чтобы поднимать эти проблемы для последующего решения, направлять процесс принятия решений и доводить результаты до сведения коллектива.
Вот ряд фундаментальных принципов, которые нужно учитывать:
• Создавайте команду в составе менеджера проекта и всех руководителей групп, которая будет рассматривать все вносимые изменения
Команда должна регулярно собираться, ответственно подходить к рассмотрению запросов на внесение изменений и гарантировать, что руководитель каждой группы может оценить эффект изменения. Менеджер проекта должен следить, чтобы рассмотрение запросов на внесение изменений шло эффективно, а рассматриваемые запросы не выходили за рамки компетенции команды. Он также должен изучать влияние изменений на план исполнения проекта. При внесении изменений нужно пересмотреть и соответствующим образом изменить план.
• Необходимо не только разрешить, но и стимулировать группы, ответственные за реализацию определённых функций, к улучшению этих функций ПО
Такая свобода поможет им быстрее пересматривать и улучшать продукт. Однако недопустимо, чтобы улучшения частных особенностей или более тонкая настройка негативно отражалась на исполнении проекта. Если изменение влияет на требования или на его внесение уйдёт больше времени, чем допускает план, при обработке запроса на внесение этого изменения нужно обязательно следовать вышеописанной процедуре.
Единственное исключение — обязательные требования. Они являются наиболее важными, и их нельзя изменять как таковые без оценки и санкций извне. От реализации этих функций зависит работа других подразделений компании, и их также необходимо включить в процесс принятия решения. Так, внешнюю экспертизу могут производить менеджеры по продукции, маркетингу, старшие менеджеры и другие ключевые заинтересованные лица.
• Необходимо ознакомить с изменениями всю команду
Эти сведения можно просто разослать по электронной почте или обговорить на очередном рабочем собрании — главное, чтобы в курсе изменений был каждый.
• Все изменения должны быть документированы
Документирование позволяет команде отслеживать и анализировать изменения в проекте. Следует указывать дату внесения изменения, его суть и краткое обоснование. Важно, чтобы на протяжении жизненного цикла выпуска ПО подобная информация хранилась в едином месте, чтобы все участники группы могли обращаться к ней по мере необходимости. Можно вести реестр изменений в начале документа со списком требований или регистрировать в специальном журнале все утверждённые запросы на внесение изменений.
Общие проблемы и решения
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Как изыскать время
Одна из самых распространённых причин для отказа от формулирования требований (а также от затраты усилий на создание прототипов пользовательского интерфейса) в том, что на решение этих задач требуется время. Узнав, сколько времени уходит на это, некоторые спрашивают: а с пользой ли оно тратится? В начале проекта все находятся под давлением потребности поскорее выдать первые результаты, поэтому такой вопрос вполне закономерен.
Ответ однозначен: «Да». Некоторые подходы к разработке ПО подразумевают затрату значительного времени на анализ и вывод подробных формулировок требований. Но подход, рассматриваемый в этой главе (и в следующих двух) предлагает цикл определения требований — он экспериментально проверен и подтверждён положительными отзывами. Это не только не позволяет группе расслабиться, но и даёт возможность проявить творческий подход и поэкспериментировать, прежде чем черновики планов будут созданы и переданы на утверждение. Кроме того, использование прототипов пользовательского интерфейса и технических решений позволяет увидеть и почувствовать результаты работы над проектом.
Формулируйте сами задачи, а не способы их решения
Спецификация требования должна отвечать на вопрос «что должно быть сделано?», а не «как это сделать?». Ответ на вопрос «как?» проще всего получить с помощью анализа технической осуществимости и создания прототипа пользовательского интерфейса. К сожалению, часто формулировки требований включают описание способов их реализации, что может сузить выбор возможных решений. Вместо этого следует позволить команде задействовать свой творческий потенциал, чтобы генерировать множество возможных решений, а затем экспериментально проверить их в реальном мире.
Рассмотрим в качестве примера вышеупомянутое приложение для обработки заказов. Одно из ключевых требований таково: «Принимая заказ на товар, нужно собрать следующую информацию: X, Y и Z». Заметьте: требование содержит формулировку самой задачи, но не способа её решения. Можно привести пример требования с описанием способа его реализации: «Пользователь должен выбрать в меню пункт New|Create Order и ввести нужную информацию в диалоговом окне». Лучше позволить команде, ответственной за разработку пользовательского интерфейса, самостоятельно найти лучший способ реализации этого требования путём работы с прототипом.
Не упустите главное
В большинстве случаев участники проекта воспринимают формулирование требований в штыки именно из-за плохо налаженного управления требованиями. Проекты страдают из-за «размазанности» и неполноты требований, отсутствия приоритетов и из-за неуправляемых изменений.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88