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

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

Если представить себе идеальный мир, в котором все происходит согласно плану, то наш проект должен безошибочно идти правильным путем, чтобы к назначенной конечной дате был бы получен финальный результат.

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

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

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

Важно осознавать, что любой проект характеризуется тремя факторами:.

• возможности создаваемого продукта;.

• стоимость работ;.

• сроки завершения.

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

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

Рис. 8.1 Взаимосвязь возможностей продукта, стоимости и сроков разработки.

8.2 Проблемы управления процессом разработки требований.

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

Первой проблемой является то, что не так уж много людей владеют достаточным опытом управления требованиями. Это, в свою очередь, связано с тем, что лишь очень немногие организации имеют хорошо поставленный внутренний процесс управления требованиями. В результате люди, сталкивающиеся на проекте с необходимостью работать с требованиями, оказываются просто не готовы к этому. В такой ситуации дать оценку планируемого времени и трудозатрат невероятно трудно, поскольку одним из основных элементов хорошей оценки как раз и является соответствующий значительный опыт. Следовательно, в этом случае все выглядит не очень хорошо уже с самого начала. Тут уместно вспомнить шутку, когда один человек спрашивает другого о том, как ему попасть в определенное место, и в качестве ответа получает: «На вашем месте я бы не стал отсюда добираться туда»!.

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

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

Третьей основной проблемой является то, что процесс управления требованиями в значительной степени зависит от типа конкретной организации. В предыдущих главах мы обсуждали различные типы требований и взаимосвязи между ними. Однако сам процесс формирования и управления требованиями и их взаимосвязями будет отличаться в зависимсоти от организации.

На наш взгляд существует три основных типа организаций:.

• Организация-покупатель - приобретает системы и использует их для своих собственных нужд. Главной задачей для организаций такого типа является разработка и управление пользовательскими требованиями, которые впоследствии используются для приемки системы.

• Организация-поставщик - отвечает на запросы организации-покупателя или организации-поставщика более высокого уровня. Организации такого типа обычно получают входящие требования и на их основе разрабатывают системные требования (и далее - спецификации системы).

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

• Организация-производитель - организация, которая разрабатывает и продает продукт. Организация такого типа формирует пользовательские требования для своих продуктов скорее под влиянием рынка, нежели общаясь с конкретными пользователями или организациями. Сбором требований в такой организации обычно занимается отдел маркетинга. Организация-производитель разрабатывает продукт в соответствии с пользовательскими (рыночными) требованиями и затем продает его.

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

Мы еще вернемся позднее к этой теме в данной главе.

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

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

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

8.2.1 Выводы.

Основные проблемы, возникающие при управлении процессом разработки требований, связаны с:.

• планированием;.

• контролем за ходом выполнения работ;.

• контролем над изменениями.

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

В заключительном разделе главы сформулированы некоторые общие подходы к управлению процессом разработки требований.

8.3 Управление требованиями в организации-покупателе.

8.3.1 Планирование.

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

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

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

Этот план может включать следующие действия:.

1.

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

2.

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

3.

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

4.

Перед интервью бывает полезно (но не всегда обязательно) собрать вместе всех кандидатов от заинтересованных сторон для того, чтобы объяснить цель предстоящих интервью. Такое общее собрание дает прекрасную возможность обсудить и разработать пользовательские сценарии, и лишний раз убедиться, что все типы заинтересованных сторон правильно определены.

5.

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

6.

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

7.

Продумать, создать и согласовать структуру пользовательских требований, в которую они будут в дальнейшем размещаться.

8.

Разместить каждое из полученных пользовательских требования в разработанную структуру (при необходимости структура может изменяться).

9.

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

10.

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

11.

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

12.

Определить процесс рецензирования требования и увязать его со значением статуса последнего. Пример процесса рецензирования представлен на рис. 8.2 в виде диаграммы переходов состояний статуса требования. Начальным значением статуса требования является значение «Предложено». Требование в этом статусе должно быть.

