■ Менеджеры низшего и среднего уровней являются исполнителями. В организации или ее подразделениях численностью 25 и менее сотрудников не должно быть «чистых» менеджеров. Необходимость в «чистых» менеджерах возникает только тогда, когда ресурсы рабочей силы превышают этот уровень. Непосредственные навыки управления могут разниться, но компетентные менеджеры обычно проводят большую часть времени, выполняя непосредственную работу, в частности, позволяющую в первую очередь понять состояние проекта, а также действия, связанные с разработкой планов и получением оценок. Более того, человек, управляющий некоей работой, должен планировать ее. Это не означает, что менеджер должен утверждать план; это означает, что менеджер должен принимать участие в его разработке. В независимых проектах, в оценке которых я принимал непосредственное участие, хорошим индикатором проблем оказывался менеджер, который не только не являлся автором плана, но и не признавал его. Это изменение прежде всего касается менеджеров проектов по созданию ПО.

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

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

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

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

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

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

■ Реальные проблемы выявляются и решаются систематически.

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

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

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

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

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

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

j.

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

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