Разработка технического задания

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

В связи с этим я решил поделиться своми наработками и выложить их в свободный доступ — раз уж продукт актуален, почему бы не дать его желающим? Разумеется, я не говорю о каких-то чужих ТЗ, в которых можно найти конфиденциальную информацию о продукте, нет — речь идёт об исключительно основных экранах MVP-версии, присутствующих в любом маркетплейсе услуг.

Как, например, в нашем RTPlatform, имеющем 15 экранов приложения. В том или ином виде они имеются во всех маркетплейсах услуг, поэтому создание аналогичного продукта не означает воровство чужой идеи. Есть некая основа, на базе которой каждый маркетплейс реализует свою идею — и именно этой основой я решил поделиться с аудиторией. Для этого я создал специальный телеграм-канал, куда буду выкладывать типовые ТЗ под те или иные популярные идеи. Уже сейчас там есть ссылка на ТЗ для маркетплейса услуг, приложения с идеей inDriver и товарного маркетплейса. Это не просто набор экранов, а тщательно расписанное, готовое ТЗ под разработку.

В связи с этим я хочу попросить своих читателей о следующем: напишите в группе поддержки канала, на какие популярные сервисы вы ориентируетесь для реализации своей идеи (YouDo, Авито, Индрайвер и проч.), а я, со своей стороны, по самым популярным направлениям буду публиковать типовые ТЗ на канале, ориентировочно по одной штуке в неделю.

Абсолютно бесплатно вы сможете их скачать, доработать под себя — и с готовым техзаданием идти к программисту. Канал никак не монетизируется, ничего покупать не надо — я лишь делюсь своим опытом и расписываю, как бы лично я взялся за реализацию того или иного сервиса MVP.

Я часто видел, как, например, на фрилансе заказчики создавали проекты аля «хочу сервис как YouDo». А что конкретно — MVP-версию с бюджетом сто-двести тысяч или полный аналог на 37 экранов, с сайтом и приложением общей стоимостью в несколько миллионов — непонятно. Приходится задавать уйму уточняющих вопросов — настоящее мучение как для разрабочтика, так и для заказчика.

А кто-то и просто говорит: «сделайте нормальное ТЗ, а потом приходите» — сам проверял, примерив на себя роль клиента. Так что моё типовое ТЗ — это агрегация опыта того, что чаще всего встречается. Оно помогает сузить ценовые рамки, поскольку помогает разработчику лучше понять, чего вы от него хотите. И в ответе он уже не будет говорить о диапазоне от ста тысяч до нескольких миллионов, а назовёт более-менее точную стоимость исходя из ваших пожеланий. Даже если исполнитель и будет перестраховываться, закладывая чуть большую сумму на каждый пункт, разбег цены всё равно не превысит 10-15%.

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

В ближайшее время на канале планирую выложить ТЗ для запуска простого мессенджера и сервисной компании.