Bus Factor: когда уход одного человека останавливает продукт
Разработчик, который знал всю архитектуру платёжного модуля, уходит в отпуск на две недели. В первый же день на проде падает интеграция с эквайрингом.
Управление командами
Ловушки продакта и руководителя: приоритеты, процессы, люди.
Ловушка тяжёлого ТЗ: 30 страниц документации вместо 2-недельного теста
PM открывает Confluence и начинает писать. Контекст продукта. Цели и метрики. Пользовательские истории — двадцать штук. Через три недели документ готов: тридцать одна страница, которую никто не дочитает.
Ловушка параллельных приоритетов: 5 направлений = прогресс ни в одном
Квартальное планирование. На доске — пять направлений. Все важные. Все с обоснованиями. Команда разошлась с ощущением, что всё будет сделано.
Ловушка бесконечного согласования: как совещания заменяют решения
Вторник, 11:00 — синхронизация по гипотезе. Итог: «нужно обсудить с техлидом». Четверг — встреча с техлидом. Итог: «покажем CPO». Следующая неделя — встреча с CPO.
Feature factory: команда строит фичи, рост не идёт
Пятница, ретроспектива. PM открывает слайд: «23 фичи за квартал, velocity выросла на 18%». В комнате удовлетворение. Через три недели приходит аналитика.
«Клиент всегда прав»: как буквальные запросы разрушают продукт
Клиент говорит: «Нам нужна интеграция с 1С». Команда строит. Клиент использует раз и забывает. Проблема не в разработке.
Ловушка тяжёлого ТЗ: 30 страниц вместо 2-недельного теста
PM три недели пишет PRD. 31 страница. Все поля заполнены, все edge cases закрыты. Разработчик открывает, читает три страницы, закрывает.
Ловушка преждевременного масштаба: большие команды убивают стартап
Series A закрыт. Инвестор говорит «масштабируйтесь». Команда удваивается за три месяца. Через полгода burn вырос в четыре раза, ARR — на 30%, runway — восемь месяцев.
Bus Factor: почему один уход останавливает весь продукт
Bus Factor (коэффициент автобуса) — минимальное количество людей, которых нужно «убрать», чтобы проект встал. Разработчик знает всю архитектуру платёжного модуля.
PAEI фреймворк: кого брать в команду на каждом этапе развития продукта
Проблема На старте нужна энергия и идеи, на MVP — терпение, ближе к PMF — процессы. Многие фаундеры приходят к PMF выгоревшими и без команды.
Закономерности управления
Сегодня был интересный ликбез на тему оргструктур, коммуникаций и управления командами, из которого я узнал про закон Конвея: "архитектура вашей системы будет копировать структуру…
«Мы добавили 15 фич, а метрики не выросли» — ловушка функционального креатива
3 недели работы. Спринт закрыт. Код чистый, багов нет, дизайн — конфетка. Ты делал всё правильно: требования согласовал, архитектуру спроектировал, тесты написал.
Как убить фичегонку и вернуть продукту фокус
Открываешь презентацию, проводишь демо - сейлзы в восторге «мы умеем всё, давай продавать».
Product Architecture Framework (PAF)
Просто и очень удобный фреймворк управления продуктом на разных уровнях. Встретил его 3 года назад и с тех пор активно применяю Что нравится: - структурирования информация -…