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

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

В данном исследовании группа R&D Effectiveness компании Alcatel проанализировала продукты и решения своих бизнес-подразделений. Были выделены четыре на первый взгляд успешные методики управления жизненным циклом продукта. Проведена количественная оценка влияния этих методик на выполнение соответствующих проектов. Результаты исследования показали, что одновременное применение всех четырех методик действительно позволяет значительно сократить задержки при выполнении проекта.

Требования и жизненный цикл продукта

Для того чтобы создать успешный продукт, необходимо определить потребности рынка и на их основе сформулировать цели и назначение продукта, которые затем реализуются в соответствии с четкими принципами управления проектом. Управление продуктом — это контроль продукта с момента его замысла до выпуска, с тем чтобы добиться максимальной пользы для компании. Требования — это своего рода строительные блоки, объединяющие различные этапы жизненного цикла продукта. Под жизненным циклом продукта мы понимаем совокупность всех операций, необходимых для того, чтобы описать, разработать, реализовать, скомплектовать, использовать, обслуживать и прекратить выпуск продукта и его соответствующих вариантов. Тем не менее, согласно отчету 2003 CHAOS, лишь 52% первоначально установленных требований к продукту находят свое отражение в его окончательной версии [2].

Согласно традиционному эмпирическому правилу определения требований, следует рассчитывать на то, что каждый месяц будут меняться от 1 до 3% всех требований. Таким образом, в проекте, запланированном на два года, меняется (добавляется, удаляется или модифицируется) свыше 30% требований. Поскольку такие изменения почти всегда приводят к переносу сроков выполнения проекта, многие подрядчики и клиенты предпочитают проекты, рассчитанные не более чем на год. Исследование показало, что такие проекты выполняются лучше [2], но сокращение длительности проекта и выбор подхода, предусматривающего итерационную работу, не всегда решают проблему.

Для того чтобы сократить количество изменяемых требований, необходимо эффективное управление жизненным циклом продукта, которое предусматривает анализ и совместную работу над продуктом в течение всего времени его существования и позволяет тем самым добиться наибольшей пользы для предприятия, его акционеров и клиентов. На рис. 1 показан упрощенный жизненный цикл продукта, которого придерживается Alcatel и многие другие компании. Предварительный (upstream) процесс охватывает все операции, предшествующие первой точке принятия решения (точка «1» на рис. 1), а основные (downstream) процессы включают в себя все операции между точками 1 и 3. (Как правило, жизненный цикл продуктов соответствует стандартам IEEE 12207 или IEEE 1074, которые описывают процесс контроля (или анализа), выполняемого между основными этапами [5]).

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

Несмотря на то что теория и практика управления проектами и инженерии требований (requirement engineering, RE) особое внимание уделяют основным процессам [1-3], никаких серьезных исследований на предварительном этапе они не предусматривают, даже, несмотря на то, что предварительные процессы тоже входят в состав RE. Зачастую так происходит из-за сложности этих процессов (т. е., из-за их гетерогенного характера, отсутствия четкого разделения ответственности за выполнение этих процессов, неясности их состава и непонятного влияния на доходы акционеров). В лучшем случае предварительные операции упоминаются в процессе формулирования требований. Больше всего серьезной реализации предварительных процессов мешает тот факт, что руководители компаний отвечают за прибыли и убытки в краткосрочной перспективе, что вынуждает их сосредоточиваться на результатах текущего квартала (т. е., выполняемых в данных момент проектах и контрактах), а не на будущих продуктах и платформах. Во время исследования мы ставили своей целью изучить в рамках дисциплины RE процессы жизненного цикла продукта, такие как выполнение анализа в контрольных точках или создание наделенных полномочиями проектных групп.

Мы посчитали это важным, поскольку плохо реализованные предварительные процессы могут привести к неэффективному планированию проекта в целом, вызвать постоянное изменение требований и назначения проекта, задержки в выполнении этапов, проблемы с конфигурацией, дефекты и общую неудовлетворенность пользователей (из-за невыполненных обещаний или неоправдавшихся ожиданий). В 2004 году Роберт Купер изучал процесс разработки нового продукта в 105 бизнес-подразделениях американских компаний, работающий в самых разных отраслях [6]. Он пришел к выводу, что 20% лучших компаний создание 79% своих новых продуктов завершают в срок, в то время как для средних компаний этот показатель составляет всего 51%. Более того, среди того же самого набора компаний с самым высоким рейтингом 66% распределяли свои ресурсы в соответствии со стратегическими задачами, и только 31% средних компаний согласовывали использование ресурсов в проекте со стратегическими задачами.

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

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

