14 материалов · приём действия · Управлять разработкой и доставкой
Выступление1 ч 5 минPeopleSense'26 — Конференция об управлении командами, процессами и собой · 2026
Проверяем доступ
«При планировании сложных фичей закладывайте в бюджет скрытые издержки: инфраструктурную непредсказуемость и необходимость непрерывного дообучения.»
здесь это прозвучало
ВыступлениеProductSense’23 — Конференция по менеджменту продуктов · 2023
Проверяем доступ
«Если продукт рассчитан на долгую жизнь, закладывайте время и бюджет на проектирование архитектуры и рефакторинг еще до старта разработки.»
здесь это прозвучало
Подкаст52 минПодкаст · 2022
Проверяем доступ
«До начала разработки нового продукта технический и продуктовый руководители должны совместно спроектировать архитектуру и обсудить бизнес-метрики.»
здесь это прозвучало
ВыступлениеProductSense Online'20 · 2020
Проверяем доступ
«При оценке каждого нового продукта или фичи нужно задавать вопрос: как это решение скажется на здоровье всей системы в краткосрочной и долгосрочной перспективе.»
здесь это прозвучало
ВыступлениеProductSense’18 Moscow — Конференция по менеджменту продуктов · 2020
Проверяем доступ
«При планировании перехода от единственного продукта к линейке нужно заранее закладывать бюджет на масштабный рефакторинг архитектуры ядра.»
здесь это прозвучало
Подкаст37 минПодкаст · 2020
Проверяем доступ
«Создавать сложную архитектуру нужно итеративно, начиная с минимально работающей системы и постепенно её модифицируя.»
здесь это прозвучало
ВыступлениеProduct Mindset Perm'19 · 2020
Проверяем доступ
«Чтобы техдолг не копился бесконечно, резервируйте фиксированную долю story points в каждом спринте или выделяйте через равные интервалы целые «пустые» технические спринты.»
здесь это прозвучало
Видео16 минПроверяем доступ
«Механики привлечения нужно закладывать в архитектуру продукта еще до запуска, потому что добавить виральность или UGC-цикл в готовую систему очень дорого.»
здесь это прозвучало
Видео8 минПроверяем доступ
«Виральные механики нужно закладывать в архитектуру продукта до запуска, а не прикручивать постфактум.»
здесь это прозвучало
Видео9 минПроверяем доступ
«После периода быстрых экспериментов на «костылях» нужно планово выделять время (например, квартал) на выплату технического долга.»
здесь это прозвучало
Видео31 минПроверяем доступ
«Первые визуальные наброски нужно показывать разработчикам, чтобы заранее выявить технические ограничения и не нарисовать то, что невозможно реализовать.»
здесь это прозвучало
Видео22 минПроверяем доступ
«Архитектуру MVP нужно сразу проектировать под масштабирование, потому что времени и ресурсов на переделку после релиза не будет.»
здесь это прозвучало
Видео54 минПроверяем доступ
«Технический трек (стабильность, uptime, рефакторинг) нужно включать в продуктовую стратегию наравне с пользовательскими фичами.»
здесь это прозвучало
Видео6 минПроверяем доступ
«При активном росте продукта критически важно контролировать накопление технического долга, чтобы сохранить возможность быстро проводить эксперименты.»
здесь это прозвучало
