TGViewer
Аналитик, который думал Аналитик, который думал @analysts_thinking · 92 subscribers
Post #148 11
Критерий приёмки нужен до того, как команда начинает работу. После появления результата команда рискует заменить им исходную цель и объяснять, почему уже сделанное можно принять.

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

Но какую проблему должна была решить повторная отправка?

Если покупатель нажимает кнопку второй раз после таймаута, система не должна создать два платежа. Значит, наблюдаемый результат связан не с количеством попыток, а с отсутствием дубля при повторном запросе с тем же ключом идемпотентности.

Команда могла реализовать повторы идеально и всё равно не решить пользовательскую задачу.

До начала работы полезно разделить три уровня проверки.

Первый уровень: завершение. Код написан, файлы созданы, обязательные поля заполнены, команда может запустить тестовый контур.
More from @analysts_thinking
  1. Oct 9, 2026Четыре доклада нельзя строить вокруг одного артефакта Исследование незнакомой системы треб…
  2. Oct 8, 2026Потерянный webhook остаётся открытым решением Таймаут не сообщает, произошло событие или н…
  3. Oct 7, 2026Промежуточное состояние нужно проектировать, а не скрывать processing не является неудобно…
  4. Oct 6, 2026return_url не означает payment.succeeded Возврат пользователя в интерфейс сообщает только…
  5. Oct 5, 2026Что на самом деле доказывает зелёный тест? Он показывает, что реализация соответствует зап…
  6. Oct 4, 2026«Показывать статус заявки» — так требование выглядело в начале. После уточнений оказалось,…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →