PMI, Scrum и Kanban – как работать с содержанием (scope) в каждом из подходов и где границы его применимости

Меня зовут Иван Селиховкин, я руководитель проектов в 15-летним стажем.

В последнее время я больше выступаю как менеджер и сам не занимаюсь вопросами содержания проекта, составлением ТЗ, сбором требований – делегирую это коллегам.

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

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

Давайте я сначала представлюсь, а потом вернусь и объясню, о чем пойдет речь.

• У меня очень разнообразный опыт проектной деятельности – в основном, в сфере ИТ и производства. Например, мое предыдущее место работы – компания, производящая медтехнику. Мы создавали аппаратуру и разрабатывали для нее софт. При этом львиная доля моих проектов – это ИТ-проекты. Сюда относится самая разная разработка – заказная, продуктовая и т.д.

• Я работал в больших и маленьких компаниях, в бюрократичных и не очень. Когда-то давно работал в госсекторе, теперь, к счастью, там не работаю. Я это говорю к тому, что на своем опыте знаю, как работает проектное управление в самых разных видах.

• На тему управления проектами я часто выступаю и периодически подтверждаю свои знания – сдаю экзамены и получаю сертификаты.

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

Основные управленческие подходы: как выбрать подходящий

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

Обсуждать выбор подхода к работе с содержанием с менеджером, не достигшим трехлетнего стажа, тяжеловато, у него все-таки обычно слишком однобокий опыт – либо побед, либо поражений. Но к трем годам стажа обычно большинство менеджеров нарабатывает какой-то бэкграунд, и у них возникает множество вопросов: «правильно ли мы тут работаем?», «как же все-таки лучше сделать, если у меня есть возможность выбирать?».

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

Когда мы говорим про менеджмент в ИТ, тут же возникает вопрос, какой подход при этом подразумевается. Я на слайд вывел три подхода, которые сразу приходят на ум. Их на самом деле больше, но эти три подхода знают более-менее все – это Скрам, Канбан и классический подход.

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

Конечно, работа с содержанием – не единственный пункт, на который мы смотрим, когда выбираем Скрам или Канбан. Но это один из двух-трех очень важных факторов, который имеет фундаментальное значение.

Предлагаю вам вместе со мной в течение 20 минут пробежаться по методам и погрузиться в них.

• Во-первых, я покажу, что означает выбор подхода в контексте работы с содержанием.

• Во-вторых, расскажу, где границы применимости подходов – как вы сможете работать с содержанием, применяя Скрам, а как – маловероятно, не ломая сам Скрам.

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

• «Руководство по Скраму», Кен Швабер и Джефф Сазерленд

• «Канбан краткое руководство», Дэвид Андерсон

• PMBoK 6^th edition – тяжелая для чтения книжка, но я для нее написал более упрощенную версию, которая вполне обеспечивает быстрое погружение – вы можете бесплатно скачать ее по ссылке.

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

На что ориентируется менеджер, думая, выбрать ему Скрам, PMI или Канбан?

• Первое – это его субъективное впечатление, что он больше любит, о чем он чаще слышал на конференциях.

• Второе – он смотрит на всякие вспомогательные вещи вроде Cynefin-framework (произносится как Кеневин-фреймворк).

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

• Если система сложная (внутри системы много связей), то, скорее, нужен классический подход в управлении проектами.

• А если система запутанная (заинтересованных сторон много, требования изменчивы, неопределенность очень высокая и т.д.), тогда, скорее, нужно что-то из Agile-семейства, тот же Скрам.

Специфика Кеневин-фреймворка в том, что он подталкивает большинство людей найти свой проект в верхнем правом квадранте. Большинство людей, которым объясняешь, как работает Кеневин-фреймворк, говорят: «Да, у нас запутанная система – у нас и заинтересованных сторон много, и изменчивость высокая, и требования меняются».

Но вообще эти тезисы подходят практически к любой ИТ-системе. Поэтому менеджер обычно решает проблему выбора либо эмоционально, либо подкрепляя свои эмоции таким Кеневин-фреймворком.

А теперь давайте посмотрим на это в разрезе работы с содержанием.

Реалии работы с заказчиком

Что такое работа ИТ-менеджера, ИТ-команды? Как ни крути, ИТ-команда – это люди, которые оказывают некоторые услуги заказчику. Это очень общее утверждение, но это примерно всегда так. Есть некий заказчик, который обычно очень смутно понимает, чего хочет. У него есть какое-то представление о своей идее, но он не может объяснить деталей до конца. С этим он приходит к ИТ-команде.

