Ещё раз про организацию разработки/управление жизненным циклом/управление созданием и развитием системы
Вы уже заметили, что наши курсы каждый вопрос рассматривают два-три раза, чтобы натренировать нейронную сетку студента. Увы, человек не компьютер, чтобы сходу загружать в мозг какие-то сложные схемы: ему нужно каждое новое понятие и описание его связи с другими понятиями предъявить несколько раз, чтобы произошло запоминание и появились ассоциативные связи с уже имеющимся знанием.
Очень частой ошибкой не только у студентов, но и у инженеров является игнорирование обсуждения по организации разработки/управлениюпроцессом разработки/управлению созданием и развитием системы (оно же в старой терминологии --- управление жизненным циклом): игнорирование обсуждения практик, игнорирование понимания того, как происходит создание и развитие системы в их проекте: каким методом разработки они пользуются и насколько это получается (в старой терминологии --- какая концепция/вид/модель жизненного цикла используется). Конечно, под «разработкой» имеют ввиду все практики, которые нужны для создания и развития системы -- и разработку, и визионерство, и практику архитектуры, и практику создания производственной платформы. Но так же, как не так часто в жизни услышишь более корректное «непрерывное всё»/continuous everything, но чаще это будет или continuous development/непрерывная разработка, или continuous delivery/непрерывный ввод в эксплуатацию, хотя понимать надо именно «всё», а не только разработка или ввод в эксплуатацию, так и в управлении процессом разработки надо понимать управление всем процессом создания и развития системы, а не только управление одной только разработкой, но не архитектурной работой, не производством, не отслеживанием прибыльности продукта.
Но всё это разговор о практиках. А студенты делают «новичковые ошибки» и перечисляют не практики создания и развития системы, а работы --- и дальше речь идёт об операционном менеджменте/управлении работами: вместо обсуждения ролей, практик/методов/способов работы и требуемых технологий обсуждаются ресурсы, даты старта и длительность работ, ответственные исполнители/оргзвенья.
Сейчас вам уже должно быть понятней, что такое жизненный цикл, и вы уже не перепутаете управление жизненным циклом с управлением работами. На всякий случай ещё раз напомним основные отличия.
Обсуждение способов выполнения работ, в какие моменты проекта в целом (грубо: весь проект в самые разные моменты по мере возникновения необходимости, или на определённых «стадиях») будут выполняться те или иные работы с точки зрения их содержательной необходимости (а не с точки зрения доступности ресурсов), выполнение работ в правильном содержательном порядке (независимо от доступности ресурсов --- «сначала загрунтовать, потом покрасить, но не наоборот»), согласование результатов по ходу их выполнения, чтобы получился результат без конфигурационных коллизий --- это всё организация разработки (product development), и с учётом всех остальных практик создания и развития системы часто «исторически» называетсяуправлением жизненным циклом (lifecycle management). Это полуинженерная-полуменеджерская практика. Инженерная она в той мере, в которой речь идёт о методах/практиках как функциональных/ролевых поведениях, рассмотрение времени функционирования систем создания (помним, что полностью -- «систем создания и развития», нам важно подчеркнуть тут «непрерывное всё») как оргролей.
Организация разработки/управление жизненным циклом отвечает на вопрос «как организованы создатели и какое у них мастерство и оборудование, чтобы по итогам разработки была успешная целевая система, и её успешность удерживалась длительное время (развитие!)». Практики для метода разработки выбирают инженеры, хорошо разбирающиеся в тех технологических операциях, тех сервисах, которые должны будут выполнить создатели системы, чтобы в правильной последовательности менять состояния описаний/проекта/design целевой/создаваемой системы и затем воплощения этой системы. В отличие от бабочки или кошечки, дом сам себя не построит, ракета сама себя не построит. Кто-то должен указать, какими методами, какими способами это делать, в какой последовательности. Вот это и делают организаторы разработки/управляющие жизненным циклом.
Менеджерской/управленческой практика организации разработки является в той мере, в которой речь идёт об инженерии не целевой системы, а инженерии систем создания. Практики --- это поведение оргролей в каких-то оргзвеньях, а это ассоциируется обычно с менеджментом, хотя речь идёт не об оргзвеньях (ответственности/полномочиях, модульное рассмотрение организации), а функциональных единицах организации/оргролях, частях «принципиальной схемы» предприятия. Собственно «организованность» как понимание кто кому из оргзвеньев что из работ может поручить, а потом спросить выполнение, при рассмотрении практик тут ни при чём. Орг-проектировщик должен понимать, что будут делать те оргзвенья, которые он проектирует, лидер должен понимать, что ему объяснять людям по поводу того, как они будут сотрудничать. Для оргпроектирования метод разработки должен быть известен (например: надо ли выделять архитектора системы в отдельную службу? Орг-проектировщик и орг-архитектор должны знать, есть ли вообще практика архитектуры в методе разработки, который будет принят в проекте! И они должны будут иметь исполнителя роли архитектора, чтобы тот начал выполнять свои функции --- но про то, что эти функции в разработке потребуются, они как раз и узнают из метода разработки/концепции жизненного цикла).
В том числе организатор разработки традиционно гарантирует целостность конфигурации практик: ни одна практика не будет пропущена (то есть будут запланированы и выполнены в какой-то инженерно правильный момент работы, её реализующие), входы одних практик смогут работать с выходами других практик (например, данные будут перекодированы из одних форматов в другие в случае информационных технологий). А ещё организатор разработки/управляющий жизненным циклом проверит, поддержаны ли практики технологиями и используют ли сотрудники технологии поддержки так, как это предусмотрено дисциплиной/теорией/объяснениями практики. Управляющий жизненным циклом часто будет работать в должности CTO (chief technology officer), ибо эта роль лучше всех разбирается в практиках работы, ведущих к созданию успешной системы. Он не разработчик и не архитектор самой целевой системы, он инженер, чьё внимание обращено на системы создания (обученные практикам люди и приданные им в поддержку технологии/инструменты). И он при этом не полностью ответственен за концепцию предприятия и орг-архитектуру, его мало волнуют вопросы назначения оргзвеньев на оргроли. Но его волнуют сами методы/практики/способы работы инженеров целевой системы (и дальше рекурсивно всех частей целевой системы). Он занимается содержательным обсуждением методов инженерной работы. А инженеры целевой системы работают с целевой системой (и помним, что роли --- это роли, а исполнители ролей могут играть и много разных ролей).
Более того, часто управление конфигурацией и изменениями системы относят к управлению жизненным циклом: ведь конфигурация меняется именно в ходе выполнения практик жизненного цикла, в ходе создания и развития системы! Отсюда же управление жизненным циклом часто называют и управлением инженерной документацией (документацией, описывающей целевую систему, равно как и описывающей её жизненный цикл --- что делать в ходе её создания). Но это только работа по форме: проверяется, выполнена ли практика системной архитектуры, проверяется наличие архитектурной документации, но нет интереса к самой архитектуре: это делает архитектор целевой системы, а управляющий жизненным циклом работает по менеджерской форме, он сам не занимается архитектурой, он занимается организацией жизненного цикла.
Не ждите, что везде это будет называться как-то одинаково. Практика организации разработки как отдельная практика новая, понятие жизненного цикла только-только начало уходить, «метод работы» трудно понимаем. Так что имена будут везде разные. Скажем, в методе организации разработки SAFe[1] (они себя называют подходом/framework, scaling agile framework, SAFe) определяют переход к continuous flow в компетенции Enterprise Solution Delivery[2]. Мы видим, что обсуждается организация процесса разработки, и даже видим традиционное объяснение, чем отличается старинная «V-диаграмма» как концепция метода разработки от «непрерывного потока» как концепции метода разработки (мы эту V-диаграмму вам специально подробно разъясняем в наших курсах, ибо вы будете ещё долго видеть её в самых неожиданных местах, так что должны понимать, о чём она вам пытается рассказать и интерес к какой практике люди выражают, когда её рисуют. А вот то, что потом пришло на её замену, уже не так легко распознать визуально, там редкое разнообразие. Но если приглядеться, можно увидеть следы горбатой диаграммы, и даже «требования» ещё там в числе практик!). Вот картинка диаграммы из пятой версии SAFe[3]:
А вот вариант этой же диаграммы из версии SAFe 6.0, выпущенной в марте 2023[4]:
Видим, что «традиционные практики» отступают, вместо этого говорится, что из сотен утверждений о будущей системе в ходе непрерывного хода разработки (flow по-русски всё-таки «ход» в случае как работ, так и разработки, хотя часто переводят и «поток») и множества вопросов по мере продвижения появляются тысячи утверждений о том, что будет, а также накапливается множество принятых решений. Но требований уже нет (хотя какие-то отсылки к ним в других частях документации остаются, но незначительные), остаётся только Evolve the Solution Intent, постепенное формирование намерения иметь конечную форму решения, при этом видно, что это намерение никогда не оказывается окончательным (часть variable, то есть часть вопросов, не нулевая, а тысячи утверждений о том, какое будет решение всё-таки не формируют собой полностью намерение решения, вопросы остаются).
Мы не будем тут обсуждать сами практики (например, если у вас уже готовят концепцию использования, даже называемую как-то другими словами, например, «намерения разработать инженерное/программное решение» то надо ли после этого готовить требования), за этим вам надо идти в курс системной инженерии. Но поддержание разговора о практиках вам нужно, чтобы вы вообще поняли, чем занимается ваш маленький проект (маленьким кусочком на этой диаграмме) или ваш большой проект (включающий несколько таких диаграмм, да ещё и по-разному устроенных, ибо кто-то будет использовать старинную V-диаграмму и всё, кто-то разворачивать у себя этот SAFe то ли пятой, то ли шестой версии, кто-то будет говорить, что у него SCRUM с совсем другими словами, а кто-то сам сочинит для себя уникальный метод разработки, и будет прав не меньше, а может и больше --- помним о неприменимости сегодня тяжёлых методов/методологий разработки!).
«Организация разработки»/«управление созданием и развитием системы»/управление жизненным циклом::практика не включает ответы на вопрос «кто это всё делает» (оргзвенья как ресурсы) и «когда делает» (операционный менеджмент, время выполнения работ). Логическое «когда» включает «красить только после зачистки» (инженерное замечание), а вот операционное «когда» с конкретными ресурсами («красит Вася в 12:00») --- вот этого в управлении жизненным циклом/управлении разработкой/управлении созданием и развитием системы нет, ибо нет экземпляров выполнения практик, то есть нет работ. Нет собственно потока работ, есть описание «непрерывный ход разработки» как тип выполнения работ по некоторым практикам в их сложной взаимосвязи, с отсылкой к «непрерывному всему», а не «непрерывному потоку собственно работ».
Экземплярами работ (то есть привязанными к определённому времени и наличию определённых ресурсов выполнению работ по каким-то методам/способам/практикам/видам деятельности/видам труда) занимается управление работами/операционный менеджмент::практика. Управление работами (operation management, управление операциями, операционный менеджмент) заключается в управлении выделением ресурсов для прохождения всех контрольных точек в срок и в соответствии с бюджетом. Управление жизненным циклом/ходом разработки (не ходом работ!) рассматривается как преимущественно инженерная дисциплина (нужно хорошо знать практики инженерной работы), управление работами (ходом работ!) как чисто менеджерская дисциплина (нужно хорошо знать практики операционного менеджмента).
Управление работами абстрагируется от инженерной сути операций, знаний о способах выполнения работ. В управлении работами достигается максимально быстрое и дешёвое выполнение работ, и для достижения этого используются не инженерные методы (например, изменить способ изготовления), а менеджерские способы (если производительность станка для обработки кучки однородных деталей мала, поставить два станка --- при этом неважно, что это за обработка).
При этом управление работами и управление разработкой тесно переплетены. Так, в системном менеджменте вы будете проходить «распожаризацию» как способ устранения авралов и «пожаров» в проекте. Там пять шагов, из которых три с половиной -- инженерные, а полтора -- операционного менеджмента. Получается, что иногда трудно даже в одной какой-то практике разделить управление работой и управление разработкой. Но чтобы сохранить чёткость мышления, надо уметь чётко различать эти практики, ибо инженерией и менеджментом чаще всего занимаются разные люди (и разные компьютерные приложения). А как же «трудно разделить»? Ну, всегда можно выполнить какую-то практику вдвоём, двумя ролями, разнесёнными по разным агентам, согласовывая действия друг с другом.