Разнообразие методов управления работами

В управлении разработкой в том числе принимается решение о том, какие именно методы управления работами выбрать, ибо существует большое разнообразие этих методов (проектное управление и то существует в довольно большом разнообразии, вариантов канбана огромное количество, управление кейсами имеет не очень похожие друг на друга версии, и так даже с крупными классами методов, которые давно у всех «на слуху»). Главный вопрос в применимости этих методов в том, можно ли заранее запланировать работы, хотя бы крупными шагами, которые можно было бы взять из какой-то обобщённой модели инженерного процесса. Помним: чтобы выполнить работу, её надо а) знать, какую именно (это задача методологии) и б) запланировать в плане выделения ресурсов. Это разные шаги, разные методы прохождения этих шагов, включая ещё и рациональность как обобщающее для этих шагов рассуждение по выбору метода и переходу к действию (скажем, вы выбрали метод, потом попытались запланировать действия по этому методу — поняли, что ресурсов недостаточно, дальше или выбираете методы добычи этих недостающих ресурсов, или выбираете новый метод, который требует другого набора ресурсов, или вообще бросаете затею — ибо она оказывается невыгодна. Вот этот выбор метода с переходом к действию — предмет рациональности, подробности в руководстве по интеллект-стеку, но азы рациональности давались уже в руководстве по рациональной работе).

Какие вообще методы/практики/стили работы применять? Например, какими методами лечить пациента, когда непонятно ещё, чем он болеет? Какими методами изготавливать систему, когда ещё непонятно, какие части войдут в её состав, да и вообще ещё плохо понятно, что сама система будет делать? Это всё вопросы методологические. Но когда они отвечены и метод работ известен, в «операционном менеджменте»/«управлении работами» проводится шаг (операционного) планирования: принимается решение — кому (оргзвено, назначаемое на роль) и когда (физический отрезок времени) выполнять работы по уже известному методу работы, чтобы общая продолжительность и стоимость работ по проекту создания и развития системы были минимальны. Обратите внимание, что минимизируются общая продолжительность и стоимость работ, а не продолжительность и стоимость той работы, которая планируется. Тем самым оптимизация идёт по общему плану работ, а не конкретной одной работы.

Управление работами имеет множество разных вариантов практик, каждая из которых характеризуется своим вариантом дисциплины, которые предлагают свои предметы интересов и соответствующие методы описания потока работ. Предпочтение для всех вариантов одно: ускорение общего (через всех работников, а не через одного работника, иногда говорят «глобального», имея в виду всё предприятие со всеми работами всех его проектов) потока работ при минимизации их стоимости.

Классическое управление проектами(project management, проектное управление) подразумевает одномоментное планирование перед началом проекта для всех контрольных точек/milestones как сроков их достижения, так и ресурсов для их достижения — и делается это на основе нормирования трудоёмкости работ. По факту это означает составление плана-графика выполнения всех работ с назначением ресурсов на эти работы ещё до начала выполнения работ, причём производительность труда работников считается известной из каких-то «нормативов». Это часто называют предварительным (up-front) планированием работ, а весь проект просто считают уникальной работой, имеющей чётко определённые время начала и конца, а также выделенные для неё ресурсы. В современных версиях методологий проектного управления, конечно, предусматривают регулярную актуализацию планов по ходу выполнения проекта, но именно актуализацию уже имеющихся планов работ, они не предполагают непрерывного планирования на маленькие шаги вперёд работы в ситуации неопределённости с содержанием, бюджетом, сроками проекта.

Обратите особое внимание, что кроме известности состава, трудоёмкости и последовательности работ перед началом проекта для управления проектами нужно знать ещё и нормы выработки для ресурсов: оценки производительности ресурсов, полученные из опыта прошлых работ. В строительстве, например, хорошо известны нормы выработки: сколько кирпичей в час в среднем кладёт каменщик, сколько арматуры в час вяжет арматурщик. А вот если речь идёт о работах по программированию, то там производительность труда может отличаться до 20 раз. Поэтому в современном проектном управлении негласно принимается, что бюджеты и сроки надо принимать как незыблемые константы, а вот состав работ можно менять — в срок и в бюджет укладываться за счёт того, что уменьшать количество работ. Это называют управлением «предметом работ проекта»/project scope, то есть определяется, что именно не будет сделано — и это означает, что какие-то запланированные фичи системы будут банально не сделаны, ибо «ресурсов не хватило, времени не хватило». Невозможность выполнения всех запланированных работ тем самым сдвигается с менеджеров (у них всё получится в срок и в бюджет — это не трогают) на инженеров (их обвинят в том, что взяли лишние обещания — часть не успеют выполнить в том объёме, в котором планировали).