Исследование в Alcatel

Компания Alcatel, 56 тыс. сотрудников которой работают в 130 странах мира, разрабатывает технологии и предлагает решения для телекоммуникационных операторов, провайдеров Internet и предприятий. Наша цель заключалась в том, чтобы понять, как уменьшить задержки при выполнении проекта. (Мы не анализировали влияние на объем продаж, доходы или уровень удовлетворенности пользователей, поскольку ситуация на рынке может серьезно изменить эти параметры, в силу чего их трудно сравнивать для разных проектов). Мы анализировали все проекты, о которых в нашей базе данных имелась достоверная информация и которые выполнялись с января 2002-го по октябрь 2003 года. Мы не выбрасывали никакие из «резко отклоняющихся значений», в силу чего не могли не учесть влияния других параметров, помимо выделенных нами четырех методик. По трудозатратам размер анализируемых при исследовании проектов колебался от нескольких человеко-недель до нескольких сотен человеко-лет.

Мы разбили свое исследование на два этапа. На первом этапе мы собрали факты и провели детальный анализ причин на достаточно малой выборке (одна репрезентативная серия продуктов). Мы тщательно оценили все проекты в этой репрезентативной серии продуктов для того, чтобы лучше понять, почему во время выполнения проектов требования меняются. Серия продуктов, использованная для этого анализа состояла из 15 проектов, которые были выполнены в 2002 году. В среднем в этих проектах после их начала было изменено около 73% требований. Треть этих изменений были техническими (например, невыполнимая спецификация), а две трети были обусловлены коммерческими причинами (и на их долю приходилось подавляющее большинство нечетких требований). Как правило, эти изменения предусматривали удаление или замену требований, но, поскольку требования имеют разное влияние и предусматривают разные трудозатраты, замена одного на другое не всегда позволяла сократить трудозатраты на реализацию всего проекта в целом.

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

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

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

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

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

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

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

Продолжительность проекта в нашем исследовании мы измеряли как время, прошедшее с момента контрольного анализа, который отмечал начало реализации проекта (рис. 1, контрольная точка 2) и до момента контрольного анализа, в результате которого было принято решение о передаче проекта клиенту или о выпуске продукта (рис. 1, контрольная точка 3). Перед началом проекта управляющая группа должна сообщить точную дату его окончания и указать ее вместе с другими данными планирования. Поэтому, для того чтобы измерить задержку проекта (и тем самым точность соблюдения сроков), мы сравнивали запланированную дату окончания проекта с реальной датой его завершения. Мы нормализовали полученное в календарных днях абсолютное значение по изначально заявленной продолжительности проекта, тоже указанной в календарных днях. Например, если первоначально проект планировалось выполнить за 100 календарных дней, а в действительности он заканчивался через 120 дней, то задержка по проекту составляла 20% и точность соблюдения сроков — 120%. Этот параметр — зависимая переменная, которую мы анализировали во время исследования.

Данные о проектах, полученные в результате исследования

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

Благодаря тому что эти методики применялись в самом разном порядке и с различными темпами, мы могли соотнести результаты (задержку проекта) с числом использованных методик. Мы пришли к выводу, что точность соблюдения сроков не зависит от размера проекта, учитывая большой диапазон масштабов проектов, присутствовавших в нашей выборке [7]. Так что меньшие по размеру проекты не обязательно выполняются лучше более масштабных. Фактически проекты, не завершенные в срок, оказались почти равномерно распределены по всему диапазону размеров проектов. Коэффициент ранговой корреляции Пирсона r = 31% показывает, что между размером проекта и задержкой при его выполнении нет никакой связи. Для оценки связи четырех методик с размером проекта использовался двухсторонний критерий хи-квадрат. Критерий показывает, что гипотезу об однородности (статистический тест) можно принять на уровне значимости a = 1%. Использование любой конкретной методики не зависело от размеров проекта.

Мы также установили, что ни одна из четырех методики не коррелирует с другой — для любой пары из четырех методик критерий показывает, что гипотезу однородности можно принять на уровне значимости a = 5% (или ниже), что подтверждает отсутствие корреляции при их применении.

