Колонки

Формула успешного техзадания. Как найти общий язык с разработчиками?

Колонки
Петр Загребельный
Петр Загребельный

Совладелец компании «Деасофт»

Софья Федосеева

В отношениях между разработчиками и заказчиками иногда возникают сложности. Заказчик часто хочет, чтобы «работало в один клик», «клиенты сами появлялись в базе» и «был красивый интерфейс с удобными кнопками». Разработчик тем временем говорит о каких-то подкапотных вещах, хотя сказано же – «красивый интерфейс». Это недопонимание может обернуться серьезными последствиями. 

Совладелец компании «Деасофт» Петр Загребельный рассказывает, как написать качественное техническое задание на разработку ИТ-продукта для бизнеса.

Формула успешного техзадания. Как найти общий язык с разработчиками?

Техзадание помогает найти общий язык. Документ полезен для всех сторон – при написании заказчик может структурировать свои бизнес-процессы, пожелания, улучшения, а для разработчиков техзадание служит инструкцией. Самое главное, что это – исходный документ всего проекта, эталон, которому надо стараться соответствовать и с помощью которого можно решать практически все спорные вопросы. 

Фото: Unsplash

Мы занимаемся автоматизацией среднего и крупного бизнеса, поэтому все рассуждения будут именно в этом ключе. Но принципы написания техзадания для разработки ПО, приложений, сервисов, в целом, примерно одни и те же. 

Подписывайтесь на канал Rusbase в «Яндекс.Дзен», чтобы ничего не пропустить

Кто станет владельцем продукта?

Первично в проекте не техзадание, а владелец продукта. Это такой человек, который назначается ответственным за разработку. Он должен встречаться с программистами и давать им задачи – управлять процессом создания продукта. Он – 80% успеха проекта. 

Потом мы ждем минимальное техзадание. В нем не должно быть много текста, ведь это первоначальный вариант документа. Главное – описать структуру бизнес-процессов и указать, какие именно моменты нужно оптимизировать. 

Обычно компании приходят к идее создания своего ПО в тот момент, когда бизнес уже работает и приносит деньги, но есть «бутылочные горлышки», в которых случаются задержки, остановки и сотрудники не могут переварить и обработать информацию. 

Компания понимает, что у нее есть огромный потенциал роста, но из-за того, что не получается решить проблемы существующими инструментами, она теряет деньги. Соответственно, владелец продукта должен знать все про эти узкие места и досконально разбираться в бизнес-процессах своей компании. Когда человек на эту должность выбран, то составить структуру техзадания уже не так сложно. 


Из чего состоит минимальное техзадание

При составлении техзадания советую придерживаться принципа «от простого к частному». Сначала можно идти по верхам: описывать разделы, которые измеряются интерфейсами. Важно на этом этапе не отвлекаться на детали. Они будут потом.

Далее опишите разделы будущей системы – например, «Главная», «Клиенты», «Справочник», «Склад». Потом подразделы – «Карточка клиента», «Просмотр заявки» и так далее. Для каждого раздела указывайте его предназначение: для чего он нужен и какие вопросы в нем решаются. 

Фото: Unsplash

Самые принципиальные разделы – это те, в которых на текущий момент происходят сбои в работе или задержки. Их нужно обязательно отразить в документе. Вот и все. Минимальное техзадание готово. 


Сначала – бизнес-процессы, потом – интерфейсы

В основе любого ПО – бизнес-процессы и логика. Уже потом – интерфейсы, кнопки и прочая красота. 

Самый забавный момент заключается в том, что неопытные менеджеры во главу угла выносят интерфейсы – мол, все должно быть по канонам UI/UX. Фактически они акцентируют внимание на второстепенном, забывая про самое важное – бизнес-логику. А ИТ-директора часто считают самым важным устойчивость системы к нагрузкам и DDoS-атакам. 

Зачастую структура техзадания зависит от того, кто его пишет и в какую сторону профессионально деградирует (кто-то – в дизайн, кто-то – в оборудование, а кто-то – в администрирование). 

Нам нужен владелец продукта, который в первую очередь заинтересован в автоматизации бизнес-процессов. Он понимает, как обрабатываются заявки и печатаются документы. Ему важны те процессы, которые происходят каждый день и их можно охарактеризовать одним словом – например, «склад», «продажи», «клиенты», «печать документов». Тогда мы понимаем, что перед нами серьезные ребята, которые думают о бизнесе, а не о количестве звездочек и цвете интерфейса. 

Что касается интерфейсов, то сегодня можно найти готовые профессиональные шаблоны на любой вкус. Существуют четкие стандарты того, как делать системы удобными и красивыми, поэтому продолжать рассуждения об интерфейсах в рамках этой статьи больше не хочется. 


Выбирайте тот язык, который понятен заказчику

В ИТ-среде люди часто используют профессиональную лексику, которая не особо знакома бизнесу из других сфер. Но описывать техзадание нужно тем языком, который понятен заказчику, потому что именно ему в итоге принимать работу. 