Почему это почти всегда так? Потому что в жизни работает эмпирическое правило: если человек до деталей знает, чего он хочет, он, как правило, сам это может сделать.

Например, я по первому образованию хирург, и только по второму – ИТ-специалист. Я могу вас уверить, что, если я как врач могу представить себе детали какой-то операции и расписать, как ее надо делать, значит, я эту операцию когда-то делал сам, и неоднократно. Если же я только в общих чертах представляю, чего хочу, значит, я в этом не специалист, и сам этого сделать не смогу.

Так вот заказчик – это почти всегда человек, который не знает деталей, потому что, если бы он их знал, он бы к вам не пришел. Он примерно понимает, чего хочет, и приходит к ИТ-команде за какой-то услугой.

Какие варианты есть у ИТ-команды в таких условиях:

• Первое – до деталей или хотя бы до среднего размера блоков прояснить, чего заказчик хочет, зафиксировать все это, и пойти работать. Это – один подход.

• Другой подход – не париться и делать, что сказали. Например, у заказчика внедрена какая-то бухгалтерская ИТ-система, и он хочет ее доработать – что-то выгрузить, поменять, сделать новый отчет. От него прилетают задачки, и он сам говорит, что приоритетней. А что приоритетнее, то мы и берем в работу первым.

• Третий вариант – мыслить какими-то блоками, которые имеют для заказчика значение. Это еще можно назвать термином MVP (minimum viable product). Заказчик накидал каких-то идей – например, он хочет мобильную игру, в которой будет 80 уровней, 50 персонажей, возможность покупать, продавать оружие и так далее. Мы ему говорим: «Хорошо, давайте из этого сделаем версию 1.0». Решаем, что в нее должно войти минимально, чтобы в это уже можно было играть, а остальное мы будем наращивать постепенно. Мы этот MVP формулируем, и дальше его реализуем.

На самом деле большинство современных менеджерских ИТ-подходов находятся где-то в этой системе координат.

• Левая часть – это скорее классический подход, когда мы тратим время на прояснение деталей и потом держимся за эти прояснения, и все время поддерживаем целостность этих документов.

• В правой части – подход, в котором можно распознать Скрам. То, что нарисовано, очень напоминает Scrum backlog. Но при этом точно так же можно использовать и Канбан-метод, и классический подход.

• Посерединке – подход типа: «Вы скажете – мы сделаем». С таким подходом вполне совместим Канбан-метод, а остальные подходы (Scrum и PMI) не очень хорошо так работают.

Таким образом, если перед нашим менеджером стоит заказчик, который смутно представляет, что хочет, можно:

• либо начать все прояснять до деталей;

• либо слушать заказчика и брать в работу то, что он скажет;

• либо третий вариант – нащупать какой-то MVP, сделать его, потом еще раз подумать, отобрать новый кусочек функциональности, его сделать, и такими кусками дальше «есть слона».

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

Главное ограничение в применении Скрам – MVP

Начнем с MVP, попробуем сформулировать из задач заказчика продукт, который имеет какую-то минимальную полезную ценность.

Тут очень важно понимать, что Scrum-framework целиком стоит на парадигме MVP. Он говорит, что работу нужно разбить на двухнедельные тайм-боксы (спринты) и работать вот такими спринтами. Спринты могут быть и трехнедельными, но не больше месяца и уж точно не меньше недели.

Смысл Scrum-framework в том, что после одного-двух-трех спринтов вы должны быть в состоянии выдать MVP.

Конечно, разбить на спринты можно все, что угодно: мы можем дорогу асфальтировать по спринтам (первые 5 метров, вторые 5 метров и т.д.). Но идеи, заложенные в Скрам, работают только тогда, когда спустя хотя бы парочку-тройку спринтов (желательно не больше, потому что три спринта могут длиться три месяца – это долго), мы отдаем заказчику в руки результат, полностью пригодный к использованию. Если этим пользоваться нельзя – то это ерунда.

К примеру, мы делали дистанционную систему регистратуры и информационную систему для врача. Мы приходим и показываем: «Смотрите, это будет ваше рабочее место, сюда вы будете нажимать, здесь у вас будет документ распечатываться, сюда нужно смотреть и т.д.» Заказчик смотрит – вроде нравится. Но при этой демонстрации мы собрали минимум полезной информации.