Необходимо отметить, что в любой момент требование, находящееся в фазе «Активно», может сменить свой статус на «Отклонено».

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

13. Выполнить рецензирование в соответствии с разработанным процессом и критериями рецензирования.

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

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

Одним из ярких примеров нереальных ограничений по срокам выполнения является проект по разработке системы управления службой скорой помощи Лондона, выполнявшийся в начале 90-х. Руководителям службы эта система нужна была для того, чтобы предоставлять властям необходимую статистику работы организации. В результате, в качестве ограничений были установлены очень короткие сроки реализации проекта и назначена ранняя дата вввода системы в промышленную эксплуатацию. Соблюсти такие сроки было невозможно. Многие компании-разработчики, участвовавшие в тендере, пытались уговорить руководство службы скорой помощи увеличить сроки реализации проекта и отодвинуть дату вввода системы в эксплуатацию, но руководство службы скорой помощи было непреклонно. В результате большинство компаний, в конце концов, отказалось от участия в тендере, а оставшиеся (менее опытные разработчики) все еще пытались выдержать поставленные ограничения по срокам. В итоге проект был полностью провален. И более того, этот проект принес ущерб многим людям.

Этот пример лишний раз подтверждает, что реализм в планировании является признаком честности и профессионализма руководителя.

8.3.2 Контроль за ходом выполнения работ.

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

Для успешного мониторинга за всем остальным процессом могут помочь три основные контрольные точки:.

• определение структуры спецификации требований;.

• определение атрибутов каждого из требований;.

• определение процесса рецензирования требований в соответствии с перечнем критериев рецензирования.

Если структура спецификации требований сформирована, то становится достаточно легко определить, где требования уже сформулированы, а где в структуре (в документе) пока еще остаются незаполненные места. Такие «дыры» можно легко найти и принять меры к их устранению.

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

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

8.3.3 Изменения.

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

Обычно этот момент наступает тогда, когда все требования прошли полный цикл рецензирования и перешли в статус «Одобрено» (см. рис. 8.2).

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

• использование пользовательских требования для конкурентного выбора поставщика;.

• заключение контракт на разработку системы;.

• завершение разработок спецификаций и начало производства системы;.

• выполнение приемочных тестов и эксплуатационных испытаний системы;.

• эксплуатация системы в промышленных условиях.

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

На какой бы стадии не находился ваш проект, процесс управления изменениями требует обязательного выполнения следующих шагов:.

1.

зафиксировать предлагаемое изменение;.

2.

определить влияние предложенного изменения;.

3.

решить - принять или отклонить предложенное изменение - и, если принять, то:.

4.

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

Предлагаемое изменение должно содержать обоснование изменения (причину) и ссылку на требование (возможно, на несколько), которое должно быть изменено, удалено или добавлено. Необходимо, чтобы и имя автора, вносящего изменение, было зафиксировано как один из обязательных параметров.

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

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

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

Всегда полезно представлять процесс управления изменением в виде диаграммы состояний (диаграммы переходов состояний). Рис. 8.3 демонстрирует такой пример.

Также важно с самого начала определить, будет ли меняться значение статуса требования, в отношении которого вносится изменение, чтобы отобразить этот факт. Существует два разных подхода к решению данного вопроса. Одна группа специалистов считает, что взаимосвязь между изменением и самим требованием, так или иначе, храниться в рамках предложения на внесение изменения и, следовательно, нет нужды менять статус самого требования. Другая группа считает, что если принимается решение внести изменение, то конкретное требование как раз и становится тем объектом, в который вносится изменение, а, следовательно, значение статуса требования также должно меняться, чтобы по статусу самого требования можно было бы в данный момент определить значение статуса предложенного изменения. (Именно такой подход применялся нами в главе 2.).

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

Рис. 8.3 Диаграмма переходов состояний управления изменениями.

В заключение перечислим основные отличительные черты процесса управления требованиями в организации-покупателе.

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

В самом начале работы процесс внесения изменений имеет незначительную степень формализации, которая постоянно увеличивается по мере развития проекта.

