Текст книги "Сделано"

Перечислим еще несколько методов.

• Определить базовые показатели доверия прогнозам. Догадка = 40 % доверия. Обоснованный расчет = 70 %. Детальный и тщательный анализ = 90 %. Лидеры команды должны согласовать, какая точность им нужна, сколько времени они дают программистам на ее расчеты и как справиться с рисками, если прогнозы не оправдаются. Не зацикливайтесь на цифрах: используйте их просто для того, чтобы четко обозначить качество прогнозов. Доверие на уровне 90 % означает, что прогнозы оправдываются в 9 случаях из 10. Если вы решили попросить команду улучшить качество прогнозов, то нужно дать ей больше времени.

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

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

• Прогнозы зависят от того, насколько хорошо программист понимает цели проекта. Прогнозы строятся на том, как программист интерпретирует спецификации (если они есть), а также цели и задачи проекта. В своей книге «Психология программирования» (The Psychology of Computer Programming) (Dorset House, 1971) Джеральд Вайнберг показывает, как отсутствие понимания основных целей напрямую воздействует на предположения программистов. Даже если технологическая задача предельно ясна, подход программиста к ее решению может значительно измениться в зависимости от общего направления всего проекта.

• Прогнозы должны опираться на предыдущие результаты работы. Хорошая привычка для программистов – отслеживать свои прогнозы по проектам. Им следует обсуждать это со своим менеджером, который должен стремиться понять, кто в его команде делает грамотный «мониторинг». Экстремальное программирование использует термин производительность, когда речь идет о вероятных результатах работы программистов (или команды) в зависимости от их предыдущих результатов[28]28
  См. Kent Beck and Martin Fowler, Planning Extreme Programming (Addison-Wesley, 2002) (Бек К., Фаулер М. Экстремальное программирование. Планирование. СПб.: Питер, 2003), pp. 60–62.


[Закрыть].

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

• Существуют методы построения грамотных прогнозов. Самый известный из них – PERT[29]29
  PERT – Program Evaluation and Review Technique, метод оценки и анализа проектов. Стандартная формула: (оптимистический прогноз + (4 × наиболее вероятный прогноз) + пессимистический прогноз) / 6. Однако существует масса вариаций и теорий о том, как лучше рассчитывать взвешенную оценку.


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

САМЫЕ ЧАСТЫЕ УПУЩЕНИЯ

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

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

• Учтены в графике больничные и отпуска всех участников процесса?

• Заложены в график сезонные праздники или другие периоды года, когда работа заходит в тупик (например, со Дня благодарения до Рождества в США, лето в Европе)? Важные дедлайны крайне тяжело соблюдать в этот период.

• Был ли доступ к графику у членов команды? Просили ли их регулярно отчитываться о проделанной работе (не вызывая при этом раздражения)?

• Кто-нибудь следил за общим графиком ежедневно или еженедельно? Было ли у этого человека достаточно полномочий, чтобы задавать грамотные вопросы и вносить коррективы?

• Проявляла ли команда интерес к графику? Если нет, то почему? Участвовала ли она в построении графика и выборе задач, которые следует выполнить, или график спустили сверху?

• Лидеры команды добавили больше функций или помогли убрать больше функций? Лидеры команды когда-нибудь говорят «нет» на новые задачи и дают разумные указания команде о том, как отвечать на новые (поздние) задачи?

• Членов команды поощряют отказываться от новой работы, которая не вписывается в задачи и видение проекта?

• Какой процент вероятности был использован в прогнозах – 90 %, 70 %, 50 %? Это было отражено в общем графике? Клиент или вице-президент учитывали это? Обсуждались ли другие предложения, которые заняли бы больше времени, но имели более высокую вероятность?

• Выделено в графике время для его корректировки и дискуссий между лидерами и менеджерами?

• Учитывал ли график сокращение рабочих часов во время праздников? Внесены в график потенциально опасные погодные изменения?

• Были ли достаточно качественными спецификации и план проекта, чтобы разработчики сделали на их основе грамотные прогнозы?

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

ЭФФЕКТ СНЕЖНОГО КОМА

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

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

Рис. 2.4. Эффект снежного кома

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

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

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

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

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

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

• Запланируйте контрольные точки для обсуждения добавлений и исключений. График должен включать короткие периоды обзора, когда лидеры могут проанализировать текущие достижения и получить новую информацию или обратную связь от клиента. Это следует прописать в контракте. Во время обзора можно удалить некоторые задачи или добавить новые в соответствии с анализом текущей ситуации, который проводит руководство. Наилучшее время для этих обзоров – между этапами или, в виде исключения, в конце каждого этапа проектирования и разработки. Хотя их можно проводить в любое время, когда возникают серьезные опасения или явные несоответствия между планом и действительностью. Задачи этой дискуссии – вернуть проект к реальности, обновить график, заново выстроить приоритеты и приступить к следующему этапу с ясностью и уверенностью в том, что вас ждет (глава 14 и глава 15).

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

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

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

• Займитесь рисками на раннем этапе. Если вы знаете, что Салли работает над самым сложным компонентом, уделите этому особое внимание с самого начала. Чем выше риск, тем больше времени понадобится для его решения. Если оставить все уязвимые моменты на потом, у вас будет гораздо меньше свободы действий. То же касается политических, организационных и ресурсных рисков. Мы обсудим управление рабочими элементами и конвейер разработки в главе 14.

