Знакомьтесь: успешная компания, которая решила двигаться в ногу со временем и автоматизировать свои процессы с помощью low-code платформы. После тендера и заключения договора с исполнителем, она нашла опытного интегратора и ушла создавать идеальное ТЗ. После года напряжённой работы, когда множество деталей было учтено и всё казалось готовым к запуску, вступила в игру реальность: приоритеты компании изменились, бюджет был пересмотрен, а идеальное ТЗ уже не отвечало актуальным потребностям. И таких примеров — множество. Как оказалось техническое задание сегодня способно пустить на дно даже небольшой проект, не говоря уже про амбициозные решения. Давайте вместе с ведущим аналитиком Comindware Игорем Простоквашиным разберём этот кейс в деталях и поймем, как избежать подобных ловушек при планировании IT-проектов.
Рояль в кустах
Мы в Comindware, как исполнители, работаем с заказчиками, которые обычно инициируют проекты через получение оценок на их реализацию. Обычно, прежде чем начать работу клиенты создают техническое задание (ТЗ) и только после этого начинается работа над проектом. Но тот документ, который мы получаем на старте проекта, я бы не назвал техническим заданием в его каноническом виде. Это скорее функциональные требования. На основе этих требований заказчик формирует свои требования к функционалу, а исполнители предоставляют сроки и стоимость. Однако, очень часто эти функциональные требования описывают лишь общие возможности системы, например, удобство, задачи, уведомления, печатные формы, интеграции и так далее. Отсутствует детализация, ответы на вопросы о том, как именно система должна функционировать или интегрироваться. За этой поверхностностью часто скрываются сложности, которые можно сравнить с "роялем в кустах" или неожиданными препятствиями.
Заказчик, из-за неопределенности с интеграторами, партнерами и платформами, не может составить конкретное техническое задание. Например, он не может детально описать, как пользователь с определенной ролью взаимодействует с системой. Без видения будущей системы, заказчики часто не могут детализировать свои требования. К тому моменту, когда они выбирают исполнителей через тендеры или конкурсы, требования могут измениться или что-то уже может быть упущено.
На основе функциональных требований от заказчика мы делаем оценки сроков и стоимости, после чего начинаем работу над проектом. Однако, заказчики часто хотят уже на старте увидеть детальное описание того, что мы, бизнес-аналитики, будем делать, вплоть до конкретных полей и интеграционных схем. Такая детализация требует времени, сопоставимого с реализацией самого решения.
Приведу два примера. Первый касается крупного производителя тяговых составов. Они нуждались в CRM-системе для управления продажами. Платформа Comindware была выбрана для реализации проекта. На старте заказчик решил работать с внешним интегратором для составления технического задания. Этот процесс занял почти год, после чего работы на проекте начались.
Второй кейс — заказчик предоставил нам верхнеуровневые функциональные требования и стал разрабатывать ТЗ. Еще весной прошлого года мы рассчитывали что к достаточно быстро закончим проект и передадим его результаты. Но техническое задание от заказчика пришло лишь через год. Процесс затянулся, у заказчика изменились условия, в результате чего проект был приостановлен. Несмотря на то, что мы были готовы к работе, реализация так и не началась из-за долгой подготовки документации.
Работать без ТЗ?
Многие могут возразить: "Как можно начать работу, не имея четкого понимания требований?" Но вот тут и кроется наша инновация. Вместо того чтобы следовать традиционной модели разработки, мы предлагаем экспериментальный подход. С помощью современных инструментов, таких как наши, можно сразу приступать к проектированию. Да, мы можем столкнуться с ошибками, но благодаря гибкости Comindware Business Application Platform, их можно быстро исправить.
Представьте, что перед вами стоит задача построить мост через железную дорогу. Традиционный подход предполагает долгие исследования и планирование. Но что, если у нас есть новый материал, который позволяет быстро создавать и корректировать конструкции? Вместо длительного проектирования можно сразу создавать решения, исправлять их или перестраивать. Зато все будет предельно практично, наглядно и соответствовать ожиданиям и реальным возможностям.
Тем не менее, для многих заказчиков, особенно в государственном секторе, техническое задание остается критически важным документом — с точки зрения внутренней отчетности или по другим бюрократическим причинам — “у нас так принято”. И здесь мы иногда идем на хитрость. Вместо того чтобы писать ТЗ на начальном этапе, мы предлагаем разработать его ближе к завершению проекта. Таким образом, оно будет отражать реальное решение, которое было создано.
Конечно, в начале проекта отсутствие четкого технического задания может вызвать ряд вопросов. Например, что именно будет утверждать руководство со своей стороны. И тут, повторюсь, что заказчики часто предоставляют лишь функциональные требования. Например, они могут указать на необходимость создания системы управления продажами, которая будет обладать определенными функциями, такими как ввод карточки контрагента или интеграция с телефонией. Однако дьявол кроется в деталях. Что именно подразумевается под "карточкой контрагента"? Сколько полей она будет содержать? Какова ее структура?
Такая неопределенность может привести к недопониманию и дополнительным затратам в будущем. Например, упоминание "калькулятора коммерческого предложения" может оказаться гораздо более сложной задачей, чем предполагалось изначально.
Главное в процессе разработки — гибкость
Бизнес-аналитики должны быть готовы быстро адаптироваться и корректировать свои действия на основе полученной информации. Если определенная функция оказывается слишком сложной или затратной, возможно, стоит пересмотреть приоритеты.
И в этом случае техническое задание становится живым документом, который формируется на протяжении всего проекта, уточняясь и дополняясь. Такой подход помогает определить, что именно будет включено в конечную систему, и служит основой для дальнейшей работы. И, да, часто четкое ТЗ формируется на более поздних этапах разработки, когда становится предельно понятно, что именно должна представлять собой законченная система.
И тут многие могут сказать, мол отсутствие долгой и четкой проработки проекта на старте играет на руку тем, кто продает платформу. Но в нашем случае продажа уже произошла. Предлагая подход, при котором техническое задание уходит на второй план, я не стремлюсь ускорить продажу. В любом случае, клиент приходит с небольшим документом, ожидая оценки стоимости. И часто все это напоминает ситуацию, когда человек обращается к строителю с вопросом о стоимости дома, не уточняя сколько у него будет этажей. Мол, вы просто скажите сколько будет стоить построить дом, а число этажей и другие детали я вам скажу уже во время строительства. Часто очень похожие запросы мы видим в сфере ИТ и автоматизации процессов в бизнесе. Клиенты часто предоставляют лишь поверхностные требования, не углубляясь в детали. Например, они могут запросить "калькулятор", не уточняя его сложность и функционал.
Да, наша задача — выяснить, что именно они имеют в виду, и оценить объем работы.
Мы работаем с этими требованиями, уточняя их и пытаясь понять глубину задачи. Если клиент хочет сложный калькулятор, это может занять гораздо больше времени и ресурсов. Наша цель — помочь управлять этой функциональностью, показать клиенту как можно определять приоритеты и планировать возможные изменения. Техническое задание, в классическом понимании, формируется ближе к концу проекта. Оно становится результатом нашего детального анализа и обсуждения с заказчиком. Этот документ описывает функционал системы, а также служит основой для тестирования и инструкций для пользователей.
«Представьте, что вы купили «Феррари», а водите ее так, будто у вас «Фиат»
Современные подходы к разработке, такие как Low-code, позволяют нам быстро приступить к настройке системы, не тратя время на подготовку обширной документации. Но это не означает, что мы игнорируем важность планирования и анализа. Наша цель — эффективно сочетать быстродействие и качество. Вспомните футболиста Златана Ибрагимовича, который был приобретен Барселоной, но «использовался» не по назначению. Говоря о стратегии своего тренера Хосепа Гвардьолы он сказал: «Представьте, что вы купили «Феррари», а водите ее так, будто у вас «Фиат». Это похоже на ситуацию, когда вам предоставляют современный инструмент в виде low-code платформы, но вы используете устаревший подход Waterfall. Вы тратите много времени на написание технического задания, а потом осознаете, что возникают различные несоответствия.
Разве не легче начать кодирование и уже увидеть результат работы сайта или системы, чем тратить два месяца на описание, где требуется фантазия? Ведь в таком случае вы ничего конкретного не видите. Простой пример — заказчик предлагает, создать кнопку зеленого цвета. Но как она будет выглядеть на практике? Возможно, было бы проще сразу что-то визуализировать. Однако, когда вы начинаете это делать, вам говорят подождать, составить техническое задание. В итоге, когда дело доходит до реализации и вы добавите фон, поля и др элементы формы, то увидите, что все это перекрывает кнопку. Без визуализации это было сложно понять.
Low-code — это Феррари, это действительно гибкий инструмент. Он позволяет быстро получать визуализацию решений и разрабатывать проект в условиях, когда результат можно получить быстрее ТЗ, и даже если этот результат заказчика не устроит — быстро внести нужные исправления.
И тут возникает резонный вопрос о том, насколько часто техническое задание соответствует реальной разработке? Можно сказать, что в большинстве случаев (около 95%) это так. Однако иногда заказчики могут предоставить нечеткие требования, которые сложно интерпретировать. Например, требование о реализации календарного представления может оказаться желанием создать что-то похожее на Outlook, что является огромной задачей. Иногда заказчики не понимают последствий своих требований, и это может привести к дополнительным сложностям в разработке.
Например, сейчас мы работаем с крупной промышленной компанией России. Она очень тщательно подошла к описанию требований и детализировала их включая описание экранных форм и полей. Мы начали реализацию, исходя из предоставленных данных. Однако в дальнейшем обсуждении задачи с заказчиком выяснилось, что требования стали более сложными. Например, изначальная форма из трех полей превратилась в форму с 30 полями, так как клиент хотел включить больше опций выбора материала. Этот пример показывает, насколько важно глубоко понимать потребности клиента и быть готовым к изменениям в ходе проекта.
«Без ТЗ нужно уметь управлять функциональностью»
Мы сталкиваемся с ситуацией, когда заказчик не готов вкладывать ресурсы в разработку ТЗ до заключения контракта. Клиенты часто хотят понимать сроки и стоимость заранее. Оптимальный вариант – когда заказчик предоставляет функциональные требования, на основе которых производится оценка проекта. Но даже при этом может возникнуть проблема "раздувания" проекта и превышения бюджета. Для контроля бюджета без конкретного ТЗ нужно уметь управлять функциональностью: детализировать и оценивать её.
Пример: можно начать с грубой оценки — калькулятор стоит, условно, 500 тысяч, интеграция — условный миллион, и так далее. Но когда начинаются уточнения, стоимость может меняться. Если заказчик решает усовершенствовать калькулятор, его стоимость может возрасти в 3 раза. Тогда приходится искать компромиссы в других частях проекта.
Этот подход может казаться неидеальным. Ведь, представьте, что вы решаете купить автомобиль, нацелившись на определенные функциональные характеристики, но в итоге получаете не то, что ожидали. Это как выбирать автомобиль, ориентируясь на функции и комплектацию через онлайн-конфигураторы, а в итоге получать что-то другое. Но вы понимаете, что при одном бюджете и заданных сроках нужно управлять функциональностью автомобиля. Это похоже на выбор определенных характеристик или наличие или отсутствия адаптивного круиз-контроля. Вы замечаете, что какие-то функции, например, регулировка сиденья или механизм открывания крыши, могут быть иными, чем вы думали. Тест-драйв может помочь разобраться, но ведь невозможно опробовать все модели.
Основные параметры проекта включают в себя сроки, бюджет и требования к функциональности. Если заказчик понимает, что определенная функция, к которой у него изменились требования, потребует дополнительных вложений или времени, он может принять решение о корректировке бюджета и сроков.
Существует несколько терминов, используемых для описания технической документации. Техническое задание (ТЗ) — это один из них, но иногда оно может быть неполным или недостаточно детализированным. В таких случаях используются другие документы, например, частное техническое задание (ЧТЗ) или пользовательские сценарии. Они описывают, как система должна функционировать в конкретных условиях. Важно понимать, что начальные требования и конечные технические документы могут различаться.
Если на начальном этапе предоставлены лишь общие требования, то нашим ответом будет детальное техническое задание. В случае, когда заказчик предоставляет документ, который он называет ТЗ, но это лишь стандартные документы по ГОСТу, мы отмечаем, что такой документ слишком обобщен. Применительно к автомобилю, представьте, что требованиями были: 4 колеса, кузов, багажник, подсветка и дизельный двигатель. По таким требованиям можно получить дизельный трактор с подсветкой. Поэтому требования всегда требуют уточнения.
При использовании гибкого инструмента low-code, можно визуализировать процесс создания продукта. Представьте, что вы приходите на завод, где множество деталей, и начинаете создавать автомобиль в непосредственном сотрудничестве с заказчиком. Вы обсуждаете каждую деталь, спрашиваете, какую гайку предпочитает заказчик, где он хочет видеть определенные элементы в машине. Заказчик, таким образом, участвует в процессе создания своего автомобиля, будь то BMW или Bentley, и каждая мелочь настраивается согласно его пожеланиям. Именно благодаря гибкости нашего инструмента мы можем быстро адаптировать требования и вносить изменения на лету, учитывая пожелания заказчика. И это, позволяет отказаться от ТЗ на старте и сделать реализацию проектов значительно быстрее.
