12 признаков того, что работаете на фабрике фич.

Проблему деморализации проектных команд и их оторванности от продукта ощущают на себе и Менеджеры продуктов, однако она существует в том числе по их вине. John Cutler раскрыл вопрос в своей статье.

Он использовал термин «фабрика фич» в своих выступлениях на паре конференций. Термин появился когда знакомый девелопер пожаловался ему, что он «просто сидит на заводе, штампует фичи и передаёт их дальше по конвейеру».

Как узнать, что вы работаете на фабрике фич?

1. Никаких метрик. Команды разработчиков не измеряют воздействие результата своей работы. А если измерения и происходят, они всегда оторваны от продуктовых метрик. Они никогда не знают, сработало ли реализованное ими решение.
2. Быстрая перетасовка команд и проектов (она же Team Tetris). Вместо того, чтобы проталкивать свои миссии и инициативы, команда постоянно разгребает назначенные сверху задачи и проекты. Хроническая многозадачность и чрезмерная эксплуатация.
3. Театр успеха вокруг запусков проектов с ограниченным обсуждением их влияния. О компании можно многое сказать по тому, что она чествует.
4. Редкие (признанные) провалы и выброшенная работа. Фичи не вырезаются. Главное мерило успеха — реализованная фича, а не результат, который она приносит. Проекты почти не ликвидируются на основе данных. Чаще всего команды даже не знают о существовании предпосылок для признания осечки.
5. Нет связи с ключевыми метриками. Редкие обсуждения желаний пользователя и бизнеса. Команда не может связать свою работу с показателями удовлетворённости пользователей и компании. Невозможно сопоставить свои итерации с тем, что важнее всего.
6. Нет ретроспектив у продакт-менеджеров. Они не проводят регулярные ретроспективы по своим продуктовым решениям и не сравнивают ожидаемые результаты с фактическими. Разработчики валидируют и верифицируют свой код, у продуктовых менеджеров такой традиции нет. Менеджеры рассматривают скорость и производительность как ключевые показатели своей работы.
7. Одержимость приоритезацией. Несоответствие между точностью приоритезации (над чем работать?) и точностью валидации (действительно ли нужно было работать над этим?). Приоритезация завязана исключительно на том, чтобы люди «чувствовали себя уверенно». Огромный объём работы уходит на определение того, какие идеи имплементировать, оставляя мало места для манёвров и импровизации, построенных на данных. Рoудмапы состоят из фич, а не результатов и/или областей, на которых стоит сконцентрироваться.
8. Никаких доводок. Как только задача перешла в статус «done», команда немедленно переходит к следующему проекту, не оставляя время на доработки, основанные на качественных и количественных данных.
9. Культура «руки прочь». Процесс загрузки наперёд состоит из того, чтобы заранее сделать часть работы и подготовить задачи для разработки. Команды напрямую не вовлечены в исследование, анализ проблемы, эксперименты и валидацию. Как только проект сдан, команда ничего не знает о том, что происходит в продажах, саппорте и у пользователей.
10. Огромные партии. Фичи выпускаются без обязательных экспериментов и огромными партиями вместо того, чтобы выходить итерационно. Вы можете работать спринтами («ура, у нас Agile»), но пользователь не получает ничего нового в конце каждого спринта.
11. Погоня за авансовой прибылью. Фичи разрабатываются, чтобы получить новые источники дохода. Не будучи изначально плохими как идея, экономические обоснования часто шатки и не предусматривают нелинейный рост в сложности продукта (в этом квартале всё будет здорово, но за эту разработку придётся заплатить много раз в будущем). Опять-таки это поддерживает идею того, что фича — единица измерения ценности. Продуктовым решениям не хватает здравого экономического обоснования.
12. Всё, что блестит. Рефакторинг, доработки и в целом возможности разработки малозаметны. Как уже упоминалось выше, главный показатель успеха — выпуск новых фич. Недостаточно внимания уделяется «здоровью» продукта в целом в отличие от всего нового и блестящего. Вообще мало кто осознаёт и оценивает влияние новых функций на юзабилити (и поддержку, и масштабирование) существующего продукта.