Как стать автором
Обновить

Комментарии 29

Спасибо за объяснения, теперь я понял почему так много раньше хороших вещей стали просто плохими, а иногда просто ужасными в Альфе.

Буду рад конкретным примерам. Обратная связь важна — она позволяет становиться лучше, постоянно совершенствоваться. Но работает такой формат только при наличии конкретных примеров и конструктивного диалога.

Я думаю имеется в виду несколько «костыльные» решения, например когда в андроид приложении часть данных кодируется в ворде/экселе и после этого ворд/эксель открывается только им(приложением). Небольшие неудобства так сказать.
В любом случае Ваш пост классный. Даже сподвигнул меня зарегистрироваться на хабре :)
Если есть возможность — можете ответить на ряд вопросов, я думаю они могут быть интересны не только мне.
1. Можете ли выложить примеры кейсов — особенно интересны схемы, как Ваши продукты доносят виденье продукта до стейкхолдеров. Как Вы обычно формируете KPI и убеждаете выделять бюджет под него.
2. Имеет ли смысл идти в банк продуктом, если последний опыт работы в банковской сфере был более 10 лет назад? Опыт работы с финансами в это время был (биржа криптовалют, ПО фасилитизации, big data).
3. Имеет ли какой-то смысл сертификация на скрам продукта? Обращаете лично Вы на нее внимание?
4. Вы говорите о неком общем духе в команде. Насколько я понимаю, он во многом формируется неким набором литературы, которую люди прочитали и разделяют ее модель. Если есть возможность, не могли бы Вы выложить некие примеры этого бэкграунда в литературе, статьях, видео — что угодно. Какие еще с Вашей точки зрения, есть критерии для этого?
5. Какие критерии успеха есть в таких больших структурах как Альфа? Я просто имел опыт только в небольших организациях и ключевым фактором всегда было максимально быстрое MVP и выход на (положительный) денежный поток. Что обычно происходит у Вас? Что обычно является критерием успеха у продукта?
Заранее спасибо :)
Продакты в Альфа-Банке — люди, формирующие каждый свою команду спецназа. Команду людей, где каждый готов прикрыть друг друга. Это именно команда, а не шестеренки в механизме.

А потом они три недели срутся по поводу банальных правок в code review. Хотя это уже другая история.

Может быть до меня такие истории не доходят, я не в курсе, правда. С ревью бывают проблемы у новеньких ребят, но это кажется допустимо.

Это была отсылка к недавней истории, где ревьювер по доброте душевной очень не хотел конфликтовать с работницей, что вылилось в три недели срача, а могло закончиться выговором для работницы и угрозой последующего увольнения, если не будет делать как надо. Но посыл в чем: нельзя совмещать позиции «бро для всех и каждого» и «лидер команды». Тут либо одно, либо другое. Причем реально работает только один вариант: быть погонщиком и бить весляров плетью, иначе они ничего не понимают, ничего делать не хотят и творят просто невозможную дичь, которую ответственным людям потом разгребать. Важно просто понимать, что большинство людей не горят на работе, а энтузиазм у них исключительно напускной. Как только понимаешь эту очевидную истину, то и плеть звучать громче начинает, и берег приближается быстрее.
Наверное, приведенный пример имеет место быть. Я не говорю о том, что все команды идеально сложены и работают как часы, но это скорее исключение, чем правило. Каждая команда находится на определенном уровне зрелости, от этого уровня зависит практически все. У всех есть базовые принципы, которые про честность, открытость, прозрачность… Ребята всегда и в открытую обсуждают что происходит (привет ретро), выявляют проблемные места (например, ревью), вырабатывают планы по устранению этих проблем (например, поменять ревьюера) и собственно постоянно совершенствуются таким образом. Команда ВСЕГДА имеет возможность уволить (если это самый подходящий вариант решения проблем(ы)). Просто это редко происходит, потому как людей, с которыми не имеет смысла работать, обычно, выявляют на испытательном сроке.
Ага, вывод на рынок требуется, а компетенция в маркетинг не требуется. В общем, продуктологи нормальных банков посмеялись.
Все компетенции, которые есть на паутинке требуются и все они важны. Это просто пример показан, как могут оцениваться компетенции продакта. Для того, чтобы компетенцию развивать и оценивать прогресс развития, нужно понимать где ты сейчас находишься.
Напротив слаборазвитых компетенций стоит восклицательный знак и стрелочка.

Сорри, если не понятно получилось.
А компетенция People Management — это управление многодетными матерями, HR или управление командой проекта? Зачем важна такая компетенция, которая не добавляет ценности продукту. Следующая на картинке Stakeholder Management — это опять компетенция из другой сферы (из управления проектами/портфелями), применяется для других целей. В общем страшно копать в глубину поданной информации, смеси проектных и управленческих методологий.
А вы не бойтесь — копайте. People management — про работу с командой (в большинстве своем), да. Про stakeholder management есть понятное описание в тексте поста. Ну и вы имеете полное право соглашаться или нет. В посте мнение автора, основанное на достаточно неплохом и немаленьком опыте. Ну а если есть какие-то предложения или дополнения с аргументацией почему это должно быть, а этого нет, то я буду рад услышать это.
Цели у всей команды единые (бизнесовые). Продакт определяет цели бизнеса, которые автоматически становятся его личными и целями команды. Команда должна разделять эти цели, люди должны быть заряжены на результат. Каждый член команды каждый день должен задавать себе вопрос — то, что я делаю, влияет на достижение цели? Это важно.


Удивил меня этот постулат. Я думал, что у инженеров цель — сделать технически грамотно то, что напридумывал кто-то, чтобы эта штука корректно работала под нагрузкой, масштабировалась, был низкий time to market. А тут получается, что все в команде должны разделять и ценить цели бизнеса.

