Information
- Rating
- Does not participate
- Location
- Белград, Белград, Сербия
- Date of birth
- Registered
- Activity
Specialization
Program Manager, Business Analyst
Senior
Project management
Strategic planning
Negotiation
Building a team
Agile
Optimization of business processes
Scrum
PMBOK
Waterfall
Change management
И Вам спасибо за дискуссию. Я бы хотела поставить лайк, но эта публикация настолько не понравилась всем, что я осталась без возможности оценивания :).
Да, это действительно два разных подхода. Я сама выросла в менеджера из геофизика и геолога. В этом подходе было много плюсов, но и минусы были.
На практике встречала менеджеров из обеих групп. И одни, и вторые встречались как хорошие, так и плохие.
для меня продакт-менеджер это не надзиратель за проектом и командой. Это полноправный участник проекта
специалиста из Вашего примера я бы отнесла больше к экспертам, чем к менеджерам. Так как пока он погружался в самые глубокие нюансы процессов и осваивал новые инструменты, он вряд ли выполнял задачи менеджера. И потому что конкретно его будет ценнее всегда держать в одном направлении деятельности, в то время, как управленцы могут менять проекты.
Но! мне очень нравится, когда менеджеры вырастают из производственных процессов. И, если говорить про опыт, мне кажется, для менеджера гораздо ценнее иметь техническое/математическое образование и опыт и логическое мышление по сравнению с управленческим образованием.
Специалист не должен это рассказывать на постоянной основе. Ни в коем случае. Я говорила про проблемные ситуации, когда имеет смысл привлечь к решению менеджера.
Менеджеры ведь тоже часто ошибаются, например, ставят невыполнимые задачи в короткий срок. И такие обсуждения могут менеджеру понять почему надо быть менее оптимистичным в планах, а так же как обоснованно рассказать об изменении сроков вышестоящему руководству.
к сожалению, выгорание зависит не только от внешних рабочих обстоятельств, но и от возраста/опыта. Я честно скучаю по тем временам, когда каждая сложная задача или очередная оптимизация казалась интересной на старте карьеры. Как себя сейчас развеселить и замотивировать на работе - пока не поняла. Но вижу, что подавляющее большинство коллег и друзей за 35+ сталкивается с одинаковыми мыслями и выгоранием.
Мне кажется, посыл в статье правильный - даже в рабочей рутине найти для себя "красивое". Да, работа это просто работа, за которую платят деньги. Но лучше, когда тебе платят за то, что тебе нравится, чем за то, что тебе не нравится.
это отличные примеры как делать не надо))
у меня были разные руководители: и те, кому надо было доказывать каждое действие и раз в квартал обосновывать необходимость развития наших давно внедренных цифровых решений (то есть буквально обосновывать деятельность отдела), и те, кто доверял моей работе, но при моем или его желании я погружала в проблемы и оперативку по проектам.
Мне, конечно, ближе второй вариант. Такой подход использую и для своих проектов и команд.
Судя по количеству минусов, я не совсем понятно доношу мысль :) Я точно не за микроменеджмент и контроль каждого разработчика.
Да, спасибо, что правильно заметили. Я объединила проектное и продуктовое управление в одну роль
Или детализация задач - большую непонятную разбиваем на маленькие понятные
Или вместе выясняем что непонятно, то есть уточняем детали
Или меняем задачу, если она реально невыполнима в таком объеме и/или сроках
И обязательно в будущем учитываем этот опыт и закладываем больше времени на реализацию
менеджер не должен мешать там, где все работает. Если появляются отклонения - идет медленно разработка (медленнее, чем запланировали вместе) или задерживается поставка релиза, он может вмешаться с целью помочь.
Например, у меня были случаи, когда разработчики регулярно не выполняли задачи в срок. Начали разбираться, и оказалось, что часть задач просто непонятна, нужно детализировать, часть задач нельзя сделать быстро, так как "код говно", хочется переписать, или разработчики работают больше чем на 1 FTE и тупо перегружены. С каждой из этих проблем надо работать по-разному.
Лично я иногда прошу погрузить в детали, объяснить почему "код говно" и зачем надо рефакторинг делать прям сейчас, или почему нельзя сделать вот такой график, а можно другой. Потому что и самой интересно, и для планирования следующих задач пригодится.
В целом, каждая роль должна делать свои задачи и нести ответственность за них. В идеальном мире продакт-менеджер должен базировать все свои решения на экспертизе и решениях ответственных сотрудников по направлениям. Но у меня бывало и так, что ответственность никто не хочел брать, и приходилось мне.
Но я с Вами согласна, что у менеджеров соблазн к мании величия и "помощи" разработчиком гораздо больше, чем наоборот)). Попробуй разработчика попросить сделать презу для стэйкхолдеров - им это вообще не надо, что очень правильно.
естественно, имеется в виду продакт-менеджер. Можно назвать эту позицию по-разному, я видела: руководитель проектов, проектный менеджер, руководитель направления, владелец продукта, просто менеджер и тд. В российских компаниях очень много вариаций. Формулировки вторичны, смысл первичен, и Вы его прекрасно понимаете.
в теории, можно добавить много профессий (да и вообще любую профессию) по схожести частичных функций. И хоть я и понимаю, что это немного сарказм, но прокомментирую конкретные перечисления.
Для меня продакт-менеджер, это роль на стыке управления проектом (у проекта есть начало и конец), управления людьми (продакт-менеджер не создает результат, который "можно пощупать", он создает наилучшие условия для создания результата), взаимодействием с заказчиком и формированием стратегии решения проблем/задач заказчика. Это если очень упрощать.
Перечисленные Вами профессии мне не кажутся на 100% подходящими, так как:
как правило, они работают в одиночку для реализации своей задачи
они создают повторяющийся сервис, а не завершенный продукт
часто действуют по строгим правилам или стандартным процедурам, а не тестируют гипотезы или адаптируются под неожиданные задачи
некоторые из профессий базируются только на теоретических трудах, в то время как продакт должен выдавать конкретные результаты
Хотя, конечно, можно найти общее: врач - аналитика и принятие решений, политик - красиво говорит и "продает" идеи, полицейский - следит за соблюдением правил
согласна))) Если Вы потратите это Время на статью, и она Вам понравится, буду рада :).
я сначала верила в КПЭ, потом наступил период, когда думала, что это формальность, но важная, так как влияет на бонус. Недавно ощутила на себе зачем они нужны. Мы начали ставить цели, которые реально важны для компании, и еще очень четко следили за качеством целей. Например, если раньше в амцель писали что-то достижимое, то сейчас начали писать цель, к достижению которой надо приложить сверхусилия. Затем на меня навалилась текучка, и я благополучно погрязла в операционке. Примерно через квартал я посмотрела на годовые КПЭ и поняла, что по нескольким из них почти ничего не делала, скорректировала свою работу на оставшееся время, отложила часть неключевых проектов и, в итоге, почти все КПЭ закрыла, а это, повторюсь, было важно для компании. Звучит немного по-джуниорски, но я уже не раз убеждаюсь в том, что даже имея многолетний опыт, мы иногда можем забывать привычные вещи, и переоткрывать их заново. В общем, итог, что система КПЭ это классная вещь, если все ее понимают одинаково, следуют ей, и она реально на что-то влияет
я очень любила все систематизировать и использовать понятные фрэймворки для разных типов проектов, нравится "причесывать" проекты под одну структуру. И в начале карьеры продакта как же было тяжело понять, что не к каждому проекту нужно применять все полезные действия. Как говорится, "не нужно натягивать ежа на глобус". Например, я люблю структурированный бэклог с тегами и классификацией эпиков - так проще смотреть аналитику и какие конкретно части бизнес-процесса мы описали более детально, какие нет. Этот анализ часто возвращает нас обратно к реформированию бэклога, так как мы видим смещения, да и много других плюсов. Но у меня есть проекты, которые я только запускаю внутри компании, а дальше реализацией не занимаюсь. И по таким проектам часто просят описания функциональности просто текстом. И как бы я не убеждала и не показывала красоту системной аналитики, сотрудникам хочется другой формат. Но я придумала, как соблюсти компромис. У меня есть набор шагов и практик для стандартного проекта, и теперь использую я их только по необходимости, если это реально нужно проекту или сотрудникам. Так что получается, использую ситуативный подход.
Но в своих любимых проектах все-таки стараюсь делать все более системно :)
я из менеджеров и точно могу сказать, что программировать вообще необязательно. Но очень важно иметь желание разобраться в проблеме и понять, например, почему разработчик не может сделать простую фичу, зачем в очередной раз нужен рефакторинг кода, почему тестировщик не находит ошибки в данных, зачем дизайнер хочет переставить кнопки местами... и так далее. То есть ключевое для менеджера - это двигать проект и решать проблемы на стыке разных специалистов или разбираться где системные отклонения. И для этого необязательно писать код. Кстати, разработчики с удовольствием обычно рассказывают и даже показывают почему надо делать оптимизацию кода, и так можно узнавать новое.
То, что в компании предложили всех маркировать с последующей оптимизацией - это, конечно, тревожный звоночек. Но иногда иксельки так и остаются иксельками без последствий :)
Я Вас очень поддерживаю как лидера изменений и нового. Но сама работала в ситуации, когда трансформация и что-то новое сначала случаласт раз в два года, а затем накатывала каждый год. И в итоге подавляющее число сотрудников настолько устали от нововведений, что просто говорили: пожалуйста, дайте спокойно поработать. И оказывали мощнейшее сопротивление на все новое. Я сама не осознала, как перешла на сторону сопротивления)))
С другой стороны, сейчас я на другой работе, где мне нужно менять процессы, и почти никто этого не хочет, сколько ни объясняй. И тебе и руководству они скажут, что согласны и все супер, а потом пойдет на раочие места и будут игнорировать тебя до последнего. А уволить/поменять никого нельзя. Вот и приходилось сражаться с сопротивлением. Но сейчас я приняла это как часть моей работы, и что вряд ли я в каждый проект найду инициативных людей, и как-то становится легче. Даже в дорожные карты проектов закладываю сроки сопротивление или, назовем это, коммуникацию ))))
Да, конечно. Но опять таки, команды изобрели в своем роде новый велосипед. Например, мы рисовали критический путь проблемных проектов и тиражировали это на остальные. Или еще пример, на совещаниях загружали материал по всему проекту, и помечали их зеленым цветом, то есть просто для чтения, материалы и вопросы, которые касались управленческих развилок, помечали оранжевым. И на встрече модератор следил за тем, чтобы не обсуждалось зеленое. Так как ранее все зеленое уже было согласовано, но на встречах с большим количеством участников все хотели высказаться и часто возвращались к уже пройденному. Получился такой интересный инструмент модерации иныестиционных комитетов с топ-менеджерами - очень полезно
Отличная статья и интересные мысли! По поводу внедрения правил наблюдала интересные ситуации. Например, про упомянутое управление рисками. Когда внедряли их в компании, то понимали значимость, и это работало - на основе них корретировались сроки, собирались мини0рабочие группы по предотвращению риска и тд. В последствии это стало просто очередным шаблоном, который заполнялся "на отвали", где риски копипастились из проекта в проект. То есть изначально хорошая системность потеряла актуальность и перестала работать, а даже начала напрягать. Ну ок, оставили их как формальный документ. Но в процессе реализации проектов возникали проблемы, сотрудники неожиданным образом выявляли, что можно было проблемы предостеречь, собирались "поштурмить", создавали реестр возможных проблем, и очень радовались своей находчивости. А когда показываешь им, что вообще-то это устория про управления рисками, и вообще-то уже давно внедренная в компании, начинали говорить "это другое". И такое случается очень часто в больших корпорациях. Как итог, для своих команд поняла, что вообще-то дурацкие шаблоны часто не дурацкие, а полезные, и регламентные процедуры вообще-то не для формальности, а реально помогают улучшить проект. Так что очень правильный совет даете - посмотреть, что есть в компании, посмотреть на лучшие практики, и внедрить, если это новое и необходимое (а если это старое, то можно сделать реинжиниринг :))