Примерно треть клиентов начинает первый разговор со мной с извинения: «Вы знаете, у нас даже ТЗ нет…». Спешу успокоить: это не проблема. Хуже, когда происходит обратное – мне приносят выстраданный за три месяца документ на сорок страниц, и уже по диагонали видно, что половину придётся переделывать. Расскажу, почему так получается и что на самом деле нужно для старта.
Почему толстое ТЗ не спасает
Техническое задание фиксирует решение. Но чтобы зафиксировать решение, нужно сначала проверить задачу: кто пользователи, что у них болит, какие ограничения есть у бизнеса. Если ТЗ писалось до этих проверок – а именно так пишется большинство ТЗ, – оно фиксирует чьи-то фантазии о продукте. Дорогие фантазии: каждая страница такого документа потом конвертируется в переделки за ваши же деньги.
Есть и вторая беда. ТЗ, написанное внутри компании, почти всегда воспроизводит текущий уклад: «сделайте как у нас сейчас, только в программе». В статье про CRM я уже говорил: автоматизированный хаос – это просто очень быстрый хаос. Увековечивать привычный беспорядок в коде – худшая инвестиция из возможных.
ТЗ, написанное до погружения в задачу, фиксирует фантазии о продукте.
Что реально нужно для первой встречи
Всего три вещи, и все – своими словами, без единого технического термина.
- Что происходит сейчас. Как устроен процесс, где теряются деньги или время, что раздражает вас и сотрудников.
- Кто сталкивается с проблемой. Менеджеры? Клиенты? Вы сами, по вечерам, в Excel?
- Какой результат изменит ситуацию. Например: «хочу, чтобы заявка обрабатывалась за час, а не за день».
Это всё. Серьёзно. Такой рассказ на одну страницу полезнее сорокастраничного ТЗ, потому что описывает саму задачу. Решение – это уже наша совместная работа на этапе погружения.
Что происходит после погружения
Дальше появляются сценарии пользователей, границы первого релиза, прототип и архитектурные решения. Именно в этот момент – и не раньше – можно осмысленно оценивать сроки и бюджет. Всё, что вам называют до этого, – гадание. Иногда вежливое, иногда наглое, но гадание.
Прототип здесь – ключевое слово. Кликабельный макет или тонкий работающий срез продукта отвечает на вопросы быстрее любых совещаний. Например, прототип диспетчерской для автопарка на полторы сотни машин мы собрали за три недели – и именно он показал заказчику, что подход рабочий. Посмотрите сами:
Кейс: прототип диспетчерской автопарка за три недели
Когда без ТЗ всё-таки нельзя
Для честности: есть ситуации, где подробное ТЗ обязательно. Тендеры и госзаказ – там без документа никуда. Контракт с жёсткой фиксированной ценой – подрядчику нужно на что-то опираться юридически. Передача проекта другой команде – здесь документация вообще единственный способ не потерять знания. Но заметьте: во всех этих случаях ТЗ пишется после проектирования и фиксирует уже принятые решения.
Так что если у вас нет ТЗ – у вас всё в порядке. Вы просто ещё не потратили деньги на документ, который пришлось бы переделывать. Для старта достаточно рассказа о ситуации на одну страницу.