8.4 Управление требованиями в организации-поставщике.

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

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

8.4.1 Подготовка коммерческого предложения.

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

Планирование.

Очень часто начальной точкой работ по проекту внутри организации-поставщика является приглашение к участию в тендере (invitation to tender = ITT) или запрос на коммерческое предложение (request for proposal = RFP). Такое приглашение или запрос содержат целый список требований, которым должна удовлетворять будущая система.

Характер полученных требований будет зависеть от типа клиентской организации, которая прислала приглашение к участию в тендере. Если клиентская организация является конечным потребителем, заказывающим систему для собственных нужд, то, вероятнее всего, полученные требования будут являться пользовательскими. В другом случае клиентская организация может быть сама поставщиком (разработчиком), желающим найти субподрядчика для выполнения части работ, например, для разработки подсистем иили компонентов системы. Тогда, вероятнее всего, организация-поставщик получит на входе системные требования и определенные ограничения относительно их реализации. Для того, чтобы избежать путаницы и сделать дальнейшее изложение более понятным и наглядным, мы будем называть требования, полученные от клиентской организации, входящими, независимо от их реального характера.

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

• четко выраженными и отделенными от информации описательного характера;.

• однозначными (недвусмысленными);.

• непротиворечивымыми (совместимыми);.

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

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

С точки зрения планирования, самым первым показателем предстоящего объема работ является количество полученных требований.

В процессе оценки и анализа входящих требований необходимо постараться выявить возможные проблемы и предложить потенциальные способы их решения, например, измененить формулировки некоторых требований или даже предложить взамен другие требования, которые, вполне возможно, могли бы быть удовлетворены уже готовым («коробочным») компонентом.

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

В этой ситуации можно рекомендовать три основных варианта развития событий:.

• полностью проигнорировать проблему;.

• сделать какое-то предположение (допущение), позволяющее устранить проблему, и,.

зафиксировав его документально, двигаться дальше;.

• принять решение, что, независимо от последствий, необходимо запросить заказчика.

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

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

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

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

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

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

Для больших проектов объем информации, которую собирает команда, может быть просто огромным, как и интервал времени между отсылкой предложения и началом реализации системы после победы в тендере (например, 6-8 месяцев). В подобном случае, еще более важно фиксировать всю собранную информацию в процессе подготовки предложения, поскольку специалисты, принимавшие участие в разработке предложения, могут и не войти в состав команды, которая будет реализовывать проект. Или - в случае включения в команду разработки - эти специалисты по истечении столь большого промежутка времени могут просто забыть часть информации или некоторые ключевые допущения и идеи.

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

Контроль за ходом выполнения работ.

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

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

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

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

Изменения.

Можно отметить следующие источники изменений, характерные для процесса подготовки коммерческого предложения:.

• заказчик;.

• поставщики (субподрядчики);.

• внутренние источники.

Можно, конечно, предположить, что заказчик не будет менять условия тендера (требования) в процессе подготовки коммерческого предложения, и в идеале это предположение справедливо. Однако, для собственной же пользы, на это не стоит надеяться. Обычно вероятность возникновения изменений связана прямопропорциональной зависимостью с размером создаваемой системы (или компонента). Для очень больших систем поставщики обычно начинают подготовку своих коммерческих предложений сразу же после получения первой черновой версии запроса на коммерческое предложение (RFP). Это необходимо для того, чтобы раньше включиться в процесс подготовки и заставить команду двигаться в нужном направлении. Разумеется, что с течением времени заказчик создает новые версии требований, которые могут содержать изменения и которые приходится отрабатывать, внося соответствующие коррективы в работу.

Самой первой задачей после получения новой версии RFP (или просто отдельного списка требований) является определение объема и характера изменений. В зависимости от желания заказчика и способа рассылки новой версии запроса (или списка требований) изменения могут быть как-то отмечены в документе, а могут быть совершенно «невидимы». Тем не менее, каждое из обнаруженных изменений должно быть соотнесено с уже выполненной работой, после чего должен быть оценен объем и план новых работ, и лишь после этого можно приступать к переделкам, если это необходимо.

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