Отнюдь не все работы с системой удаётся запланировать до начала выполнения этих работ, когда уже определяются бюджеты и сроки, но мало что известно про описание системы (нет ещё концепции системы, нет архитектуры, нет подробного проекта/design с точностью, достаточной для изготовления — рабочей документации, «рабочки»), мало что известно про трудности производства/изготовления воплощения системы, иногда даже неизвестно, кто будет (даже так: кто сможет) систему изготовить, причём во множестве её самых разных ожидающихся версий. То есть непонятно, что будем делать — это означает, что непонятно, кто это будет делать, непонятны создатели (в проектном управлении создатели — это «ресурсы», как сами оргзвенья, так и входящий в их состав инструментарий и необходимые для работы материалы). Предварительное планирование легко делать для проектов изготовления и сборки, когда описание системы готово. Это, например, крупное машиностроение «под заказ» при уже готовом проекте системы, строительство. Но вот детально планировать работы по описанию/проектированию сложной системы обычно не удаётся — часто даже непонятно, какие при проектировании могут потребоваться ресурсы, сколько и каких частей системы придётся разрабатывать, сколько гипотез надо будет отвергнуть, прежде чем найдётся приемлемый вариант проектного решения. И тогда используют другие методы управления работами, не требующие обязательного up-front планирования и обязательного знания норм выработки для выполняющих работы ресурсов.

Если непонятно, какие могут быть большие куски работы в задуманном проекте, то проект переименовывается в программу (которая сама будет состоять из проектов как отдельных «пакетов работ»), а метод управления работами тут — управлении программами (program management, управление программами проектов). По мере понимания содержания работ и требуемых ресурсов для проектов в рамках программы (это инженерная, содержательная работа!), в рамках программы запускаются отдельные составляющие её проекты. Каждый проект будет проходить предварительное/up-front планирование достижения своих контрольных точек (milestones), как в классическом проектном управлении. Но у программы не будет плана запуска отдельных проектов программы (только невнятные неформальные намётки, часто называемые roadmap), ибо деятельность программы как раз и состоит в выявлении этих проектов и планировании их, а дальше работы проектов управляются стандартными методами проектного управления. Скажем, roadmap может быть объявлен для создания и развития системы: создания как выпуска MVP, а развития системы — заранее будет намечено, как во времени будут располагаться какие-то версии системы с увеличивающимися со временем возможностями/фичами. Управление программами отличается от остальных методов управления работами тем, что более мелкие работы (проекты) управляются в них другим методом, нежели сама программа: в программах работ обычно нет «подпрограмм», зато есть «проекты» из проектного управления. В проектах же обычно можно найти подпроекты, в процессах процессного управления — подпроцессы, в кейсах управления кейсами — подкейсы и т.д. Все методы управления работами предусматривают разбиение работ, но методы на каждом уровне разбиения остаются теми же — за редкими исключениями, вроде управления программами проектов, которое предусматривает для своих проектов переход к проектному управлению.

Если методы работы, конечные результаты, контрольные точки (моменты времени) и ресурсы для их выполнения известны, но неизвестно, в какой момент происходит запуск большого числа однотипных работ, речь идёт о процессном управлении (process management). Процессом тут называют не метод работы (рабочий процесс), не уникальную работу, а типовую последовательность шагов, обычно определяемую не столько планом (и уж тем более не графиком), а регламентом (описание метода работы, заданное «императивно», как последовательность шагов, возможно, с какими-то разветвлениями по достижению определённых условий). В последние несколько лет вместо регламента чаще используется компьютерная программа. Если процесс описывается компьютерной программой, его называют workflow/«поток работ» и оговаривают, что это такие работы, одни части которых выполняются людьми, а другие части — компьютерами. Тогда workflow описывается по факту дважды: один раз регламентами (для людей), другой раз кодом программы (для компьютеров, причём речь идёт о классическом корпоративном софте, а не о системах AI). Всё чаще в регламентах ничего уже не пишут, ибо компьютерная программа очень жёстко определяет, что должен и даже что вообще может сделать работник, который участвует в workflow (все мы слышали: «да, вы имеете право, но компьютер не пускает меня выполнить ту операцию, которую вы хотите»).

Все эти перечисленные варианты методов управления работами потихоньку сдают свои позиции управлению кейсами (case management), которое приходит под самыми разными именами. Собственное имя «управление кейсами» она имеет разве что в медицине, а её варианты в других сферах называются очень по-разному (какой-нибудь «Kanban for development», поддерживаемый софтом issue tracker, или TameFlow с критикой Kanban как устаревшего метода операционного менеджмента).

Это всё обсуждались варианты методов операционн****ого менеджмента (прикладная методология операционного менеджмента): предметы интереса операционных менеджеров лежат в том**, кто****::оргзвено** что**::работа** когда::время** с чем::«рабочий продукт»** делает, и предпочтение в том, что **общую (глобальную) скорость выпуска (throughput)** надо увеличить исключительно за счёт правильного выбора времени запуска работ в зависимости от наличия ресурсов и поступающих в неожиданные моменты от инженеров новых решений о необходимости каких-то работ и задействовании каких-то неожиданных ресурсов.

Операционному менеджменту посвящён большой раздел в руководстве по системному менеджменту.