Decision gate: пересмотр выделения ресурсов
В ISO 15288 используется термин decision gate, для которого было принято неочевидное решение передавать его на русском как пересмотр выделения ресурсов. Понятие decision gate является одним из центральных в подходе жизненного цикла: к нему привязаны контроль времени, выделение ресурсов, риск-ориентированность, проверка соответствия требованиям, входные и выходные условия стадии, контроль целостности проекта-design и т.д. Поэтому предложенный перевод "пересмотр выделения ресурсов" нужно тщательно обосновать.
Термин decision gate отражает один из возможных подходов к определению формы жизненного цикла (последовательности расположения стадий ЖЦ), в котором стадийная работа перемежается специально организованным рассмотрением результатов этой работы. ISO 15288 недвусмысленно требует, чтобы между стадиями по их итогам обязательно было организовано принятие решений -- и вводит для этого decision gates. В литературе управления жизненным циклом (часто под другими именами -- product delivery, software process и т.д.) этот подход давно известен, а на русский gate незамысловато транслитерируется как "гейт".
Но "гейт решения" -- не перевод, а транслитерация. К тому же понятие decision gate не так легко понимается и принимается инженерами (особенно, если эти инженеры представляют заинтересованную сторону разработчиков, а не владельцев ресурсов), а стандарт ISO 15288 совсем не зря требует наличия пересмотра выделения ресурсов.
Можно было бы использовать метафору и перевести decision gate как "шлюз". Действительно, все результаты проекта как бы собирают в межстадийной шлюзовой камере, закрывая затем проход как назад, так и вперед без того, чтобы владельцы ресурсов тщательно не проинспектировали собранное, а затем принимают решение о пропуске вперед или возврате назад на основании результатов такого рассмотрения. Но слово "шлюз" тут лишь чуть лучше транслитерации "гейт".
Gate является одним из специальных видов milestone -- контрольных точек проекта и отличается тем, что обязательно находится между стадиями. Другие контрольные точки могут быть расставлены в графике проекта для удобства отслеживания реальной скорости его прохождения по сравнению с плановой скоростью -- а это не имеет отношения ни к стадиям, ни к принятию каких-то решений о переходе от стадии к стадиям. Именно поэтому в ISO 15288 говорится не просто о milestone, а о gates, и не просто о gates, а о decision gates.
В стандарте языка описывания (metamodel) методов управления жизненным циклом (systems and software process engineering) OMG SPEM 2 оговаривается, что milestones (и, следовательно, decision gates как подвид milestone) в речи обычно означает как точку во времени, так и связанную с этой точкой работу (общее название для независимых от времени практик-мероприятий-дел и разворачивающихся во времени процедур-стадий-пересмотров-проектов). Поэтому SPEM 2 рекомендует моделировать milestones через работы (Work Definition). Gate -- это межстадийный milestone. Какая работа проводится в gates? По-английски эта работа обычно называется review -- буквально "пересмотр". Какие решения пересматриваются? Как решения разработчиков (проектные решения, включая требования), так и решения по выделению ресурсов. Какие решения принимаются по итогам этого межстадийного пересмотра? Обычно это решения о выделении ресурсов для продолжения проекта. Это продолжение проекта может быть 4 видов:
-- переход к новой стадии (с утверждением новых требований и нового финансирования)
-- доработки в рамках предыдущей стадии
-- прекращение всего проекта
-- пропуск следующей стадии ввиду незначительных рисков (например, выполняется уже десятый однотипный проект, и архитектура системы давно устоялась -- поэтому сразу после Исследований идет Разработка, пропуская стадии Оценивание и Основание).
Эти четыре варианта представляются осмысленными для любого метода управления жизненным циклом, использующим принцип decision gates. Они были взяты из метода пошагового выделения ресурсов (Incremental Commitment Model, ICM), в котором был обобщен опыт десятка популярных методов управления жизненным циклом (http://ailev.livejournal.com/691464.html).
Почему не передать decision gates как "решение о выделении средств", не используя слово "пересмотр", а передавая gate через его природу ("выделение средств [на следующую стадию]"), а decision привычно как "решение"?
Во-первых, "решение" не имеет оттенка работы, уж скорее это слово указывает просто факт и момент его принятия. Поэтому планировщики проекта могут не отвести достаточного времени для содержательного рассмотрения результатов стадии и не предусмотреть выделения средств для "решения". Слово "пересмотр" подразумевает все-таки какое-то действие, пересмотр может занять время. Более того, "решение" можно спутать с простым "go - no-go" (и так часто и пишут). На самом деле решение может касаться и других аспектов: изменения требований, изменения финансирования (как в сторону его уменьшения, так и в сторону увеличения), изменения длительности следующей стадии и т.д. Речь именно о "пересмотре".
Во-вторых, обычно решение о выделении ресурсов на весь проект (все его стадии) принимается близко к началу проекта -- но наличие decision gates как раз требует, чтобы это решение регулярно (между всеми стадиями) пересматривалось. То есть точный перевод decision gates должен бы быть "подтверждение решения о выделении ресурсов на следующую стадию, делаемое владельцами ресурсов в момент времени между стадиями на основании рассмотрения результатов предыдущей стадии". Кратко -- "пересмотр выделения ресурсов" (ибо это включает в себя рассмотрение результатов предыдущей стадии, а "межстадийность" будет понятна из контекста и объяснений).
Три слова вместо одного -- это, конечно, много. Единственное слово, которое можно опустить -- это "выделение", но при этом исчезает смысл, при котором пересмотр ведут не-разработчики, а именно владельцы ресурсов (т.е. "пересмотр ресурсов", а не выделение ресурсов могут делать и разработчики, а вот "пересмотр выделения ресурсов" обязательно делают их владельцы).
При устном использовании этого трехсловного термина он наверняка будет сокращен до одного слова ("пересмотр"), но это не так страшно. Это ключевое слово, ключевая практика, ключевая процедура.
Теоретический смысл обязательного включения работы по пересмотру выделения ресурсов между всеми стадиями заключается в необходимости синхронизации параллельно ведущихся разработок так, чтобы заинтересованные стороны-владельцы ресурсов могли составить впечатление об итогах стадии в целом -- и принять решение по продолжению работ на основании целостного описания, а не на основании разрозненных нестыкуемых между собой разной степени проработанности сведений о системе. Вероятность того, что трудности возникнут при стыковке готовых ("в металле", "в бетоне", "в коде" и даже "в голове" для человеко-системной интеграции) частей системы очень велика, поэтому эта стыковка-интеграция должна проходить не однократно в момент окончания стадии интеграции (изготовления, сборки, наладки) и начала стадии эксплуатации, а существенно чаще, для чего предусматривается несколько пересмотров выделения ресурсов.
Казалось бы, это рассуждение про необходимость регулярной (по мере поэтапного появления разных уровней описания -- идеи, архитектуры, детальных чертежей или исходного кода, готовой системы или объектного/бинарного кода) проверки того, соответствуют ли части системы друг другу тривиально, и подтверждается многочисленными исследованиями. Слишком большая параллельность в работах ведет к огромному объему переделок -- если никто никого не ждет, то решения по разным частям системы принимаются независимо, результирующая система оказывается неработоспособна, и нужны большие переделки.
Наиболее полная аргументация по необходимости регулярной синхронизации параллельных работ даже за счет мнимого увеличения общего времени разработки на величину непрерывно ведущейся промежуточной сборки была выработана программной инженерией при разработке концепции "непрерывной интеграции" в группе гибких (agile) методов управления жизненным циклом. Конечно, лишние затраты времени на промежуточную интеграцию существенно уменьшаются ввиду автоматизации этой интеграции, но суть остается: выигрыш от более частой интеграции и прогона полного набора тестов на собранной системе много выше потерь времени на эту повторяющуюся и нудную работу.
Кроме этих практических наблюдений и рассуждений на основе "здравого смысла" есть и академические работы о пользе регулярной синхронизации частей проекта, означающей по факту уменьшение перекрытия различных потоков работ в ходе параллельной разработки частей системы (http://www.allbusiness.com/company-activities-management/product-management/10562070-1.html): AitSahlia, Johnson, and Will (1995) используют методы управления жизненным циклом, чтобы показать, что полное перекрывание [связанных работ во времени] неоптимально. Они замечают, что неопределенность может поглотить преимущества параллельного исполнения работ. Krishnan, Eppinger, and Whitney (1997a) оптимизируют перекрывание пары деятельностей на основе скорости изменения предшествующей по результатам деятельности и чувствительности к этим изменениям в следующей за ней. Они показывают, что различные типы перекрытия определяют разные компромиссы по времени, стоимости и качеству. Расширяя эту работу, Loch and Terwiesch (1998) учитывают эффект коммуникации и эффекты неопределенности в определении оптимальной степени параллельности и показывают, что улучшение коммуникации позволяет увеличивать перекрытие, уменьшая переделки. Дальнейшее продолжение Joglekar et al. (2001) учитывает ограничения по ресурсам и порождение переделок, и показывает, что для определения оптимального перекрытия важны факторы, внешние по отношению к перекрывающейся паре работ. Roemer and Ahmadi (2004) исследуют перекрытие и неудачи в модели двух работ. Двигаясь немного за пределы двух активностей, Roemer, Ahamdi, and Wang (2000) моделируют перекрытие смежных стадий жизненного цикла и демонстрируют компромиссы "время -- стоимость", изменяемые количеством перекрытия. Таким образом, в присутствие неопределенности, эффективность коммуникации, доступные ресурсы и другие характеристики проекта, такие как предпочтения по стоимости или времени, определяют решения по перекрытию стадий.
ISO 15288 прямо говорит, что стадии могут перекрываться. Но между стадиями в любом случае должен быть пересмотр выделения ресурсов, что ограничивает возможности по перекрытию стадий и заставляет принимать специальные меры по синхронизации работ (см., например, предложения по данному вопросу метода поэтапного выделения ресурсов, http://ailev.livejournal.com/691464.html).
На практике делаются следующие наиболее частые ошибки управления жизненным циклом:
а) не включают обоснование реализуемости для проекта целиком на уровне промежуточных уровней описания. При выполнении практики Интеграция (изготовление, сборка, наладка) получают много сюрпризов по нестыковкам, объем переделок становится огромным -- время и бюджет увеличиваются в разы.
б) проект планируют так, чтобы у исполнителей не было запасов времени между работами (приоритет загрузки ресурсов). Это имеет сразу два негативных последствия: случайные отклонения в отдельных работах невозможно скомпенсировать (все задержки будут просуммированы, и на это время задержится весь проект), также невозможно будет правильно спланировать промежуточный межстадийный пересмотр выделения ресурсов -- решение о выделении ресурсов можно будет принимать только по небольшим работам, но не по всему проекту в целом. То есть пересмотреть проект при таком подходе будет невозможно: пока пересматриваешь один ручеек этой речки, другие ручейки уже убежали.
в) "недопересмотры" и "псевдопересмотры" -- когда решение по выделению ресурсов по факту не может быть принято, но любое частное решение по какой-нибудь гаечке оформляется как полноценный пересмотр всего проекта. В тот момент, когда проект заходит в тупик, уже нет способов планово организовать принятие полноценного корректирующего решения по всем работам проекта -- только "авральные" внесистемные, внепроцедурные, внерегламентные.
г) слишком мало стадий в высокорисковых больших проектах: например, пересмотр выделения ресурсов случается в самом начале проекта, а затем только при передаче в эксплуатацию (через 5-10 лет после принятия решения о старте проекта -- проект ведь может быть очень большой!), затем сразу в момент вывода из эксплуатации (через десятки лет). Нельзя удивляться, что весь проект проходит в непрерывных авральных совещаниях по переделкам на всех стадиях, но эти совещания мало меняют ход проекта: принятие решений по отдельной параллельной струйке в речке ведущихся работ мало влияет на течение других струй. А интегрирующую задвижку на всю речку ведущихся работ просто не предусмотрели, поэтому о речке в целом мало кто думает (знаменитое "к пуговицам претезний нет?") -- отсюда и огромное число переделок в таких недосинхронизированных, недопересмотренных проектах.
д) при пересмотре выделения ресурсов не меняют требования, хотя и корректируют выделяемые ресурсы. Требования тоже нужно менять, утверждая под свежевыделенные ресурсы новые требования. Для этого, конечно, доработка требований должна входить в работы предыдущей стадии.
Этот список можно продолжать и продолжать, но все эти ошибки подробно разбираются в рамках конкретных методов управления жизненным циклом (ICM, RUP, DSDM, OpenUP, spiral model, V-model и т.д.). Правда, в каждом методе обсуждается только класс "любимых" для этого метода ошибок, и игнорируются другие.
Термин decision gate отражает один из возможных подходов к определению формы жизненного цикла (последовательности расположения стадий ЖЦ), в котором стадийная работа перемежается специально организованным рассмотрением результатов этой работы. ISO 15288 недвусмысленно требует, чтобы между стадиями по их итогам обязательно было организовано принятие решений -- и вводит для этого decision gates. В литературе управления жизненным циклом (часто под другими именами -- product delivery, software process и т.д.) этот подход давно известен, а на русский gate незамысловато транслитерируется как "гейт".
Но "гейт решения" -- не перевод, а транслитерация. К тому же понятие decision gate не так легко понимается и принимается инженерами (особенно, если эти инженеры представляют заинтересованную сторону разработчиков, а не владельцев ресурсов), а стандарт ISO 15288 совсем не зря требует наличия пересмотра выделения ресурсов.
Можно было бы использовать метафору и перевести decision gate как "шлюз". Действительно, все результаты проекта как бы собирают в межстадийной шлюзовой камере, закрывая затем проход как назад, так и вперед без того, чтобы владельцы ресурсов тщательно не проинспектировали собранное, а затем принимают решение о пропуске вперед или возврате назад на основании результатов такого рассмотрения. Но слово "шлюз" тут лишь чуть лучше транслитерации "гейт".
Gate является одним из специальных видов milestone -- контрольных точек проекта и отличается тем, что обязательно находится между стадиями. Другие контрольные точки могут быть расставлены в графике проекта для удобства отслеживания реальной скорости его прохождения по сравнению с плановой скоростью -- а это не имеет отношения ни к стадиям, ни к принятию каких-то решений о переходе от стадии к стадиям. Именно поэтому в ISO 15288 говорится не просто о milestone, а о gates, и не просто о gates, а о decision gates.
В стандарте языка описывания (metamodel) методов управления жизненным циклом (systems and software process engineering) OMG SPEM 2 оговаривается, что milestones (и, следовательно, decision gates как подвид milestone) в речи обычно означает как точку во времени, так и связанную с этой точкой работу (общее название для независимых от времени практик-мероприятий-дел и разворачивающихся во времени процедур-стадий-пересмотров-проектов). Поэтому SPEM 2 рекомендует моделировать milestones через работы (Work Definition). Gate -- это межстадийный milestone. Какая работа проводится в gates? По-английски эта работа обычно называется review -- буквально "пересмотр". Какие решения пересматриваются? Как решения разработчиков (проектные решения, включая требования), так и решения по выделению ресурсов. Какие решения принимаются по итогам этого межстадийного пересмотра? Обычно это решения о выделении ресурсов для продолжения проекта. Это продолжение проекта может быть 4 видов:
-- переход к новой стадии (с утверждением новых требований и нового финансирования)
-- доработки в рамках предыдущей стадии
-- прекращение всего проекта
-- пропуск следующей стадии ввиду незначительных рисков (например, выполняется уже десятый однотипный проект, и архитектура системы давно устоялась -- поэтому сразу после Исследований идет Разработка, пропуская стадии Оценивание и Основание).
Эти четыре варианта представляются осмысленными для любого метода управления жизненным циклом, использующим принцип decision gates. Они были взяты из метода пошагового выделения ресурсов (Incremental Commitment Model, ICM), в котором был обобщен опыт десятка популярных методов управления жизненным циклом (http://ailev.livejournal.com/691464.html).
Почему не передать decision gates как "решение о выделении средств", не используя слово "пересмотр", а передавая gate через его природу ("выделение средств [на следующую стадию]"), а decision привычно как "решение"?
Во-первых, "решение" не имеет оттенка работы, уж скорее это слово указывает просто факт и момент его принятия. Поэтому планировщики проекта могут не отвести достаточного времени для содержательного рассмотрения результатов стадии и не предусмотреть выделения средств для "решения". Слово "пересмотр" подразумевает все-таки какое-то действие, пересмотр может занять время. Более того, "решение" можно спутать с простым "go - no-go" (и так часто и пишут). На самом деле решение может касаться и других аспектов: изменения требований, изменения финансирования (как в сторону его уменьшения, так и в сторону увеличения), изменения длительности следующей стадии и т.д. Речь именно о "пересмотре".
Во-вторых, обычно решение о выделении ресурсов на весь проект (все его стадии) принимается близко к началу проекта -- но наличие decision gates как раз требует, чтобы это решение регулярно (между всеми стадиями) пересматривалось. То есть точный перевод decision gates должен бы быть "подтверждение решения о выделении ресурсов на следующую стадию, делаемое владельцами ресурсов в момент времени между стадиями на основании рассмотрения результатов предыдущей стадии". Кратко -- "пересмотр выделения ресурсов" (ибо это включает в себя рассмотрение результатов предыдущей стадии, а "межстадийность" будет понятна из контекста и объяснений).
Три слова вместо одного -- это, конечно, много. Единственное слово, которое можно опустить -- это "выделение", но при этом исчезает смысл, при котором пересмотр ведут не-разработчики, а именно владельцы ресурсов (т.е. "пересмотр ресурсов", а не выделение ресурсов могут делать и разработчики, а вот "пересмотр выделения ресурсов" обязательно делают их владельцы).
При устном использовании этого трехсловного термина он наверняка будет сокращен до одного слова ("пересмотр"), но это не так страшно. Это ключевое слово, ключевая практика, ключевая процедура.
Теоретический смысл обязательного включения работы по пересмотру выделения ресурсов между всеми стадиями заключается в необходимости синхронизации параллельно ведущихся разработок так, чтобы заинтересованные стороны-владельцы ресурсов могли составить впечатление об итогах стадии в целом -- и принять решение по продолжению работ на основании целостного описания, а не на основании разрозненных нестыкуемых между собой разной степени проработанности сведений о системе. Вероятность того, что трудности возникнут при стыковке готовых ("в металле", "в бетоне", "в коде" и даже "в голове" для человеко-системной интеграции) частей системы очень велика, поэтому эта стыковка-интеграция должна проходить не однократно в момент окончания стадии интеграции (изготовления, сборки, наладки) и начала стадии эксплуатации, а существенно чаще, для чего предусматривается несколько пересмотров выделения ресурсов.
Казалось бы, это рассуждение про необходимость регулярной (по мере поэтапного появления разных уровней описания -- идеи, архитектуры, детальных чертежей или исходного кода, готовой системы или объектного/бинарного кода) проверки того, соответствуют ли части системы друг другу тривиально, и подтверждается многочисленными исследованиями. Слишком большая параллельность в работах ведет к огромному объему переделок -- если никто никого не ждет, то решения по разным частям системы принимаются независимо, результирующая система оказывается неработоспособна, и нужны большие переделки.
Наиболее полная аргументация по необходимости регулярной синхронизации параллельных работ даже за счет мнимого увеличения общего времени разработки на величину непрерывно ведущейся промежуточной сборки была выработана программной инженерией при разработке концепции "непрерывной интеграции" в группе гибких (agile) методов управления жизненным циклом. Конечно, лишние затраты времени на промежуточную интеграцию существенно уменьшаются ввиду автоматизации этой интеграции, но суть остается: выигрыш от более частой интеграции и прогона полного набора тестов на собранной системе много выше потерь времени на эту повторяющуюся и нудную работу.
Кроме этих практических наблюдений и рассуждений на основе "здравого смысла" есть и академические работы о пользе регулярной синхронизации частей проекта, означающей по факту уменьшение перекрытия различных потоков работ в ходе параллельной разработки частей системы (http://www.allbusiness.com/company-activities-management/product-management/10562070-1.html): AitSahlia, Johnson, and Will (1995) используют методы управления жизненным циклом, чтобы показать, что полное перекрывание [связанных работ во времени] неоптимально. Они замечают, что неопределенность может поглотить преимущества параллельного исполнения работ. Krishnan, Eppinger, and Whitney (1997a) оптимизируют перекрывание пары деятельностей на основе скорости изменения предшествующей по результатам деятельности и чувствительности к этим изменениям в следующей за ней. Они показывают, что различные типы перекрытия определяют разные компромиссы по времени, стоимости и качеству. Расширяя эту работу, Loch and Terwiesch (1998) учитывают эффект коммуникации и эффекты неопределенности в определении оптимальной степени параллельности и показывают, что улучшение коммуникации позволяет увеличивать перекрытие, уменьшая переделки. Дальнейшее продолжение Joglekar et al. (2001) учитывает ограничения по ресурсам и порождение переделок, и показывает, что для определения оптимального перекрытия важны факторы, внешние по отношению к перекрывающейся паре работ. Roemer and Ahmadi (2004) исследуют перекрытие и неудачи в модели двух работ. Двигаясь немного за пределы двух активностей, Roemer, Ahamdi, and Wang (2000) моделируют перекрытие смежных стадий жизненного цикла и демонстрируют компромиссы "время -- стоимость", изменяемые количеством перекрытия. Таким образом, в присутствие неопределенности, эффективность коммуникации, доступные ресурсы и другие характеристики проекта, такие как предпочтения по стоимости или времени, определяют решения по перекрытию стадий.
ISO 15288 прямо говорит, что стадии могут перекрываться. Но между стадиями в любом случае должен быть пересмотр выделения ресурсов, что ограничивает возможности по перекрытию стадий и заставляет принимать специальные меры по синхронизации работ (см., например, предложения по данному вопросу метода поэтапного выделения ресурсов, http://ailev.livejournal.com/691464.html).
На практике делаются следующие наиболее частые ошибки управления жизненным циклом:
а) не включают обоснование реализуемости для проекта целиком на уровне промежуточных уровней описания. При выполнении практики Интеграция (изготовление, сборка, наладка) получают много сюрпризов по нестыковкам, объем переделок становится огромным -- время и бюджет увеличиваются в разы.
б) проект планируют так, чтобы у исполнителей не было запасов времени между работами (приоритет загрузки ресурсов). Это имеет сразу два негативных последствия: случайные отклонения в отдельных работах невозможно скомпенсировать (все задержки будут просуммированы, и на это время задержится весь проект), также невозможно будет правильно спланировать промежуточный межстадийный пересмотр выделения ресурсов -- решение о выделении ресурсов можно будет принимать только по небольшим работам, но не по всему проекту в целом. То есть пересмотреть проект при таком подходе будет невозможно: пока пересматриваешь один ручеек этой речки, другие ручейки уже убежали.
в) "недопересмотры" и "псевдопересмотры" -- когда решение по выделению ресурсов по факту не может быть принято, но любое частное решение по какой-нибудь гаечке оформляется как полноценный пересмотр всего проекта. В тот момент, когда проект заходит в тупик, уже нет способов планово организовать принятие полноценного корректирующего решения по всем работам проекта -- только "авральные" внесистемные, внепроцедурные, внерегламентные.
г) слишком мало стадий в высокорисковых больших проектах: например, пересмотр выделения ресурсов случается в самом начале проекта, а затем только при передаче в эксплуатацию (через 5-10 лет после принятия решения о старте проекта -- проект ведь может быть очень большой!), затем сразу в момент вывода из эксплуатации (через десятки лет). Нельзя удивляться, что весь проект проходит в непрерывных авральных совещаниях по переделкам на всех стадиях, но эти совещания мало меняют ход проекта: принятие решений по отдельной параллельной струйке в речке ведущихся работ мало влияет на течение других струй. А интегрирующую задвижку на всю речку ведущихся работ просто не предусмотрели, поэтому о речке в целом мало кто думает (знаменитое "к пуговицам претезний нет?") -- отсюда и огромное число переделок в таких недосинхронизированных, недопересмотренных проектах.
д) при пересмотре выделения ресурсов не меняют требования, хотя и корректируют выделяемые ресурсы. Требования тоже нужно менять, утверждая под свежевыделенные ресурсы новые требования. Для этого, конечно, доработка требований должна входить в работы предыдущей стадии.
Этот список можно продолжать и продолжать, но все эти ошибки подробно разбираются в рамках конкретных методов управления жизненным циклом (ICM, RUP, DSDM, OpenUP, spiral model, V-model и т.д.). Правда, в каждом методе обсуждается только класс "любимых" для этого метода ошибок, и игнорируются другие.