Не стесняйтесь задавать вопросы, если вам непонятен термин. Чтобы избежать субъективности в понятиях, определения лучше согласовывать. Вообще, компании, которым необходимо ПО, как правило, знают, чего хотят, а слова для объяснения найдутся. 

Не ограничивайте себя в изложении мыслей и процессов, ведь создание технического задания, как бы это странно ни звучало, – творческий процесс. Но важно помнить про святое правило: гениальность – в простоте. 


Как пишется окончательное техзадание

Окончательный вариант техзадания всегда пишется разработчиками, но в тесной связке с владельцем продукта. Лишь в постоянном диалоге можно сформировать качественный документ, который охватит все тонкости разработки. 

А самое главное, что ТЗ задает темп, по нему можно понять, как мы будем двигаться дальше и в каком формате. Это как тренировочные забеги с проверкой возможностей друг друга. Должна случиться синергия, и она случается, когда заказчик знает, чего хочет, а разработчик понимает, как он это сделает. 

Фото: Unsplash

Итак, техзадание – это документ, который, с одной стороны, учитывает требования заказчика, с другой – определяет ход и темп разработки проекта. Поэтому в нашей компании техзадание всегда включает:

  1. документ с описанием структуры, разделов, бизнес-логики и прочих важных по мнению сторон вещей;
  2. бэклог (описание задач по каждому разделу);
  3. прототипы (интерактивные интерфейсы системы), с помощью которых можно согласовать все процессы работы компании в будущем ПО; я считаю, что прототипы должны быть в техзадании по умолчанию, но на рынке это не обязательно. 

Такой комплект уже можно передавать в работу, а минимальное техзадание больше нужно для оценки проекта: стоимости и сроков реализации. 


Почему важно общаться с разработчиками

Техзадание – это подготовка к подписанию договора, поэтому заказчик и разработчик отвечают с его помощью на все свои вопросы. Документ служит каркасом для построения системы, поэтому в идеале он должен отражать всю необходимую информацию. 

Но жизнь есть жизнь, и поэтому всегда остаются вещи, которые были упущены в силу каких-то обстоятельств. В таком случае все зависит от опыта разработчика (да, именно разработчика), а не заказчика. 

Дело в том, что заказчик обычно верит, что программисты сделают все, как надо, а у разработчика, наоборот, появляются риски, потому что какие-то вещи оказались не учтены, а значит, не заложены в стоимость проекта.

Фото: Unsplash

Мы всегда придерживаемся принципа, что бизнес-процессы должны быть замкнутыми – если в цепочке не хватает какого-то звена, мы его ищем и добавляем. Такие вещи все-таки должны быть отражены в техзадании.

Сам по себе документ не спасет от несогласованности между бизнесом и исполнителем. Однако помогает подход, когда клиент принимает участие в создании продукта. Именно для этого и нужен бэклог, чтобы поэтапно двигаться по всем пунктам системы. При этом заказчику достаточно общаться с разработчиками два раза в неделю. 

Но стоит отказаться от идеи реализовывать проект без клиента – такой подход несет много боли и печали. 


Почему разработчикам не стоит всегда прикрываться техзаданием

Иногда во время разработки возникают причины, по которым все же приходится отклоняться от техзадания. Естественно, это влияет и на стоимость проекта. Если мы говорим о заказном ПО, то это системы, которые создаются под особенности бизнеса.

Когда заказчик просит сделать то, что выходит за рамки документа, включаются простые человеческие отношения. Тот, кто хочет разругаться с клиентом, будет говорить: «А мы это в ТЗ не учитывали!» Но сразу возникнет обратный вопрос: «Почему вы это не учли в ТЗ?» 

Разработка – это отношения между взрослыми и опытными личностями. Только есть нюанс – заказчик, как правило, думает, что все согласовано, и картинка в его голове будет непременно реализована. Так что, разработчики, помните – на вас ответственность, и техзадание на самом деле больше нужно вам, а не заказчику! 


В итоге

Успешное техзадание, как и проект в целом, во многом зависит от двух вещей – опыта разработчика в создании продуктов и уровня понимания заказчиком бизнес-процессов своей компании. 

Главное, чтобы документ отвечал на все важные вопросы. Чем больше деталей вы обсудите в начале проекта, тем быстрее и качественнее он будет реализован. Если же процесс изначально идет туго, то заказчику стоит задуматься о смене подрядчика.


Фото на обложке: Unsplash

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Как избежать недопонимания с заказчиком? Восемь советов для эффективной работы
  2. 2 «Многие заказчики просто не дают права на ошибку». Кейсы бизнес-авиации
  3. 3 Пять стоп-фраз, которые помогут определить неадекватного заказчика
  4. 4 Как заказчикам и разработчикам приложений понять друг друга — четыре совета
  5. 5 «И со шрифтами там поиграйте»: как официально обезопасить себя от тысяч правок заказчика

Актуальные материалы —
в Telegram-канале @Rusbase