Часто можно столкнуться с мнением, что техническое задание (ТЗ, PRD «product requirements document») в наши дни скорее мертво чем живо. Сегодня, когда не только стартапы, но и крупные компании при разработке нового продукта часто пользуются технологией MVP (минимально функционального продукта) многим кажется что устное, меняющееся по ходу работ, задание на прототипирование модели  выглядит гораздо современнее и работает эффективнее, чем тома записей заказчика, зачастую мягко говоря не очень непрофессиональные.

Ниже показана схема создания нового продукта или очередной итерации MVP на основе Технического Задания. В идеальном варианте техническое задание составляется заказчиком при активном участии потенциального исполнителя или имеющих необходимую компетенцию экспертов.

 

Разберём диаграмму подробнее:

  • Выявление У заказчика появляется потребность улучшения существующего функционала прибора или видение нового продукта. На основе их оy формулирует основные требования к будущему устройству.
  • Анализ Заказчик знакомит со своими пожеланиями потенциального исполнителя или эксперта(одного или нескольких) , обладающих необходимыми компетенциями. Они совместно производят анализ теоретической возможности исполнения пожеланий и оценивают ресурсы, которые для этого потребуются.
  • Адаптация В ходе проведения экспертизы обычно оказывается что отдельные функции будущего прибора существенным образом усложняют его реализацию, другие невыполнимы или требуют слишком дорогостоящего решения. Производится мозговой штурм в ходе которого прорабатывается функциональность будущего устройства. Слишком затратные и не имеющие большой важности функции исключаются. Отдельные требования модифицируются в сторону упрощения  например точность измерения температуры, или температурный диапазон работы прибора. Некоторые могут заменяться на другие, обеспечивающие заданную функциональность проще например при небольшом потоке данных можно заменить интерфейс WiFi на BLE. Иногда в ходе этого процесса становится ясно, что разработка данного продукта не имеет смысл потому, что не принесёт ничего кроме убытков. Такое может случиться если устройство получается слишком дорогим, его разработка настолько сложна, что при имеющихся у клиента ресурсах может затянуться на годы, или при сегодняшнем уровне технологий поставленная задача вообще не решается. В этом случае лучше поставить точку, зафиксировать убытки и заняться чем-нибудь другим. Если же в ходе процесса адаптации был достигнут компромисс пора переходить к его документированию.
  • Документирование Техническое задание должно быть реалистичным как по своим требованиям так и по срокам, сформулировано простым языком и оперировать конкретными понятиями. В ТЗ должна отражаться не только сумма вознаграждения исполнителя, но и общий бюджет проекта, хотя бы ориентировочно. Оно должно содержать план-график работ.  В случае, если в процессе адаптации временные затраты и стоимость реализации отдельных пунктов остались до конца не ясны, этот факт следует упомянуть в ТЗ. При необходимости всё это скрепляется договором. В зависимости от сложности и специфики проекта ТЗ может иметь разный уровень детализации. Техническое Задание также должно включать в себя календарный план-график выполняемых работ, про него следует сказать пару слов отдельно. Существует два подхода — закладывать изначально дополнительное время на неизбежные форсмажоры, либо строить оптимистичные прогнозы, но отметить, что на отдельных участках возможны затруднения, на преодаление которых может потребоваться дополнительное время, а в особых случаях и материальные ресурсы. О подобных случаях исполнитель обязуется сообщать заказчику и они совместно корректируют план.
  • Тестирование Тестирование устройства важно не только как возможность определить насколько оно удовлетворяет требованиям ТЗ. Не менее важный этап — демонстрация возможностей потенциальным потребителям и инвесторам с целью выявления сильных и слабых сторон. Только после демонстрации потенциальным потребителям круг замкнётся и  можно будет переходить либо к оптимизации для промышленного производства, либо к следующей итерации модели MVP.

В заключении привожу два варианта ТЗ, разной степени сложности и детализации:

Первый пример ТЗ

Второй пример ТЗ