Иногда кажется, что баги появляются из ниоткуда. Всё вроде описано, макет приложен, сроки стоят. Но при приёмке всплывает то, что никто не ожидал: «а почему оно работает не так?» На деле 80% багов рождаются не из ошибок разработки, а из того, что мы по-разному видим мир. Не бывает «плохо написанного» ТЗ — бывает недоописанное. Не бывает «глупого вопроса» от тестировщика — бывает слепая зона, в которую менеджер просто не заглянул. И это не плохо. Это и есть работа: согласовывать разные картины мира, пока из них не сложится единая. Когда я пишу задачу (я пишу не только баги), я вижу перед глазами цепочку смыслов: зачем это нужно, как это улучшит жизнь пользователя, что с этим произойдёт после релиза. Когда задачу читает разработчик, он видит архитектуру, зависимости, границы ответственности между сервисами. Когда её читает тестировщик, он видит данные, которые могут не подгрузиться, и сценарии, где всё ломается. Мы читаем один и тот же текст, но каждый как будто через свою **** (линзу). Проблема в том, что в ТЗ редко отражается весь контекст. Менеджер считает очевидным то, что в его голове. Разработчик додумывает по опыту. Тестировщик проверяет по документу и по интуиции. И в итоге получается ситуация, где всё сделали «по ТЗ», но ожидания у всех разные. Я давно перестал психовать из-за ошибок вроде «не та логика кнопки» или «не сохранён статус при обновлении». Почти всегда это следствие недоописанной постановки. Чтобы сократить такие ситуации, можно ввести чек-лист “слепых зон” — инструмент самопроверки перед тем, как задача уйдет в разработку. Вот один из примеров: 🧭 Чек-лист: есть ли в ТЗ слепые зоны Если хотя бы на один пункт нет ответа, значит, где-то останется тень, и кто-то её потом достроит на свой вкус. Цель задачи понятна? Написано, зачем это нужно пользователю или бизнесу, а не просто «что сделать». Определены сценарии использования? Не только «как должно работать», но и «что произойдёт, если что-то пойдёт не так». Указаны состояния и переходы? Что происходит до, во время и после действия. Есть данные для проверки? Примеры, тестовые учётки, границы значений, ограничения. Определены роли и доступы? Кто видит, кто может редактировать, кто не должен видеть вовсе. Продуманы ошибки и валидации? Что показываем пользователю, если что-то не так. Понятны зависимости? Нужны ли внешние сервисы, очереди, API, кэши. Известны ограничения? Размеры файлов, лимиты, таймауты, версии браузеров. Есть метрика успеха? Как понять, что задача решена правильно. Согласованы термины? Все ли одинаково понимают слова. 💬 Как использовать ChatGPT для проверки ТЗ В эру нейросетей можно подключать ChatGPT, чтобы проверить, вижу ли я всё, что должен видеть. Он помогает вытащить на поверхность скрытые риски, о которых забываешь, когда долго крутишь одну и ту же задачу. Вот довольно универсальный промт для проверки: Ты — аналитик, специалист по постановке задач и тестированию. Я пришлю тебе текст ТЗ или описание задачи. Твоя цель — найти возможные “слепые зоны”: места, где могут появиться разные трактовки, неочевидные сценарии или недостающие данные. Проанализируй задачу и верни список пунктов вида: 1. Потенциальная слепая зона — <описание> Почему важно — <пояснение> Как уточнить — <предложение конкретного уточнения в тексте ТЗ> Можно просто ставить задачу и получить взгляд со стороны. Но помните о конфиденциальности важных данных. 💡 Ваши лайки помогают продвигать блог 💰 Донаты заставляют писать дальше 📖 Все тексты - на igorkolosov.ru