Comments 23
Давай начнем с ответственности
ПМ отвечает за выполнение проекта в целом. С него главный спрос. За все :)
Аналитик - за функциональные требования. Т.е. скоуп в части функциональных требований, и их трансляцию во все стороны: продакт, разрабы, тестеры.
Почему-то все сразу начинаю писать про обязанности и т.д., игнорируя базу
Совмещать на небольших проектах - отличная и частая практика.
Вы судя по всему, уже выросли до этого уровня
Добрый день!
Да, но я же начал статью не только с обязанностей, но и как раз с ответственности. Что для меня лично одно и то же почти
Про совмещение на небольших проектах - все так, про это тоже пишу
Спасибо за мнение!
У вас добавлены обязаности продукта. Это характерно для очень маленьких проектов.
Это не обязаности аналитика. Продукт - человек спонсора, которые отвечает за успех продукта, в том числе, и после внедрения.
Просто не имеет смысла ставить вопрос о совмещении роли аналитика и проджекта, когда в реальности у вас все.
У меня было такое на разработке внутреннего демо продукта на 3 спринта. Тогда аналитик действительно совмещает все это, а я помогаю решать технические вопросы + закрываю технические outcomes демо продукта. Но для коммерческого продута - сорчн за прямоту, это либо маленький проект, либо такой стиль организации.
Я когда то работал в большом банке, у них в бизнес вертикали были свои shadow-проекты и shadow ИТ. Они чего то там пилили, иногда даже что-то большое, когда был "придворный" поставщик. Даже часто приходилось с ним интегрироваться в официальных проектах. Хотя момент передачи в поддержку таких "франкенштейнов" вызывал вопросы. Самое забавное, когда такому бизнес "решале" выдавался акт, который надо подписать (а значит и все сделать), чтобы передать систему на поддержку. И тут наступала лютая боль и паника, как у кота, которого застукали на семейном столе за поеданием хозяйской еды. Доки нет, решение и близко не натянуто в отказоустойчивый конфиг, стек под капотом никому не интересен для поддержки, так как спецов нет ...
Поэтому shadow оставалось часто в таком полулегальном положении :) И нам удобно - есть быстрые бойцы, которых можно поймать и применить бесплатно, бизнес двигается и вроде как ИТ-бюджет, кроме затрат на железо, не напрягается
Вот про shadow-проекты - снова с тобой согласен! Ибо в Сбере я такой продукт класса Office Productivity и легализовывал целый год (!). И это та еще история, которую публично рассказывать больно и стыдно.
А про совмещение ролей - перечитайте пожалуйста еще раз цель статьи. Да, свое мнение (основанное на моем опыте и моих проектах) в статье дал. На истину оно не претендует и я его (мнение) не продаю. Оно просто имеет право на сущестование.
Главная цель статьи: дать возможность подумать и подискутировать на тему совмещения ролей. И поделиться своим опытом и мнением. Что вы и другие комментаторы сделали и делают.
За это каждому спасибо!
Shadow проекты и решения - классический отложенный долг. Ура, quick win, вышли на рынок - все верно. Бизнес не нашел ресурсов сделать официально и на коленке собрал сам. Это может жить годами и реально приносить пользу. Но только как нишевое решение.
Но со временем есть риски того, что главный движитель уволится, и центр компетенции развалится, а любая ИТ контора, в том числе и внутренняя попросит 3 цены за взятие его на поддержку. Либо расходы на поддержание станут большими, а работы больше нет, так как ИТ подразделение, наняв админа, дает ему в поддержку 20 систем, а в shadow ИТ у shadow ITшника их две. И получается стоимость уже не радует. Где-то скажется дефицит качественного тестирования
Про компетенции ... почему возникает боль и ржака (внешних наблюдателей) при попытке сдать систему в поддержку официально? Все просто. В акте 10 подписей, под каждым правильная дока, нормально выстроенное решение и много работы. ИТ безопасность вам расскажет про сертификаты, шифрование, аутентификацию, ЭЦП, корректную работу с персональными данными ... а у shadiw- проекте этого либо нет, либо сделано так, что без слез не взглянешь. А почему? Потому что это надо было вписывать в задачи отдельно, а значит тратить свое время, которого не было из-за совмещения, да и часто нехватки знаний (так как опытный спец сразу знает, как правильно и потратит децл времени, а shadow швейцарский ножик уйдет со встречи гуглить половину терминов). Архитектура спросит, а чего вы будете делать при отказе этого квадратика. А окажется, что данные пропадут, а аргумент, что до того ничего не падало не проканает. А на отказоустойчивость надо потратить много времени, и своего, и команды. Злая разработка попросит покрытие unit-тестами 75% кода и результаты сканера, после чего пошлет shadow команду с папиоусом километровой длины
Shadow подход - это почти всегда компромис где все, кроме функциональных требований выпадает в осадок. Поэтому ЕСТЬ ВРЕМЯ совмещать. Но если делать продукт под корпоративные стандарты качества - швейцарский ножик, как правило, сразу или чуть погодя поймет, что уже так не работает
Огромное спасибо за историю! Меня прям передернуло от флешбеков)
Оформил ваши комментарии как пост в своем канале, в теле поста сослался на ваш профиль - https://t.me/godnolytika/143
Все плохо. У вас был крайне неудачный опыт((
Роль аналитика совсем не подразумевает анализ рынка и потребностей. Это роль продакта (продакт менеджера) которую, так уж вышло, вы тоже на себя взвалили.
А проджект не выбирает фреймворк (это даже продакт не делает, это техлид, иногда это называется тимлид) и не контролирует метрики (это делает продакт).
Ну и уж точно обе роли совсем не про коммуникацию в команде. Не в том плане что люди с этой ролью не могут на себя брать такие задачи, а а том что роль от этого все равно не перестанет называться "скрам мастер" (ну или политрук или зампокадрам по старому)
Итого: в бедного вас ради экономии ставок впихнули 5 ролей: проджект, продакт, аналитик, тех(тим)лид и скрам-мастер.
Не скажу что так нельзя или это не встречается, но это точно не хорошо. Нормально если есть хотя бы три живых человека на эти роли. Т-шейп это замечательно, но тут уже не Т, а Ж-шейп.
Роль продакта: понимать что хочет бизнес и как это влияет на метрики. Видеть как это влияет на роадмап и бэклог. Отвечает за результат.
Роль бизнес-аналитика: переводить то что описал продакт на технический язык - документация, спецификация API, сущности и методы, передача этого всего дизайну и потом разработчикам.
Роль техлида: выбор фреймворков, библиотек, стэка (если это все уже не выбрано раньше) и остальных решений которые все эти задачи поддержат технически и не похоронят проект под ворохом зависимостей и ограничений.
Проджект контролирует сроки, бюджеты, согласует правки. Ходит за продактом пока не получит оценки дедлайнов.
Скрам-мастера (коуч) - следит за коммуникацией и процессами. Следит за обменом информации.
Нормально если на эти пять ролей есть трое. Ну минимум двое. Один продакт со скилами проджекта, второй техлид и аналитик, шарят скрам процессы. Или один аналитик и продакт а одном, второй техлид и скрам, шарят пополам проджектовую часть. Но когда все эти роли расписаны в одном человеке - это жесть. Я вам очень соболезную, и понимаю почему в статье общий посыл "так не надо".
Понятно что много задач эти ребята решают совместно и хорошо бы на некоторых встречах с бизнесом продакту быть вместе с аналитиком. Или на встречах типа PBR рулить процессами техлиду и аналитику одновременно. Но это не значит что впихнуть все в одного человека это нормально.
Добрый день!
Ну во-первых, я не могу сказать, что опыт у меня был неудачный. В рамках своего плана развития внутри компании я очень хотел стать продактом. И реализуя этот проект я увидел возможность им стать через транзишн аналитик->менеджер проекта->менеджер продукта. Более того, мне даже прямо сказали про это. Но, увы, из Сбера я ушел по причинам, не связанным с работой, но с личной безопасностью.
Про анализ рынка - часто бывает такое, что этим занимается бизнес-аналитик, особенно на западе. Также этим могут заниматься и продуктовые аналитики. Ну и продакт менеджеры. И обратите внимание, я специально написал ВТОРИЧНЫЕ исследования.
Про фреймворк - когда команду подбираешь под проект, то ты как проджект должно определить, по какому фреймворку она должна работать, чтобы успешно закрыть проект. Про тех стек речи нет - естественно, это вне компетенций проджекта
Про коммуникации - я еще раз обращу внимание, что проджект менеджер - он про ПРОЕКТ. Продакт менеджер про КОМАНДУ. То, что вы упомянули скрам-мастер, это определенная РОЛЬ в КОМАНДЕ, которая работает по фреймворку Scrum. А мы говорим про проектную деятельность, в которую зачастую вовлечены несколько команд. Скрам-мастера в этом случае некорректно приплетать.
А про мнение касательно совмещения ролей - большое спасибо, что поделились!
Если проджект - про проект, а продакт - про команду, то про продукт-то кто? Тот самый аналитик?
Привет! Спасибо за замечание - я не успел поправить комментарий, что продакт менеджер про ПРОДУКТ. Хабр не дал это сделать..
В обсуждении в моем канале уже успели этот момент разобрать.
Я человек ленивый, поэтому сделаю копипаст комментария Сергея Елизарова - ценнейшего человека в нашем коммьюнити:
"напишу критику сюда: продакт это не про команду, продакт это про продукт — у него объект управления это продукт)
ему не надо думать о команде, ему надо думать о ценности продукта и достигает он ее или нет) и если нет — как ее достигать. а это сложная работа, и если совместить обе роли, то будет страдать одна из шапочек
про команду — это people manager, им может быть как продакт (что, на самом деле, по мне порочная практика, не видел хороших реализаций), но чаще — это тимлид/любой другой пипл менеджер. часто видел, что это ложится на проджекта (точнее, называют проджектом пипл менеджера)"
И также поделюсь мнением Сергея касательно идеальной комбинации команды.
Я данный сетап поддерживаю и с удовольствием в таком бы поработал:
"самую идеальную комбинацию я видел, которая хорошо работает :
1. есть и проджект, который умеет головой отвечать за деньги, бюджетирование и использование ресурсов помимо разработки + вести переговоры + координировать кросс-функциональную команду
2. есть продакт по долгу службы (если это проекты поверх продукт) — он умеет вычленить, что нужно и как нужно, в каком приоритете и вляет на цели проекта так, чтобы это принесло пользу продукту в рамках стратегии
3. есть технический менеджер — он же пипл менеджер. он агрегирует кадровые риски, готовит команду и "спонсирует" людьми проект + отвечает за их кусок работы, организует процесс доставки ценности
4. ну и есть команда разработки с аналитиком, где аналитик уже вторичную валидацию проводит и доуточняет решение
из п.4 так-то можно вычленить аналитика, если у продакта достаточно ресурса, продакт лучше может описать что нужно, т.к. имеет больше контекста)"
Скрам буклеты со мной не согласятся, но если ПМ не следит за коммуникацией это почти гарантирует проблемы.
Чем больше живу, тем больше убеждаюсь, что ПМ это не про таски в джире двигать и бюджет обновлять, а про то как следить за коммуникациями, проверять и перепроверять, что все на одной волне и знают зачем они делают то что делают и что у них есть всё что нужно для работы.
Под фреймфорком автор имел в виду не технический фреймворк, который для написания кода, а процессный - канбан например.
Роль системного аналитика не подразумевает анализ рынка, а роль бизнес-аналитика вполне себе. Автор пишет, что совмещал обе.
Анализ рынка (емкость, основные клиенты, маржинальность - все вот это) на крупных проектах - это работа продуктового аналитика - помощника продакта.
Еще в аналитика (помимо задач трех видов аналитиков, продакта, проджекта и срам-мастера) могут пытаться запихивать задачи маркетолога, пиарщика, тест-дизайнера и еще многих и многих специалистов.
Пункт 2 отдайте системному аналитику и не мучайте этим бизнес-аналитика :)
Спасибо за статью, автор. Похоже её не так просто понять основной массе аудитории, средний разработчик или QA часто довольно смутно понимает, чем отличается проджект менеджер, продакт менеджер, бизнес-аналитик, системный аналитик, скрам-мастер, и причём здесь тимлид :)
Так что имхо мало кто сможет прямо нормально погрузиться в материал.
А по сути статьи - совместить БА и СА - это уже не очень просто, и эффективно так делать получится скорее на небольших проектах. Вы к этому добавили ещё сверху тимлида и проджекта, что вообще похоже на чудеса эквилибристики. Из моего опыта так можно жить только если команда состоит из 2 человек, а аналитика требуется по минимуму, и при этом заказчики и стейкхолдеры проекта - очень лояльные люди, и у них с вами и между собой отличная коммуникация. Во всех остальных случаях это путь в трэш и безумие :)
Я работал в таком сетапе команды из двух человек: проджект-менеджер, занимающийся в недозагруженное время требованиями и проектированием, два разработчика и тестировщик. Плюсы - экономлю на коммуникациях, когда например внутренний РМ просит аналитика оценить сроки; минусы - отсутствие коллегиального мнения, например, в том же вопросе формулирования сроков ;)
А ещё плюс - разнообразие задач защищали от выгорания.
Привет!
Расскажи пожалуйста, а было ли в таком сетапе у вас проблемы отсутствия подробной документации?
Либо разработчики/тестировщик составлением проектной документации занимались?
Были ли задачи, когда нужно было доработать сервис, который последний раз версионировали год назад? Как разбирались с этим?
А если кто-то из команды ушел из команды - как бы опыт перенимали?
Вопросы без претензий и подколов если что, мне просто интересен опыт твой.
было ли в таком сетапе у вас проблемы отсутствия подробной документации?
Документированием разработанных фичей в данном случае занимался я (как аналитик) скорее по личностным причинам: разработчики были слишком гордые, чтобы записывать за собой, а мне в таком объеме писать было даже в радость.
Требования и архитектура/проектирование точно были за мной как за аналитиком. Не могу ответить на вопрос с точки зрения «в таком сетапе» :(
Либо разработчики/тестировщик составлением проектной документации занимались?
Под проектной документацией я понимаю документы управления проектом - планы календарные, управления коммуникациями, риски и пр., что в PMI PMBoK. По поскольку всея команда на ладони, то из «проектной» документации был только беклог/роадмап.
Были ли задачи, когда нужно было доработать сервис, который последний раз версионировали год назад? Как разбирались с этим?
— ну, аналитик, давай объясняй нам, что это и как работало
— да это вы же сами писали год назад, вы ведь задокументировали за собой, верно?
— вот ты токсик!
— ладно, вот описание на уровне функциональности и архитектура, а глубже сами копайте. «Код - лучшая документация», вы же говорили, - «Там все структурировано и понятно»
Есть ощущение, что @fenrrr хотел получить систематизированный ответ, а я скатился до частного случая
Капитан, полностью взаимно благодарен за комментарий!
Попали просто в яблочко про то, что я хотел донести :)
И второе попадание туда же: в Сбере у меня действительно "команда" состояла из меня, разработчика и двух экспертов со стороны - архитектора и ux-дизайнера. Соответственно и стейкхолдеры были лояльные (и пассивные): видели мое видение, верили мне и не были против моей активности.
В Альфе же я был "играющим тренером" - тимлид-аналитиком. Команда была уже побольше, но менеджерские задачи что по проекту, что по команде, что по процессам никуда не делись))
P.S. Я веду ТГ-канал, где пишу статьи и путевые заметки для аналитиков и тимлидов - буду рад, если примешь приглашение присоединиться! Всегда рад "насмотренным" и бодрым людям в сообществе)
https://t.me/godnolytika
Мне кажется, что эта база:
БА - требования
ПМ - срок, объем, бюджет
Профессиональный стандарт «Руководитель проектов в области информационных технологий».
Профессиональный стандарт «Бизнес-аналитик».
Реестр профессиональных стандартов:
Проджект менеджер и аналитик: два сапога — пара?