Юлий Минькин, директор по развитию проектного офиса
В проектах по созданию автоматизированных систем есть один документ, который часто становится причиной споров, недопонимания и даже конфликтов. Речь идет о техническом задании, или просто ТЗ. Казалось бы, что может быть проще? Берешь, описываешь, что нужно сделать, и вперед! Но не тут-то было.
Представьте, что вы заходите в ресторан и говорите официанту: "Приготовьте мне что-нибудь вкусненькое". Что вы получите в итоге? Скорее всего, недоумевающий взгляд и кучу уточняющих вопросов. Потому что "вкусненькое" – это слишком расплывчато и субъективно. Для кого-то это стейк, для кого-то – вегетарианский салат, а для кого-то – острая лапша по-тайски.
Так же и с техническим заданием. Многие считают, что достаточно написать "сделайте крутой сайт" или "нам нужна программа для управленческого учета", и разработчики сразу же побегут воплощать идею в жизнь. Но реальность немного сложнее.
Давайте разберемся, что же такое настоящее техническое задание и почему оно так важно.
Интересно, что несмотря на кажущуюся простоту понятия "техническое задание", в реальности существует множество интерпретаций этого термина. Кто-то считает ТЗ просто списком пожеланий, другие видят в нем подробную инструкцию для разработчиков. Однако мало кто знает, что в России существует официальный документ, регламентирующий, чем на самом деле является техническое задание.
Речь идет о ГОСТе 34.602-2020 "Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы". Этот стандарт четко определяет, что такое техническое задание и какую роль оно играет в процессе разработки.
Согласно ГОСТу, техническое задание – это основополагающий документ, который определяет требования и порядок создания автоматизированной системы. Иными словами, это не просто набор пожеланий или технических деталей, а структурированный перечень того, что должна делать система и как она должна создаваться.
Незнание или игнорирование этого стандарта часто приводит к созданию документов, которые называются "техническим заданием", но по сути таковыми не являются. Это может быть что угодно: от расплывчатого описания идеи до детальной спецификации программного кода. Такие псевдо-ТЗ не только не выполняют свою истинную функцию, но и могут стать источником конфликтов и недопонимания между заказчиком и исполнителем.
Понимание истинного назначения технического задания, закрепленного в ГОСТе, помогает избежать многих проблем и сделать процесс разработки более эффективным. Это своего рода "договор о намерениях" между заказчиком и исполнителем, четко определяющий, что должно быть сделано, но оставляющий простор для творческих и технических решений.
Начнем с того, что ТЗ – это не просто список пожеланий заказчика. Это не набросок идей на салфетке в кафе. И уж точно не детальная инструкция для программистов, как написать код.
Представьте, что вы решили построить дом. Вы же не просто приходите к строителям и говорите: "Постройте мне дом". Вы описываете, сколько этажей вам нужно, какая должна быть планировка, из каких материалов строить, какие коммуникации провести. Вы не указываете, какие материалы необходимы и как именно забивать гвозди или класть кирпичи – это уже дело профессионалов. Но вы четко формулируете, что хотите получить в итоге.
То же самое и с техническим заданием в IT-проекте. Это документ, который описывает, что должна делать система, но не как именно это должно быть реализовано. Это может показаться странным, но именно такой подход позволяет создавать действительно эффективные решения.
Допустим, вы заказываете разработку приложения для доставки еды. В техническом задании вы не будете писать "использовать язык программирования Python и фреймворк Scrum". Вместо этого вы опишете функции, которые должно выполнять приложение: "пользователь должен иметь возможность просматривать меню, добавлять блюда в корзину, оформлять заказ и отслеживать его статус".
Такой подход дает разработчикам свободу в выборе технических решений. Может быть, они предложат использовать более современные технологии, о которых вы даже не слышали. Или найдут способ реализовать ваши требования более эффективно, чем вы предполагали.
Но главное – техническое задание служит своего рода контрактом между заказчиком и исполнителем. Это документ, к которому обе стороны могут обратиться в случае споров или недопонимания. "Смотрите, мы договаривались именно об этом".
Конечно, в процессе работы над проектом могут возникнуть новые идеи или измениться требования. И это нормально! ТЗ – не высеченный в камне закон. Это живой документ, который может и должен меняться по мере развития проекта. Главное – чтобы все изменения были согласованы и зафиксированы.
Еще один важный момент: техническое задание – это не только про технологии. Хорошее ТЗ отвечает на вопрос "зачем?", а не только на вопрос "что?".
Например, если вы разрабатываете систему управления складом, в ТЗ важно указать не только, какие отчеты должна формировать система, но и зачем они нужны. Это поможет разработчикам лучше понять контекст и, возможно, предложить более эффективные решения.
Иногда кажется, что составление подробного технического задания – это лишняя трата времени. Особенно когда хочется побыстрее начать работу над проектом. Но поверьте, время, потраченное на качественное ТЗ, окупится сторицей. Это как хорошая подготовка перед путешествием: чем лучше вы спланируете маршрут, тем меньше неприятных сюрпризов вас ждет в пути.
Конечно, не стоит впадать в другую крайность и пытаться описать в ТЗ абсолютно все до мельчайших деталей. Техническое задание – это не художественный роман, и чем оно короче и четче, тем лучше. Главное – найти золотую середину между слишком общими формулировками и излишней детализацией.
Интересно, что в некоторых случаях процесс составления технического задания может быть даже более ценным, чем сам документ. Почему? Потому что в ходе обсуждения и формулирования требований часто всплывают важные вопросы и нюансы, о которых раньше никто не задумывался. Это помогает лучше понять, что действительно нужно, а от чего можно отказаться.
В конце концов, хорошее техническое задание – это как карта для путешественника. Оно не гарантирует, что путь будет легким, но значительно повышает шансы добраться до цели в срок и без лишних приключений.
Так что в следующий раз, когда вам понадобится разработать новую систему или модернизировать существующую, не спешите сразу погружаться в обсуждение технических деталей. Начните с составления качественного технического задания. Это может показаться сложным и даже скучным процессом, но поверьте – оно того стоит.
Ведь в конечном итоге, техническое задание – это не просто документ. Это инструмент коммуникации, способ структурировать мысли и идеи, возможность посмотреть на проект с разных сторон. И чем лучше вы овладеете этим инструментом, тем успешнее будут ваши проекты.
Так что не бойтесь технических заданий. Научитесь использовать их правильно, и они станут вашим надежным помощником в мире IT-разработки. Кто знает, может быть, однажды вы даже полюбите процесс их составления. Ведь нет ничего приятнее, чем видеть, как из набора требований и идей постепенно вырисовывается образ будущего продукта. И все это – благодаря правильно составленному техническому заданию.
✈️ Больше полезного и интересного ищите в нашем Telegam-канале. Подписывайтесь! По вопросам сотрудничества, по внедрению 1С:ERP и не только пишите по этому адресу : erp.lab@1cbit.ru
Лаборатория внедрения 1С:ERP | @erplab