Есть легенда, что хорошее ТЗ сначала появляется в голове бизнеса, потом аккуратно превращается в текст и уже после этого попадает к разработчику. Это, конечно, неправда.

На самом деле путь ТЗ выглядит примерно так.

1. Бизнес — Нам нужно, чтобы пользователю стало удобнее. — Что именно должно стать удобнее? — Ну… всё. — А как? — Ну вы же разработчики. Придумайте, как лучше. И на этом этапе рождается первая версия ТЗ: «Сделать удобно».

2. PM Проджект-менеджер выслушивает бизнес, кивает, записывает всё, что понял, и переводит это на язык корпоративного оптимизма: «Необходимо реализовать улучшение пользовательского опыта в части взаимодействия с системой». Готово. Бизнес доволен. PM доволен. Никто ничего не понял.

3. Разработка Задача попадает в разработку. Через 7 минут: — Мы сейчас весь проект переделываем? — Нет, давайте просто впихнём это сюда. — Куда «сюда»? — Ну… куда-нибудь. — А как оно должно работать? Пауза. — А вот это уже хороший вопрос. Начинается археологическое исследование существующей системы.

4. Вопросы летят обратно PM Список небольшой: Что именно должен делать пользователь? В какой момент? А если он сделал наоборот? А если два раза? А если вообще не сделал? Кто имеет право? Что происходит после? Что происходит до? Почему? А зачем? И где-то внизу: «Можете, пожалуйста, описать бизнес-логику?»

5. Ответ PM Через несколько часов приходит ответ: «Пользователь должен иметь возможность сделать это стандартным способом. При этом в некоторых случаях необходимо предусмотреть альтернативный сценарий. Но только если это необходимо». Разработка: — Что значит «если необходимо»? PM: — Ну, по ситуации. Разработка: — По какой? PM: — По бизнес-ситуации. Прекрасно. ТЗ стало ещё понятнее.

6. Tech Lead Tech Lead открывает задачу. Закрывает. Открывает снова. Смотрит в потолок. Достаёт валерьянку. — Так… Значит, можно сделать через текущую архитектуру… Пауза. — …или не можно. Ещё пауза. — Ладно. Сначала посмотрим. И начинает мысленно проектировать систему, которой пока нет, но которая уже вызывает боль. 7. Разработчик Наконец задача приходит разработчику. Он читает её три раза. На четвёртый раз начинает подозревать, что проблема не в нём. На пятом решает: «Ладно. Сделаю так, как это логично сделать». И делает. Работает. Красиво. Архитектурно. Возможно даже лучше, чем просили. Правда, никто не знает, просили ли именно это.

8. Тестировщик Тестировщик получает задачу. Читает ТЗ. Потом код. Потом начинает придумывать собственную реальность. — А почему пользователь здесь может сделать А? Разработчик: — Потому что так написано в ТЗ. — А должен делать Б. — Где это написано? — Это очевидно. Вот это страшное слово. «Очевидно». После него обычно начинается изменение бизнес-логики. Через пару часов исходный сценарий выглядит примерно так: Бизнес хотел: А → Б → В PM записал: А → В → Б Разработчик сделал: А → Б → В, но технически правильно Тестировщик считает правильным: В → Г → Б → А → почему вообще пользователь здесь?

9. Доработка Тестировщик: «Не принято. Не соответствует ожидаемому поведению». Разработчик: — Какому? Тестировщик: — Ожидаемому. — Кем ожидаемому? — Бизнесом. Бизнес в этот момент впервые узнаёт, что от него чего-то ожидали. Теперь валерьянку пьют двое.

10. PM И тут появляется PM. Каждый час: — Ну когда? — Ещё делаем. Через час: — Ну когда? — Всё ещё делаем. Через час: — Ну что там? — Там всё ещё то же самое. Через час: — А можем сегодня? Разработчик медленно закрывает ноутбук. Tech Lead молча смотрит в стену. Тестировщик открывает новый баг.

11. Финал Начинает нервничать PM. Потом разработчик. Потом Tech Lead. Потом тестировщик. Потом бизнес. А затем все собираются на созвоне. Бизнес: — Коллеги, а почему всё так сложно? Разработка: — Потому что изначально было непонятно, что нужно сделать. PM: — Но я же всё записал! Тестировщик: — А я всё проверил! Tech Lead: — А я вообще ничего не трогал. Я только планировал. Тишина. И тут кто-нибудь произносит: «Давайте ещё раз обсудим, что именно мы хотим сделать». #ТЗ #юмор