В отношениях между разработчиками и заказчиками иногда возникают сложности. Заказчик часто хочет, чтобы «работало в один клик», «клиенты сами появлялись в базе» и «был красивый интерфейс с удобными кнопками». Разработчик тем временем говорит о каких-то подкапотных вещах, хотя сказано же – «красивый интерфейс». Это недопонимание может обернуться серьезными последствиями.
Техзадание помогает найти общий язык. Документ полезен для всех сторон – при написании заказчик может структурировать свои бизнес-процессы, пожелания, улучшения, а для разработчиков техзадание служит инструкцией. Самое главное, что это – исходный документ всего проекта, эталон, которому надо стараться соответствовать и с помощью которого можно решать практически все спорные вопросы.
Кто станет владельцем продукта?
Первично в проекте не техзадание, а владелец продукта. Это такой человек, который назначается ответственным за разработку. Он должен встречаться с программистами и давать им задачи – управлять процессом создания продукта. Он – 80% успеха проекта.
Потом мы ждем минимальное техзадание. В нем не должно быть много текста, ведь это первоначальный вариант документа. Главное – описать структуру бизнес-процессов и указать, какие именно моменты нужно оптимизировать.
Компания понимает, что у нее есть огромный потенциал роста, но из-за того, что не получается решить проблемы существующими инструментами, она теряет деньги. Соответственно, владелец продукта должен знать все про эти узкие места и досконально разбираться в бизнес-процессах своей компании. Когда человек на эту должность выбран, то составить структуру техзадания уже не так сложно.
Из чего состоит минимальное техзадание
При составлении техзадания советую придерживаться принципа «от простого к частному». Сначала можно идти по верхам: описывать разделы, которые измеряются интерфейсами. Важно на этом этапе не отвлекаться на детали. Они будут потом.
Далее опишите разделы будущей системы – например, «Главная», «Клиенты», «Справочник», «Склад». Потом подразделы – «Карточка клиента», «Просмотр заявки» и так далее. Для каждого раздела указывайте его предназначение: для чего он нужен и какие вопросы в нем решаются.
Самые принципиальные разделы – это те, в которых на текущий момент происходят сбои в работе или задержки. Их нужно обязательно отразить в документе. Вот и все. Минимальное техзадание готово.
Сначала – бизнес-процессы, потом – интерфейсы
В основе любого ПО – бизнес-процессы и логика. Уже потом – интерфейсы, кнопки и прочая красота.
Самый забавный момент заключается в том, что неопытные менеджеры во главу угла выносят интерфейсы – мол, все должно быть по канонам UI/UX. Фактически они акцентируют внимание на второстепенном, забывая про самое важное – бизнес-логику. А ИТ-директора часто считают самым важным устойчивость системы к нагрузкам и DDoS-атакам.
Зачастую структура техзадания зависит от того, кто его пишет и в какую сторону профессионально деградирует (кто-то – в дизайн, кто-то – в оборудование, а кто-то – в администрирование).
Нам нужен владелец продукта, который в первую очередь заинтересован в автоматизации бизнес-процессов. Он понимает, как обрабатываются заявки и печатаются документы. Ему важны те процессы, которые происходят каждый день и их можно охарактеризовать одним словом – например, «склад», «продажи», «клиенты», «печать документов». Тогда мы понимаем, что перед нами серьезные ребята, которые думают о бизнесе, а не о количестве звездочек и цвете интерфейса.
Что касается интерфейсов, то сегодня можно найти готовые профессиональные шаблоны на любой вкус. Существуют четкие стандарты того, как делать системы удобными и красивыми, поэтому продолжать рассуждения об интерфейсах в рамках этой статьи больше не хочется.
Выбирайте тот язык, который понятен заказчику
В ИТ-среде люди часто используют профессиональную лексику, которая не особо знакома бизнесу из других сфер. Но описывать техзадание нужно тем языком, который понятен заказчику, потому что именно ему в итоге принимать работу.
Не стесняйтесь задавать вопросы, если вам непонятен термин. Чтобы избежать субъективности в понятиях, определения лучше согласовывать. Вообще, компании, которым необходимо ПО, как правило, знают, чего хотят, а слова для объяснения найдутся.
Не ограничивайте себя в изложении мыслей и процессов, ведь создание технического задания, как бы это странно ни звучало, – творческий процесс. Но важно помнить про святое правило: гениальность – в простоте.
Как пишется окончательное техзадание
Окончательный вариант техзадания всегда пишется разработчиками, но в тесной связке с владельцем продукта. Лишь в постоянном диалоге можно сформировать качественный документ, который охватит все тонкости разработки.
А самое главное, что ТЗ задает темп, по нему можно понять, как мы будем двигаться дальше и в каком формате. Это как тренировочные забеги с проверкой возможностей друг друга. Должна случиться синергия, и она случается, когда заказчик знает, чего хочет, а разработчик понимает, как он это сделает.
Итак, техзадание – это документ, который, с одной стороны, учитывает требования заказчика, с другой – определяет ход и темп разработки проекта. Поэтому в нашей компании техзадание всегда включает:
- документ с описанием структуры, разделов, бизнес-логики и прочих важных по мнению сторон вещей;
- бэклог (описание задач по каждому разделу);
- прототипы (интерактивные интерфейсы системы), с помощью которых можно согласовать все процессы работы компании в будущем ПО; я считаю, что прототипы должны быть в техзадании по умолчанию, но на рынке это не обязательно.
Такой комплект уже можно передавать в работу, а минимальное техзадание больше нужно для оценки проекта: стоимости и сроков реализации.
Почему важно общаться с разработчиками
Техзадание – это подготовка к подписанию договора, поэтому заказчик и разработчик отвечают с его помощью на все свои вопросы. Документ служит каркасом для построения системы, поэтому в идеале он должен отражать всю необходимую информацию.
Но жизнь есть жизнь, и поэтому всегда остаются вещи, которые были упущены в силу каких-то обстоятельств. В таком случае все зависит от опыта разработчика (да, именно разработчика), а не заказчика.
Дело в том, что заказчик обычно верит, что программисты сделают все, как надо, а у разработчика, наоборот, появляются риски, потому что какие-то вещи оказались не учтены, а значит, не заложены в стоимость проекта.
Мы всегда придерживаемся принципа, что бизнес-процессы должны быть замкнутыми – если в цепочке не хватает какого-то звена, мы его ищем и добавляем. Такие вещи все-таки должны быть отражены в техзадании.
Сам по себе документ не спасет от несогласованности между бизнесом и исполнителем. Однако помогает подход, когда клиент принимает участие в создании продукта. Именно для этого и нужен бэклог, чтобы поэтапно двигаться по всем пунктам системы. При этом заказчику достаточно общаться с разработчиками два раза в неделю.
Но стоит отказаться от идеи реализовывать проект без клиента – такой подход несет много боли и печали.
Почему разработчикам не стоит всегда прикрываться техзаданием
Иногда во время разработки возникают причины, по которым все же приходится отклоняться от техзадания. Естественно, это влияет и на стоимость проекта. Если мы говорим о заказном ПО, то это системы, которые создаются под особенности бизнеса.
Когда заказчик просит сделать то, что выходит за рамки документа, включаются простые человеческие отношения. Тот, кто хочет разругаться с клиентом, будет говорить: «А мы это в ТЗ не учитывали!» Но сразу возникнет обратный вопрос: «Почему вы это не учли в ТЗ?»
Разработка – это отношения между взрослыми и опытными личностями. Только есть нюанс – заказчик, как правило, думает, что все согласовано, и картинка в его голове будет непременно реализована. Так что, разработчики, помните – на вас ответственность, и техзадание на самом деле больше нужно вам, а не заказчику!
В итоге
Успешное техзадание, как и проект в целом, во многом зависит от двух вещей – опыта разработчика в создании продуктов и уровня понимания заказчиком бизнес-процессов своей компании.
Главное, чтобы документ отвечал на все важные вопросы. Чем больше деталей вы обсудите в начале проекта, тем быстрее и качественнее он будет реализован. Если же процесс изначально идет туго, то заказчику стоит задуматься о смене подрядчика.
