Как универсально управлять проектами

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

Каждый бизнес, так или иначе, сталкивается с вопросом: каким образом реализовывать проекты. В современном, быстро меняющемся мире гибкость — уже просто необходимость. Именно поэтому, так часто стали использовать философию agile, при этом все равно возникают высокоуровневые планы действий, и вклиниваются миксы разных моделей, методологий и философий. Чем больше проект, тем сложнее и запутаннее. Попробуем разобраться.

Вся загвоздка в том, что мир многогранен и часто подход к управлению проектами зависит от таких вещей как:

• направления бизнеса

• конкретного проекта или продукта

• масштаба и объема работ

• точности требований

• людей в разных слоях компании

• заказчика и желаемого результата

Там где будет работать одно — другое ни к месту. Это все конечно сотни раз прописано и кажется очевидным. Тогда в чем вопрос.

А так ли все нестабильно и индивидуально на самом деле, и неужели общего «рабочего» подхода нет?

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

Выглядит схематически так, постараюсь объяснить как с этим работать.

Для качественного понимания разделил проекты на несколько типов, цифры условные.

По масштабу и длине проекта:

• Простые (до ~3 месяцев)

• Средние (от ~3 месяцев до ~1 года)

• Сложные (от ~1 года до бесконечности)

По точности поставленных целей:

• Точные (тендеры, дубликаты проекта, партия товара — цель ясна и полностью понятна)

• Смутные (все остальное, где цель — вроде есть, но как она должна точно выглядеть — не понятно)

Вот тут поверхностно напомню про некоторые стандартные модели и методологии и их основную черту:

Модель — структура, по которой мы работаем.

Методология — способ, которым мы работаем, а также набор принципов, которых мы придерживаемся.

Философия — «стиль жизни».

..

Spiral (спиральная метамодель) — включает в себя несколько моделей SDLC, например, итеративную (циклы), при этом делаем упор на анализ рисков.

Iterative (итеративная модель) — шаг за шагом улучшаем «общую картину». На каждом цикле‑итерации предоставляем результат.

Incremental (инкрементная модель) — на каждом шаге делаем 1 кусок, но целиком и полностью.

Waterfall (водопадная или каскадная модель) — классика — «шаг за шагом», пока не сделали предыдущий, новый не начинаем. Требования не меняем.

Scrum — методология. Один из вариантов Agile — философии. При этом используем итерации (циклы) обычно — пара недель. И подходим ко всему «гибко». Много видимся и обсуждаем, как идут дела, чтобы быть в курсе и быстро реагировать.

А теперь возьмем, как принято, крупный проект с Мона Лизой и начнем разбираться.

Итак представим, что перед нами «смутный проект»

Так как картина нашего мира быстро меняется, строить конкретные планы (модель Waterfall) для больших проектов — очень самоуверенная штука, особенно в текущих реалиях. Даже масштабные инженерные госзаказы — спорно. А вот верхнеуровневые бизнес‑цели проекта — возможно и даже нужно.

От спирали (метамодель Spiral) взял красивое название и анализ рисков. Зачем? Ну, как по мне, реальность такова, что без анализа рисков на каждом крупном бизнес‑шаге можно сесть в лужу. Конечно же, это не обязательно.

..

Вывод: этот кусок можно использовать в любых проектах для верхнеуровневых бизнес‑целей.

А теперь тот же уровень абстракции, только в контексте «точного проекта». В этой ситуации у нас более явные цели. Например: тендер на станцию зарядки для электромобилей «Энергия Москвы» — имеем четкое тз и нужно просто сделать. При этом внутри самого проекта мы вольны делать так, как удобнее, быстрее, дешевле и тд.

Естественно, чем крупнее проект, тем больше рисков. Соответственно нужно больше опираться именно на бизнес‑цели, а не на четкий результат каждого шага. Тут вариативно, потому что граница размеров проекта размыта.

Вывод: Эту часть используем в «точных» проектах, средне‑великих (иногда), средних, маленьких.

Идем дальше.

Спускаемся на один уровень абстракции. Между огромными шагами есть средние. И снова, чем больше проект, тем массивнее конструкция, что логично. Держим в голове «смутный проект».

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

