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