Четыре методики

На рис. 3 приведены общие результаты анализа влияния на продолжительность проекта всех четырех методик. При использовании трех или четырех методик точность соблюдения сроков значительно увеличивалась. Применение одной или двух методик, как и отсутствие всех, не оказывало существенного влияния на задержку в сроках реализации проекта. Двухсторонний критерий хи-квадрат подтверждает гипотезу однородности на уровне значимости a = 1%. При использовании трех или четырех методик число проектов, выполненных в срок, увеличивалось на 20%. В той же ситуации (три или четыре методики) количество проектов, которые были задержаны не более чем на 5% времени, возрастало с 45 до 63%, а проектов, которые были задержаны на 10% времени, увеличивалось с 56 до 77%.

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

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

Создание эффективной управляющей группы для каждой версии продукта

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

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

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

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

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

Концентрация на анализе в контрольных точках

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

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

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

Оценка требования с разных точек зрения

Требования должны оценивать все члены управляющей группы, чтобы тем самым гарантировать, что ситуация изучена со всех сторон. Группа должна обсуждать каждое требование и определять конкретные практические ситуации, в которых оно играет важную роль, что необходимо для корректного внесения изменений и установки приоритетов. Зачастую, исходя из ошибочной трактовки требований рынка, формируется неверный состав проекта, что в итоге вынуждает постоянно менять требования. Анализ влияний, таким образом, базируется на требованиях [8], а также на определении приоритетов и управлении портфелем — динамическом процессе принятия решения, направленном на создание правильного сочетания продуктов и выбор правильных проектов для реализации данной стратегии [4, 9].

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

Взаимосвязь состава портфеля и отдельных продуктов

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

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

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

***

Проекты, которые мы оценивали, несмотря на то, что они в первую очередь относятся к встроенным системам и программным приложениям, охватывают широкий диапазон проектов, где главную роль играет программное обеспечение, поэтому результаты исследования применимы не только к отрасли телекоммуникаций. (Этот вывод подтверждают и тесты на производительность, которые мы выполняли для автомобильной и оборонной отраслей, а также для рынка информационных систем [3, 4]). Интеграция предварительных процессов с процессами RE, касающимися жизненного цикла продукта, могут помочь сократить задержки более чем на 20% в год.

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

Литература

  1. M. Chrissis, M.Konrad, S. Shrum, CMMI: Guidelines for Process Integration and Product Improvement. Addison-Wesley, 2003.
  2. CHAOS Chronicles v. 3.0, The Standish Group Int'l, 2003; www.standishgroup.com/chaos/toc.php.
  3. W. Royce, Software Project Management, Addison-Wesley, 1999.
  4. C. Ebert et al., Best Practices in Software Measurement, Springer, 2004.
  5. M. McGrath, Next Generation Product Development: How to Increase Productivity, Cut Costs, and Reduce Cycle Times, McGraw-Hill, 2004.
  6. R. Cooper et al., Benchmarking Best NPD Practices: Research-Technology Management, Part I, 2004, Part II, 2004, Part III, 2004.
  7. C. Ebert, Requirements BEFORE the Requirements: Understanding the Upstream Impacts, Proc. Int'l Conf. Requirements Eng. (RE 05), IEEE CS Press, 2005.
  8. J. Giesen, A. Voelker, Requirements Interdependencies and Stakeholder Preferences, Proc. Int'l Conf. Requirements Eng. (RE 02), IEEE CS Press, 2002.
  9. L. Gorchels, The Product Manager's Handbook: The Complete Product Management Resource, McGraw-Hill, 2000.
  10. J. Doerr, B. Paech, M. Koehler, Requirements Engineering Process Improvement Based on an Information Model, Proc. Int'l Conf. on Requirements Eng. (RE 04), IEEE CS Press, 2004.

Кристофер Эберт (christofebert@ieee.org) — директор компании Alcatel по исследованиям и разработкам, член Alcatel Technical Academy, имеет сертификат преподавателя CMMI.

Christof Ebert, Understanding the Product Life Cycle: Four Key Requirements Engineering Techniques, IEEE Software, May/June, 2006. IEEE Computer Society, 2006, All rights reserved. Reprinted with permission.