Гораздо полезнее было бы, если бы мы посадили врача, и он сам попробовал бы разобраться в этой системе. Ценность сразу кратно больше. Это суперценность, которую Scrum пытается извлекать. Он говорит: отдайте продукт человеку в работу, посмотрите, как он мучается, сделайте выводы и доработайте.

В чем ограничения в применении Скрам?

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

• Наверху показан путь создания продукта не через MVP. Клиент захотел машину – мы ему сначала сделали колесо, потом шасси, потом кузов и только потом машину. Пока мы не достигли последней стадии, клиент ничем пользоваться не мог.

• Во второй строке тоже не MVP. Да, клиент хотел машину. Зачем мы ему пихаем велосипед, потом самокат, потом мотоцикл? Есть известный тезис, что нельзя построить мост по Скраму. Да, нельзя – я об этом много раз говорил и еще раз повторю. Как бы прекрасно люди вроде Сазерленда не писали о том, что они делают ремонт по Скраму (когда делается одна комната, они живут в другой), в общем случае и к строительству, и к производству Скрам плохо применим.

• Для понятия MVP реально подходит только нижняя строчка. Обращайте на это внимание.

В качестве примера первого ограничения приведу пример из моей практики. На предыдущем месте работы мы делали томографы. У томографа есть специальный PACS-сервер, который хранит сделанные снимки. Его функциональность заключается в том, чтобы принимать и отдавать изображения по запросу, поэтому хороший PACS-сервер должен быть быстрым, энергоэффективным и работать без сбоев. Мы создавали такие PACS-серверы, и команда пыталась это делать по Скрам, по спринтам.

Я говорил: «Стоять! Какой у нас MVP?» – они говорят: «у нас MVP – сервер» – «Отлично, значит, MVP у нас в конце. Можем ли мы посередине проекта, в первую треть проекта дать заказчику в руки что-то полезное?» – «Нет не можем».

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

Второе ограничение – построить мост по Скраму нельзя. Если заказчик просил мост, значит, ему нужен мост, по которому он будет ездить. Нельзя ему дать сначала сваи, потом на них положить какой-нибудь настил и т.д. Нельзя ему сдать сначала первую треть моста, потом вторую треть моста, потом и весь мост. Это не спринты, это не MVP.

В качестве возражения на этот пример обычно говорят: «Пока строится мост, можно дать заказчику паромную переправу или объездную дорогу, и пусть он пока этим пользуется». Хорошо, представьте заказчик ездит по вашей паромной переправе или объездной дороге. Какую обратную связь вы от него получаете? Нравится ли ему ваш мост? В том-то и дело, что здесь, как на второй строчке слайда, вы дали ему совершенно другой продукт и собираете совершенно ненужную обратную связь. Он и без вас, наверное, умел ездить на другую сторону – ему мост нужен.

Скрам и Канбан не применимы при большом количестве взаимосвязей

Давайте теперь разберемся с применимостью гибких подходов.

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

Второе ограничение при выборе гибких подходов – это взаимосвязи. Это ограничение касается:

• и подхода Канбан «Что сказали, то и делаем», где на доске у нас задачи из колонки ToDo едут вправо в сторону Done;

• и подхода Скрам «Попробуем сформировать MVP и cделать его», где бэклог продукта реализуется через спринты и бэклоги спринтов.

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

Покажу на примере.

На картинке – пример Канбан-доски с задачами и ответственными.

Обратите внимание, что в Канбане есть две необязательные роли:

• Service Request Manager – тот, кто пополняет и приоритизирует колонку ToDo, он здесь в красной шляпе;

• Service Delivery Manager или Flow-мастер – следит за потоком и ограничивает незавершенную работу, он здесь показан в серой шляпе

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

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

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

Такие блокеры есть возможность установить и в Jira, и в Kaiten. А в классическом Канбане все блокеры и взаимосвязи между ними держит в голове Service Delivery Manager (дядька в серой шляпе).

А теперь представьте, что ваш проект так устроен, что многие задачи в нем нужно делать параллельно – в 1С это сплошь и рядом бывает. Например, когда в компании много подразделений – склад, логистика, финансовый блок – и для каждого используется своя учетная система. Представьте, что склад в своей системе что-то поменял, для них релиз выкатили. Бухгалтерии теперь тоже надо это поменять параллельно, иначе все сломается, и данные со склада до бухгалтерии дойдут сломанные.

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

Когда все залеплено блокерами, Канбан-метод плохо работает. У вас ломаются метрики – вы не понимаете, почему ползут вверх Cycle Time, Time-to-market и прочее. Но мы сейчас не про время, мы про содержание.

