Время — деньги. Создание команды разработчиков программного обеспечения

для тестирования реальных пользователей и обновить требования до начала этапа планирования.

Ячейка 2. Ряд возможностей ПО, созданного конкурентами, предвосхищают нужды потребителей, поэтому хотелось бы наверстать упущенное. Следует изучить предложения конкурентов, понять, что они сделали правильно, а что — нет, и извлечь урок из допущенных ими ошибок. Риск, связанный с требованиями из этой ячейки, меньше в сравнении с риском в ячейке 1, так как уже существуют программные продукты, способные стать материалом для изучения и извлечения уроков. Однако следует ожидать быстрого изменения рынка и потребностей клиентов, поэтому, прежде чем перейти к формализации требований и созданию плана проекта, придётся затратить много усилий на моделирование технических характеристик и анализ удобства использования.

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

Ячейка 4. Тактика заключается в расширении функциональности продукта, который уже поставляют конкуренты. Риск в случае такого ПО должен быть относительно невелик, так как вы работаете в основном с хорошо известными функциями и технологиями на устоявшемся рынке. Поскольку риск столь мал, на тестирование удобства использования и последовательное улучшение прототипа уйдёт меньше времени, чем в других случаях.

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

Определение приоритетов

Определив и проанализировав требования, вы вплотную приблизились к обладанию полным набором функциональности. Но, прежде чем идти дальше, нужно задать приоритеты требований. Это поможет заранее оценить важность каждого требования и понять, как они связаны с другими требованиями.

Почему это так важно

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

Коллектив должен заранее прийти к соглашению об уровне приоритета каждого из требований. Лучше, чтобы в момент принятия трудных решений (если такой момент настанет) об исключении той или иной функции вами не владели эмоции и напряжённость ситуации, что может сказаться на принятии решения. Не должно быть никаких сомнений в том, какие функции обязательны, а какие — нет. Приоритетные функции данного выпуска должны быть ясны каждому участнику проекта.

Как это делается

Каждому требованию должен быть назначен тот или иной приоритет. Детализация приоритетов может быть любой, в зависимости от потребностей. Уровни приоритета можно определить следующим образом:

• Необходимые

Обязательно должны быть воплощены в программе, без этого её нельзя выпускать на рынок. Необходимые функции должны быть реализованы и испытаны как можно раньше; этому нужно уделить максимум внимания и все ресурсы.

• Желательные

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

• Возможные

Эти требования также желательны, но реализуются в последнюю очередь и являются первыми кандидатурами на удаление, если вдруг возникнут проблемы со сроками.

Утверждение требований

Многие ошибочно считают, что сформулировав требования, они готовы к распределению заданий и планированию проекта. Это не так. Нужно выполнить ещё два важных действия: провести техническую экспертизу основных факторов риска, связанных с технологиями, и создать прототип пользовательского интерфейса вашей программы. См. об этом главы 9 и 10.

Представим на минуту, что прототип пользовательского интерфейса уже готов и технологическая экспертиза закончена. Готовы ли вы поставить свою подпись на списке требований? Ещё нет. Нельзя утверждать требования, пока не составлен план работы. Может оказаться, что на исполнение плана должно уйти слишком много времени, и придётся отказаться от реализации части требований. Если требования уже утверждены, то может оказаться, что при их реализации не удастся уложиться в заданные временные рамки. Не стоит утверждать требования поодиночке, пока не будет ясности с другими требованиями.

Управление внесением изменений

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

Вот ряд фундаментальных принципов, которые нужно учитывать:

• Создавайте команду в составе менеджера проекта и всех руководителей групп, которая будет рассматривать все вносимые изменения

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