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