Дякую за чудовий матеріал. Чи планували ви розширення вашої спільноти за межами вашої компанії? Цікавлюся практичним досвідом побудови саме локального комьюніті за географічним признаком.

Согласен на 100%. Аня, желаю вам найти комфортную компанию где вы сможете продолжить развиваться с удовольствием и хорошим результатом.

Обратите внимание, правильный адрес ул. Гоголя, 29

Антон, спасибо за развернутый ответ. Я вас поддержу, и соглашусь что требовать от клиента пункты 1,3,7 и 10 это не всегда оправдано, а часто не имеет смысла. Я разделяю роли постановщика задачи и клиента. Это не всегда один и тот же персонаж.
Статья адресована именно постановщику задачи. Он может быть как на стороне клиента, так и внутри команды. Звать его могут Product owner|Product manager|Business analyst|Technical writer итд. Вот этому парню советы и адресованы.

Зависит от цели команды. Если цель это качественный продукт в срок, то полагаю что такой способ делу не поможет. Риск «интеграция со сторонним API» переместится на этап приемочного тестирования, но меньше не станет. Скорее вы даже потратите лишнее время на Mock-API.

Если не секрет, то какие из пунктов действительно стоит делать во благо проекта, и почему?
(Не спора ради, а чтобы рассмотреть разные кейсы).

Опыт будет жестким, но весьма полезным. Как раз в такой мясорубке есть шанс стать самостоятельным QA, а не подаваном-обезъянкой, который прокликивает чужие тест планы.

Нет. Писал на русском изначально. Нужна?

Не пришло на ум ничего оригинальнее чем «Poor spec — the result will be wreck». Но я тот еще лингвист.

Пост про постановку требований «взагали», и носит собирательный характер, как по работе в продуктовых командах, так и в аутсорсе. Попытки сделать дядю клиента виноватым, а себя пушистым здесь нет. Более того, многие ошибки, к сожалению, довелось допустить самому при постановке задач.