Есть мнение, что этот баланс достигается на основании оценок уверенности в точности определения проблемы и в корректности решения. То есть, возможны три ситуации:
- Решаемая проблема - это предположение (мы не знаем точно, существует ли такая проблема).
- Решаемая проблема известна и валидна, но решение - это предположение (мы не знаем, сработает ли решение).
- И проблема, и решение известны и валидны (мы точно знаем, что нужно сделать, и точно знаем, что это решит проблему).
Эти ситуации упорядочены от скорости к качеству.
Логика такова, что если мы не до конца понимаем проблему, то нам нужно как можно больше экспериментировать, а это значит, как можно чаще выпускать в мир рабочие продукты и собирать обратную связь. Тут можно пожертвовать качеством (внутренним, очевидно, в первую очередь) ради скорости.
Если мы точно знаем проблему, но не уверены, сработает ли решение, то нужно замедлиться и прорабатывать решения более качественно (возможно, это следствие того, что в этой ситуации нужно инжинирить решение, создавать его сразу правильно?). Хотя тут тоже возможны варианты, наверное… экспериментировать с решениями ведь тоже нужно. Но и основной ход разработки решения (основанный на SotA-идеях?) не должен страдать.
А если мы точно знаем, какова проблема, и точно знаем, что наше решение с ней справится, то нужно выкатывать очень качественное решение, возможно, и с задержкой по срокам. Другими словами, нужно реализовать известное решение наилучшим способом, а не самым быстрым.