Изменения, поступающие от поставщиков (субподрядчиков), более вероятны. Зачастую изменения поступают сразу и из-за того, что субподрядчик находит во входящих требованиях такие, которые он никак не может удовлетворить. Или изменения могут поступить позднее, если субподрядчик обнаружит, что он не может выполнить то, что вначале не вызывало у него сомнений.

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

• входящие требования;.

• требования для поставщиков и субподрядчиков (можно назвать их исходящими);.

• допущения, предположения и интерпретации, сделанные командой, разрабатывающей.

коммерческое предложение.

8.4.2 Выполнение проекта Планирование.

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

На стадии разработки все задачи должны быть определены более подробно, нежели чем на стадии подготовки коммерческого предложения. Более того, само коммерческое предложение, принятое заказчиком, на стадии разработки может уже рассматриваться как часть входящих требований.

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

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

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

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

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

Не мешает также обсудить с заказчиком оставшиеся допущения и замечания (хотя лучше было бы это делать в процессе обсуждения контракта).

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

С точки зрения управления требованиями каждый релиз системы должен строиться на некотором наборе требований, которые и предполагается воплотить именно в данном релизе. Такой подход может быть легко реализован, если у каждого требования появится специальный «релизный» атрибут. Это может быть атрибут либо булева типа, либо перечислимого. Для перечислимого типа возможный список значений может выглядеть следующим образом:.

{ TBD, Релиз 1, Релиз 2, Релиз 3 } ,.

где TBD (to be decided = «необходимо определить») обычно является значением по умолчанию, т. е. определяет некий первичный набор реализованных требований. Для булева типа атрибута, как известно, возможно иметь всего два значения, поэтому атрибут такого типа применяют, в случае если запланировано всего два релиза системы.

Контроль за ходом выполнения работ.

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

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

Еще одной задачей руководителя является контроль за актуальность (обновлением) всей проектной документации. Это особенно важно при внесении изменений во входящие требования. Необходимо, чтобы производные требования и, соответственно, все связи между входящими и производными требованиями были также скорректированы в соответствии с принятыми изменениями. Это же относится и к обновлению требований и связей между ними на всех других уровнях.

Изменения.

Причины возникновения изменений на стадии разработки ничем не отличаются от трех перечисленных ранее причин возникновения изменений на этапе подготовки коммерческого предложения. Хотя объем изменений со стороны заказчика здесь обычно меньше, чем на этапе тендера. А вот объем внутренних изменений и изменений со стороны субподрядчиков, напротив, гораздо больше. Процедура определения характера и последствий изменений также ничем не отличается от описанной ранее. Однако следует заметить, что изменения, вносимые в процессе разработки, могут иметь гораздо более серьезные последствия. Небольшие изменения в процессе тендера могут быть легко приняты всеми сторонами без каких-либо дополнительных затрат. Более серьезные изменения могут привести лишь к корректировке условий договора. В то время как изменения, вносимые в процессе разработки, обычно приводят к изменению сроков и стоимости проекта. После определения возможных последствий изменений, задачей руководителя является принятие решения о том, может ли компания взять на себя дополнительные затраты по реализации этих изменений или же необходимо обсудить их с заказчиком иили субподрядчиками.

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

Суммируя все вышесказанное, можно отметить следующие основные положения. Организации-поставщики, участвуя в тендере, готовят коммерческие предложения и, если выигрывают тендер, приступают к разработке системы. Хорошо разработанные входящие требования невероятно важны как основа для дальнейшей разработки системы. Для успешного выполнения проекта необходимо всегда иметь «свежие» (обновленные) версии входящих требования. Наличие связей (трассировки) между входящими требованиями, производными требованиями всех уровней, требованиями для субподрядчиков, тестовой информацией позволяет правильно оценивать влияние предлагаемых изменений, и всегда иметь представление о ходе выполнения работ по проекту.

8.5 Управление требованиями в организации-производителе.

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

