Бизнесу высокое качество не нужно, ни в коде ни в конечном продукте, оно не является конкурентным преимуществом. Достаточно среднего, нормального качества, работает - и слава богу. По крайней мере в Enterprise секторе это так.

Очень хочется, чтобы целевые рамки по объемам, качеству и срокам были как-то формально определены. Если рассматривать продукт в целом, то идеальная схема выглядит как-то так:

1. Бизнес заявляет, что ему нужен такой-то продукт (функциональные требования) не ниже такого-то уровня качества к такой-то дате.
2. Инженеры разбивают функциональные требования на крупные функциональные блоки продукта и декомпозируют работы до какого-то уровня детализации. Здесь же определяют взаимосвязи, блоки, требуемую очередность реализации. Возможно, что тут уже будет понятно, что потребуются какие-то платформенные штуки, т.е. инструменты, которые не дадут прямой пользовательской ценности, но позволят двигаться быстрее при разработке.
3. Менеджер составляет и отслеживает календарный план работ, т.е. определяет границы мини-проектов (реализация отдельных функциональных блоков продукта, вплоть до отдельных фич/историй). То есть тут должны появиться те же типы требований, что и для продукта в целом, только на более низком уровне декомпозиции: такая-то фича не ниже такого-то уровня качества к такой-то дате.
4. Инженеры пилят эти мини-проекты с максимальной возможной скоростью для заданного уровня качества. Если обнаруживаются возможности для улучшения продукта или ускорения процесса, то их нужно попытаться включить в менеджерский план (с учетом рисков, естественно).

Моя личная боль прямо сейчас в том, что этапы 2 и 3 практически не существуют. Для каждой фичи более-менее определены функциональные требования, да и то не всегда, а вот сроки и качество обычно не задаются вообще. Ну, то есть, для сроков есть, конечно, спринты, но пилить одну историю несколько спринтов - это распространенная ситуация.

Из-за реального “провала” между этапами идеальной модели и возникают ситуации вроде моей, когда накапливается напряжение между бизнесом, менеджментом и инженерами, так как скорость разработки кажется недостаточной, а качество кажется избыточным. Кажется - потому что в рамках каждой конкретной фичи сравнить-то не с чем, плана и требований на этом уровне декомпозиции не существует.

Инженеры не знают, в какое качество целиться, менеджеры не знают, какие сроки контролировать, бизнес не понимает, что получится в итоге. Тотальная неосведомленность.

В таких условиях, конечно, инженерам можно “партизанить”, то есть договариваться на завышенные сроки и заниженное качество по каждой фиче, но функциональные требования реализовывать быстрее, а оставшееся время посвящать повышению качества. Бизнес видит, что инженеры заняты только работой над фичами (единственно полезной работой с точки зрения бизнеса), инженеры могут удовлетворить свою страсть к рефакторингу и библиотекам переиспользуемого кода, а менеджеры… ну, у нас же Менеджмент 2.0, скрам и Agile, менеджеры не нужны. Вроде как “и волки сыты, и овцы целы” и даже продукту хорошо. Еще и медаль “За героические действия” можно получить, если вдруг случится какой-нибудь аврал, бизнес будет считать, что на работу потребуется 5 дней, а инженеры закостылят за один.

Сарказм, конечно, и довольно горький :( Потому что я хочу прозрачности и понятности в работе, хочу точно понимать, каковы требования к моей работе, хочу иметь возможность повлиять на итоговый результат, реализовав какое-нибудь “рац.предложение”. В описанных реалиях такое почти невозможно.

Тем не менее, для меня вырисовывается план действий.

Во-первых, реально работать по принципу “Make it work, make it right, make it fast”, но после каждого “make” отчитываться о результате и передавать рабочий продукт дальше с описанием костылей и наложенных ограничений. Если бизнес решит, что “make it right” не нужен, то есть примет риски, связанные с ограничением и тех.долгом - ну что ж, так тому и быть.

Во-вторых, для всех новых фич стремиться прояснить и сформировать в головах у всех участников проекта требования к срокам и качеству, возможно, кто-нибудь, обладая этой информацией сможет выполнять роль операционного менеджера.