• Графики выполняют три функции: формулируют обязательства; позволяют каждому сотруднику увидеть, как его работа вписывается в общую картину; помогают отслеживать ход проекта. Даже когда график срывается, он не теряет ценности.

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

• Все прогнозы приблизительны, следовательно, и графики, состоящие из них, – тоже. Это говорит не в пользу надежности графиков, потому что приблизительность накапливается (80 % × 80 % = 64 %).

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

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

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

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

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

Г. В течение дня постарайтесь начинать и завершать работу над задачами точно вовремя. А затем подумайте, стоило ли оно того. Почему да или почему нет?

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

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

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

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

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

Глава третья. Как понять, что делать

* * *

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

Фред Брукс писал: «Самое сложное в создании программной системы – решить, что создавать. Ни одна другая часть концептуальной работы не таит столько проблем с определением подробных технических требований, включая пользовательские, аппаратные и программный интерфейсы. Ничто так не сказывается на результатах так сильно в случае ошибки. Исправлять здесь что-либо сложнее, чем где-либо. Так что самая важная функция, которую создатель программного продукта выполняет для клиента, – постоянный поиск и доработка требований к продукту».

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

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

Развенчание мифов планирования

Небольшой проект для внутреннего сайта с командой из одного человека не требует такого же процесса планирования, как проект на 300 человек и $10 млн для отказоустойчивой операционной системы. В целом, чем больше людей и взаимосвязей, тем больше «структурного порядка» они требуют. Однако даже простые проекты, где «в составе» один человек, получают огромную пользу от планирования. Оно дает возможность анализировать принятые решения, выявлять необоснованные допущения и добиваться согласия между отдельными людьми и организациями. Планы играют роль силовой функции против любых видов глупости, потому что требуют решать важные вопросы, пока еще есть время рассмотреть другие варианты. Как говорил Авраам Линкольн: «Если бы у меня было шесть часов, чтобы срубить дерево, четыре часа я бы потратил на то, чтобы наточить топор», – а это, на мой взгляд, означает, что грамотная подготовка сокращает объем работы.

Планирование проекта предполагает поиск ответа на два вопроса. Ответ на первый: «Что нам нужно сделать?» – принято называть сбором требований. Ответ на второй: «Как мы это сделаем?» – называют проектированием и спецификациями (рис. 3.1). Требование – подробное описание критериев работы. (К примеру, требование для приготовления ужина – подобрать недорогие ингредиенты и приготовить из них вкусное и питательное блюдо.) Грамотные требования легко понять и сложно переиначить. Могут быть разные способы спроектировать продукт в соответствии с требованиями, но итоговый результат должен сразу показывать, соблюдены они или нет. Спецификация – просто план создания продукта, который соответствует всем требованиям.

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

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

ТИПЫ ПРОЕКТОВ

Несколько критериев влияют на сбор требований и проектирование. Я возьму три простых и разноплановых примера, чтобы проиллюстрировать эти критерии[30]30
  Еще одно сравнение разных типов софтверных проектов см. http://www.joelonsoftware.com/articles/FiveWorlds.html.


[Закрыть].

• Супермен-одиночка. В самом простом проекте может участвовать только один человек. От программирования до маркетинга, бизнес-планирования и приготовления обеда – он все делает сам и сам себя финансирует.

• Небольшая команда на аутсорсинге. Созданием сайта или разработкой приложения занимается небольшая фирма из 5–10 программистов и одного менеджера. В договоре прописываются обязанности обеих сторон. По окончании срока договора заканчиваются и отношения, если клиент не предлагает новый контракт или проект.

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

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

КАК ОРГАНИЗАЦИИ ВЛИЯЮТ НА ПЛАНИРОВАНИЕ

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

• Кто определяет требования? Кто-то должен определить требования и получить по ним согласие от всех заинтересованных сторон (клиент или вице-президент). В случае супермена-одиночки это просто: он сам себе голова. У внештатной команды есть клиент, который жестко контролирует требования и, возможно, этап проектирования. И, наконец, в многочисленной команде есть комитеты или другие подразделения компании, которые эта команда обслуживает (и чье одобрение требуется в той или иной форме). Иногда требования делятся на общие («Это будет спортивный пикап») и конкретные («Наша цель – 12 литров на сто километров и полный привод»).

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

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

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

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

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

ОСНОВНАЯ ПРОЕКТНАЯ ДОКУМЕНТАЦИЯ

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

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

• Анализ требований рынка (marketing requirements document, MRD). Это анализ бизнес-команды или маркетинга. Цель – объяснить, какие бизнес-возможности существуют и как проект может использовать их. В одних организациях это справочный документ для тех, кто принимает решения. В других это основа проекта, и вся последующая работа опирается на нее. MRD помогает определить суть проекта.

• Документ-видение. Выстраивает все представления о проекте в единую структуру и опирается на MRD. Учитывает цели проекта, их обоснование, а также функции, требования и сроки по проекту (глава 4). Документ-видение – это суть проекта.

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

• Иерархическая структура работ (work breakdown structure, WBS). Спецификации детально описывают предстоящую работу, а WBS определяет, как команда разработчиков ее выполнит. Какие задачи нужно решить в первую очередь? Кто этим займется? На какие части можно разделить работу и как их отслеживать? WBS может быть предельно простой (таблица) или крайне сложной (графики и инструменты). В главе 7 и главе 13 мы рассмотрим разработку документов WBS. Она, в частности, определяет, как будет реализован проект с точки зрения команды. (На Agile-досках демонстрируются все карточки, которые можно преобразовать в WBS.)