Классический источник напряжений и дисфункций в командах разработки — да на самом деле, в любых командах — это путаница между целями и ограничениями.
Команды часто ошибочно принимают ограничения за цели. Типичнейший пример: команда принимает требования к продукту за свою цель, теряя из виду реальные потребности, которые изначально породили эти требования.
Требования, архитектура, дизайн приложения — это ограничение. Как правило, одну проблему можно решить бесчисленным количеством способов, но мы просто выбрали один конкретный. Это по определению и есть ограничение.
Я видел много технических стартапов, которые теряли из виду, что, как и зачем они делают, и скатывались к 100-процентному фокусированию на добыче денег, необходимых исключительно на поддержание текущего состояния дел. Такое встречается очень часто. Подумайте о всех этих благотворительных фондах, которые начинали с чёткой цели (условно говоря, "спасти кота"), но спустя несколько лет вперёд оказывается, что большинство их усилий — если не все — направлены лишь на то, чтобы найти денег на то, чтобы выплатить всем зарплату и продолжать "благотворительность".