В первой части я описал модель перфоманса с учетом затрат на поддержку.
Плохие новости - легаси скорее всего похоронит проект. Хорошие новости - это произойдет не сразу. Если ожидаемое время жизни вашего проекта 5-10 лет и больше, то вы, скорее всего, столкнетесь с конфликтом интересов Project'a и Product'a.
Project работает при наличии конечной даты. Product работает в условии открытой даты, то есть дата смерти продукта неизвестна. Четкий deadline будет мотивировать project'a, а сообщение в стиле "Ваш продукт будет закрыт 29 февраля 2028" скорее будет демотивировать product'a.
Эффективный project management может стать той самой дорогой, которая вымощена благими намерениями. Например,
- Вам надо сделать срочный проект к дате.
- Вы успеваете сделать, но пришлось срезать углы и пару часов в неделю команде надо разбираться в продакшене.
- На ретро вы решаете, что пара часов в неделю, это ничтожно мало какие-то 5%. Good enough.
- Вы повторяете три шага выше десяток раз. Старые проблемы никуда не деваются. Новые проекты привозят свои 5%. Вот уже 43% (1-0,95^11) времени команда занимается проблемами продакшена. Вы оказываетесь где-то здесь.
Для Product'a налицо проблема - медленно идёт delivery business value. Для Project'a все отлично: спринты закрываются, велосити стабильно, планы работают точно. "В этом полугодии не удастся ничего нового сделать," - говорит Project, так и выходит.
Что дальше?
- Вариант 1. Прибыль растет, есть деньги. Скорее всего, будет принято решение расширить команду. Управлять будут те же люди и так же. Все шаги будут пройдены с теми же результатами пока на столкнетесь с Вариантом 2.
- Вариант 2. Прибыль не растет, нет денег. Скорее всего, это начало конца: будет предложено переделать архитектуру за 3-6 месяцев, которая не будет сделана даже за 12-18 месяцев, дальше essential maintenance и decomission.
Стоит отметить, что пока Project будет проходить очередной виток цикла и оставаться в Варианте 1, он или она будут постить успешный успех в линкед ин, указывая success track record и демонстрируя рост команды в управлении. Потом может случиться market wide событие типа кризисов 2008, 2012, 2015, 2020, 2022. И всем будет ясно что наш Project - звезда, просто кризисы предсказать невозможно.
Вариант 1 преподносится как win-win и для Project'a и для Product'a. Особенно если в фасилитации участвует коуч, который рассказывает, что косты нельзя сделать меньше нуля, а вот прибыль - only sky is the limit.
Логика говорит, что с точки зрения Product'a вы гарантированно увеличили Cost продукта (затраты на команду), которые будет платить каждый месяц вне зависимости от Revenue. Если вы еще к этому добавите, что-то стиле "текущие косты - это факты, а будущие revenue - это фантазии," есть все шансы, что команда откроет форточку и выбросит вас туда вместе c душными мыслями.
В момент очередного изменения команда обнаружит себя в ситуации Алисы в Зазеркалье.
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
Может, Красная Королева и от того и красная, что уже горит в вот-вот выгорит.
Стратегии работы с этим конфликтом я опишу в следующем посте. Пишите свои варианты в комментариях!