Анатолий Левенчук - Системное мышление

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

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

По факту это означает составление плана-графика выполнения работ с назначением ресурсов на эти работы ещё до начала выполнения работ.

Это часто называют предварительным (up-front) планированием работ, а весь проект просто считают уникальной работой, имеющей чётко определённые время начала и конца, а также выделенные для неё ресурсы.

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

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

Если непонятно, какие могут быть контрольные точки больших кусков работы, то речь идёт об управлении программами(program management).

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

Управление программами отличается от остальных методов управления работами тем, что отношение часть-целое в них меняет тип управления работами, а в остальных методах нет: в программах обычно нет «подпрограмм», но есть «проекты».

В проектах же обычно подпроекты, в процессах подпроцессы, в кейсах подкейсы и т. д.

Если контрольные точки и ресурсы для их выполнения известны, но неизвестно, в какой момент происходит запуск большого числа однотипных работ, речь идёт о процессном управлении(process management).

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

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

Эти гибкие методологии считают относящимися к разновидностям спиральной модели.

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

Общее для всех этих гибких методологий/методов и соответствующих им видам жизненного цикла в том, что они используют в части управления работами управление кейсами(case management) 189 189 http://ailev.livejournal.com/946134.html .

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

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

Тут могут быть использованы удобные для управления кейсами методы планирования, например, канбан (Kanban for development 190 190 https://en.wikipedia.org/wiki/Kanban_(development) для управления кейсами прежде всего, для планирования производственных процессов используется обычно Kanban for manufacturing 191 191 https://en.wikipedia.org/wiki/Kanban ). И даже тут жизнь контрольной точки в управлении кейсами не заканчивается, потому как в рамках управления изменениями конфигурации нужно сообщить участникам проекта, что кейс закрыт: состояние системы изменилось, и всем остальным нужно ориентироваться на новую ситуацию.

Технологии, используемые для гибких методов в управлении жизненным циклом и управления кейсами в управлении работами – это технологии трекинга контрольных точек(issue tracking, часто их называют «системы управления задачами», «системы отслеживания ошибок», «системы отслеживания поручений»). Название отражает тот факт, что контрольные точки появляются не в плановом порядке, они изначально представляют собой вопрос/проблему(issue), требующую своего решения. Трекеры(issue trackers, софт для трекинга контрольных точек 192 192 Кроме трекеров контрольных точек общего вида, были распространены трекеры ошибок в программном обеспечении bug trackers, трекеры инцидентов/заявок пользователей в ходе администрирования IT-инфраструктуры. Постепенно опыт работы с этими специализированными трекерами был обобщён, и сегодня трекеры более-менее универсальны. ) учитывают эти контрольные точки по мере их появления.