А что будет, если то, что кто-то придумал будет разрабатываться долго, в итоге будет работать криво, да ещё и падать под нагрузкой? Все верно, бизнес пострадает так, что потом его восстановить будет очень сложно.


Безусловно командные метрики есть, но это скорее метрики, недели цели. DevTeam должна делать быстро и качественно — обычно это про скорость производства (например количество сжигаемых US/на единицу времени) и количество допущенных багов.


Но, важно понимать, что цель одна — делать бизнес. И все что делается, делается ради этой цели. Иногда и закостылить надо где-то, факт.

Всёже ИМХО банк это не MIT, нравится это кому-то или нет, но продукты имеют вполне реальный бюджет как денежный так и временной, и задача реализовать максимально качественно но в разумные для бизнеса сроки.

Правильное замечание. У продукта есть свой жизненный цикл, и надо на нём не «делать бизнес», а или «сделать бизнес» или потратить ресурсы на что-то более выгодное.
Все зависит от уровня декомпозиции бизнеса. Есть Банк — он делится на бизнес линии, бизнес линии делятся на более мелкие бизнеса и т.д. Но каждый уровень бизнеса самостоятельный и управляется целями.

В моем понимании, когда вы говорите о продукте, который имеет временной бюджет — вы говорите о задаче в рамках бизнеса. Ибо странно говорить о бизнесе, который вы строите, что он имеет временной бюджет — вы постоянно его развиваете, ищете новые возможности, новые точки роста, расширяетесь, запускаете смежные продукты, появляются какие-то ответвления.

Есть у нас, например, продукт «Рублевые платежи». Скорее даже продуктовое направление или, проще говоря — бизнес. У этого этого бизнеса есть свой PnL и свои бизнес-цели.

Когда цели определены и синхронизированы со стратегией всей компании, с глобальными целями всего бизнеса (т.е. мы понимаем, как работа над «Рублевыми платежами» влияет на весь банк и понимаем, почему мы хотим достигнуть именно этих целей) появляется модель приоритезации задач/продуктов (зависит от уровня декомпозиции).

Условно, мы оцениваем бизнес-велью каждой задачи/продукта (как задача влияет на достижение целей) и трудоемкость реализации. Получаем итоговый скор балл, на основе которого определяются приоритеты.

Естественно, у каждого продукта или задачи есть свои цели и метрики.

А дальше все зависит от внутренней организации работы — можно разделиться по стримам, можно просто брать поочереди задачи/продукты из беклога, можно еще как-то — вариантов масса.
Это его собственный маленький бизнес, за который он отвечает. И расстаться с ним не так уж просто:)

И всё таки собственный бизнес есть собственный. Нигде «по найму» не дадут управлять так, как в собственном.

Дадут. Просто правовое поле разное немного. В полностью своем бизнесе — государство, у нас банк, который накладывает свои ограничения.
Это нормально. Суть в том, что именно продакт, действительно отвечает за все, что происходит с доверенным ему бизнесом. И имеет все необходимые полномочия, чтобы принимать любые решения в рамках существующего правового поля.

НЛО прилетело и опубликовало эту надпись здесь
Мне больше нравится владелец. И кажется, что похож наш PO больше на владельца. Мы стараемся создать такие условия работы, такую мотивацию, чтобы продакт чувствовал себя собственником бизнеса. Мы хотим, чтобы он и команда понимали и чувствовали, что их вознаграждение полностью зависят от результата, который они показывают. Нет никаких ограничений, кроме возможностей команды.
НЛО прилетело и опубликовало эту надпись здесь
У всех PO есть возможность повлиять на уровень ЗП.

Прямые полномочия по изменению ЗП, возможно, скоро появятся у зрелых PO. На самом деле, практика показывает — текущий уровень влияния (текущие возможности) PO на вознаграждение людей в команде достаточен для удовлетворения всех потребностей.

Сейчас пилотируем программы, когда бонус-пулом команды является % от прибыли бизнеса, над развитием которого они работают.

Вообще, вне зависимости от системы мотивации, вознаграждение всегда зависит от результата.

Во многие направления вы сейчас просто не сможете "выйти" со своим бизнесом, просто потому что не хватит стартового капитала, а период массового начального накопления уже прошёл. Поэтому в некоторых сферах можно поучаствовать только как наёмный работник (управляющий партнёр?) но не как собственнику.

НЛО прилетело и опубликовало эту надпись здесь

Продакт = Product owner = Владелец продукта

НЛО прилетело и опубликовало эту надпись здесь

Ну вы же цитируете меня, не знаю что ещё добавить к своим словам. Юридически, прав владения, конечно, нет. Жду кульминационного вопроса с вашей стороны. Задавайте, не стесняйтесь.

Спасибо за статью! Один вопрос. В статье говорится о том, что продакт должен быть строгим лидером для своей команды. Так ли это? Ведь все работают по SCRUM системе(по крайней мере в лабе), где каждый член команды должен быть равным. Кроме того, бывают случаи, когда команда отказывается от продакта и меняет его.
Лидер — не равно руководитель и не равно небожитель. Продакт должен быть лидером, человеком, который ведет людей за собой, объединяет, формирует ту самую команду о которой мы говорим.

Все равны, но у каждого своя специализация, своя ключевая компетенция. Продакт задает направление, в котором должна двигаться команда. Поэтому для него архиважной компетенцией является лидерство. Потому что он отвечает за бизнес, за людей, которые работают в этом бизнесе.

Если продакт плохо управляет бизнесом — вы будете делать не то, что нужно, не достигнете целей. Кажется команда быстро начинает это понимать и тогда к продакту появляется много вопросов — если ситуация не исправляется, то у продакта один путь — уйти из команды, а может быть и из банка.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий