Еще один камень к классическим проджектам

Канал о системном и бизнес-анализе, продуктовом мышлении и архитектуре. Как выявлять реальные проблемы, строить работающие решения и не терять здравый смысл в IT. Все вопросы - @innokentyB

проджект-менеджерпродактуправление проектом

Еще один камень кину в сторону классических проджектов. Сегодня смотрел запись интенсива по прдуктовому менеджменту и там был вопрос, а где границы работы продакта. Один из вариантов был "от идеи до продакшена", звучит вроде здраво, но ведущая возмутилась: "Это как то по проджектовому звучит, довести до продакшена и бросить".

И вот тут у меня действительно сложилась картинка, почему деятельность менеджеров проектов мне так претит:

  1. Раньше я уже упоминал про ориентацию на сроки и бюджет, а не на ценность. Сколько раз у меня такое было, что нужно приложить немного больше усилий и сделать конфетку. Но проджет либо сразу отметал идею, либо фейлил переговоры по ней с заказчиком, а один раз даже просто сказал, что заказчик отказал, хотя даже не выходил с этим предложением. Очень часто для таких специалистов лень или страх становились блокерами в донесении реальной ценности.
  2. Фанатичное следование плану и желание всех на этот план натянуть. Никогда не забуду, как чудесные проджекты из одной из компаний большой четверки перед сдачей устраивали ежечасные статусы накануне сдачи проекта, задолбав всю команду. В два часа ночи (дада, статусы продолжались) я просто сказал, что иду спать невзирая на их возмущения, моему примеру последовала вся команда.
  3. Умение и желание спихивать с себя ответственность. Однажды был проект,в рамках которого требовалось загрузить в систему клиентскую базу в несколько сотен тысяч клиентов с договорами, актами и прочим атрибутивным составом. Система была оборудована встроенным 1с подобным интерпретатором (но это не 1С), были варианты грузить через него, делать все проверки бизнес логики, дедупликацию, сверку и тд, все в интерпретаторе в несколько потоков. Или грузить нативно из табличек в SQL и там скриптами проверять и все делать. Первый вариант выглядел дешевле - все проверки уже есть в бизнес логике системы, почему бы не переиспользовать. Я написал четко, почему это будет работать долго, плохо и больно, однако это же было дешевле в разработке и сдедали по первому варианту. В результате загрузка из 3 недель превратилась в 4-месячное полуручное адище с ручной разбивкой файлов и подбором оптимального размера файла. Надо ли говорить, что проджект пытался обвинить меня в недостатках проектирования и изучения данных, спасло меня только то, что все было зафиксировано в письме.
  4. И это тот самый поинт из начала поста, им реально все равно, что будет после завершения проекта, продакшен - уже не их зона ответственности, сколько раз я это слышал - нам главное сдать, а там посмотрим, найдут - доделаем, или на проекте развития. Что это не решает проблем пользователей и заказчика в целом было все равно.

Я прекрасно понимаю, что далеко не все проджект менеджеры такие, но большая часть людей, работают на отвали и это печально.

Дискуссия

Oreo
Может, у тебя просто проджекта нормального не был (с) ?) Но если серьезно, то я похожие проблемы замечал, но у меня пока от продуктового и проектного подхода впечатления на равных
Matvey
Могут ли отдельные индивиды ставить под сомнение профессию? Знаю одну небольшую компанию (из серии один мой друг), где крупные проекты без проджекта просто не взлетят. Допускаю, что дело может быть в сильном разрыве между продактами и техлидами. Или что нет нормально внедренного Фреймворка взаимодействия команд. Но так или иначе вижу, как проджект направляет разносторонние ручейки в одно русло. Не впадая в описанные тобой крайности
PRO анализ в ИТ
Matvey
Могут ли отдельные индивиды ставить под сомнение профессию? Знаю одну небольшую компанию (из серии один мой друг), где крупные проекты без проджекта просто не взлетят. Допускаю, что дело может быть в сильном разрыве между продактами и техлидами. Или что…
Возможно, я потому и написал именно про свой опыт, но все же это не отменяет последнего тезиса, что после передачи в продакшн проджект перестает заниматься продуктом, потому что проект окончен
PRO анализ в ИТ
Раздражает именно негибкость проджектов и нежелание идти на изменения
Boris Ishkin
PRO анализ в ИТ
Возможно, я потому и написал именно про свой опыт, но все же это не отменяет последнего тезиса, что после передачи в продакшн проджект перестает заниматься продуктом, потому что проект окончен
Если проджект перестает заниматься продуктом по окончании проекта - это же вполне нормальная ситуация. Было бы странно, если было бы наоборот. (Хотя это "странно" и было в моей личной жизни, когда я после реализации проекта перешел по факту на позицию менеджера продукта.) Вопрос в том, 1) какой скоуп заложен в проект, 2) понимает ли заказчик (объяснили ли ему), что продукт по окончании проекта должен будет модифицироваться, а не останется as is, 3) как заказчик решил с этим жить (у него есть собственный продакт, собственная поддержка или договор на поддержку или еще что-то). И еще - мы же обсуждаем абстрактные роли. Но мы же понимаем, что на практике все сложнее и связано с целым рядом факторов, от корпоративной культуры и уровня кристаллизации ролей в компании до реалий конкретного проекта и взаимоотношений стейкхолдеров.
PRO анализ в ИТ
Boris Ishkin
Без обид, похоже больше на частные эпизоды, из которых сделан тотальный вывод типа "все мужики козлы")) Я вот не такой, trust me dude)) Где-то сейчас в каналах этих проджектов наверняка обсуждают зеркальные посты про отвратительных и бесполезных продакт-менеджеров...…
А я же не говорю, что все такие, но в моей практике таких было большинство, причем вне зависимости от организации.
Присоединиться к обсуждению →

Читайте так же