Менеджеры проектов не нужны
Обратите внимание, что в названии нет знака вопроса. Я не хочу рассуждать, нужны менеджеры проектов в современной разработке программного обеспечения или нет. Практика показывает, что нет. Я только пытаюсь разобраться, почему так сложилось.
Работая более 20 лет в IT-индустрии, каждую новую разработку я начинал строить с проектного офиса. Более того, несколько раз мне приходилось объяснять руководству, зачем нанимать пиэмов. При наличии руководителей отделов, не так просто объяснить людям, которые не принимают непосредственного участия в разработке софта, что же именно будут делать менеджеры проектов. Приходилось преодолевать заметное сопротивление.
Но для меня было аксиомой, что проектный офис и менеджеры проектов являются основой успеха. И скажи мне кто-нибудь лет пять назад, что менеджеры проектов не нужны, я бы спорил с ним до конца.
Примечание редактора: этот текст — результат доклада Дмитрия Круглова из компании Arrival на митапе «Пиэмная».
Или всё-таки нужны
Начнем с того, что попробуем защитить эту профессию. Хотя бы потому, что результаты на последних местах работы достигнуты, в том числе, благодаря успешно построенным проектным офисам.
Управление проектами — не прерогатива IT. Это наука, которой больше 50 лет. Наука, у которой есть своя священная книга. Конечно, PMBoK не единственная в своем роде, есть PRINCE и, наверняка, ещё несколько книг, более-менее претендующих на лавры. Но PMBоK является основой международных стандартов и это говорит о её высоком уровне признания. Так что будем отталкиваться от неё.
Давайте сыграем в игру: если вы работаете менеджером проекта, попробуйте, не заглядывая вперед, вспомнить ваши основные области деятельности с точки зрения международного стандарта и института, которому более 50 лет?
Например, управлять проектными требованиями. Или управлять ожиданиями. Может быть вы помните про управление сроками. Наверняка коллеги, представляющие бизнес, регулярно спрашивают, когда именно будет готова та или иная задача. Может быть вы вспомните про управление стейкхолдерами, что встречается гораздо реже. Ещё что? Управление коммуникациями. Последнее встречается так же редко, как стейкхолдеры. А ведь это важная и непростая задача в наше время, когда все участники проекта предпочитают делиться важной информацией в Telegram, вместо требуемых по уставу проекта электронных писем. Как тут управлять коммуникациями, если вас просто не зовут в чат, в котором обсуждают, например, качество вашей работы?
Сравните то, что удалось вспомнить, с перечнем из PMBoK:
Все пункты очень вменяемые. Кажется, эту деятельность действительно нужно делать каждому менеджеру проектов. Что-то из этого может быть менее очевидным, например проектная интеграция. Но если вам доводилось силами нескольких команд делать по-настоящему крупную фичу, которую нужно перед запуском собрать воедино, то вы понимаете, о чем этот пункт. Кстати, задача разработки одной функциональности в нескольких командах параллельно до сих пор системно не решена.
Диаграмма Гантта
Если есть деятельность, должен быть её результат. Мое личное мнение состоит в том, что работа сделана при наличии соответствующего артефакта. Для программиста это работающий программный код. Для специалиста по тестированию — разработанные или выполненные сценарии тестирования, заведенные в системе ошибки или созданные автотесты. Для дизайнера — графические макеты.
Что является артефактом работы менеджера проектов? Из всех возможных артефактов, включая сообщения в Telegram: «Добавьте меня, наконец-то, в ваш чат, я не могу без этого управлять проектом!», — в первую очередь я бы отметил диаграмму Гантта. Это прекрасный инструмент, который может ответить на множество вопросов про проект и помогает визуализировать большинство областей деятельности менеджера проектов. Ведь хорошая диаграмма Гантта содержит в себе сроки, ресурсы, стоимость, зависимости. Туда можно добавить в качестве задач требования по коммуникациям. Можно добавить даже управление стейкхолдерами и их ожиданиями с помощью вех и описания ожидаемого результата. Получается универсальный инструмент на все случаи жизни.
Большая часть задач этих областей решается через управление одной сущностью — диаграммой Гантта.
Его популярность и универсальность подтверждается количеством инструментов и сервисов, позволяющих вам создавать ваши диаграммы. Попробуйте в поиске набрать «Гантт онлайн» и посмотрите, какой длины список ссылок на любой вкус и цвет вы получите.
Что же получается: у нас есть профессия, есть деятельность и есть хороший артефакт, как ее результат. Так в чем подвох?
Всё дело в нюансах. Вот, например, с Ганттом не все так хорошо.
Во-первых, диаграммы больших проектов рано или поздно становятся нечитаемыми. У меня был опыт работы с проектом масштаба «больше года» в Microsoft Project. Чтобы распечатать его план, нужно было склеивать шесть листов A4. На одном листе текст получался слишком мелким.
Во-вторых, диаграммы больших проектов очень трудоемки в сопровождении. Внесение изменений часто может сделать только сам автор, иначе план разваливается из-за сложной системы зависимостей.
В-третьих, надо признать, что многие диаграммы никто, кроме самого менеджера проекта, не читает. Получается, что этот артефакт произведен PM-ом и ему же одному нужен и понятен.
В современной разработке программного обеспечения от Гантта, в большинстве своем, отказались. Мы перестали использовать в создании продукта этот артефакт, так нужен ли нам его автор?
Если попробовать погуглить тему полезности менеджеров проектов в IT, станет понятно, что эта дискуссия ведется давно. Она успела стать очередным холиваром, как, например, противостояние любителей iOS и Android, Windows или OS X. Только цитаты в результатах поиска ещё более эмоциональны: «Нужны ли нам PM?», «Почему мы решили избавиться от PMов», «Является ли работа PM-а бесполезной?».
Я не берусь утверждать, что чаша весов в глобальном споре склоняется в пользу отказа от PM, но, как минимум, количество сторонников этой точки зрения существенно.
Гибкие методологии
Начиная работать в компании, где у меня есть задача построить в очередной раз команду разработки с нуля, я осознал, что на ближайшие полгода-год у меня нет задач для PM-а. Сначала я его добавил в оргструктуру по привычке. А потом своей же рукой и вычеркнул. Вычеркнул интуитивно, но задался вопросом: «Почему так получилось?».
Мое исследование причин привело к пониманию, что IT обладает рядом уникальных качеств, которые позволили внедрить гибкие методологии. Существует классическое сравнение: строительство дома и разработка программного обеспечения. Это в чём-то похожие дисциплины, недаром в обеих есть роль архитектора. И там, и там существует набор функциональных и нефункциональных требований, существует инфраструктура, внутренние коммуникации, сборка, доставка и интеграция.
Но строительство ведётся в реальном мире и имеет очень долгий и дорогой цикл производства до первого теста, до получения первой обратной связи, до получения результата. Цена ошибки в строительстве очень высока.
В IT продукт цифровой. И производственный цикл может быть очень коротким. За два десятка лет мы смогли создать инструменты и технологии, которые привели к появлению гибких методологий разработки. Тут я готов спорить, что причинно-следственная связь именно такая: возможность быстро экспериментировать и получать работающий результат привела к тому, что возникли методологии, как именно это делать. Конечно, это короткая положительная обратная связь, и следом продолжили развиваться инструменты. А потом опять доработали методологии. И так далее по спирали мы несемся ко все более и более короткому time to market.
Роли
Гибкие методологии стали стандартом де-факто и привнесли в процесс разработки программного обеспечения новые роли. И эти новые роли начали отнимать деятельность и артефакты у менеджеров проектов.
Product owner (PO)
Существуют проекты, у которых есть несколько заказчиков, несколько владельцев и несколько людей, принимающих решения. PM для них тот человек, который добивается компромисса. Он всех их сводит, помогает расставить приоритеты, примиряет. Кому-то говорит: «Нет», чьи-то интересы лоббирует. Но бизнес понимает, что в непрерывных поисках компромиссов ресурсы тратятся неэффективно. Больше всего расходуется самый ценный ресурс — время.
Поэтому в гибких методологиях поступают просто — говорят одному человеку от бизнеса что-то в духе: «Ты крайний за деньги, за трафик и за конверсию. И нам, если честно, все равно, что и с каким приоритетом ты делаешь в продукте. Главное, чтобы к концу года конверсия выросла с 1% до 1,1%, а то проект убыточен». И PO получает право единолично принимать решения, сам определяет приоритет, создает соответствующие артефакты (планы, roadmap-ы, требования) и забирает кусок работы у PM-а.
Техлид (TL)
Лет десять назад в IT начали менять устоявшуюся архитектуру.
До этих перемен технологии и инструменты в основном создавались для «слоёной архитектуры» — слой баз данных, слой бизнес-процессов, слой агрегации, клиентский слой. Но как только этот подход стал классическим, как только компании обзавелись соответствующими слоям отделами, пришли гибкие методологии. И все дружно решили, что «слоеные пироги» — это плохо и нужно формировать кросс-функциональные команды.
Не сказать, чтобы это было новой идеей. Как называют универсальных разработчиков? Full stack. Один из разработчиков старше 30 лет на собеседовании сказал: «Я был full stack разработчиком во времена, когда термина full stack еще не существовало». Когда-то мы все были фулстеками, потому что нужно было делать вообще всё, включая администрирование баз данных и настройку компьютера директора.
Кросс-функциональные команды привнесли новую роль: техлид. Техлид не только потеснил руководителей отделов, но и забрал на себя техническую часть работы PM-а. В первую очередь, всё, что связано с оценкой сложности и сроков. К моменту перехода на гибкие методологии многие смирились с тем, что команда разработки должна сама оценивать сроки своей работы.
Системный аналитик (SA)
Системный аналитик — не новая роль, и во многих Agile методологиях её нет. Не берусь утверждать наверняка, но возможно в явном виде она есть в SAFE. Но SAFE, в целом, пограничная методология. Тем не менее, эта роль крайне полезна и интересна. Она, как смазка в сложном механизме, позволяет ему работать тихо и гладко. Системный аналитик это частично владелец продукта, частично архитектор. Он уточняет и детализирует требования бизнеса до уровня конкретных фич. Лучшие из системных аналитиков способны продвигать свои идеи и видение в обе стороны, используя комбинацию технической грамотности и soft skills. Там, где работают системные аналитики, менеджер проекта лишен деятельности по управлению требованиями.
Scrum Master (SM)
Scrum Master сильно потеснил роль менеджера проекта. Жаль, что сейчас сами SM стали кандидатами на вымирание.
Серьезно, рано или поздно Scrum Master будет преподавать в школах. Будут уроки про Agile, где Scrum Master будет рассказывать 12-летним школьникам, как работают гибкие методологии и какие существуют практики. Уже сейчас опыт работы по Agile стал повсеместным явлением среди разработчиков. На интервью 19 из 20 человек работают по двухнедельным итерациям, а разговор о процессах превращается в перечисление их параметров:
— В чем оценка?
— Story Points.
— Какой Velocity?
— 68.
— А как планируете проекты?
— В «маечных» оценках S, M, L.
Это очень быстрый разговор. С нынешними техлидами все параметры процесса можно обсудить за час. После этого они идут работать с командой и им для этого не нужен Scrum Master. Индустрия эту роль уже почти переварила и движется дальше.
Конечно, так не везде. Наверняка есть много компаний, которые нужно дотягивать до рыночных стандартов и это не быстрый процесс. В России и через 10 лет можно будет найти работу Scrum Master-ом в каком-нибудь «Леноблхозпромлесповал», когда организация решит своих трех программистов перевести на Agile.
За время своей популярности Scrum Master-а успели полностью забрать у PM-а все вопросы внутри проектной команды. Забрали не на себя, а на членов команды, фасилитируя их вовлечение в проектную работу. Это, кстати, заметно подняло уровень зрелости IT в глазах бизнеса.
Или всё-таки не нужны
Что же остаётся? Я взял на себя смелость выделить те задачи, которые при работе по гибким методологиям решаются другими ролями.
Что же осталось у менеджеров проектов после этого? Остались коммуникации, интеграция и закупки. Кажется, не так много, чтобы держать на этой роли выделенного человека? Самое время сказать, что PM-ы не нужны. Но нет.
Всё-таки нужны
Есть категории IT-проектов, в которых без выделенного менеджера провал практически гарантирован.
Проекты в реальном мире
Те, кто работают с мобильной разработкой, знают, что тут со скоростью внесения изменений и ценой ошибки не всё так гладко. Если в мобильной разработке пропустили ошибку и заметили её не сразу, то сделать обновление на всю аудиторию будет сложно. Часть пользователей не обновят свои приложения и ошибка останется. Из этой проблемы, например, выросли подходы с удаленным управлением функциональностью мобильных приложений.
А ведь это сотая доля боли PM-ов, которые управляют разработкой программного обеспечения, например, для управления сортировочным конвейером на складе масштабом в 5 миллионов единиц товара. В таких проектах десятки зависимостей от поставщиков оборудования, итерации измеряются месяцами, а цена ошибки возрастает на порядок.
Проекты, связанные с оборудованием, возвращают нас из цифровых миров в нашу реальность, в которой до сих пор актуально классическое управление по PMBoK-у.
Зонтичные проекты
На зонтичных проектах гибкие методологии буксуют. Такие проекты большие и сложные. Сложность означает явные и неявные зависимости, и на определенном масштабе разработка без выделенного менеджера проекта становится крайне неэффективной. В таких проектах у PM-а основными задачами являются проектная интеграция, управление зависимостями и сроками.
Проекты с большой ценой ошибки
Всегда останутся индустрии, в которых ошибки нужно исключить по максимуму — медицина, авиация, космическая индустрия, военная сфера. В этих областях, когда случается ошибка, либо гибнут люди, либо теряются очень большие деньги. Примеры легко найти в интернете. Начните с истории про европейскую ракету «Ариан-5».
В таких областях PM останутся востребованы, но к ним будут предъявляться очень высокие требования в части компетенций и опыта. И чем меньше будет доля таких проектов, тем жестче будет отбор кандидатов.
Проекты без части ролей
Жизнь — суровая штука, и взять по выделенному человеку на каждую из ролей не всегда возможно. Пока мир не совершенен, останутся PM-ы, которые выполняют работу Product Owner-а. Или PM-ы, которые де-факто работают техлидами. Такие совмещения часто свойственны стартапам.
Если продлить во времени те тенденции, которые имеют место в индустрии сейчас, нас ждет будущее, в котором роль PM-а в чистом виде останется актуальной для небольшого числа проектов по разработке программного обеспечения, работу которых мы пока не знаем как автоматизировать или распределить между другими членами команды.
Текст подготовили:
Автор — Дмитрий Круглов
Редакторы — Евгений Шкляр, Денис Вонсаровский
Мнение автора по некоторым вопросам может не совпадать со мнением редакции блога и компании Яндекс.Деньги.
