Portfolio Management для Development-команд
Публичный постПривет,
А можете посоветовать хорошие курсы, фреймворки, статьи или доклады про Portfolio Management для Engineering Manager'ов и Software Engineer'ов?
Пример задачи, которую я хочу считаю, что можно решить с помощью Portfolio Management:
У нас есть большое количество внутренних R'n'D инициатив. Часто это внутренние технические задачи, которые могут улучшить нефункциональные требования вроде стоимости поддержки, стоимости изменений или масштабируемости. Хочется минимальным усилиями собрать и поддерживать в актуальном состоянии набор карточек проектов, взвесить их по эффорту и пользе.
Проблемы, которые возникают здесь:
- Сложно сравнить улучшение двух нефункциональных требований между собой. Например: масштабируемость против поддерживаемости.
- Для того, чтобы оценить эффорт, часто нужен дополнительный ресёрч, а после того, как изначальный ресёрч провели, могут появляться какие-то уточнения.
- Часть возможностей для инвестиций, возможно, может взвесить продуктовый менеджер, но есть ощущение, что если у него нет хороших метрик про нефункциональные требования и команда не может их продемонстрировать, то продуктовым менеджерам будет проще оптимизировать пользу для клиентов. Даже, если это приводит к тому, что следующие инициативы становятся дороже в долгосрочной перспективе или команда тратит больше времени на поддержку. Если развивать этот тезис, то возможно, мне нужен не портфолио менеджмент, а какой-то стандартный набор метрик для этого (возможно, у кого-то есть положительный опыт использования DORA для того, чтобы решить подобную проблему).
Эти задачи можно держать в беклоге, но это выглядит не особенно удобно, из-за того, что может быть не понятно, из чего складывается приоритет, плюс, иногда запутывает, когда в беклоге находятся одновременно возможности для инвестиций и предметные задачи по улучшению конкретной системы.
Можно выбрать эвристику, что мы 20% времени тратим на улучшение внутренних процессов, но если так, то внутри команды нужно самим отвечать на вопрос, что является наиболее важным. И также интересно, почему именно 20%.
Мне кажется, что Portfolio Management как раз таки может решить эту проблему, и поддерживать обзор возможностей для инвестиций в актуальном состоянии. Но, возможно, есть более простые способы решить эту проблему.
Привет!
Я бы попробовал применить тут failure analysis вкупе с next big thing, которую выбирают инженеры.
А именно: если вы уже в продакшене (или даже близки к нему), то у вас наверняка есть какое-то число фак-апов, будь то любые обращения пользователей в техподдержку, или же неудачные релизы (слишком длинные где пришлось выйти за рамки выделенного времени или где пришлось откатываться или где по итогу стало больше багов, чем обычно) или какие-то высокие косты или иные нарушения SLA. Для каждого такого прокола можно провести root cause analysis и определить, что сконтрибутило и в каких пропорциях (не всегда причина однозначна, это может быть комбинация факторов, даже с разными весами). Это позволить приоретизировать нефункциональщину.
Дальше я обычно обращаюсь к экспертам. Ты правильно сказал — Продакт менеджер — это эксперт по продукту с точки зрения рынка и пользователей. Он тут мало поможет. Настоящие эксперты — люди, кто разрабатывает продукт. Потому я бы показал им условный ТОП-3 из полученного списка и попросил сделать ставки — что мы должны чинить первым. Тут можно использовать любую технологию — распределить 10 "пунктов" между ТОП-3 или же голосовать как в скраме при помощи planning poker и аргументировать свою оценку. Так команда выберет 1 вещь, на которой они сосредоточатся.
Сколько времени этой вещи выделять — пожалуй, самый сложный вопрос. Я бы выделил вообще всё время команды, организовав какой-то "хакатон" или "инженерный спринт" или "кул-даун" между регулярными итерациями по разработки бизнес-функционала, если конечно время терпит.
Другой подход — найти одного или нескольких "чемпионов" (добровольцев), кто не будет участвовать в следующей итерации, а прицельно займутся решением этой самой выбранной проблемы и представят своё решение на "защиту" перед остальной командой.
Захар здорово расписал. Я бы ещё к этому процессу анализа портфеля добавил финансовые метрики - например, ожидаемые затраты и выручка, ARPU и так далее.
Есть отличная книга про то, как выбирать и считать разные метрики в ходе проектов - How to measure anything, автор: Douglas Hubbard. Очень советую.
Захар, спасибо, очень полезный и подробный ответ.
По поводу разбора роадмапа после проекта — да, мы эту штуку практикуем и очень полезная штука. Я думаю, что мы не сильно закапывались именно в нефункциональные фичи, потому, что у нас скорее срывы сроков бывают из-за того, что мы не до конца хорошо знаем скоуп или из-за того, что какие-то фичи, которые в документации описаны просто на первый взгляд имеют свои нюансы :)
Я бы сказал, что большую часть информации про нефункциональные требования проектов мы получаем, уже когда они находятся в эксплуатации. Я работаю с платформенными командами, поэтому чаще всего, у нас много вещей в эксплуатации и иногда прилетают новые требования, и мы допиливаем проекты. И вот сейчас я думаю, что было бы полезно оценивать сложность проекта не только, когда он доделан, но и после пары-тройки кварталов эксплуатации.
При этом, для новых проектов чаще всего это можно покрыть с помощью Production Readiness Review, и больше проблем бывает с более старыми проектами, которые были созданы с помощью неактуальных практик или со временем деградировали в нефункциональных требованиях или нашли новые юз кейсы, которые не были хорошо продуманы заранее. Наверно, для них тоже бы не помешало это ревью.
Я думаю, что наш текущий процесс как раз-таки похож на ТОП-3 фичи и переодические технические спринты, но всё ещё кажется, что это бывает недостаточным. Например, беклог с техническими доделками растёт быстрее, чем мы успеваем его разобрать и неосознанно для себя мы принимаем решение отложить какую-то вещь, иногда, возможно, не до конца поняв её долгосрочную пользу. Например, возможно, если мы заметили какую-то возможность для улучшения, если её доформулировать, поресёрчить и замасштабировать на несколько проектов, это сэкономит значительное время и позволит делать новые фичи быстрее (что может принести сравнимую пользую с разработкой фичи).
И тут как раз вопрос, есть ли какой-то способ это всё хорошо посчитать и актуализировать это подсчитанное состояние, при условии, что проекты развиваются и мы умнеем :)
Прямо сейчас, хочется взять и просто попытаться посчитать пользу, но боюсь, что для проблем с разными требованиями (скорость добавление новой фичи vs поддержит ли наше масштабирование в течении 3 лет vs сократить время, которое мы тратим на саппорт vs сократить ресурсы) придётся придумывать шкалы, разбираться, как это транслируется в стоимость владения. Но в такой момент возникает ощущение, что я изобретаю велосипед.
UPD: хотя, если переформулировать мой запрос как Cost of Ownership, можно найти много полезного. Попробую поресёрчить, возможно, смогу найти ответ на свой вопрос по этому запросу :)
Поресёрчив несколько докладов, нашёл достаточно хороший обзорный доклад про Portfolio Management, и каким образом он взаимодействует с Agile командами. И, кажется, что даже если для конкретной задачи нет подобной иерархии, возможно подробное разделение концептов может помочь.
Не уверен, что это идеально отвечает на мой вопрос, но доклад очень годный.