Так что же с этим делать? А ничего.

У Канбан-метода посыл такой же, как у Scrum framework – он звучит примерно так: «Минимизируйте зависимости в бэклоге, формулируйте задачи так, чтобы между ними не было зависимостей, или их было меньше». Если между собой связаны две-три задачи – это не проблема, но, когда каждая вторая задача связана с еще двумя – это офигенная проблема. Фактически ваш бэклог превращается в диаграмму Ганта, но поскольку в Канбан-методе это не очень уместно, то зависимости вы заменяете на блокеры.

Это еще одна граница применимости. Если вы обратитесь к известному Канбан-тренеру и спросите у него, что делать с большим количеством зависимостей, он, скорее всего, ответит вопросом: «Уверены ли вы, что у вас уместен Канбан-метод?». Мне несколько очень знаменитых Канбан-тренеров уже так отвечали.

Повторю: блокеры и зависимости – это ограничения в применении Канбан-метода и Scrum. Можно применять, но чем больше будет зависимостей, тем больше вы будете мучиться.

Источники дополнительных взаимосвязей при использовании Канбан-метода

Кроме этого, при приемке задачи и проверке критериев готовности – Definition of done (критерий полной готовности задачи) и Acceptance criteria (критерий того, что задача не просто готова, а еще и работает так, как надо заказчику) также могут возникать зависимости в виде ряда дополнительных задач, среди которых какие-то – очевидные, а какие-то – нет. Тут тоже нужно быть внимательным.

И еще одно, последнее. Возможно, это прозвучит неочевидно, но среди каденций – регулярных мероприятий, которые вы проводите при использовании Канбан-метода, есть такая вещь, как Delivery planning meeting – собрание планирования поставки.

Все каденции, используемые в Канбан-методе, показаны на слайде.

Delivery planning meeting проводится по мере выпуска релизов – на этой встрече вы обсуждаете, о чем нужно не забыть подумать при ближайшей поставке, что в эту поставку включить. Такие встречи проводятся, помимо прочего, еще и для того, чтобы подумать, что дополнительно не-ИТ-шного нужно не забыть сделать.

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

Delivery planning meeting – это еще один источник зависимостей, поэтому, возможно, его имеет смысл запустить по доске отдельной карточкой, чтобы про эти зависимые задачи не забыть.

Повторюсь: когда зависимостей становится много, Канбан-метод начинает буксовать.

Влияние взаимосвязей на Скрам

Со Скрамом та же самая история. На слайде показано, как устроен Скрам – бэклог, спринты, красота.

Причем в бэклоге Скрама лежат не только User Story, но и всякие прекрасные вещи вроде технического долга, RnD-задач и всякого такого.

И тут возникает та же самая проблема: если в бэклоге много взаимосвязей, работать по Скраму сложно.

К счастью для нас, менеджеров, Скрам так построен, что менеджера в нем нет – это очень удобно. Вместо этого там есть владелец продукта, который полностью находится за пределами Scrum Guide, поэтому неизвестно, как он принимает решения и на что он смотрит.

Поэтому просто найдите человека, который будет уметь при помощи всяких Story Map, Customer Journey Map и прочего придумывать, что нужно делать в первую очередь, а, во-вторых, держать в голове взаимосвязи, которые плодятся в бэклоге.

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

Пока этих взаимосвязей немного – все прекрасно.

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

Ограничения применимости классических подходов

Чтобы закруглиться, давайте поковыряем еще и классический подход – там тоже есть проблемы.

В отличие от тех подходов, о которых мы говорили раньше, он предполагает, что:

• мы собрали требования, структурировали их;

• потратили время на то, чтобы из требований бэклога сделать целостное ТЗ;

• потом вы это ТЗ превращаете в некую иерархическую структуру работ;

• а на основе иерархической структуры работ вы строите сетевую диаграмму – то, что менеджмент называет диаграммой Ганта.

Плюс диаграммы Ганта в том, что она узаконивает зависимости.

И если для Скрама или Канбана много зависимостей – это плохо, то для классических подходов – это нормально, они так привыкли жить.

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

Почему же тогда считается, что работать с требованиями по классическим подходам сложно?

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

