Каждому проектному менеджеру — от junior до senior, известен скоуп методологий управления проектами. Но многие работодатели не понимают, кто такой менеджер проектов, чем он должен заниматься и какие методологии работают для конкретных задач. Как не выбрать то — не знаю что и не попасть туда — не знаю куда? Давайте разбираться вместе.
Всем привет! Меня зовут Лана Демченко, я администратор проектов направления медицинских ИТ‑продуктов в компании «БАРС Груп». Также имею опыт работы в продажах и в административном управлении. У меня за плечами много собеседований в качестве соискателя. У меня за плечами много собеседований в качестве соискателя. Там я собирала информацию о скилах, которые нужны менеджеру проекта для профессионального роста. Хочу поделиться с вами своими накопленными знаниями, опытом и некоторыми решениями.
Функции руководителя проекта
Чтобы не выбрать «то — не знаю что», необходимо в первую очередь ответить на вопрос, кто такой менеджер проектов и чем будет полезен компании. Это специалист, который ставит цели, задачи и контролирует реализацию проектов в отведенных рамках. Его непосредственные обязанности — планирование, организация, контроль исполнения проектов, повышение эффективности проектного управления в плане коммуникаций и оптимизации процессов.
Теперь проанализируем среду, в которой предстоит работать с продуктом или проектом, и определим максимально эффективные методологии управления.
Для этого есть разные техники и инструменты. В первую очередь, это опыт, который можно консолидировать и проанализировать с помощью известного инструмента «PMBOK» — руководство к своду знаний по управлению проектами. Это стандарт проектного управления. Обычно эксперты не рекомендуют его новичкам, так как изложенная в нем информация сложна для усвоения. Этот источник лучше изучать, когда накоплен определенный проектный бэкграунд, а описанную в «PMBOK» теорию можно будет наслоить на наработанную практику и затем сделать выводы.
Но что делать, если PMBOK еще не по зубам, а требуется ориентироваться в новых проектах и продуктах? И как понять, что проектный офис правильно выбирает методологию под свои цели и задачи?
Нередко бывает, что на собеседованиях говорят: «Мы работаем по Kanban‑методу», а когда погружаешься в процесс, понимаешь, что никакой это не Kanban‑метод, а некий итеративный процесс работы с применением обычной доски (kanban в переводе с японского — доска) без использования устоявшихся метрик.
Ситуационная модель принятия решений
Вернемся к анализу и выбору нужной методологии в зависимости от поставленных целей. Для определения типа среды разработки и принятия эффективных мер по решению проблем нам пригодится достаточно простая техника – Модель Кеневина (Cynefin framework).
Данный фреймворк описывает четыре типа среды: хаотичная (запутанная); простая упорядоченная (четкая и понятная); сложная упорядоченная; комплексная (состоящая из множества взаимосвязанных частей).
1) Мы понимаем, что находимся в хаотичной среде, если:
ситуация экстренная;
нет возможности и времени для долгосрочного планирования;
дедлайны горят, проект/продукт имеет высокие риски.
Например, мы находимся в комнате, где случился пожар, или на корабле, у которого треснула корма, и повсюду хлещет вода. В таком случае помогают «Новые практики»/Do and Fix — мы должны как можно быстрее проанализировать ситуацию, прямо на месте принять решение, каким будет следующий шаг, и незамедлительно действовать.
Думаю, такая методология применяется во многих IT‑компаниях (и не только в России), но не как стандартная практика, а скорее сезонная (например, на этапе сдачи проекта и служит для «тушения пожаров»).
2) Простую упорядоченную среду определить легче всего. Как правило, в ней действия и процессы уже наработаны. Мы действуем по накатанным рельсам и четко знаем каждый следующий шаг. В таком проекте нет смысла проводить какие‑то изменения: даже на начальном этапе все достаточно просто распланировать, выдать оценку и посчитать стоимость, так как подобное делали раньше. Думаю, вы поняли о чем идет речь. Конечно же, в этой среде лучше всего применять Waterfall.
Может показаться, что эта методология устарела, ведь проект — это динамическая деятельность, и сложно предугадать, что произойдет дальше, а Waterfall как раз‑таки не приемлет никаких изменений. Такая методология отличается очень жесткими рамками, и любое отклонение от первоначального плана (который разработан до конца проекта и согласован) увеличивает стоимость проекта в несколько раз. Главный минус метода — приходится переделывать все с самого начала, так как нельзя внести изменения в какой‑то конкретный этап. Тем не менее, Waterfall жив и подходит для государственных организаций, работающих на тендерной основе. Или для коммерческих компаний, где нужно внедрять CRM‑систему (типовое стандартное решение, с примерно одинаковой стоимостью для всех заказчиков).
3) Сложная упорядоченная среда отличается от простой упорядоченной тем, что здесь также прослеживается причинно‑следственная связь, но она не столь очевидна и требует более глубокого анализа. Приведем пример: мы занимаемся строительством жилых комплексов. На первый взгляд, есть четкое понимание, как это реализовать, так как ранее был уже подобный опыт. Но каждый такой проект уникален и требует более глубокого анализа ситуации (так как учитываются рыночная ситуация, локация участка, особенности ландшафта и многие другие параметры).
В такой среде наиболее подходящими будут стандарты проектного управления: американский подход PMI (PMBOK) и британский Prince2. Также применим относительно новый фреймворк, основанный на двух этих методологиях — P3express.
Казалось бы, здесь применим и Waterfall, который также позволяет проследить причинно‑следственную связь. Но, в том же строительстве, на любом этапе могут произойти изменения: оборудование вышло из строя, а у поставщика не оказалось в наличии замены; привезли некачественные материалы; не вышли на смену рабочие, погода не позволяет проводить работы т.д. В таком случае нам, увы, придется подстраиваться и менять план проекта частями, а согласно Waterfall частично мы не можем это сделать, и выйдет это минимум в два раза дороже.
4) Комплексная среда (состоящая из множества взаимосвязанных частей) характерна тем, что в начале проекта ситуация неопределенная. И прогнозировать сразу финал – оценку по стоимости, времени и ресурсам, очень сложно, а иногда и невозможно. Можно обладать примерным видением проекта по вехам или по дорожной карте, но выдать точную оценку, когда проект будет завершен, на начальном этапе не получится.
Обычно в такой ситуации заказчик формирует желаемый результат на старте проекта, а весь функционал и процессы детализируются уже в проектном боевом режиме. Так получается потому, что в подобной среде разрабатываются новые уникальные продукты, не имеющие аналогов и предшественников. Команде не на что опереться, так как схожего опыта ни у кого нет.
Наиболее подходящими фреймворками в этой среде станут Scrum и его масштабируемые версии (такие как SAFe), XP (экстремальное программирование), Lean (бережливое производство), Crystal и другие. Ознакомиться с ярким примером применения одной из таких «гибких» методологий можно в книге Джеффа Сазерленда «Scrum. Революционный метод управления проектами».
Куда же отнести Канбан-метод? Если мы обратимся к книге Дэвида Андерсона «Kanban. Альтернативный путь в Agile», ответ станет понятен. Данный подход предназначен для оптимизации уже работающих процессов с целью повышения скорости доставки фичей и быстрого реагирования на те или иные изменения. Поэтому Kanban подходит ко всем средам разработки (простая упорядоченная, сложная упорядоченная, комплексная), кроме хаотичной. Несмотря на то, что Kanban не относится группе Agile, некоторые источники в интернете, курсы и даже работодатели называют Kanban-метод методологией.
Какая методология больше подходит для российской IT реальности?
Обратимся к психологии и межкультурной коммуникации. Не секрет, что в США IT‑технологии развиваются быстрее, чем в России. Большинство существующих фреймворков придумали именно американцы и разрабатывали они их, учитывая свой менталитет. В чем же тогда главные отличия российского менталитета от американского, и какая методология не будет хорошо работать в России?
Для американцев характерна скорее индивидуальная работа, нежели коллективная. Еще в школе им закладывают установку на самостоятельность. Каждый ребенок мечтает стать самым популярным в школе — это гарантирует уважение со стороны сверстников и родителей. Социум заставляет их разносторонне проявлять себя, привлекать внимание и повышать свою узнаваемость. В американских школах частенько бывают дни самоуправления школьников, каждый семестр проходят дебаты, где дети учатся публично отстаивать свою точку зрения и оттачивают навыки самопрезентации.
Взрослые американцы также стремятся показать свою индивидуальную работу и поэтому им комфортнее отстраниться в рабочее время от окружающих. К тому же, так проще погрузиться в задачи, не переключаясь с одной на другую. Рабочее пространство в большинстве фирм организовано по типу «Open space», однако это индивидуальные рабочие места с настольными перегородками, в отличие от российских офисов, где пространство максимально открыто, что способствует общению и командной работе. Россиянам привычнее выполнять работу коллективно, и лучше дружно несколькими кабинетами, поэтому и рабочее пространство в офисе более открытое.
Для американцев характернее разработать что‑то с нуля. Процесс доработку уже имеющегося решения они считают не особо эффективным, ведь еще со школы приветствуется генерация новых уникальных идей. Под такие жизненные установки и условия работы отлично подходит Scrum.
Для наших же сограждан характерно взять что‑то готовое, а затем дорабатывать, совершенствовать, подстраивать под себя. Для такого формата работы больше подходят Waterfall, PMI, Kanban‑метод, а также разные гибридные agile методологии. Например, наша компания «БАРС Груп» использует PMI + SAFe (так как работает на госсектор, а численность сотрудников в компании и количество департаментов настолько большое, что уместна гибкая методология управления). В России также популярны p3express и Less.
В российской действительности в чистом виде Scrum, на мой взгляд, не используют не только из‑за разности в менталитетах, но и разных условий в разработке. Хотя многие отечественные компании называют российский адаптированный Scrum тем же самым скрамом, который описан в другой книге Джеффа Сазерленда и Кена Швабера «Руководство по Скраму» (или «The Scrum Guide»). Хотелось бы процитировать заключение из русскоязычной версии этого источника от 2017 года: «Детальное описание фреймворка представлено в рамках этого Руководства. Роли, артефакты, правила и события Скрама не подлежат изменению. Хотя использование отдельных элементов данного фреймворка допустимо, но полученный результат не может называться Скрамом. Скрам существует только в качестве цельного фреймворка, но он может вмещать в себя другие техники, методологии и практики«. А в книге Ивана Селиховкина „Черная книга скрам“ описан пример, когда одна российская IT‑компания решила внедрить у себя скрам в чистом виде, и это в итоге не увенчалось успехом.
А вы как считаете, можно ли адаптировать устоявшиеся методологии/frameworks индивидуально под свою компанию, и называть все тем же именем, или это все же будет какая‑то новая, эксклюзивная методология, которую стоит назвать иначе? Не спадет ли «классическая» шапка фреймоворка с современной головы без «подгонки» и адаптации? Напишите в комментариях, что думаете по этому поводу!
