Comments 60
В отсутствие проектного метода разработки менеджер проекта не нужен. Новости!
Тут я не соглашусь, так как Scrum вполне себе проектный метод. Но не буду спорить. Лучше приведу интересный пример из жизни. Был у меня кандидат в PM-ы из крупнейшего зеленого российского банка. Рассказывал, что там для выполнения проектов создан и внедрен такой детальный и системный проектный фрэймворк, что он на одном из проектов, эксперимента ради, ничего не делал как PM. Только пересылал сообщения от одних людей, до других. И проект завершился успешно и в срок. Вывод, если задаться целью, можно экспертизу PMа запрограммировать в процессе.
Автор: Свитер теперь не нужен! У нас есть худи, лонгслив, толстовка и свитшот и кардиган.
Программист: Вот этот почище и без дыры дайте.
Программист: Вот этот почище и без дыры дайте.
Главная проблема диаграммы Гантта не в том, что она становится сложной и трудносопровождаемой, а в том, что она создаёт видимость чёткого плана там, где его нет, а часто и не может быть.
www.greesha.ru/livejournal/символ-несбывшихся-надежд
www.greesha.ru/livejournal/символ-несбывшихся-надежд
Теоретически, исследовательские, неточные, высокорисковые задачи можно в Гантте расписать и потом регулярно актуализировать. Практически, трубоемкость этого сильно превышает пользу. Поэтому никто так не делает.
Любой инструмент менеджера должен быть живым. Если команда не опирается на план — его сделал плохой менеджер проекта, т.к. план оторван от жизни и бесполезен, либо инструменты его использования командой ущербны. Менеджер обязан знать инструменты управления, которые создают его команде комфортную интеграцию каждого в процесс. И каждый артефакт должен быть полезен, а не формален.
В этом случае не будет такого, когда план, хоть на 10 лет вперед будет несостоятельным.
Да, конечно, когда горизонт планирования велик, вероятность изменений тоже велика. Но план это то, что мы планируем СЕГОДНЯ на будущее. Это не контракт подписанный "кровью". План живет и развивается вместе с проектом. Каждый день. И его развитие задача очень и очень занимательная. И это реально полезная и нужная работа всем и каждому в команде.
В статья я рассуждал о диаграмме Гантта. Ее главная сила с моей, сугубо личной, точки зрения состоит в управлении зависимостями. А в современной разрботке зависимостям фактически объявлена война.
В гибких методологиях план работ существует в другом виде. Чаще всего я встречал его как сочетание roadmap-а фич на горизнте плюс-минус года, набора квартальных целей и целей и составов спринтов.
В гибких методологиях план работ существует в другом виде. Чаще всего я встречал его как сочетание roadmap-а фич на горизнте плюс-минус года, набора квартальных целей и целей и составов спринтов.
По моему проблема диаграмма имеет пробелмы не только в этом.
Основная проблема в том, что это инструмент маркетинга — когда проект создается, утвердается и продается диаграмма Ганта выглядит довольно презентабельно и умнО для среднего менеджера/собственника/дилетанта (если она влазит на лист А3)
А вот когда проект уже идет, она бесполезна. На не видно текущего состояния проекта. Да, на каждой активности видно процент выполнения, но не видно реальных сроков: 100% долно быль быть в январе, а выполнено 50% но в марте. Также не видно реально задействованые ресурсы. Не видно перепланировок, дробления и переноса задач.
Т.е. после начала проекта этот документ становится мертвым.
Основная проблема в том, что это инструмент маркетинга — когда проект создается, утвердается и продается диаграмма Ганта выглядит довольно презентабельно и умнО для среднего менеджера/собственника/дилетанта (если она влазит на лист А3)
А вот когда проект уже идет, она бесполезна. На не видно текущего состояния проекта. Да, на каждой активности видно процент выполнения, но не видно реальных сроков: 100% долно быль быть в январе, а выполнено 50% но в марте. Также не видно реально задействованые ресурсы. Не видно перепланировок, дробления и переноса задач.
Т.е. после начала проекта этот документ становится мертвым.
Да-да, кросс-функциональные команды.
Только почему-то это сводится к «Так. У нас будут кросс-функциональные команды, поэтому тестеры теперь будут оставаться после работы 2 часа и учиться стеку Java у разработки. И аналитике заодно. А Java-разработчики быстро пройдут курс по С++ у коллег, потому что backend на С++. И да, всё это за свой счёт, кто против — бланк на увольнение по собственному есть в сети.»
Только почему-то это сводится к «Так. У нас будут кросс-функциональные команды, поэтому тестеры теперь будут оставаться после работы 2 часа и учиться стеку Java у разработки. И аналитике заодно. А Java-разработчики быстро пройдут курс по С++ у коллег, потому что backend на С++. И да, всё это за свой счёт, кто против — бланк на увольнение по собственному есть в сети.»
Это выглядит странно. Под кросс-функуиональными командами я имел в виду команды, где каждый специалист профессионал в своей области, но все вместе делают один продукт. И сравнивал с классическим подходом, когда есть отдел Java с руководителем, отдел FE с руководителем. И у QA есть свой руководитель. И все эти руководители распределяют задачи между сотрудинками каждый по своей системе. Это не архаика, вот прямо сейчас, в 2019ом у моего друга, который в роли PO работает, такая структура пытается проекты делать.
Видел классический подход с отдельными командами специалистов по сетям, по linux, по win, по ELK, по hadoop, по scala, по прикладному софту, у которых постоянно не хватает привелегий что-то сделать и которые ставят друг другу задачи.
На мой взгляд, это ни капли не лучше, чем команда, где всех и каждого тянут в fullstack.
На мой взгляд, это ни капли не лучше, чем команда, где всех и каждого тянут в fullstack.
На мой взгляд, это ни капли не лучше, чем команда, где всех и каждого тянут в fullstack.
Я прошу прощения, если ввел в заблуждение своим отступлением в сторону в тексте. Я считаю, что кроссфункциональная команда — это группа профильных специалистов, решающих общую задачу. Они не должны быть fullstack разработчиками. Наоборот, чем более профессиональны FE, BE и QA, тем сильнее команда и быстрее делается работа. Про fullstack я вспомнил просто как пример того, что все идеи ходят по кругу.
Определение кроссфункциональной команды на практике сильно зависит от типа и масштабов организации. Субъективно прежде всего от бас-фактора. Если у вас в команде один бэкендер и на замену ему быстро никого выдернуть нельзя, то хоть кто то хоть как-то должен быть способен его подменить. Иначе у вас по сути никакой команды не будет случись что с ним. В большой ИТ-компании с "пулом ресурсов" можно набрать команду из узких специалистов, в средней не ИТ-компании с отделом разработки из 7 человек, для каждого элемента стэка и(или) флоу крайне желательно иметь хотя бы дублирование каждой технической роли, но даже ролей больше 7 легко может оказаться. И тут без многостагочников никуда.
UFO just landed and posted this here
В случае с DevOps, QA и PM действительно так происходит. Не везде. И это, пока что, не стало трендом. Но примеры есть. В 2015ом крупная европейская eComm компания с штатом в 250+ разработчиков одномоментно расформировала отделы системных администраторов и «обрадовала» команды разработки, что они теперь сами за прод отвечают. Шок, это очень мягкое определение того, что там было. Но ничего, справились. Работают.
Я бы дальше пошел. Сейчас пора на полном серьезе задуматься, а что мы будем делать в эпоху автоматизации работы. Вот на Medium была интересная заметка: «The Coders Programming Themselves Out of a Job». Там обсуждали, в частности, разумно ли говорить работодателю, что ты автоматизировал свою работу. Часть тех, кто на это отважился, были уволены с аргументацией, что не за что тебе теперь платить зарплату.
Это я к тому, что история с распределением работы PM-а внутри команды еще не самое сложная. Сложнее, когда работу забирает автоматизация.
Я бы дальше пошел. Сейчас пора на полном серьезе задуматься, а что мы будем делать в эпоху автоматизации работы. Вот на Medium была интересная заметка: «The Coders Programming Themselves Out of a Job». Там обсуждали, в частности, разумно ли говорить работодателю, что ты автоматизировал свою работу. Часть тех, кто на это отважился, были уволены с аргументацией, что не за что тебе теперь платить зарплату.
Это я к тому, что история с распределением работы PM-а внутри команды еще не самое сложная. Сложнее, когда работу забирает автоматизация.
UFO just landed and posted this here
Простите, чем больше работаю с автоматизацией, тем меньше верю в победу автоматизации.
Или сразу на уровень «Автоматические танкеры будут ходить с экипажем 1 человек и 1 собака. У человека будет задача кормить собаку, а у собаки — кусать человека, если он попробует нажать хоть 1 кнопочку», или проблемы из-за людей.
На днях перед запуском Очень Автоматизированного Скрипта на ПАК известного вендора посмотрел в конфиг, мало ли что там — и действительно, в конфиге данные 2 кластеров вместо одного. Скрипт должен был накатывать фабричный образ ОС со стиранием всех данных, было бы очень эпично потерять data lake с 5 годами данных.
Или потом другой скрипт автоматизации (от вендора этого ПАК) роли на кластерах с ноды на ноду автоматически перенёс без вопросов — половина софта слегла, потому что параметры сервисов уехали пёс пойми куда…
Или сразу на уровень «Автоматические танкеры будут ходить с экипажем 1 человек и 1 собака. У человека будет задача кормить собаку, а у собаки — кусать человека, если он попробует нажать хоть 1 кнопочку», или проблемы из-за людей.
На днях перед запуском Очень Автоматизированного Скрипта на ПАК известного вендора посмотрел в конфиг, мало ли что там — и действительно, в конфиге данные 2 кластеров вместо одного. Скрипт должен был накатывать фабричный образ ОС со стиранием всех данных, было бы очень эпично потерять data lake с 5 годами данных.
Или потом другой скрипт автоматизации (от вендора этого ПАК) роли на кластерах с ноды на ноду автоматически перенёс без вопросов — половина софта слегла, потому что параметры сервисов уехали пёс пойми куда…
Я бы сказал, что эти примеры ошибок подтверждают сложность этой задачи и ее неготовность к массовому применению. Но и полет на сверхзвуковых скоростях или в космос когда-то казался невозможно сложной задачей. Сейчас бизнес видит в автоматизации способ сокращения расходов и на ее внедрение тратятся значительные инвестиции. А где есть финансирование, там будет и результат.
справились. Работают.
оставляя базы данных без паролей в открытом доступе.
CleanOps — это ж удалёнка! Сами готовят, сами убирают, могут работать на 2 часа дольше, потому что транспорт от кровати в кресло не нужен…
Вот появятся надёжные трекинговые инструменты — точно всех по домам разгонят, чтоб аренду не платить.
Вот появятся надёжные трекинговые инструменты — точно всех по домам разгонят, чтоб аренду не платить.
Есть кейс офиса, где убрали мусорные корзины, вообще, вроде как по требованию лэндлорда. Не РФ, и контора весьма крупная и серьезная :) В итоге каждая тима сама себе завела личные мусорки и лично их опустошает :)
Мне кажется все гораздо проще, это не роли исчезают — это просто для успешного выполнения своей роли теперь нужно знать код. И это движение в правильном направлении. Работаю в большой успешной американской компании, где очень хорошо работает 'научный подход'. Т.е. все должно подтверждаться экспериментом. Тут как ни крути, а знать SQL(или что-то подобное) и чуть чуть Python или Java просто необходимо. (По другому просто не сможешь показать результаты своей работы)
А то что появилось больше программистов которые неплохи в менеджменте или менеджеров которые понимают в коде — этож хорошо, меньше косяков из-за не понимания мира друг друга, выше качество продуктов, быстрее инновации.
А то что появилось больше программистов которые неплохи в менеджменте или менеджеров которые понимают в коде — этож хорошо, меньше косяков из-за не понимания мира друг друга, выше качество продуктов, быстрее инновации.
HH с вами согласен, что не нужны. По крайней мере слово «менеджер». В российских реалиях тяжелых извращений понятие «менеджер проектов» не равно понятию «руководитель, управляющий и т.п. проекта». Те гении, что менеджерами зовут мелких продавцов, под менеджерами проектов понимают зачастую помощника начальника или руководителя, уровня администратора. Нормальное понимание этого термина даже не в половине существующих вакансий.
Убить надо того, кто в самом начале продавцов назвал менеджерами.
Убить надо того, кто в самом начале продавцов назвал менеджерами.
Знаете какой вопрос меня терзает, когда я читаю очередную такую статью? Только не обижайтесь. Вопрос такой — чо вас так колбасит? Стоит очередному менеджеру дойти до кризиса самооценки, как он клепает очередную статью на хабре. Для кого? Кому? Зачем? Вы проверьте, их тут каждую нелелю выпускают.
Ответ на все вопросы — CMMI. Все ваши манипуляции с ролями описанные в статье, не позволят достичь 5го уровня зрелости компании.
Выделю из прочего один важнейший аспект — конфликт интересов менеджера и команды проекта. Менеджер не функциональный руководитель команды, а административный. Он дает оценку эффективности работы команды, но не мотивирует ее, и не развивает. Он использует выделенные ресурсы. Контролирует рамки проекта, бюджет, непозволяя ресурсам уйти в пике по своим профессиональным направлениям.
Но! Менеджер проект это артефакт определенного уровня зрелости компании. И на начальных уровнях он действительно не нужен.
Я совершенно не обижаюсь на любые комментарии. Тем более, адекватные. Я описал причины, по которым выступил с этой темой. Вкратце: я большой сторонник проектного офиса и хорошо понимаю его ценность. Но вот я сменил работу и попал в другую среду, с другими целями, задачами и приоритетами. И теперь готов не теоретически, а практически обсуждать вторую сторону баррикад.
По поводу CMMI вы правы. И про контроль проектов с бюджетом и сроками вы правы. Посмотрите, я в конце цепочки рассуждения оставил четыре категории проектов, в которых PM остается актуальной ролью.
Не соглашусь только с жесткой связкой: зрелость компании и необходимость PM-а. Подумайте, Spotify или Valve — зрелые компании. Но работают без PM-ов. Я думаю, это больше вопрос требований к продукту и процессу, чем зрелость компании.
По поводу CMMI вы правы. И про контроль проектов с бюджетом и сроками вы правы. Посмотрите, я в конце цепочки рассуждения оставил четыре категории проектов, в которых PM остается актуальной ролью.
Не соглашусь только с жесткой связкой: зрелость компании и необходимость PM-а. Подумайте, Spotify или Valve — зрелые компании. Но работают без PM-ов. Я думаю, это больше вопрос требований к продукту и процессу, чем зрелость компании.
Так кто же занимается планированием? Роадмап — это не план, это хотелки. План — это большой объем достаточно обезьяньей работы, особенно актуализация плана. Но как без плана называть трудоемкость проекта и сроки? И актуализировать сроки в процессе разработки?
Поциеты против врачей. Вот если бы Яндекс деньги заявили что не нужны деньги или яндекс, это была бы новость. Не путайте лозунги для повышения мотивации и вовлеченности инженеров, коими наполнен скрам, и то, как на самом деле работают эти механики. Менеджер больше всего нужен когда в проекте что-то идёт не так и возникает необходимость решать небанальные вопросы.
Вот тут я не соглашусь. Если команде, когда что-то пошло не так, нужен менеджер, это незрелая команда. Вот у меня в командах разработки на 7-10 человек есть TL и три старших специалиста (BE, FE, QA). И они потому TL и старшие, что умеют решать сложные вопросы и не давать спринтам идти не так. Они очень опытные, умные, мотивированные, интересные, веселые и позитивные ребята. Им точно не нужен PM. Ему просто нечего будет делать днями напролет.
Это всё просто переименовывание ролей и перераспределение обязаннсостей. Есть множество функций, есть множество людей, обладающие различными скилл-сетами и люди просто делят функции между собой. «overhead»-люди (PM,SA,SM), делающие грязную работу, которую не хотят или не могут делать разработчики, придумывают себе новые названия, перераспределяют эту грязную работу между собой, но суть не меняется. если ты умеешь организовывать работу людей, то какая разница как ты называешься — PM или SM?
Согласен с очень базовой вещью: если работу нужно сделать, кто-то ее должен сделать. Ее можно перекладывать между ролями, но исчезнуть она не может, если только не сменятся условия (изменение методологии, автоматизация, отсутствие требований и т.д.).
Но вот что интересно: разработчики растут. Тут уже был комментарий про то, что зрелость IT специалистов на рынке подросла. Сейчас есть возможность собрать команды, в которых уровень ответственности и осознанности TL и старших разработчиков будет таким, при котором им в рамках гибкой методологии не нужен будет PM.
Но вот что интересно: разработчики растут. Тут уже был комментарий про то, что зрелость IT специалистов на рынке подросла. Сейчас есть возможность собрать команды, в которых уровень ответственности и осознанности TL и старших разработчиков будет таким, при котором им в рамках гибкой методологии не нужен будет PM.
Менеджеры проектов может и нет, а менеджеры людей пригодятся. Этих оставим.
Согласен, но это тема на отдельную дискуссию. Про то, как за последние 5-7 лет в IT начали меняться требования к руководителям людей. Это очень интересный процесс. И у меня сейчас на работе очень наглядная ситуация с двуми группы специалистов: с хорошим управлением людьми и без него. Разница видна невооруженным глазом.
Если под менеджером проекта понимать того единственного человека, который отвечает за успех проекта перед руководством или акционерами, то такая роль никогда не исчезнет. И не важно, какая методология используется, где рисуются тикеты или диаграммы Ганта и какой размер у проекта. Как только ответственность становится размытой или коллективной, это первый шаг к провалу.
Во-первых я писал, что эту ответственность акционеры и руководители возложили на PO. Фактически, под эту ответственность выделяются средства.
Во-вторых, коллективная ответственность отличаяется от коллективной безответственности. Со вторым провал обеспечен. С первым — обеспечен успех.
Во-вторых, коллективная ответственность отличаяется от коллективной безответственности. Со вторым провал обеспечен. С первым — обеспечен успех.
Какая разница, какие погоны висят на человеке? Тимлид он или руководитель отдела — если перед вышестоящим за успех он отвечает, то у него есть роль руководителя проекта. А по поводу коллективной ответственности — предположим, с одним из проектов возникают серьёзные проблемы. Кого ваш руководитель вызывает на ковёр? Весь коллектив выстраивает? И они хором должны пообещать что-то хорошее? ) Ну вот честно, не представляю я такой ситуации. Это всё быстро заканчивается, как только у собственников возникает серьёзный риск потери серьёзных денег.
Дело в том, что теперь понятие успеха размыто. Если взять кастомную разработку для внешнего заказчика, то там с успехом всё это понятно — это пройденные тесты, подписанные акты и полученные деньги.
Если же речь идёт про другую крайность — компании (типа Яндекса), которые сами разрабатывают, сами обслуживают и сами продают свои сервисы, то здесь измерять успех команды разработки почти невозможно когда это уже действующий сервис, приносящий доход/прибыль. Владелец видит, что за год доход(другие показатели) сервиса увеличился на столько, сколько хотелось. Но успех ли это команды разработки? Может быть это удачное стечение обстоятельств, успешные маркетинговые акции или что-то ещё, а разработчики лишь сделали кучу непонятных неудобных фич, из-за которых пользователи раздражены и готовы уйти от сервиса, но пользуются по инерции.
Вот люди и развлекаются с методологиями, перераспределением обязанностей, коллективной безответственностью (я никогда не поверю в коллективную ответственность — это либо банкрот компании, либо поиск козла отпущения). Но ведь кто-то же должен это пробовать? Компания 10-100 человек не может себе позволить так рисковать, Яндекс может.
Конечно, в Яндексе и любой другой большой продуктовой компании должна быть своя специфика по сравнению с заказной разработкой и некоторыми другими видами IT-компаний. Но при этом возникает вопрос — а корректно ли называть проектами то, что они делают? Предположу, что к подавляющему большинству их активностей больше применима процессная терминология и KPIs, а не проектные. Тогда всё становится на свои места.
Интересная статья, вообщем тут не с чем не поспоришь. Но… каждый раз читая про очередную систему управления проектами (как панацею от всех управленческих проблем) искреннее удивляюсь тому, что не рассматривается контекст, основа той среды, где зародилась конкретная система управления процессами (ну или проектами).
Почему то никто не пишет о том, что для разных процессов (индустрий, проектов и тд) нужны разные системы управления. В некоторых глобальных процессах scrum, agile и прочие могут быть просто разрушительными, в других случаях использование классических систем не принесет никакого результата.
Я полагаю, что проектный менеджер (как единица) возник потому, что типичная корпоративная среда, в которой появляются проекты:
— является функционально ориентированной, а задачи проекта могут затрагивать две или более областей одновременно,
— является индивидуалистической средой, где личные достижения важнее командных результатов (много вы знаете случаев когда за командный промах увольняли сотрудника (руководитель не в счет, ибо большинство увольнений идут за личные недоработки) ?)
Исходя из необходимости делать проекты (как таковые) был придуман проектный менеджер. Кстати, интересный факт состоит в том, что инновационные проекты в классических системах как правило проваливались, известный успешный проект был у японцев (Canon кажется), которые создали в таком проекте струйный принтер.
При таком подходе проект мог быть успешным только он имел более высокий приоритет чем функциональные обязанности каждого, что по сути перекраивало организационную структуру компании.
Отличие «классических» проектных методов в том, что в «тех» проектах хорошо понимали что хотят получить, но не знали как конкретно, в какие сроки, и за какие деньги. Современные проектные системы (в большинстве своем) построены из скорее непонимания того что в итоге нужно и как скорее это выяснить.
О чем это я? ))) Исходя из конкретного окружения, ситуации и целей можно выбрать наиболее эффективную систему управления процессами (а может и набор из разных систем), а не проектную систему, под которую будут подгоняться процессы.
Почему то никто не пишет о том, что для разных процессов (индустрий, проектов и тд) нужны разные системы управления. В некоторых глобальных процессах scrum, agile и прочие могут быть просто разрушительными, в других случаях использование классических систем не принесет никакого результата.
Я полагаю, что проектный менеджер (как единица) возник потому, что типичная корпоративная среда, в которой появляются проекты:
— является функционально ориентированной, а задачи проекта могут затрагивать две или более областей одновременно,
— является индивидуалистической средой, где личные достижения важнее командных результатов (много вы знаете случаев когда за командный промах увольняли сотрудника (руководитель не в счет, ибо большинство увольнений идут за личные недоработки) ?)
Исходя из необходимости делать проекты (как таковые) был придуман проектный менеджер. Кстати, интересный факт состоит в том, что инновационные проекты в классических системах как правило проваливались, известный успешный проект был у японцев (Canon кажется), которые создали в таком проекте струйный принтер.
При таком подходе проект мог быть успешным только он имел более высокий приоритет чем функциональные обязанности каждого, что по сути перекраивало организационную структуру компании.
Отличие «классических» проектных методов в том, что в «тех» проектах хорошо понимали что хотят получить, но не знали как конкретно, в какие сроки, и за какие деньги. Современные проектные системы (в большинстве своем) построены из скорее непонимания того что в итоге нужно и как скорее это выяснить.
О чем это я? ))) Исходя из конкретного окружения, ситуации и целей можно выбрать наиболее эффективную систему управления процессами (а может и набор из разных систем), а не проектную систему, под которую будут подгоняться процессы.
Вы верно уловили суть.
У меня только один комментарий: фактически с приходом гибких методологий мы наблюдаем, как меняется корпоративная культура с функциональной на продуктовую. Что причина, что следствие не берусь рассуждать. Но определенно успех и конкурентное преимущество компаний, которые это уже сделали, ускоряет общее изменение.
Что тут говорить, если самые классические банки начинают создавать свои «лаборатории» или «гаражи», отказываясь в них от иерархических функциональных структур.
У меня только один комментарий: фактически с приходом гибких методологий мы наблюдаем, как меняется корпоративная культура с функциональной на продуктовую. Что причина, что следствие не берусь рассуждать. Но определенно успех и конкурентное преимущество компаний, которые это уже сделали, ускоряет общее изменение.
Что тут говорить, если самые классические банки начинают создавать свои «лаборатории» или «гаражи», отказываясь в них от иерархических функциональных структур.
Не в каждом бизнесе может возникнуть «продуктовый» подход, вы правы в том, что изменения идут в эту сторону. Я полагаю, что в жестко централизованной модели бизнеса, когда есть условный отдел который отвечает за продукты и инновации, такой подход себя изжил. Отдельные попытки были успешны и не очень (IBM в момент создания PC). Централизация, как метод управления тихо умирает, а нового пока не придумали, есть только отдельные методики и подходы.
Лучше всего «продуктовый» подход ощущается в работе IT компаний, так как там:
— продукта нет (
— чем он будет не знает никто )
— как его сделать пока непонятно
— как он будет воспринят (и что соответственно придется менять) не предскажет никто.
Функциональную модель на таком не построишь.
Какая степень определенности — такой и проектный метод :). Когда запускали новый вид зубной пасты (какой нибудь Colgate например) неопределенности было крайне мало, было понятно как сделать новый продукт. Сейчас этот метод просто не работает.
Лучше всего «продуктовый» подход ощущается в работе IT компаний, так как там:
— продукта нет (
— чем он будет не знает никто )
— как его сделать пока непонятно
— как он будет воспринят (и что соответственно придется менять) не предскажет никто.
Функциональную модель на таком не построишь.
Какая степень определенности — такой и проектный метод :). Когда запускали новый вид зубной пасты (какой нибудь Colgate например) неопределенности было крайне мало, было понятно как сделать новый продукт. Сейчас этот метод просто не работает.
Всегда останутся индустрии, в которых ошибки нужно исключить по максимуму — медицина, авиация, космическая индустрия, военная сфера.
Может у них там да. У нас точно нет. В падени ракетоносителя виноват слесарь. В военной сфере вообще неприминимы понятия рыночных отношений. Да и нарисованные план-графики в виде диаграммы Ганта, абсолютно бессмысленны из за отсутствия функциональных зависимостей между последовательными этапами. Часто многое держится на человеческих отношениях. Сразу говориш оператору какие кнопки ненажимать чтоб башку не оторвало. Многое зависит от конкретной команды. Какой Скрам если есть ГОСТ.
Формулировка «там» и «тут» как ни странно, применяется только «тут». «Там» тоже есть военное производство (ну уж точно не меньше чем у нас, оно в сотни раз больше и сложнее), но «там» не сравнивают с тем что «тут» и не говорят что что-то не будет работать по этой причине.
В военной сфере «тут» не применимы понятия рынка, потому что:
— никто не считает во сколько обходится изделие, либо считают без учета капитальных затрат.
— нет конкуренции (попытки одного министра обороны заставить делать изделия на уровне цен и качеств зарубежных аналогов как вы помните привели к отставке министра)
— как общий мотив — все сравнивается со своим же, отечественным, в то время как вся военная индустрия мира работает на глобальные рынки.
При таких параметрах рыночных отношений не может быть в принципе.
Странно, но ГОСТ не противоречит скраму, ибо ГОСТ не определяет регламент управления бизнес процессами (да и никогда он и не определял).
То что многое держится на человеческих отношениях — это огромный минус системы управления, так как, люди, как ресурс управления:
— могут делать ошибки
— подвержены субъективизму и коррупции
— имеют ограниченный ресурс.
Разумеется, это касается простых операций, ибо «кнопки ненажимать» явно не в сфере ТРИЗ.
В военной сфере «тут» не применимы понятия рынка, потому что:
— никто не считает во сколько обходится изделие, либо считают без учета капитальных затрат.
— нет конкуренции (попытки одного министра обороны заставить делать изделия на уровне цен и качеств зарубежных аналогов как вы помните привели к отставке министра)
— как общий мотив — все сравнивается со своим же, отечественным, в то время как вся военная индустрия мира работает на глобальные рынки.
При таких параметрах рыночных отношений не может быть в принципе.
Странно, но ГОСТ не противоречит скраму, ибо ГОСТ не определяет регламент управления бизнес процессами (да и никогда он и не определял).
То что многое держится на человеческих отношениях — это огромный минус системы управления, так как, люди, как ресурс управления:
— могут делать ошибки
— подвержены субъективизму и коррупции
— имеют ограниченный ресурс.
Разумеется, это касается простых операций, ибо «кнопки ненажимать» явно не в сфере ТРИЗ.
Насколько я понимаю, для компании — разработчика ПО, или компании, где часть структуры постоянно занята циклом улучшения ПО, эта деятельность частично становится операционной (PM и ядро команды опытные, накоплена статистика). Но все же если нечто выглядит как утка, плавает как утка и крякает как утка один человек отвечает за проект в-целом, то от делегирования части ответственности он PM'ом быть не перестает. Как называется его должность — дело десятое…
Точка зрения интересная, но спорная.
1) В моей области деятельности — внедрение систем управления бизнес-процессами — такими как ERP, WMS, SRM, CRM — гибкие методологии не прижились, всё делается по старому сердитому каскадному подходу и без пиэма никуда.
2) В разработке теперь вместо одного PM теперь PO+TL+SM+SA? Забавно :-)
1) В моей области деятельности — внедрение систем управления бизнес-процессами — такими как ERP, WMS, SRM, CRM — гибкие методологии не прижились, всё делается по старому сердитому каскадному подходу и без пиэма никуда.
2) В разработке теперь вместо одного PM теперь PO+TL+SM+SA? Забавно :-)
Безусловно спорная. Более того, через год у меня вполне могут изменится условия и задачи, и я вернусь к старому доброму институту проектного офиса.
Про второй пункт хочется ответить: стало больше ролей, но вы же знаете, что в гибких методологиях один из негласных принципов: two pizzas team. Роли — ролями, а размер команд лучше держать до 10 челоек. А не как в одном крупном изместном банке, где на переписывание софта для call-center собирали отдел в 50 человек.
Про второй пункт хочется ответить: стало больше ролей, но вы же знаете, что в гибких методологиях один из негласных принципов: two pizzas team. Роли — ролями, а размер команд лучше держать до 10 челоек. А не как в одном крупном изместном банке, где на переписывание софта для call-center собирали отдел в 50 человек.
отдел и проект это параллельные миры. У отдела может быть много проектов, а в проекте могут быть задействованы много отделов.
кроме того, если в проекте более одной скрам-команды, то кто-то должен координировать их и отчитываться перед начальством. Кто бы это мог быть? ;-)
В одном моём проекте было 8 скрам-команд. Но я их толком даже не знал, взаимодействовал с одним руководителем разработки.
кроме того, если в проекте более одной скрам-команды, то кто-то должен координировать их и отчитываться перед начальством. Кто бы это мог быть? ;-)
В одном моём проекте было 8 скрам-команд. Но я их толком даже не знал, взаимодействовал с одним руководителем разработки.
Поиски «волшебной таблетки», одним махом решающей все вопросы во всех сферах, продолжаются.
Так и хочется сделать краткий пересказ статьи:
В настоящем скрам ПМ не нужен, но скрам не везде применим :)
Подвох в слове "настоящий" — редкая птица. И как по мне, то основная проблема в отсутствии мотивированных самоорганизующихся кроссфункциональных команд. ПМ как раз нужен, чтобы с ним команда стала такой для внешнего мира. Мотивировать, организовывать, привлекать "смежников" и т. п. Проще говоря, как-то закрывать дыры команды в серии двухнедельных проектов.
Sign up to leave a comment.
Менеджеры проектов не нужны