Привет! Спасибо за замечание - я не успел поправить комментарий, что продакт менеджер про ПРОДУКТ. Хабр не дал это сделать..
В обсуждении в моем канале уже успели этот момент разобрать. Я человек ленивый, поэтому сделаю копипаст комментария Сергея Елизарова - ценнейшего человека в нашем коммьюнити:
"напишу критику сюда: продакт это не про команду, продакт это про продукт — у него объект управления это продукт)
ему не надо думать о команде, ему надо думать о ценности продукта и достигает он ее или нет) и если нет — как ее достигать. а это сложная работа, и если совместить обе роли, то будет страдать одна из шапочек
про команду — это people manager, им может быть как продакт (что, на самом деле, по мне порочная практика, не видел хороших реализаций), но чаще — это тимлид/любой другой пипл менеджер. часто видел, что это ложится на проджекта (точнее, называют проджектом пипл менеджера)"
И также поделюсь мнением Сергея касательно идеальной комбинации команды. Я данный сетап поддерживаю и с удовольствием в таком бы поработал:
"самую идеальную комбинацию я видел, которая хорошо работает :
1. есть и проджект, который умеет головой отвечать за деньги, бюджетирование и использование ресурсов помимо разработки + вести переговоры + координировать кросс-функциональную команду
2. есть продакт по долгу службы (если это проекты поверх продукт) — он умеет вычленить, что нужно и как нужно, в каком приоритете и вляет на цели проекта так, чтобы это принесло пользу продукту в рамках стратегии
3. есть технический менеджер — он же пипл менеджер. он агрегирует кадровые риски, готовит команду и "спонсирует" людьми проект + отвечает за их кусок работы, организует процесс доставки ценности
4. ну и есть команда разработки с аналитиком, где аналитик уже вторичную валидацию проводит и доуточняет решение
из п.4 так-то можно вычленить аналитика, если у продакта достаточно ресурса, продакт лучше может описать что нужно, т.к. имеет больше контекста)"
Расскажи пожалуйста, а было ли в таком сетапе у вас проблемы отсутствия подробной документации? Либо разработчики/тестировщик составлением проектной документации занимались? Были ли задачи, когда нужно было доработать сервис, который последний раз версионировали год назад? Как разбирались с этим? А если кто-то из команды ушел из команды - как бы опыт перенимали?
Вопросы без претензий и подколов если что, мне просто интересен опыт твой.
Вот про shadow-проекты - снова с тобой согласен! Ибо в Сбере я такой продукт класса Office Productivity и легализовывал целый год (!). И это та еще история, которую публично рассказывать больно и стыдно.
А про совмещение ролей - перечитайте пожалуйста еще раз цель статьи. Да, свое мнение (основанное на моем опыте и моих проектах) в статье дал. На истину оно не претендует и я его (мнение) не продаю. Оно просто имеет право на сущестование.
Главная цель статьи: дать возможность подумать и подискутировать на тему совмещения ролей. И поделиться своим опытом и мнением. Что вы и другие комментаторы сделали и делают.
Капитан, полностью взаимно благодарен за комментарий! Попали просто в яблочко про то, что я хотел донести :)
И второе попадание туда же: в Сбере у меня действительно "команда" состояла из меня, разработчика и двух экспертов со стороны - архитектора и ux-дизайнера. Соответственно и стейкхолдеры были лояльные (и пассивные): видели мое видение, верили мне и не были против моей активности.
В Альфе же я был "играющим тренером" - тимлид-аналитиком. Команда была уже побольше, но менеджерские задачи что по проекту, что по команде, что по процессам никуда не делись))
P.S. Я веду ТГ-канал, где пишу статьи и путевые заметки для аналитиков и тимлидов - буду рад, если примешь приглашение присоединиться! Всегда рад "насмотренным" и бодрым людям в сообществе)
Ну во-первых, я не могу сказать, что опыт у меня был неудачный. В рамках своего плана развития внутри компании я очень хотел стать продактом. И реализуя этот проект я увидел возможность им стать через транзишн аналитик->менеджер проекта->менеджер продукта. Более того, мне даже прямо сказали про это. Но, увы, из Сбера я ушел по причинам, не связанным с работой, но с личной безопасностью.
Про анализ рынка - часто бывает такое, что этим занимается бизнес-аналитик, особенно на западе. Также этим могут заниматься и продуктовые аналитики. Ну и продакт менеджеры. И обратите внимание, я специально написал ВТОРИЧНЫЕ исследования.
Про фреймворк - когда команду подбираешь под проект, то ты как проджект должно определить, по какому фреймворку она должна работать, чтобы успешно закрыть проект. Про тех стек речи нет - естественно, это вне компетенций проджекта
Про коммуникации - я еще раз обращу внимание, что проджект менеджер - он про ПРОЕКТ. Продакт менеджер про КОМАНДУ. То, что вы упомянули скрам-мастер, это определенная РОЛЬ в КОМАНДЕ, которая работает по фреймворку Scrum. А мы говорим про проектную деятельность, в которую зачастую вовлечены несколько команд. Скрам-мастера в этом случае некорректно приплетать.
А про мнение касательно совмещения ролей - большое спасибо, что поделились!
Спасибо за комментарий. Касательно кейса - да, совершенно верно, это тот кейс. Только фишка в том, что коллега обратилась сначала ко мне, а потом уже в ваш чат :) ну или это было сделано параллельно. И ответил я в личке первым.
Просто в какой-то момент я понял, что тема будет интересна всем подписчикам, поэтому выложил статью на своем канале. И в том числе тут на Хабре.
Статья моя уже разошлась по многим каналам по системному анализу в ТГ.
В встрече вашего клуба я не участвовал, хотя очень хотелось. И вы об этом знаете.
Использование ментальной карты с Димой я согласовал. Так что пытаться уличить меня в чем-то не нужно. И карта отлично отражает суть проблемы KPI в моем понимании.
К слову, очень жду запись встречи. Все еще интересно послушать мнения коллег!
Опыт грустный у тебя… но скажу так, что твои прокаченная насмотренность и навыки ни в какую мусорку никогда слиты не будут.
Ибо работодатель у тебя в твоей жизни будет далеко не первый, а вот жизнь - она целиком и полностью твоя.
Мне отец всегда говорил, что никогда не знаешь, когда и в какой ситуации твой навык пригодится. Вот я помнится создал свой первый канал (как благотворительный проект) в 2020, параллельно работа я в Альфе.
Тогда я вообще не предполагал, что в 2023 уволюсь из найма и смогу себе достойно на хлеб зарабатывать на канале уже личного бренда.
Так что если работодатель навыки твои обесценивает - бросай его нахрен, ищи того, кто тебя реально будет ценить. Или покажи свою ценность публично :)
Никто из нас не проектирует фейсбуки на лету, но я этого и не прошу сделать на собеседовании :)
Мне важно оценить, как человек размышляет и работает, а не что он зазубрил. Повторюсь, что мои методы отрабатывают и приносят вэлью командам в виде классных ребят пока на 100% (тьфу-тьфу-тьфу).
Мне очень понравился твой вопрос, и я более подробно на него отвечу у себя в канале.
Если вкратце - да, работодатель всегда будет давать предпочтение кандидату с опытом в айти, нежели без опыта. Это вполне логично. Но дальше идут куча факторов и детальный разбор профиля кандидата, в ходе которого рекрутер принимает решение, звать ли его на собеседование или нет. Вот про них я в воскресенье пост напишу.
А насчет стоит ли выбирать СА как стартовую профессию? Мой ответ, да, стоит, главное чтобы была внутренняя искра и желание учиться и погружаться в технику. Ибо даже в анализе есть достаточно хард скиллов, которые необходимо освоить.
Да, возможно я не до конца довел мысль про то, что все рассмотренные примеры «плохих» и «хороших» аналитиков - это сугубо субъективная оценка работодателя-собеседующего. Некие уайт и редфлаги, и я их попытался обобщить. Дело это конечно неблагодарное, потому что ситуаций куча разных (которую ты в общем-то и описал по тексту).
В первом твоем кейсе вопрос критично стоит в том, что аналитик твой как будто независимая единица, которая сама себе задачи ставит и живет в отрыве от команды. Это мое впечатление такое) Для этого и должно быть руководитель, который такую единицу возьмет и определит фокус на том, что делать «надо», а не то, что она «любит».
Во втором про хладнокровного - отчасти соглашусь. Если это джун. В миддлах+ бывает этой «искры» не хватает, дабы быть фасилитатором встреч тех же. Хотя при желании вполне такие хладнокровные могут на место любого уверенного поставить, вспоминаю сразу безопасников в сбере))
Да, каждая система класса начиная от Business Critical (как в примере) предполагает выделение отдельного архитектора. Тут совмещение ролей недопустимо.
Вот, теперь с вашим поинтом согласен. А то первый комментарий был весьма категоричным.
Когда приводил пример с архитектурой в статье - я всего лишь хотел отметить, что желание разобраться в чем-то новым ни в кое случае не будет порицаться, а только наоборот.
Но дальше идут ограничения ресурсные. Никакой менеджер тебе не пообещает уволить текущего архитектора просто потому что ты можешь его заменить :)
Моя позиция: архитектор, аналитик и прочее - это в первую очередь роль, а не профессия. Соответственно кто на уровне C1 и C2 всё придумал, тот и будет архитектором. После этого ты как архитектор можешь курировать развитие данного модуля, при этом если задачи в этом нет - к разработке C3 и С4 тебе и вовлекаться не нужно. У тебя могут быть свои задачи на проработку аналитики, например.
Верно мыслишь, но увы, бывает даже на собеседовани про легаси-бардак на проекте тебе не расскажут :) Только когда сам проект курить начнёшь. И да, про этот нюанс в описании вакансии тем более никто не укажет
Очень достойно расписал то, о чем я в целом хотел коснуться и разобрать дальше. Прям спойлер словил))
Касательно собеседований, тут на самом деле чисто на неком эмоциональном интеллекте нужно пытаться кандидата проанализировать. И желательно звать на собес еще кого-нибудь для более полной оценки. Я бывает провожу для аналитиков отдельный собес-знакомство с командой, чтобы ребята пообщались-позадавали друг другу вопросы.
Ибо если аналитик в коллектив не вливается - на уровне тимлида направления приходится потом некоторые конфликты разруливать. А это время, концентрация и деньги.
Огромное спасибо за историю! Меня прям передернуло от флешбеков)
Оформил ваши комментарии как пост в своем канале, в теле поста сослался на ваш профиль - https://t.me/godnolytika/143
Привет! Спасибо за замечание - я не успел поправить комментарий, что продакт менеджер про ПРОДУКТ. Хабр не дал это сделать..
В обсуждении в моем канале уже успели этот момент разобрать.
Я человек ленивый, поэтому сделаю копипаст комментария Сергея Елизарова - ценнейшего человека в нашем коммьюнити:
"напишу критику сюда: продакт это не про команду, продакт это про продукт — у него объект управления это продукт)
ему не надо думать о команде, ему надо думать о ценности продукта и достигает он ее или нет) и если нет — как ее достигать. а это сложная работа, и если совместить обе роли, то будет страдать одна из шапочек
про команду — это people manager, им может быть как продакт (что, на самом деле, по мне порочная практика, не видел хороших реализаций), но чаще — это тимлид/любой другой пипл менеджер. часто видел, что это ложится на проджекта (точнее, называют проджектом пипл менеджера)"
И также поделюсь мнением Сергея касательно идеальной комбинации команды.
Я данный сетап поддерживаю и с удовольствием в таком бы поработал:
"самую идеальную комбинацию я видел, которая хорошо работает :
1. есть и проджект, который умеет головой отвечать за деньги, бюджетирование и использование ресурсов помимо разработки + вести переговоры + координировать кросс-функциональную команду
2. есть продакт по долгу службы (если это проекты поверх продукт) — он умеет вычленить, что нужно и как нужно, в каком приоритете и вляет на цели проекта так, чтобы это принесло пользу продукту в рамках стратегии
3. есть технический менеджер — он же пипл менеджер. он агрегирует кадровые риски, готовит команду и "спонсирует" людьми проект + отвечает за их кусок работы, организует процесс доставки ценности
4. ну и есть команда разработки с аналитиком, где аналитик уже вторичную валидацию проводит и доуточняет решение
из п.4 так-то можно вычленить аналитика, если у продакта достаточно ресурса, продакт лучше может описать что нужно, т.к. имеет больше контекста)"
Привет!
Расскажи пожалуйста, а было ли в таком сетапе у вас проблемы отсутствия подробной документации?
Либо разработчики/тестировщик составлением проектной документации занимались?
Были ли задачи, когда нужно было доработать сервис, который последний раз версионировали год назад? Как разбирались с этим?
А если кто-то из команды ушел из команды - как бы опыт перенимали?
Вопросы без претензий и подколов если что, мне просто интересен опыт твой.
Вот про shadow-проекты - снова с тобой согласен! Ибо в Сбере я такой продукт класса Office Productivity и легализовывал целый год (!). И это та еще история, которую публично рассказывать больно и стыдно.
А про совмещение ролей - перечитайте пожалуйста еще раз цель статьи. Да, свое мнение (основанное на моем опыте и моих проектах) в статье дал. На истину оно не претендует и я его (мнение) не продаю. Оно просто имеет право на сущестование.
Главная цель статьи: дать возможность подумать и подискутировать на тему совмещения ролей. И поделиться своим опытом и мнением. Что вы и другие комментаторы сделали и делают.
За это каждому спасибо!
Капитан, полностью взаимно благодарен за комментарий!
Попали просто в яблочко про то, что я хотел донести :)
И второе попадание туда же: в Сбере у меня действительно "команда" состояла из меня, разработчика и двух экспертов со стороны - архитектора и ux-дизайнера. Соответственно и стейкхолдеры были лояльные (и пассивные): видели мое видение, верили мне и не были против моей активности.
В Альфе же я был "играющим тренером" - тимлид-аналитиком. Команда была уже побольше, но менеджерские задачи что по проекту, что по команде, что по процессам никуда не делись))
P.S. Я веду ТГ-канал, где пишу статьи и путевые заметки для аналитиков и тимлидов - буду рад, если примешь приглашение присоединиться! Всегда рад "насмотренным" и бодрым людям в сообществе)
https://t.me/godnolytika
Добрый день!
Ну во-первых, я не могу сказать, что опыт у меня был неудачный. В рамках своего плана развития внутри компании я очень хотел стать продактом. И реализуя этот проект я увидел возможность им стать через транзишн аналитик->менеджер проекта->менеджер продукта. Более того, мне даже прямо сказали про это. Но, увы, из Сбера я ушел по причинам, не связанным с работой, но с личной безопасностью.
Про анализ рынка - часто бывает такое, что этим занимается бизнес-аналитик, особенно на западе. Также этим могут заниматься и продуктовые аналитики. Ну и продакт менеджеры. И обратите внимание, я специально написал ВТОРИЧНЫЕ исследования.
Про фреймворк - когда команду подбираешь под проект, то ты как проджект должно определить, по какому фреймворку она должна работать, чтобы успешно закрыть проект. Про тех стек речи нет - естественно, это вне компетенций проджекта
Про коммуникации - я еще раз обращу внимание, что проджект менеджер - он про ПРОЕКТ. Продакт менеджер про КОМАНДУ. То, что вы упомянули скрам-мастер, это определенная РОЛЬ в КОМАНДЕ, которая работает по фреймворку Scrum. А мы говорим про проектную деятельность, в которую зачастую вовлечены несколько команд. Скрам-мастера в этом случае некорректно приплетать.
А про мнение касательно совмещения ролей - большое спасибо, что поделились!
Добрый день!
Да, но я же начал статью не только с обязанностей, но и как раз с ответственности. Что для меня лично одно и то же почти
Про совмещение на небольших проектах - все так, про это тоже пишу
Спасибо за мнение!
Игорь, привет!
Спасибо за комментарий. Касательно кейса - да, совершенно верно, это тот кейс. Только фишка в том, что коллега обратилась сначала ко мне, а потом уже в ваш чат :) ну или это было сделано параллельно. И ответил я в личке первым.
Просто в какой-то момент я понял, что тема будет интересна всем подписчикам, поэтому выложил статью на своем канале. И в том числе тут на Хабре.
Статья моя уже разошлась по многим каналам по системному анализу в ТГ.
В встрече вашего клуба я не участвовал, хотя очень хотелось. И вы об этом знаете.
Использование ментальной карты с Димой я согласовал. Так что пытаться уличить меня в чем-то не нужно. И карта отлично отражает суть проблемы KPI в моем понимании.
К слову, очень жду запись встречи. Все еще интересно послушать мнения коллег!
Привет!
Опыт грустный у тебя… но скажу так, что твои прокаченная насмотренность и навыки ни в какую мусорку никогда слиты не будут.
Ибо работодатель у тебя в твоей жизни будет далеко не первый, а вот жизнь - она целиком и полностью твоя.
Мне отец всегда говорил, что никогда не знаешь, когда и в какой ситуации твой навык пригодится. Вот я помнится создал свой первый канал (как благотворительный проект) в 2020, параллельно работа я в Альфе.
Тогда я вообще не предполагал, что в 2023 уволюсь из найма и смогу себе достойно на хлеб зарабатывать на канале уже личного бренда.
Так что если работодатель навыки твои обесценивает - бросай его нахрен, ищи того, кто тебя реально будет ценить. Или покажи свою ценность публично :)
Добрый день!
Большое спасибо, рад был быть полезным :)
Коллега на проекте из кейса выполняла роль именно БА. И отталкивался я от метрик, которые именно к KPI БА можно привязать.
Скажите, почему именно такое впечатление сложилось у вас после прочтения статьи?
Добрый день!
Да, такое бывает. И я считаю это нормальным.
Я в двух компаниях совмещал данные роли. Позиция называлась аналитик. Я про это много на канале рассуждал. Почитайте вот этот пост.
Добрый день!
Никто из нас не проектирует фейсбуки на лету, но я этого и не прошу сделать на собеседовании :)
Мне важно оценить, как человек размышляет и работает, а не что он зазубрил. Повторюсь, что мои методы отрабатывают и приносят вэлью командам в виде классных ребят пока на 100% (тьфу-тьфу-тьфу).
Добрый день!
Мне очень понравился твой вопрос, и я более подробно на него отвечу у себя в канале.
Если вкратце - да, работодатель всегда будет давать предпочтение кандидату с опытом в айти, нежели без опыта. Это вполне логично. Но дальше идут куча факторов и детальный разбор профиля кандидата, в ходе которого рекрутер принимает решение, звать ли его на собеседование или нет. Вот про них я в воскресенье пост напишу.
А насчет стоит ли выбирать СА как стартовую профессию? Мой ответ, да, стоит, главное чтобы была внутренняя искра и желание учиться и погружаться в технику. Ибо даже в анализе есть достаточно хард скиллов, которые необходимо освоить.
Сергей, привет! Рад тебя снова видеть тут)
Да, возможно я не до конца довел мысль про то, что все рассмотренные примеры «плохих» и «хороших» аналитиков - это сугубо субъективная оценка работодателя-собеседующего. Некие уайт и редфлаги, и я их попытался обобщить. Дело это конечно неблагодарное, потому что ситуаций куча разных (которую ты в общем-то и описал по тексту).
В первом твоем кейсе вопрос критично стоит в том, что аналитик твой как будто независимая единица, которая сама себе задачи ставит и живет в отрыве от команды. Это мое впечатление такое) Для этого и должно быть руководитель, который такую единицу возьмет и определит фокус на том, что делать «надо», а не то, что она «любит».
Во втором про хладнокровного - отчасти соглашусь. Если это джун. В миддлах+ бывает этой «искры» не хватает, дабы быть фасилитатором встреч тех же. Хотя при желании вполне такие хладнокровные могут на место любого уверенного поставить, вспоминаю сразу безопасников в сбере))
Добрый день!
Да, каждая система класса начиная от Business Critical (как в примере) предполагает выделение отдельного архитектора. Тут совмещение ролей недопустимо.
Вот, теперь с вашим поинтом согласен. А то первый комментарий был весьма категоричным.
Когда приводил пример с архитектурой в статье - я всего лишь хотел отметить, что желание разобраться в чем-то новым ни в кое случае не будет порицаться, а только наоборот.
Но дальше идут ограничения ресурсные. Никакой менеджер тебе не пообещает уволить текущего архитектора просто потому что ты можешь его заменить :)
Добрый день!
Это уровни модели C4 для визуализации архитектуры приложения, вот здесь можно почитать https://c4model.com
Или в статье-переводе: https://infostart.ru/1c/articles/1540208/
Добрый день!
Объясните свою позицию, пожалуйста.
Моя позиция: архитектор, аналитик и прочее - это в первую очередь роль, а не профессия.
Соответственно кто на уровне C1 и C2 всё придумал, тот и будет архитектором.
После этого ты как архитектор можешь курировать развитие данного модуля, при этом если задачи в этом нет - к разработке C3 и С4 тебе и вовлекаться не нужно.
У тебя могут быть свои задачи на проработку аналитики, например.
Привет!
Верно мыслишь, но увы, бывает даже на собеседовани про легаси-бардак на проекте тебе не расскажут :) Только когда сам проект курить начнёшь. И да, про этот нюанс в описании вакансии тем более никто не укажет
Добрый день!
Очень достойно расписал то, о чем я в целом хотел коснуться и разобрать дальше. Прям спойлер словил))
Касательно собеседований, тут на самом деле чисто на неком эмоциональном интеллекте нужно пытаться кандидата проанализировать. И желательно звать на собес еще кого-нибудь для более полной оценки. Я бывает провожу для аналитиков отдельный собес-знакомство с командой, чтобы ребята пообщались-позадавали друг другу вопросы.
Ибо если аналитик в коллектив не вливается - на уровне тимлида направления приходится потом некоторые конфликты разруливать. А это время, концентрация и деньги.