Комментарии 9
Эффективная продуктовая команда — та, которая выпускает классные (коммерчески успешные) продукты.
Эффективная продуктовая команда - та, которая справляется с поставленной перед ней задачей.
В общем случае задача - обеспечить прибыль компании.
Команда при этом может работать "в минус", может не поставлять вообще ничего, может поставлять некачественные (с точки зрения компании, не пользователя) решения раз в год от силы.
Если от этого у компании в целом прирастает прибыль - продуктовая команда справилась со своей частью задачи.
Чтобы сделать классный продукт, нужно быстро поставлять качественные решения пользователям.
А вот и он, featurebloat driven development. Давно не виделись, здравствуй...
"Классный продукт" - это такой продукт, который за разумную цену делает свой факинг джоб.
"Быстрой поставке качественных решений" тут не место.
Например, потому, что "быстро" - это иллюзия и чистый вред. Для пользователя. А значит, продукт уже не будет "классным".
Мало просто выпустить классную фичу, нужно обязательно собрать аналитику/данные/метрики и ответить на вопрос "а что она нам дала?". Может, вы ее зря делали :)
"Давно не виделись, здравствуй..." х2.
Т. е. оценки потенциальной прибыльности ЗАРАНЕЕ - НЕ ПРОИЗВОДИТСЯ.
При адекватном планировании этот этап идёт вторым пунктом, а не самым последним, когда претензии предъявлять уже не к кому.
Дальше читать не стал. Статья смердит чайкингом и скрипом уключин.
Т. е. оценки потенциальной прибыльности ЗАРАНЕЕ - НЕ ПРОИЗВОДИТСЯ.
При адекватном планировании этот этап идёт вторым пунктом, а не самым последним, когда претензии предъявлять уже не к кому
Карта != территория
Вы не получаете ОС от бизнеса о реализованных фичах? A/B тестирование, эксперименты лишняя трата времени?
Планирование - это прогноз. Ваши прогнозы всегда сбываются?
За время разработки может произойти многое: конкуренты выпустили продукт раньше вас и ваш релиз уже не так интересен; низкое качество реализации испортило все впечатление от фичи и она не принесла заявленной ценности; затянули с разработкой, а рынок уже другой и хайп прошел.
В продуктовой разработке без ОС никуда.
Чтобы докрутить конверсию в регистрацию на 1% порой столько надо экспериментов провести и копий сломать, одного прогноза тут не достаточно.
Я позволю себе роскошь ответить крайне избирательно. Нет настроения трясти воздух впустую. Осень...
Конверсия. Конверсию можно поднять и на процент, и на два, и на десять (от текущего, хаха), если не мешать маркетингу делать его часть работы. Помочь ему сделать его часть работы. На этапе планирования учесть их пожелания. Возможно, провести беглый аудит текущего положения вещей.
Ещё раз повторю: аналитика нужна до старта собственно работ, а не после релиза.
Насчёт аргумента "за время разработки всё может измениться" - Вы можете привести хоть один пример столь турбулентной сферы? Нет, правда, где стандарты и степень хайповости меняются нынче настолько часто и мощно?
Тут еще вопрос "производственного процесса", выбранного командами в Jira, который определяет этапы в процессе перевода фич/эпиков/задач из одного состояния в другой, вплоть до Ready for release. У вас единые требования здесь? Одна методология для всех? Ведь где-то могут вводить апрувы или код ревью в процесс, где-то нет, в зависимости от зрелости команды, ее квалификации. И такой момент, можно делать быстро, но не качественно, как-то оцениваете качество?
Команды живут в одном проекте в Jira, в котором запущены параллельные спринты (под каждую команду). Воркфлоу и DoD стандартизированы и едины на весь проект, то есть все команды живут в одном процессе. Но есть разделение воркфлоу под каждый тип задачи (эпики, стори, тех стори, баг, саб-таск). Впринципе любая из команд может инициировать изменения в рабочем процессе, но эти изменения должны быть приняты остальными командами.
Да, качество конечно же оцениваем. И пост-фактум по выпущенным фичам, и на этапе планирования оцениваем потенциальный эффект. На эту тему готовлю вторую часть статьи, там будет подробный разбор как мы это делаем.
Как правило, первыми способами обойти систему будут положительные под предлогами — "а давайте нарезать таски на более мелкие", "а давайте меньше брать в спринт", "а давайте оставлять временной резерв на непредвиденные задачи и вбросы". Это приводит к положительному эффекту процесса разработки. Ведь действительно, нужно лучше декомпозировать задачи, не брать в работу то, что "не лезет", и оставлять время на исправление багов.
Выигрывая в управляемости, снижается общая производительность.
У задач есть ненулевые накладные расходы. Все это кратко растет с ростом их количества и количества контуров обратной связи.
Команды со временем учатся торговаться и попадать в оценки (ага, полезный скилл), а эффективные менеджеры - получать бонусы за удержание проекта в зелёной зоне. Цена - сдвиг time to market далеко вправо. Впрочем, вы предлагаете его игнорировать, что оставляет наблюдать кругом лишь положительные, с точки зрения данной методологии, эффекты.
На первом изображении уже оптимизированная структура?
Двойные команды с численностью больше 10 человек. 3+1 архитектора на 14+1 системных аналитиков, продуктовых аналитиков как архитекторов. При этом UX вынесены из стримов, а архитекторы внутри.
Какие предпосылки для такой структуры?
Есть во всей этой предлагаемой схеме одна очень странная вещь - story points или что там измеряется, почему-то решают сжигать при деплое на prod. Из-за этого команды, вместо разработки довольно значительных частей продукта итеративно и постепенно, делают финты ушами чтобы вылить в прод, сделать нагрузочное тестирование, приемочное тестирование просто пустого сервиса, потому что им так Agile адепты сказали. Это создает абсолютно ненужное напряжение, бестолковую работу ради работы и все потому, что кажется что это уменьшает time to market/release cycle. Сервис созданной по кнопке new solution - не решает ни одной проблемы ни пользователя, ни бизнеса. Перестаньте так делать и перестаньте насиловать команды.
Как оценивать эффективность продуктовых команд. Часть 1: процессные метрики