8.5.1 Планирование Продукт с одной версией.

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

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

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

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

Рис. 8.4 «Ворота стадий» и работа над проектом.

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

Если принято решение продолжить проект, то следующая стадия (Ворота стадии 1) может начаться только после того, как для нее определены собственные цели, бюджет и временные рамки. Для второй стадии может быть, например, принято решение сделать коммерческое предложение с подробным расчетом стоимости и более детальным исследованием объемов рынка сбыта.

Можно предположить, что целью следующих «ворот» будет оценка предполагаемой прибыли от реализации системы по отношению к предполагаемым затратам. Это опять же приведет к необходимости принятия решения относительно целесообразности продолжения работ по проекту. Если будет решено продолжить инвестировать проект, то возникнет необходимость принять решение об объеме работ для следующей стадии, например, это может выглядеть так:.

• более подробно оценить стоимость разработки и производства системы;.

• разработать прототип;.

• создать упрощенные комплекты системы и раздать их на пробную эксплуатацию реальным потребителям (а-, Р-тестирование);.

• запустить производство в полном объеме;.

• и т. д.

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

Несколько продуктов и версий.

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

Еще один фактором, который необходимо принимать во внимание, является возможное наличие различных версий продукта, предназначенных для различных рынков. Например, необходимо иметь продукт, пользовательский интерфейс которого поддерживает разные языки, чтобы иметь возможность продаваться в разных странах мира.

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

На рис. 8.5 схематично показаны несколько параллельных модификаций одного и того же продукта, каждая их которых имеет несколько версий, находящихся на разных стадиях своего жизненного цикла. Буквы S, D, U обозначают различные фазы разработки продукта.

- разработку спецификаций (specification), производство (development) и коммерческую эксплуатацию (use). С точки зрения метода «ворота стадий», каждой из этих фаз соответствует одна или несколько стадий жизненного цикла продукта.

Рис. 8.5 Версии и модификации.

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

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

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

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

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

8.5.2 Контроль за ходом выполнения работ.

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

• созданы ли новые артифакты, которые могут служить объектами трассировки (например, элементы решения, связанные с пользовательскими требованиями, или элементы спецификаций, соответствующие системным требованиям);.

• заполнены ли значения атрибутов;.

• определены ли статусы проверки;.

• существуют ли необходимые связи (трассировка) от одних наборов данным к другим (например, связи между пользовательскими и системными требованиями; или связи между системными требованиями и элементами спецификации; или в целом - связь от требований к стратегии проверки и далее к результатам выполнения тестов).

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

8.5.3 Изменения.

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

• должно ли вносимое изменение затрагивать все модификации продукта?;.

• когда данное изменение должно быть внесено в каждую из модификаций?.

Нетрудно угадать наиболее распространенный ответ - изменение должно быть внесено во все модификации, но не одновременно!.

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

Рис. 8.6 Диаграмма переходов состояний для управления изменениями требований для.

модификаций.

Из рис. 8.6 видно, что для каждой модификации вносимые изменения должны иметь свои собственные значения состояний «Запланировано», «Отложено», «Включено». При этом значение «Выполнено» состояние первичного изменения может принять только после отработки его по всем модификациим продукта.

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

8.6 Заключение.

Информация в заключении специально сгруппирована под теми же заголовками, что и последовательность материала, изложенного в данной главе.

8.6.1 Планирование.

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

Конечными результатами могут быть:.

• различные объекты информации (например, список заинтересованных сторон, пользовательские требования, системные требования, элементы спецификации или решения);.

• атрибуты, относящиейся к соответствующим информационным объектам;.

• связи между объектами информации, необходимые для организации трассировки, стратегией проверки, контроля изменений и т.п.;.

• критерии для рецензирования и анализа качества информационных объектов и их атрибутов;.

• достижение определенных состояний объектов (например, последовательная смена значений статуса рецензируемого требования по результатам его анализа).

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

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

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

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

8.6.2 Контроль за ходом выполнения работ.

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

8.6.3 Изменения.

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

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