• Кроме этого, у классических подходов гораздо более высокая стоимость –первоначальная проработка занимает много времени, а у бизнеса столько времени очень часто нет, он не готов столько ждать, он говорит: «Поехали, потом заведешь!» Кроме этого, нужно еще поддерживать целостность всего этого. А что делать, если заказчик решил внести правки в ТЗ, пришел с новыми требованиями? Они должны пойти по цепочке – мы должны скорректировать ТЗ, скорректировать диаграмму Ганта. И это гораздо сложнее, чем докинуть User Story в бэклог, и ее там приоритизировать. И гораздо дороже во времени. Правда, когда у вас достаточно сложная система, у вас может не быть другого выхода, и вам придется потратить это время, но в целом – цена такая.

• Еще одна проблема классического подхода – это проблема экспертности. Чтобы написать ТЗ и сделать иерархическую структуру работ, у команды должно быть большое количество экспертных знаний. В команде должны быть аналитики, люди, которые умеют работать с требованиями. В Скраме или в Канбан-методе иметь аналитиков в команде не обязательно, потому что в Скраме есть бэклог, который мы потихонечку прорабатываем и уточняем. А в классическом методе у вас должна быть высокая планка экспертных знаний. Это – еще одно важное ограничение.

Итак, классический подход – это трудоемко, дорого и гораздо выше требования к экспертным знаниям команды.

Выводы

Обобщаем все, что я сказал.

Изначально у нас был заказчик, который смутно понимал, что хочет.

В такой ситуации у нас есть три варианта, как двигаться дальше:

• либо прояснять до крупных блоков,

• либо вообще не париться, брать задачки, которые он приносит,

• либо мыслить категориями MVP.

У каждого из этих вариантов есть свои проблемы – они все сейчас на слайде:

• для Scrum обязателен MVP – но быстродоступный MVP есть не везде;

• для подходов Scrum и Kanban – есть проблема взаимосвязей (возникают блокеры);

• проблема взаимосвязей лечится классическим подходом, но там своя цена – это дорого, трудоемко и требует экспертных знаний.

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

Cynefin-фреймворк для запутанных систем подталкивал нашего менеджера к выбору Agile-подходов. А мы сейчас рассмотрели еще один аспект выбора – с точки зрения работы с содержанием. Я вам попытался рассказать показания и противопоказания к выбору того или иного подхода в зависимости от содержания требований в проекте.

Еще раз напомню подходы, про которые мы сегодня говорили:

• Скрам (Scrum) – «Руководство по Скраму», Кен Швабер и Джефф Сазерленд

• Канбан-метод (Kanban) – «Канбан краткое руководство», Дэвид Андерсон

• PMBoK 6th edition – «Управление ИТ-проектом с нуля в любой организации», Иван Селиховкин

Если что-то из этого вы не читали, можно посмотреть.

Вопросы:

Если невозможен MVP, невозможны небольшие релизы, может ли быть польза от применения Скрам?

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

Может быть, Скрам на стройке начинается с уровня мастера участка?

Насчет мастера участка спасибо, это интересная аналогия. Но если начальнику участка нужно спроектировать и построить ангар – какой тут может быть MVP?

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

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

Но когда мы дробим стройку на команды, эти команды внутри могут работать по Скрам. Вот у нас так в проектном офисе тоже есть. Сверху Канбан, а снизу – Скрам-команда, например.

Терминологический вопрос – вы сначала обозначили подходы как Скрам, Канбан и PMI. Как вы считаете, правомерно ли название подхода PMI, если со 2 января 2021 года в требованиях к основному экзамену PMP половина вопросов уже касается гибких методик управления?

Я могу называть подход PMI длинно – «классический подход к управлению проектами, такой как PMI, Prince 2 и т.д». А могу кратко – PMI-подход.

Я просто постарался донести мысль, что, когда я говорю PMI, я имею в виду подход, основанный на сборе требований, формализации их в ТЗ, и превращение их в диаграмму Ганта.

Действительно, еще шестое издание PMBoK содержало приложение в 100 страниц под названием Agile Practice Guide. Но тот факт, что шестая и седьмая версия PMBoK пытаются вобрать в себя все многообразие, и от процессов мы переходим к принципам, не мешает нам говорить о классическом управлении проектами.

То же самое – Prince сейчас поделился на Prince классический и Prince for Agile. Классический подход никуда не делся, он существует для проектов, у которых много внутренних связей, блокеров и всего остального.

От того, что, что PMBoK 7 изменится, а PMBoK 6 стал включать в себя приложение по Agile, не значит, что исчез классический подход. Он никуда не исчез, его просто нужно каким-то словом назвать. Модель Cynefin никуда от нас не делась – все остается.

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Сбор требований и составление ТЗ: современные подходы в управлении проектами".