Обратите внимание, что в названии нет знака вопроса. Я не хочу рассуждать, нужны менеджеры проектов в современной разработке программного обеспечения или нет. Практика показывает, что нет. Я только пытаюсь разобраться, почему так сложилось.
Работая более 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-а в чистом виде останется актуальной для небольшого числа проектов по разработке программного обеспечения, работу которых мы пока не знаем как автоматизировать или распределить между другими членами команды.
Текст подготовили:
Автор — Дмитрий Круглов
Редакторы — Евгений Шкляр, Денис Вонсаровский
Мнение автора по некоторым вопросам может не совпадать с мнением редакции блога и компании Яндекс.Деньги.
Комментарии (60)
dididididi
05.04.2019 14:10+8Автор: Свитер теперь не нужен! У нас есть худи, лонгслив, толстовка и свитшот и кардиган.
Программист: Вот этот почище и без дыры дайте.
Greesha
05.04.2019 14:50+1Главная проблема диаграммы Гантта не в том, что она становится сложной и трудносопровождаемой, а в том, что она создаёт видимость чёткого плана там, где его нет, а часто и не может быть.
www.greesha.ru/livejournal/символ-несбывшихся-надежд
Dimmentio Автор
05.04.2019 15:33Теоретически, исследовательские, неточные, высокорисковые задачи можно в Гантте расписать и потом регулярно актуализировать. Практически, трубоемкость этого сильно превышает пользу. Поэтому никто так не делает.
rpiontik
05.04.2019 22:08Любой инструмент менеджера должен быть живым. Если команда не опирается на план — его сделал плохой менеджер проекта, т.к. план оторван от жизни и бесполезен, либо инструменты его использования командой ущербны. Менеджер обязан знать инструменты управления, которые создают его команде комфортную интеграцию каждого в процесс. И каждый артефакт должен быть полезен, а не формален.
В этом случае не будет такого, когда план, хоть на 10 лет вперед будет несостоятельным.
Да, конечно, когда горизонт планирования велик, вероятность изменений тоже велика. Но план это то, что мы планируем СЕГОДНЯ на будущее. Это не контракт подписанный "кровью". План живет и развивается вместе с проектом. Каждый день. И его развитие задача очень и очень занимательная. И это реально полезная и нужная работа всем и каждому в команде.Dimmentio Автор
06.04.2019 10:47В статья я рассуждал о диаграмме Гантта. Ее главная сила с моей, сугубо личной, точки зрения состоит в управлении зависимостями. А в современной разрботке зависимостям фактически объявлена война.
В гибких методологиях план работ существует в другом виде. Чаще всего я встречал его как сочетание roadmap-а фич на горизнте плюс-минус года, набора квартальных целей и целей и составов спринтов.
max1gu
08.04.2019 11:34По моему проблема диаграмма имеет пробелмы не только в этом.
Основная проблема в том, что это инструмент маркетинга — когда проект создается, утвердается и продается диаграмма Ганта выглядит довольно презентабельно и умнО для среднего менеджера/собственника/дилетанта (если она влазит на лист А3)
А вот когда проект уже идет, она бесполезна. На не видно текущего состояния проекта. Да, на каждой активности видно процент выполнения, но не видно реальных сроков: 100% долно быль быть в январе, а выполнено 50% но в марте. Также не видно реально задействованые ресурсы. Не видно перепланировок, дробления и переноса задач.
Т.е. после начала проекта этот документ становится мертвым.mayorovp
08.04.2019 16:46Это всё как раз — наименьшая из проблем. Достаточно регулярно обновлять диаграмму, чтобы она не была «мёртвой».
DrunkBear
05.04.2019 15:48Да-да, кросс-функциональные команды.
Только почему-то это сводится к «Так. У нас будут кросс-функциональные команды, поэтому тестеры теперь будут оставаться после работы 2 часа и учиться стеку Java у разработки. И аналитике заодно. А Java-разработчики быстро пройдут курс по С++ у коллег, потому что backend на С++. И да, всё это за свой счёт, кто против — бланк на увольнение по собственному есть в сети.»Dimmentio Автор
05.04.2019 15:59Это выглядит странно. Под кросс-функуиональными командами я имел в виду команды, где каждый специалист профессионал в своей области, но все вместе делают один продукт. И сравнивал с классическим подходом, когда есть отдел Java с руководителем, отдел FE с руководителем. И у QA есть свой руководитель. И все эти руководители распределяют задачи между сотрудинками каждый по своей системе. Это не архаика, вот прямо сейчас, в 2019ом у моего друга, который в роли PO работает, такая структура пытается проекты делать.
DrunkBear
05.04.2019 16:23Видел классический подход с отдельными командами специалистов по сетям, по linux, по win, по ELK, по hadoop, по scala, по прикладному софту, у которых постоянно не хватает привелегий что-то сделать и которые ставят друг другу задачи.
На мой взгляд, это ни капли не лучше, чем команда, где всех и каждого тянут в fullstack.Dimmentio Автор
05.04.2019 16:31На мой взгляд, это ни капли не лучше, чем команда, где всех и каждого тянут в fullstack.
Я прошу прощения, если ввел в заблуждение своим отступлением в сторону в тексте. Я считаю, что кроссфункциональная команда — это группа профильных специалистов, решающих общую задачу. Они не должны быть fullstack разработчиками. Наоборот, чем более профессиональны FE, BE и QA, тем сильнее команда и быстрее делается работа. Про fullstack я вспомнил просто как пример того, что все идеи ходят по кругу.
T13Nemo
05.04.2019 20:06-1Все бы ничего, но ваше понимание не вписывается, например, в концепт T-Shaped People и Swarming, которые в том же Scrum явщяются одной из основ фреймворка.
Что же касается задач, которые у вас остались черными на картинке, то их, в том чиле, выполняет Scrum Master.
Dimmentio Автор
05.04.2019 20:16Я тут привел личное мнение про состав кросс-функциональных команд. Что, кстати, было до недавних пор одним из главных расхождений во мнении с руководителем разработки на моей прошлой работе. Я не сторонник классического Scrum и очень ценю именно глубокую профессиональную экспертизу.
VolCh
07.04.2019 15:44Определение кроссфункциональной команды на практике сильно зависит от типа и масштабов организации. Субъективно прежде всего от бас-фактора. Если у вас в команде один бэкендер и на замену ему быстро никого выдернуть нельзя, то хоть кто то хоть как-то должен быть способен его подменить. Иначе у вас по сути никакой команды не будет случись что с ним. В большой ИТ-компании с "пулом ресурсов" можно набрать команду из узких специалистов, в средней не ИТ-компании с отделом разработки из 7 человек, для каждого элемента стэка и(или) флоу крайне желательно иметь хотя бы дублирование каждой технической роли, но даже ролей больше 7 легко может оказаться. И тут без многостагочников никуда.
eugene_bx
05.04.2019 16:43DevOps — пусть программист запрограммирует поддержку инфраструктуры, тогда без админов обойдёмся.
QA — пусть программист запрограммирует все тесты, тогда без тестеров обойдёмся.
Scrum — пусть программисты сами себя и проекты поменеджат, без менеджеров обойдёмся.
Что на подходе? CleanOps — пусть сами офисы убирают, уборщики не нужны.
Экономика, должна быть экономной.Dimmentio Автор
05.04.2019 16:54В случае с DevOps, QA и PM действительно так происходит. Не везде. И это, пока что, не стало трендом. Но примеры есть. В 2015ом крупная европейская eComm компания с штатом в 250+ разработчиков одномоментно расформировала отделы системных администраторов и «обрадовала» команды разработки, что они теперь сами за прод отвечают. Шок, это очень мягкое определение того, что там было. Но ничего, справились. Работают.
Я бы дальше пошел. Сейчас пора на полном серьезе задуматься, а что мы будем делать в эпоху автоматизации работы. Вот на Medium была интересная заметка: «The Coders Programming Themselves Out of a Job». Там обсуждали, в частности, разумно ли говорить работодателю, что ты автоматизировал свою работу. Часть тех, кто на это отважился, были уволены с аргументацией, что не за что тебе теперь платить зарплату.
Это я к тому, что история с распределением работы PM-а внутри команды еще не самое сложная. Сложнее, когда работу забирает автоматизация.eugene_bx
05.04.2019 17:02У нас тоже так, одним прекрасным утром отделу из 80-ти тестеров сказали — «имели мы вас в виду» и выходное пособие.
Я не против автоматизации — всеми руками за. Когда это произойдёт, надеюсь что наконец то в обществе настанут благорастворения воздухов и изобилия плодов земных. Как бы это не называли — коммунизмом, раем, сингулярностью или ещё как.
Но пока только немножко другая картина вырисовывается. И райские коммунизмы только у отдельно взятых индивидов (не то чтобы я против, лично тоже довольно близко к этому), но картина интересная. Думаю ожидает нас весёлое десятилетие.grinCo
05.04.2019 22:43Если автоматизацией занимались эти уволенные тестеры, то они легко найдут себе новую работу, т.к. у них уже есть опыт и результат. Если не они — то им нужно просто изучать автоматизацию.
DrunkBear
05.04.2019 17:15+1Простите, чем больше работаю с автоматизацией, тем меньше верю в победу автоматизации.
Или сразу на уровень «Автоматические танкеры будут ходить с экипажем 1 человек и 1 собака. У человека будет задача кормить собаку, а у собаки — кусать человека, если он попробует нажать хоть 1 кнопочку», или проблемы из-за людей.
На днях перед запуском Очень Автоматизированного Скрипта на ПАК известного вендора посмотрел в конфиг, мало ли что там — и действительно, в конфиге данные 2 кластеров вместо одного. Скрипт должен был накатывать фабричный образ ОС со стиранием всех данных, было бы очень эпично потерять data lake с 5 годами данных.
Или потом другой скрипт автоматизации (от вендора этого ПАК) роли на кластерах с ноды на ноду автоматически перенёс без вопросов — половина софта слегла, потому что параметры сервисов уехали пёс пойми куда…Dimmentio Автор
05.04.2019 20:21-2Я бы сказал, что эти примеры ошибок подтверждают сложность этой задачи и ее неготовность к массовому применению. Но и полет на сверхзвуковых скоростях или в космос когда-то казался невозможно сложной задачей. Сейчас бизнес видит в автоматизации способ сокращения расходов и на ее внедрение тратятся значительные инвестиции. А где есть финансирование, там будет и результат.
DrunkBear
05.04.2019 16:56CleanOps — это ж удалёнка! Сами готовят, сами убирают, могут работать на 2 часа дольше, потому что транспорт от кровати в кресло не нужен…
Вот появятся надёжные трекинговые инструменты — точно всех по домам разгонят, чтоб аренду не платить.eugene_bx
05.04.2019 17:05Отсидка штанов в офисе никому не мешала симулировать работу. Хотя конечно для слабых духом (типа меня) удалёнка будет ударом.
Vegatron
06.04.2019 10:48Есть кейс офиса, где убрали мусорные корзины, вообще, вроде как по требованию лэндлорда. Не РФ, и контора весьма крупная и серьезная :) В итоге каждая тима сама себе завела личные мусорки и лично их опустошает :)
viru0
05.04.2019 18:16Мне кажется все гораздо проще, это не роли исчезают — это просто для успешного выполнения своей роли теперь нужно знать код. И это движение в правильном направлении. Работаю в большой успешной американской компании, где очень хорошо работает 'научный подход'. Т.е. все должно подтверждаться экспериментом. Тут как ни крути, а знать SQL(или что-то подобное) и чуть чуть Python или Java просто необходимо. (По другому просто не сможешь показать результаты своей работы)
А то что появилось больше программистов которые неплохи в менеджменте или менеджеров которые понимают в коде — этож хорошо, меньше косяков из-за не понимания мира друг друга, выше качество продуктов, быстрее инновации.Dimmentio Автор
05.04.2019 20:26Согласен полностью. Лучшие из Product Owner-ов полным ходом осваивают SQL для работы с первоисточниками данных на репликах и временами что-то пишут в команде. И развитие программистов в менеджменте востребовано и происходит все активнее. Оба процесса очень правильные.
virtualsys
05.04.2019 19:45HH с вами согласен, что не нужны. По крайней мере слово «менеджер». В российских реалиях тяжелых извращений понятие «менеджер проектов» не равно понятию «руководитель, управляющий и т.п. проекта». Те гении, что менеджерами зовут мелких продавцов, под менеджерами проектов понимают зачастую помощника начальника или руководителя, уровня администратора. Нормальное понимание этого термина даже не в половине существующих вакансий.
Убить надо того, кто в самом начале продавцов назвал менеджерами.
rpiontik
05.04.2019 21:30+3Знаете какой вопрос меня терзает, когда я читаю очередную такую статью? Только не обижайтесь. Вопрос такой — чо вас так колбасит? Стоит очередному менеджеру дойти до кризиса самооценки, как он клепает очередную статью на хабре. Для кого? Кому? Зачем? Вы проверьте, их тут каждую нелелю выпускают.
Ответ на все вопросы — CMMI. Все ваши манипуляции с ролями описанные в статье, не позволят достичь 5го уровня зрелости компании.
Выделю из прочего один важнейший аспект — конфликт интересов менеджера и команды проекта. Менеджер не функциональный руководитель команды, а административный. Он дает оценку эффективности работы команды, но не мотивирует ее, и не развивает. Он использует выделенные ресурсы. Контролирует рамки проекта, бюджет, непозволяя ресурсам уйти в пике по своим профессиональным направлениям.
Но! Менеджер проект это артефакт определенного уровня зрелости компании. И на начальных уровнях он действительно не нужен.Dimmentio Автор
06.04.2019 10:56Я совершенно не обижаюсь на любые комментарии. Тем более, адекватные. Я описал причины, по которым выступил с этой темой. Вкратце: я большой сторонник проектного офиса и хорошо понимаю его ценность. Но вот я сменил работу и попал в другую среду, с другими целями, задачами и приоритетами. И теперь готов не теоретически, а практически обсуждать вторую сторону баррикад.
По поводу CMMI вы правы. И про контроль проектов с бюджетом и сроками вы правы. Посмотрите, я в конце цепочки рассуждения оставил четыре категории проектов, в которых PM остается актуальной ролью.
Не соглашусь только с жесткой связкой: зрелость компании и необходимость PM-а. Подумайте, Spotify или Valve — зрелые компании. Но работают без PM-ов. Я думаю, это больше вопрос требований к продукту и процессу, чем зрелость компании.
Scf
05.04.2019 23:08+1Так кто же занимается планированием? Роадмап — это не план, это хотелки. План — это большой объем достаточно обезьяньей работы, особенно актуализация плана. Но как без плана называть трудоемкость проекта и сроки? И актуализировать сроки в процессе разработки?
Dimmentio Автор
06.04.2019 10:59Никто, если от конкретной команды в ее работе не требуется прогноз дальше чем на один месяц. Иногда есть только ориентир или, как говоряд на западе, полярная звезда. И путь к ней корректируется каждый месяц.
Scf
06.04.2019 12:10Для продуктовой команды — наверное, да. В бюджет закладывается годовой ФОТ команды, а дальше она работает, как умеет. Для проектной разработки так не получится.
funca
06.04.2019 00:17Поциеты против врачей. Вот если бы Яндекс деньги заявили что не нужны деньги или яндекс, это была бы новость. Не путайте лозунги для повышения мотивации и вовлеченности инженеров, коими наполнен скрам, и то, как на самом деле работают эти механики. Менеджер больше всего нужен когда в проекте что-то идёт не так и возникает необходимость решать небанальные вопросы.
Dimmentio Автор
06.04.2019 11:03Вот тут я не соглашусь. Если команде, когда что-то пошло не так, нужен менеджер, это незрелая команда. Вот у меня в командах разработки на 7-10 человек есть TL и три старших специалиста (BE, FE, QA). И они потому TL и старшие, что умеют решать сложные вопросы и не давать спринтам идти не так. Они очень опытные, умные, мотивированные, интересные, веселые и позитивные ребята. Им точно не нужен PM. Ему просто нечего будет делать днями напролет.
funca
07.04.2019 21:54Бывают ситуации когда команда может работать сама по себе. Процессы в большей степени отлажены, административные вопросы закрываются другими подразделениями в компании. Но в целом задачи управления это отдельный навык. Специализация рулит.
in_heb
06.04.2019 00:30+1Это всё просто переименовывание ролей и перераспределение обязаннсостей. Есть множество функций, есть множество людей, обладающие различными скилл-сетами и люди просто делят функции между собой. «overhead»-люди (PM,SA,SM), делающие грязную работу, которую не хотят или не могут делать разработчики, придумывают себе новые названия, перераспределяют эту грязную работу между собой, но суть не меняется. если ты умеешь организовывать работу людей, то какая разница как ты называешься — PM или SM?
Dimmentio Автор
06.04.2019 11:07Согласен с очень базовой вещью: если работу нужно сделать, кто-то ее должен сделать. Ее можно перекладывать между ролями, но исчезнуть она не может, если только не сменятся условия (изменение методологии, автоматизация, отсутствие требований и т.д.).
Но вот что интересно: разработчики растут. Тут уже был комментарий про то, что зрелость IT специалистов на рынке подросла. Сейчас есть возможность собрать команды, в которых уровень ответственности и осознанности TL и старших разработчиков будет таким, при котором им в рамках гибкой методологии не нужен будет PM.
AlexunKo
06.04.2019 02:08+1Менеджеры проектов может и нет, а менеджеры людей пригодятся. Этих оставим.
Dimmentio Автор
06.04.2019 11:10Согласен, но это тема на отдельную дискуссию. Про то, как за последние 5-7 лет в IT начали меняться требования к руководителям людей. Это очень интересный процесс. И у меня сейчас на работе очень наглядная ситуация с двуми группы специалистов: с хорошим управлением людьми и без него. Разница видна невооруженным глазом.
meranged
06.04.2019 09:21+2Если под менеджером проекта понимать того единственного человека, который отвечает за успех проекта перед руководством или акционерами, то такая роль никогда не исчезнет. И не важно, какая методология используется, где рисуются тикеты или диаграммы Ганта и какой размер у проекта. Как только ответственность становится размытой или коллективной, это первый шаг к провалу.
Dimmentio Автор
06.04.2019 11:11Во-первых я писал, что эту ответственность акционеры и руководители возложили на PO. Фактически, под эту ответственность выделяются средства.
Во-вторых, коллективная ответственность отличаяется от коллективной безответственности. Со вторым провал обеспечен. С первым — обеспечен успех.meranged
06.04.2019 11:22Какая разница, какие погоны висят на человеке? Тимлид он или руководитель отдела — если перед вышестоящим за успех он отвечает, то у него есть роль руководителя проекта. А по поводу коллективной ответственности — предположим, с одним из проектов возникают серьёзные проблемы. Кого ваш руководитель вызывает на ковёр? Весь коллектив выстраивает? И они хором должны пообещать что-то хорошее? ) Ну вот честно, не представляю я такой ситуации. Это всё быстро заканчивается, как только у собственников возникает серьёзный риск потери серьёзных денег.
in_heb
07.04.2019 00:58Дело в том, что теперь понятие успеха размыто. Если взять кастомную разработку для внешнего заказчика, то там с успехом всё это понятно — это пройденные тесты, подписанные акты и полученные деньги.
Если же речь идёт про другую крайность — компании (типа Яндекса), которые сами разрабатывают, сами обслуживают и сами продают свои сервисы, то здесь измерять успех команды разработки почти невозможно когда это уже действующий сервис, приносящий доход/прибыль. Владелец видит, что за год доход(другие показатели) сервиса увеличился на столько, сколько хотелось. Но успех ли это команды разработки? Может быть это удачное стечение обстоятельств, успешные маркетинговые акции или что-то ещё, а разработчики лишь сделали кучу непонятных неудобных фич, из-за которых пользователи раздражены и готовы уйти от сервиса, но пользуются по инерции.
Вот люди и развлекаются с методологиями, перераспределением обязанностей, коллективной безответственностью (я никогда не поверю в коллективную ответственность — это либо банкрот компании, либо поиск козла отпущения). Но ведь кто-то же должен это пробовать? Компания 10-100 человек не может себе позволить так рисковать, Яндекс может.meranged
07.04.2019 13:23+1Конечно, в Яндексе и любой другой большой продуктовой компании должна быть своя специфика по сравнению с заказной разработкой и некоторыми другими видами IT-компаний. Но при этом возникает вопрос — а корректно ли называть проектами то, что они делают? Предположу, что к подавляющему большинству их активностей больше применима процессная терминология и KPIs, а не проектные. Тогда всё становится на свои места.
VolCh
07.04.2019 15:52В больших продуктах часто встречал внутренние проекты, типа новой эпик фичи. Всё по взрослому, бюджеты, сроки, скоупы, риски и т. п.
skhf
06.04.2019 11:11Интересная статья, вообщем тут не с чем не поспоришь. Но… каждый раз читая про очередную систему управления проектами (как панацею от всех управленческих проблем) искреннее удивляюсь тому, что не рассматривается контекст, основа той среды, где зародилась конкретная система управления процессами (ну или проектами).
Почему то никто не пишет о том, что для разных процессов (индустрий, проектов и тд) нужны разные системы управления. В некоторых глобальных процессах scrum, agile и прочие могут быть просто разрушительными, в других случаях использование классических систем не принесет никакого результата.
Я полагаю, что проектный менеджер (как единица) возник потому, что типичная корпоративная среда, в которой появляются проекты:
— является функционально ориентированной, а задачи проекта могут затрагивать две или более областей одновременно,
— является индивидуалистической средой, где личные достижения важнее командных результатов (много вы знаете случаев когда за командный промах увольняли сотрудника (руководитель не в счет, ибо большинство увольнений идут за личные недоработки) ?)
Исходя из необходимости делать проекты (как таковые) был придуман проектный менеджер. Кстати, интересный факт состоит в том, что инновационные проекты в классических системах как правило проваливались, известный успешный проект был у японцев (Canon кажется), которые создали в таком проекте струйный принтер.
При таком подходе проект мог быть успешным только он имел более высокий приоритет чем функциональные обязанности каждого, что по сути перекраивало организационную структуру компании.
Отличие «классических» проектных методов в том, что в «тех» проектах хорошо понимали что хотят получить, но не знали как конкретно, в какие сроки, и за какие деньги. Современные проектные системы (в большинстве своем) построены из скорее непонимания того что в итоге нужно и как скорее это выяснить.
О чем это я? ))) Исходя из конкретного окружения, ситуации и целей можно выбрать наиболее эффективную систему управления процессами (а может и набор из разных систем), а не проектную систему, под которую будут подгоняться процессы.
Dimmentio Автор
06.04.2019 11:16Вы верно уловили суть.
У меня только один комментарий: фактически с приходом гибких методологий мы наблюдаем, как меняется корпоративная культура с функциональной на продуктовую. Что причина, что следствие не берусь рассуждать. Но определенно успех и конкурентное преимущество компаний, которые это уже сделали, ускоряет общее изменение.
Что тут говорить, если самые классические банки начинают создавать свои «лаборатории» или «гаражи», отказываясь в них от иерархических функциональных структур.skhf
06.04.2019 14:29Не в каждом бизнесе может возникнуть «продуктовый» подход, вы правы в том, что изменения идут в эту сторону. Я полагаю, что в жестко централизованной модели бизнеса, когда есть условный отдел который отвечает за продукты и инновации, такой подход себя изжил. Отдельные попытки были успешны и не очень (IBM в момент создания PC). Централизация, как метод управления тихо умирает, а нового пока не придумали, есть только отдельные методики и подходы.
Лучше всего «продуктовый» подход ощущается в работе IT компаний, так как там:
— продукта нет (
— чем он будет не знает никто )
— как его сделать пока непонятно
— как он будет воспринят (и что соответственно придется менять) не предскажет никто.
Функциональную модель на таком не построишь.
Какая степень определенности — такой и проектный метод :). Когда запускали новый вид зубной пасты (какой нибудь Colgate например) неопределенности было крайне мало, было понятно как сделать новый продукт. Сейчас этот метод просто не работает.
r3pab
06.04.2019 11:16Всегда останутся индустрии, в которых ошибки нужно исключить по максимуму — медицина, авиация, космическая индустрия, военная сфера.
Может у них там да. У нас точно нет. В падени ракетоносителя виноват слесарь. В военной сфере вообще неприминимы понятия рыночных отношений. Да и нарисованные план-графики в виде диаграммы Ганта, абсолютно бессмысленны из за отсутствия функциональных зависимостей между последовательными этапами. Часто многое держится на человеческих отношениях. Сразу говориш оператору какие кнопки ненажимать чтоб башку не оторвало. Многое зависит от конкретной команды. Какой Скрам если есть ГОСТ.skhf
06.04.2019 14:44Формулировка «там» и «тут» как ни странно, применяется только «тут». «Там» тоже есть военное производство (ну уж точно не меньше чем у нас, оно в сотни раз больше и сложнее), но «там» не сравнивают с тем что «тут» и не говорят что что-то не будет работать по этой причине.
В военной сфере «тут» не применимы понятия рынка, потому что:
— никто не считает во сколько обходится изделие, либо считают без учета капитальных затрат.
— нет конкуренции (попытки одного министра обороны заставить делать изделия на уровне цен и качеств зарубежных аналогов как вы помните привели к отставке министра)
— как общий мотив — все сравнивается со своим же, отечественным, в то время как вся военная индустрия мира работает на глобальные рынки.
При таких параметрах рыночных отношений не может быть в принципе.
Странно, но ГОСТ не противоречит скраму, ибо ГОСТ не определяет регламент управления бизнес процессами (да и никогда он и не определял).
То что многое держится на человеческих отношениях — это огромный минус системы управления, так как, люди, как ресурс управления:
— могут делать ошибки
— подвержены субъективизму и коррупции
— имеют ограниченный ресурс.
Разумеется, это касается простых операций, ибо «кнопки ненажимать» явно не в сфере ТРИЗ.
Shapeshifter
06.04.2019 12:06Насколько я понимаю, для компании — разработчика ПО, или компании, где часть структуры постоянно занята циклом улучшения ПО, эта деятельность частично становится операционной (PM и ядро команды опытные, накоплена статистика). Но все же если
нечто выглядит как утка, плавает как утка и крякает как уткаодин человек отвечает за проект в-целом, то от делегирования части ответственности он PM'ом быть не перестает. Как называется его должность — дело десятое…
Stepan555
06.04.2019 13:56Точка зрения интересная, но спорная.
1) В моей области деятельности — внедрение систем управления бизнес-процессами — такими как ERP, WMS, SRM, CRM — гибкие методологии не прижились, всё делается по старому сердитому каскадному подходу и без пиэма никуда.
2) В разработке теперь вместо одного PM теперь PO+TL+SM+SA? Забавно :-)Dimmentio Автор
06.04.2019 23:17Безусловно спорная. Более того, через год у меня вполне могут изменится условия и задачи, и я вернусь к старому доброму институту проектного офиса.
Про второй пункт хочется ответить: стало больше ролей, но вы же знаете, что в гибких методологиях один из негласных принципов: two pizzas team. Роли — ролями, а размер команд лучше держать до 10 челоек. А не как в одном крупном изместном банке, где на переписывание софта для call-center собирали отдел в 50 человек.Stepan555
07.04.2019 18:36отдел и проект это параллельные миры. У отдела может быть много проектов, а в проекте могут быть задействованы много отделов.
кроме того, если в проекте более одной скрам-команды, то кто-то должен координировать их и отчитываться перед начальством. Кто бы это мог быть? ;-)
В одном моём проекте было 8 скрам-команд. Но я их толком даже не знал, взаимодействовал с одним руководителем разработки.
lotse8
06.04.2019 18:33Поиски «волшебной таблетки», одним махом решающей все вопросы во всех сферах, продолжаются.
VolCh
07.04.2019 16:27Так и хочется сделать краткий пересказ статьи:
В настоящем скрам ПМ не нужен, но скрам не везде применим :)
Подвох в слове "настоящий" — редкая птица. И как по мне, то основная проблема в отсутствии мотивированных самоорганизующихся кроссфункциональных команд. ПМ как раз нужен, чтобы с ним команда стала такой для внешнего мира. Мотивировать, организовывать, привлекать "смежников" и т. п. Проще говоря, как-то закрывать дыры команды в серии двухнедельных проектов.
Eldhenn
В отсутствие проектного метода разработки менеджер проекта не нужен. Новости!
Dimmentio Автор
Тут я не соглашусь, так как Scrum вполне себе проектный метод. Но не буду спорить. Лучше приведу интересный пример из жизни. Был у меня кандидат в PM-ы из крупнейшего зеленого российского банка. Рассказывал, что там для выполнения проектов создан и внедрен такой детальный и системный проектный фрэймворк, что он на одном из проектов, эксперимента ради, ничего не делал как PM. Только пересылал сообщения от одних людей, до других. И проект завершился успешно и в срок. Вывод, если задаться целью, можно экспертизу PMа запрограммировать в процессе.
VolCh
Скрам можно считать проектным методом для проектов длиной в пару недель :) Упрощенным в чем, что избыточно для таких коротких проектов. С вынесенными "за скобки" вещами повторяющиеся каждый раз.