Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

Три артефакта координации работ менеджеров и инженеров


(это слайд из http://www.slideshare.net/ailev/ss-2290189).

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

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

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

Для того, чтобы понимать, какие именно это стадии жизненного цикла, и какие требуются содержательные артефакты (состояние системы на конец стадии -- проект, или прототип, или готовая система), а также для фиксации самого факта наличия пересмотра выделения ресурсов между этими стадиями необходимо иметь описание (лучше -- компьютерную модель) жизненного цикла. Требование иметь это описание есть в ISO 15288, а в руководствах к нему (ISO TR 24748-1 и ISO TR 19760) рассказывается о том, что между стадиями происходит пересмотр выделения ресурсов, т.е. происходит принятие решения о том,
-- выделить ли ресурсы для перехода к следующей стадии,
-- продолжить ли выполнение текущей стадии в счет уже выделенных ресурсов, или небольшой добавки ресурсов, достаточной для получения результатов, позволяющих принять решение о выделении ресурсов для перехода на следующую стадию
-- закрыть проект (признать, что дальнейшее выделение ресурсов нецелесообразно0

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

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

Когда говорится о "требованиях", то имеется ввиду:
-- разные виды требований (прежде всего -- заинтересованных лиц, к числу которых прежде всего относим менеджеров; требования к системе, определяющие границы системы)
-- текущее понимание требований: переговоры между менеджерами и инженерами идут в течение всего хода проекта, а не только в самом начале проекта. Поэтому требования фиксируются на предыдущем пересмотре выделения ресурсов (базис, baseline), чтобы команда инженеров могла спокойно работать всю стадию N до текущего пересмотра ресурсов. В то же время, всю эту стадию N требования пересматриваются, и к пересмотру готовится новый набор требований -- который будет зафиксирован на новую стадию N+1. Ибо менеджерам выделять деньги на продолжение реализации устаревших требований "по состоянию на конец стадии N-1" было бы неправильно: в ходе выполнения стадии N были получены новые знания, и требования просто обязаны быть откорректированы. Инженеры и менеджеры должны поэтому договориться о пределах этой корректировки, и как эта корректировка может повлиять на бюджет, сроки и риски проекта в целом.

ISO 15288 не рассказывает об этой работе с требованиями, он просто фиксирует необходимость наличия разных видов требований, а также необходимость трассировки этих требований к разным заинтересованным сторонам -- и постулирует непротиворечивость требований к системе (что означает, что заинтересованные стороны должны по этим требованиям договориться). Работа по непрерывному изменению всех видов требований в ходе всего жизненного цикла и недопустимость замораживания начальных требований оговаривается практически всеми методами управления жизненным циклом. Метод постадийного выделения ресурсов (ICM) конкретизирует, что
-- должна проводиться процедура фиксации требований на каждую следующую стадию N+1, но фиксируемый вариант должен уточняться в ходе всей предыдущей стадии N
-- возможность выполнения требований в ходе проекта должна доказываться инженерами менеджменту в моменты пересмотра выделения ресурсов.

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

Это замечание очень похоже на разницу оценка успеха проекта "традиционным" управлением проектами (анализ освоенных объемов), а оценки "по Голдратту" -- оценки того, когда проект будет выполнен. Менеджеров интересует не успех предыдущей стадии, а успех будущей стадии (помним: в этот момент происходит выделение ресурсов на будущую стадию N+1. Ресурсы на предыдущую стадию были выделены при предыдущем пересмотре выделения ресурсов после стадии N-1 и перед стадией N. Поэтому интересуют риски продолжения проекта, а не то, насколько справились инженеры с выполнением задач предыдущей стадии -- менеджеров интересует оценка будущего, а не оценка прошлого).

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

Слово "доказательство" (а не сверка, проверка и т.д.) тут не случайно: в какой-то момент в методе ICM пришлось менять термин на "доказательство", ибо все другие термины позволяли инженерам просто предъявлять результат работы ничего не понимающим в содержании менеджерам, и тем самым их ошибки становились очевидными только на самых поздних стадиях проекта, когда исправлять их было уже поздно. ICM прямо говорит, что должна быть продемонстрирована очевидность (evidence) приемлемости рисков продолжения проекта.

В ходе осознания проблемы коммуникации между менеджерами и инженерами было предложено и опробовано множество (порядка десятка) разных методов такого "доказательства приемлемости рисков", но выжил только один: работа в ходе всего проекта с особым артефактом "оценочное дело" (assurance case). Этот способ получил свою фиксацию в особом стандарте системной инженерии ISO 15026. Оценочное дело (термин выбран по аналогии с "судебным делом") доказывает, что требования будут выполнены:
-- для каждой декларации соответствия требованиям (т.е. необходимо поддерживать соответствие "оценочного дела" артефакту "требования") формулируется
-- набор промежуточных аргументов в поддержку этих деклараций.
-- Для каждого аргумента в оценочное дело "подшиваются" материалы, показывающие неголословность этих аргументов (результаты испытаний, акты экспертных заключений, расчеты и т.д.).

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

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

Степень формальности указанного механизма может быть разной, реализация информационных систем, поддерживающих все три описанных артефакта может существенно различаться -- но общие принципы координации работ менеджеров и инженеров остаются прежними:
-- артефакт "описание жизненного цикла" определяет стадии и предусматривает между ними пересмотры выделения ресурсов -- моменты, в которые менеджеры и инженеры договариваются друг с другом о продолжении работ на основе доказательства приемлемости рисков неудачи проекта.
-- артефакт "требования" существует (это просто другая формулировка выражения "требования документированы"), в моменты пересмотра выделения ресурсов происходит фиксация варианта требований (baselining). Это не отменяет факта работы над требованиями в течение всей стадии (менеджеры получают в конце каждой стадии уточненные требования).
-- артефакт "оценочное дело" заказывается менеджерами как необходимый результат каждой стадии, подготавливается инженерами-разработчиками к каждому пересмотру выделения ресурсов, и проверяется независимыми инженерами в момент пересмотра выделения ресурсов.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 5 comments