В разработке, если одно требование можно истолковать двояко, всегда стоит брать тот вариант, что достаточен, без избыточности.

За одним исключением — если это требование общепринято.

Вот это исключение и рвет нервы в этих услугах.

Есть две ключевые ошибки:

1. Делать избыточно, полагая что так лучше, потому что больше. На основании каких-то своих тараканов в голове.

2. Делать достаточно, упуская из внимания сущность «общепринятое требование».

В первом случае велики риски затрат и ошибок, что ведет к нарушению ожиданий, а значит снижению качества ПО.

Во втором случае велик риск сразу перейти к нарушению ожиданий и опять же к низкому качеству.

Но что такое достаточность? Философски на этот вопрос отвечает принцип Бритвы Оккама.

Потому тут стоит выбирать такую стратегию:

1. Делать всегда по шкале достаточности.

2. Но при этом задавать себе вопрос «А как это делают другие в большинстве случаев?». И если есть один или два ответа на этот вопрос, то стоит на всякий случай либо заложить именно этот вариант в оценку, либо уточнить детали у Заказчика и либо дополнить требование нужными формулировками, либо поставить рамки, которые позволят отсечь общепринятое требование.

Это позволит выйти на нормальный уровень ожиданий и качества.

А если хочется высокого качества и долгих, успешных отношений, то стоит еще задать вопрос. А что можно сделать такого, что сделает продукт круче, не сильно дорогое, но очень заметное и эффектное? Сделать это и превзойти ожидания заказчика. В этом и секрет качества любых продуктов.

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

Вот такие дела.