Comments 60
Программист: Вот этот почище и без дыры дайте.
www.greesha.ru/livejournal/символ-несбывшихся-надежд
Любой инструмент менеджера должен быть живым. Если команда не опирается на план — его сделал плохой менеджер проекта, т.к. план оторван от жизни и бесполезен, либо инструменты его использования командой ущербны. Менеджер обязан знать инструменты управления, которые создают его команде комфортную интеграцию каждого в процесс. И каждый артефакт должен быть полезен, а не формален.
В этом случае не будет такого, когда план, хоть на 10 лет вперед будет несостоятельным.
Да, конечно, когда горизонт планирования велик, вероятность изменений тоже велика. Но план это то, что мы планируем СЕГОДНЯ на будущее. Это не контракт подписанный "кровью". План живет и развивается вместе с проектом. Каждый день. И его развитие задача очень и очень занимательная. И это реально полезная и нужная работа всем и каждому в команде.
В гибких методологиях план работ существует в другом виде. Чаще всего я встречал его как сочетание roadmap-а фич на горизнте плюс-минус года, набора квартальных целей и целей и составов спринтов.
Основная проблема в том, что это инструмент маркетинга — когда проект создается, утвердается и продается диаграмма Ганта выглядит довольно презентабельно и умнО для среднего менеджера/собственника/дилетанта (если она влазит на лист А3)
А вот когда проект уже идет, она бесполезна. На не видно текущего состояния проекта. Да, на каждой активности видно процент выполнения, но не видно реальных сроков: 100% долно быль быть в январе, а выполнено 50% но в марте. Также не видно реально задействованые ресурсы. Не видно перепланировок, дробления и переноса задач.
Т.е. после начала проекта этот документ становится мертвым.
Только почему-то это сводится к «Так. У нас будут кросс-функциональные команды, поэтому тестеры теперь будут оставаться после работы 2 часа и учиться стеку Java у разработки. И аналитике заодно. А Java-разработчики быстро пройдут курс по С++ у коллег, потому что backend на С++. И да, всё это за свой счёт, кто против — бланк на увольнение по собственному есть в сети.»
На мой взгляд, это ни капли не лучше, чем команда, где всех и каждого тянут в fullstack.
На мой взгляд, это ни капли не лучше, чем команда, где всех и каждого тянут в fullstack.
Я прошу прощения, если ввел в заблуждение своим отступлением в сторону в тексте. Я считаю, что кроссфункциональная команда — это группа профильных специалистов, решающих общую задачу. Они не должны быть fullstack разработчиками. Наоборот, чем более профессиональны FE, BE и QA, тем сильнее команда и быстрее делается работа. Про fullstack я вспомнил просто как пример того, что все идеи ходят по кругу.
Все бы ничего, но ваше понимание не вписывается, например, в концепт T-Shaped People и Swarming, которые в том же Scrum явщяются одной из основ фреймворка.
Что же касается задач, которые у вас остались черными на картинке, то их, в том чиле, выполняет Scrum Master.
Определение кроссфункциональной команды на практике сильно зависит от типа и масштабов организации. Субъективно прежде всего от бас-фактора. Если у вас в команде один бэкендер и на замену ему быстро никого выдернуть нельзя, то хоть кто то хоть как-то должен быть способен его подменить. Иначе у вас по сути никакой команды не будет случись что с ним. В большой ИТ-компании с "пулом ресурсов" можно набрать команду из узких специалистов, в средней не ИТ-компании с отделом разработки из 7 человек, для каждого элемента стэка и(или) флоу крайне желательно иметь хотя бы дублирование каждой технической роли, но даже ролей больше 7 легко может оказаться. И тут без многостагочников никуда.
Я бы дальше пошел. Сейчас пора на полном серьезе задуматься, а что мы будем делать в эпоху автоматизации работы. Вот на Medium была интересная заметка: «The Coders Programming Themselves Out of a Job». Там обсуждали, в частности, разумно ли говорить работодателю, что ты автоматизировал свою работу. Часть тех, кто на это отважился, были уволены с аргументацией, что не за что тебе теперь платить зарплату.
Это я к тому, что история с распределением работы PM-а внутри команды еще не самое сложная. Сложнее, когда работу забирает автоматизация.
Или сразу на уровень «Автоматические танкеры будут ходить с экипажем 1 человек и 1 собака. У человека будет задача кормить собаку, а у собаки — кусать человека, если он попробует нажать хоть 1 кнопочку», или проблемы из-за людей.
На днях перед запуском Очень Автоматизированного Скрипта на ПАК известного вендора посмотрел в конфиг, мало ли что там — и действительно, в конфиге данные 2 кластеров вместо одного. Скрипт должен был накатывать фабричный образ ОС со стиранием всех данных, было бы очень эпично потерять data lake с 5 годами данных.
Или потом другой скрипт автоматизации (от вендора этого ПАК) роли на кластерах с ноды на ноду автоматически перенёс без вопросов — половина софта слегла, потому что параметры сервисов уехали пёс пойми куда…
справились. Работают.
оставляя базы данных без паролей в открытом доступе.
Вот появятся надёжные трекинговые инструменты — точно всех по домам разгонят, чтоб аренду не платить.
А то что появилось больше программистов которые неплохи в менеджменте или менеджеров которые понимают в коде — этож хорошо, меньше косяков из-за не понимания мира друг друга, выше качество продуктов, быстрее инновации.
Убить надо того, кто в самом начале продавцов назвал менеджерами.
Знаете какой вопрос меня терзает, когда я читаю очередную такую статью? Только не обижайтесь. Вопрос такой — чо вас так колбасит? Стоит очередному менеджеру дойти до кризиса самооценки, как он клепает очередную статью на хабре. Для кого? Кому? Зачем? Вы проверьте, их тут каждую нелелю выпускают.
Ответ на все вопросы — CMMI. Все ваши манипуляции с ролями описанные в статье, не позволят достичь 5го уровня зрелости компании.
Выделю из прочего один важнейший аспект — конфликт интересов менеджера и команды проекта. Менеджер не функциональный руководитель команды, а административный. Он дает оценку эффективности работы команды, но не мотивирует ее, и не развивает. Он использует выделенные ресурсы. Контролирует рамки проекта, бюджет, непозволяя ресурсам уйти в пике по своим профессиональным направлениям.
Но! Менеджер проект это артефакт определенного уровня зрелости компании. И на начальных уровнях он действительно не нужен.
По поводу CMMI вы правы. И про контроль проектов с бюджетом и сроками вы правы. Посмотрите, я в конце цепочки рассуждения оставил четыре категории проектов, в которых PM остается актуальной ролью.
Не соглашусь только с жесткой связкой: зрелость компании и необходимость PM-а. Подумайте, Spotify или Valve — зрелые компании. Но работают без PM-ов. Я думаю, это больше вопрос требований к продукту и процессу, чем зрелость компании.
Так кто же занимается планированием? Роадмап — это не план, это хотелки. План — это большой объем достаточно обезьяньей работы, особенно актуализация плана. Но как без плана называть трудоемкость проекта и сроки? И актуализировать сроки в процессе разработки?
Поциеты против врачей. Вот если бы Яндекс деньги заявили что не нужны деньги или яндекс, это была бы новость. Не путайте лозунги для повышения мотивации и вовлеченности инженеров, коими наполнен скрам, и то, как на самом деле работают эти механики. Менеджер больше всего нужен когда в проекте что-то идёт не так и возникает необходимость решать небанальные вопросы.
Но вот что интересно: разработчики растут. Тут уже был комментарий про то, что зрелость IT специалистов на рынке подросла. Сейчас есть возможность собрать команды, в которых уровень ответственности и осознанности TL и старших разработчиков будет таким, при котором им в рамках гибкой методологии не нужен будет PM.
Во-вторых, коллективная ответственность отличаяется от коллективной безответственности. Со вторым провал обеспечен. С первым — обеспечен успех.
Дело в том, что теперь понятие успеха размыто. Если взять кастомную разработку для внешнего заказчика, то там с успехом всё это понятно — это пройденные тесты, подписанные акты и полученные деньги.
Если же речь идёт про другую крайность — компании (типа Яндекса), которые сами разрабатывают, сами обслуживают и сами продают свои сервисы, то здесь измерять успех команды разработки почти невозможно когда это уже действующий сервис, приносящий доход/прибыль. Владелец видит, что за год доход(другие показатели) сервиса увеличился на столько, сколько хотелось. Но успех ли это команды разработки? Может быть это удачное стечение обстоятельств, успешные маркетинговые акции или что-то ещё, а разработчики лишь сделали кучу непонятных неудобных фич, из-за которых пользователи раздражены и готовы уйти от сервиса, но пользуются по инерции.
Вот люди и развлекаются с методологиями, перераспределением обязанностей, коллективной безответственностью (я никогда не поверю в коллективную ответственность — это либо банкрот компании, либо поиск козла отпущения). Но ведь кто-то же должен это пробовать? Компания 10-100 человек не может себе позволить так рисковать, Яндекс может.
Почему то никто не пишет о том, что для разных процессов (индустрий, проектов и тд) нужны разные системы управления. В некоторых глобальных процессах scrum, agile и прочие могут быть просто разрушительными, в других случаях использование классических систем не принесет никакого результата.
Я полагаю, что проектный менеджер (как единица) возник потому, что типичная корпоративная среда, в которой появляются проекты:
— является функционально ориентированной, а задачи проекта могут затрагивать две или более областей одновременно,
— является индивидуалистической средой, где личные достижения важнее командных результатов (много вы знаете случаев когда за командный промах увольняли сотрудника (руководитель не в счет, ибо большинство увольнений идут за личные недоработки) ?)
Исходя из необходимости делать проекты (как таковые) был придуман проектный менеджер. Кстати, интересный факт состоит в том, что инновационные проекты в классических системах как правило проваливались, известный успешный проект был у японцев (Canon кажется), которые создали в таком проекте струйный принтер.
При таком подходе проект мог быть успешным только он имел более высокий приоритет чем функциональные обязанности каждого, что по сути перекраивало организационную структуру компании.
Отличие «классических» проектных методов в том, что в «тех» проектах хорошо понимали что хотят получить, но не знали как конкретно, в какие сроки, и за какие деньги. Современные проектные системы (в большинстве своем) построены из скорее непонимания того что в итоге нужно и как скорее это выяснить.
О чем это я? ))) Исходя из конкретного окружения, ситуации и целей можно выбрать наиболее эффективную систему управления процессами (а может и набор из разных систем), а не проектную систему, под которую будут подгоняться процессы.
У меня только один комментарий: фактически с приходом гибких методологий мы наблюдаем, как меняется корпоративная культура с функциональной на продуктовую. Что причина, что следствие не берусь рассуждать. Но определенно успех и конкурентное преимущество компаний, которые это уже сделали, ускоряет общее изменение.
Что тут говорить, если самые классические банки начинают создавать свои «лаборатории» или «гаражи», отказываясь в них от иерархических функциональных структур.
Лучше всего «продуктовый» подход ощущается в работе IT компаний, так как там:
— продукта нет (
— чем он будет не знает никто )
— как его сделать пока непонятно
— как он будет воспринят (и что соответственно придется менять) не предскажет никто.
Функциональную модель на таком не построишь.
Какая степень определенности — такой и проектный метод :). Когда запускали новый вид зубной пасты (какой нибудь Colgate например) неопределенности было крайне мало, было понятно как сделать новый продукт. Сейчас этот метод просто не работает.
Всегда останутся индустрии, в которых ошибки нужно исключить по максимуму — медицина, авиация, космическая индустрия, военная сфера.
Может у них там да. У нас точно нет. В падени ракетоносителя виноват слесарь. В военной сфере вообще неприминимы понятия рыночных отношений. Да и нарисованные план-графики в виде диаграммы Ганта, абсолютно бессмысленны из за отсутствия функциональных зависимостей между последовательными этапами. Часто многое держится на человеческих отношениях. Сразу говориш оператору какие кнопки ненажимать чтоб башку не оторвало. Многое зависит от конкретной команды. Какой Скрам если есть ГОСТ.
В военной сфере «тут» не применимы понятия рынка, потому что:
— никто не считает во сколько обходится изделие, либо считают без учета капитальных затрат.
— нет конкуренции (попытки одного министра обороны заставить делать изделия на уровне цен и качеств зарубежных аналогов как вы помните привели к отставке министра)
— как общий мотив — все сравнивается со своим же, отечественным, в то время как вся военная индустрия мира работает на глобальные рынки.
При таких параметрах рыночных отношений не может быть в принципе.
Странно, но ГОСТ не противоречит скраму, ибо ГОСТ не определяет регламент управления бизнес процессами (да и никогда он и не определял).
То что многое держится на человеческих отношениях — это огромный минус системы управления, так как, люди, как ресурс управления:
— могут делать ошибки
— подвержены субъективизму и коррупции
— имеют ограниченный ресурс.
Разумеется, это касается простых операций, ибо «кнопки ненажимать» явно не в сфере ТРИЗ.
1) В моей области деятельности — внедрение систем управления бизнес-процессами — такими как ERP, WMS, SRM, CRM — гибкие методологии не прижились, всё делается по старому сердитому каскадному подходу и без пиэма никуда.
2) В разработке теперь вместо одного PM теперь PO+TL+SM+SA? Забавно :-)
Про второй пункт хочется ответить: стало больше ролей, но вы же знаете, что в гибких методологиях один из негласных принципов: two pizzas team. Роли — ролями, а размер команд лучше держать до 10 челоек. А не как в одном крупном изместном банке, где на переписывание софта для call-center собирали отдел в 50 человек.
кроме того, если в проекте более одной скрам-команды, то кто-то должен координировать их и отчитываться перед начальством. Кто бы это мог быть? ;-)
В одном моём проекте было 8 скрам-команд. Но я их толком даже не знал, взаимодействовал с одним руководителем разработки.
Так и хочется сделать краткий пересказ статьи:
В настоящем скрам ПМ не нужен, но скрам не везде применим :)
Подвох в слове "настоящий" — редкая птица. И как по мне, то основная проблема в отсутствии мотивированных самоорганизующихся кроссфункциональных команд. ПМ как раз нужен, чтобы с ним команда стала такой для внешнего мира. Мотивировать, организовывать, привлекать "смежников" и т. п. Проще говоря, как-то закрывать дыры команды в серии двухнедельных проектов.
Менеджеры проектов не нужны