Каждый заказчик хочет знать «ну че там», будь он внутренний или внешний, гос или не гос. Такой подход создает больше уверенности как внутри команд, так и на стороне руководителей. Больше видимого результата — меньше стресса — часто больше дела. И, конечно, все упирается в оптимизацию ресурсов и уточнения требований у заказчика. Классика…

Именно поэтому и возникли все эти чудесные схемы управления. Ну и частично, чтобы «бабки рубить» модными словами. (про некоторые методологии и философии)

А теперь прибавим сюда немножечко анализа рисков (модель Spiral) да‑да, снова она, потому что не только бизнес‑цели нуждаются иногда в переоценке на большой дистанции, но и основные шаги. Отслеживая прогресс, мы можем более адекватно прогнозировать, что будет в итоге, какое время и сумму еще нужно вложить, и где мы проседаем. (снова не обязательно)

Вывод: можно использовать это почти везде, где‑то как основу проекта, где‑то как вложенный уровень «Waterfall» абстракции. Для больших, средне‑крупных, средних, некоторых маленьких проектов, а также разных продуктов. Кроме, например, ….

…вот такого варианта — возвращаем контекст «точного проекта». Внимание на волшебную Мона Лизу. Это ситуация, когда разные отделы, домены, команды и тд. делают что‑то в очень разном режиме и на каждом шагу — это целый проект.

Например, мы строим ракету. В таком ключе мы не можем собрать всю конструкцию за раз, а потом, по факту, допиливать на коленке каждый модуль и итеративно улучшать. Какой выход? waterfall

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

Вывод: используем, когда «не собирается» на каждой итерации; как полноценный проект, либо в составе «Waterfall» абстракции; для почти всех размеров проекта.

Ну и теперь ура, нижняя абстракция.

Таак, ну, тут поговорим о том, как нам все успевать в больших и средних проектах. Основной недостаток waterfall и, иногда, incremental — не гибкость и «шаг за шагом» что значит, каждый работает только тогда, когда предыдущий закончил хотя бы «нормально».

Устраняем недостаток, распараллелив процессы, насколько это возможно, на куски‑инкременты (модель Incremental). Теперь у нас есть бОльший кусок, разделенный на меньшие. Где каждая команда и тд. занимается, очевидно, своим.

В сумме с предыдущей абстракцией у нас, на самом деле, вышла Эволюционная модель — в итерации встроены инкременты.

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

Вывод: уверен, и так понятно, используем в «составе», когда дел и делающих много.

И последний рывок. До которого добрались самые заинтересованные и «скролящие»

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

Методологии Scrum, Canban и модель V это просто, как примеры исполнения на самом низком уровне. Также сюда иногда хорошо подойдет Waterfall отдельно или в составе Scrum, или в виде «инструкций».

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

Например, принцип модели V — тестирование, можно вклинивать и в абстракции более высокого порядка, если есть смысл. Или использовать эту же модель, только для СМК — управление качеством.

Методологию RUP — можно включать в среднюю абстракцию на уровне Iterative, если нужно ооп и упор на архитектуру. (она в принципе достаточно гибкая и была создана как «универсальное решение», как и этот шаблон)

Обобщим по статье:

По большей части проект — подпроекты с вложенностью (Большой‑(Средний средний‑(малый малый малый))).

• На самом высоком уровне — бизнес‑цели, либо точные проекты

• На среднем уровне — итеративно с наложением подходящих «модулей» — тестирование, анализ рисков и расчетом на нужное кол‑во шагов.

• На низком уровне — вложенность кусков — инкрементов в каждый шаг итерации.

• На самом низком уровне — инкременты, делаем максимально гибко, используя подходящую структуру.

Касаемо философий и некоторых принципов — это вопрос уже немного другой, как по мне.

Ну вроде все, спасибо, что дочитали, добавлю — «все это индивидуально») Естественно, существует масса исключений, без них никуда… Все, что можно «обобщить» для универсального шаблона — надеюсь доступно донес. Это в том числе благодаря людям, которые делают выжимку из своего опыта и пишут статьи, спасибо вам, если читаете.

Если будут какие‑то дополнения, корректировки или просто комменты, которые могут помочь форумчанам или мне в более глубоком понимании, для улучшения шаблона — буду рад.

Вопросы можно писать в телеграмм @heritager_tech, по возможности буду отвечать.