Любой качественный продукт начинается с правильного и точно составленного технического задания.
1. Что такое ТЗ
ТЗ – это основной документ, которым руководствуются разработчики и проектировщики, приступая к разработке нового продукта. Оно определяет основные направления разработки: технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования к будущему продукту.
2. Для чего нужно ТЗ
По сути, ТЗ – ставит задачу для разработчиков, а так же определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения. В хорошо составленном ТЗ каждый нюанс должен быть регламентирован, чтобы не оставалось места для самодеятельности.
Детально продуманное и проработанное ТЗ – это залог четкой и безотказной работы продукта. Все сценарии должны быть учтены, а нюансы предугаданы.
Составляя не качественное ТЗ, есть риск что конечный продукт не будет соответствовать ожиданиям, и для исправления понадобится куча времени и дополнительный бюджет.
3. Структура ТЗ
ТЗ должно содержать следующие основные пункты:
· Введение;
· Основания для разработки;
· Назначение разработки;
· Требования к продукту;
· Требования к документации;
· Технико-экономические показатели;
· Стадии и этапы разработки;
· Порядок контроля и приемки;
· Приложения.
После того как задача разбита на смысловые блоки, можно переходить к написанию самого технического задания.
При разработке ТЗ как правило руководствуются следующими стандартами:
· ГОСТ 15.016-2016 (научно-исследовательские и опытно-конструкторские работы в области изделий машиностроения и приборостроения);
· ГОСТ 19.201-78 (разработка программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения);
· ГОСТ 34.602-89 (разработка автоматизированной системы (АС) для автоматизации различных видов деятельности);
· IEEE STD 830-1998 (Recommended Practice for Software Requirements Specifications);
· ISO/IEC/ IEEE 29148-2011 (System requirements specification, Software requirements specification).
При правильном использовании любого из вышеперечисленных стандартов, естественно адаптируя под себя и свой продукт, можно разработать максимально точное и при этом понятное ТЗ.
Прописывая каждый пункт, нужно ставить конкретные цели, при этом описывать их максимально подробно, полно, по возможности с указанием всех характеристик, фич и ценностей. Так же можно приводить примеры, чтобы было понятно «как надо / как не надо делать».
При этом важно помнить, что если нет четкого представления технического задания у себя в голове — не получится изложить его на бумаге.
4. Взаимодействие с разработчиками
Взаимоотношения разработчиков и заказчиков по сей день служат отличной темой для шуток.
Суть проблемы кроется в различии основных функций этих людей. Зачастую все сводится к простому непониманию друг друга. Оптимальный вариант взаимодействия – это работа в команде. Общий успех зависит не только от профессионализма разработчика, но и от желания наладить прочные и эффективные рабочие взаимоотношения.
Разработчик может иметь совершенно противоположные точки зрения на бизнес-процесс. В этом случае необходимо совместно обсудить и согласовать спорные вопросы. Всегда отвечайте на вопросы разработчика, проговаривайте нюансы и восприятие каждой детали. Лучше голосом, а не только по переписке.
Иногда вопросы не задают — боятся, что их посчитают глупыми или некомпетентными. Поэтому, даже если вопросов нет, нужно обязательно уточнять у исполнителя, все ли он понял.
Любые внесения изменений и правки согласовывайте и документируйте.
5. Типовые ошибки и рекомендации по их обходу при разработке ТЗ
1. Нечеткие цели и задачи. Перед постановкой технического задания заполните таблицу с двумя столбцами: «какую проблему я хочу решить», «как ее можно решить».
2. Мало технической информации. Прописывайте каждую деталь, составляйте список терминов и сокращений, а так же ведите историю правок.
3. Размытые или неустановленные сроки. Указывайте реально осуществимые сроки выполнения работ с учетом времени на согласование проектной документации и приемо-сдаточных мероприятий.
4. Не регламентировано взаимодействия. Прописывайте регламент взаимодействия. Этот документ регламентирует взаимодействие сторон в рамках выполнения работ по ТЗ.
5. Нет ответственных лиц. Всегда назначайте и прописывайте ответственных лиц, потом поможет при разбирательствах, в случае не соответствий.
6. Нет критериев оценки результата. Прописывайте в пункте «порядок контроля и приемки».
Выводы
Резюмируя вышеизложенное, можно сказать следующее:
1. Подробно описывайте все этапы и подпункты даже по самым незначительным работам.
2. Чтобы сделать качественный продукт разработчику нужно понимание что вы от него хотите. Помогите ему с этим!
Надеюсь эта статья будет полезна всем кто так или иначе связан с разработкой продуктов и составлением ТехЗаданий.
На написание статьи меня подтолкнуло обучение в Product University https://productuniversity.ru/, за что им огромное спасибо.
При подготовке статьи использовался мой личный опыт и опыт моих коллег, а так же общедоступные материалы из сети интернет.
