Обсуждение в Facebook: техническое задание до заключения контракта на разработку

В Russian Apple Developer User Group в Facebook проходит интересная дискуссия. Андраш Густи («Бегемот-бегемот») задал вопрос о времени составления технического задания – делается ли оно до начала выполнения работ и если делается, то что в него входит?

Составления ТЗ, отрисовка или создание прототипов может отнимать довольно много времени (до нескольких недель), однако есть шанс того, что заказчик, взяв их, контракт не заключит, откажется или уйдет с готовым решением в другую студию.

Как разработчики работают с техническими заданиями на этапе подготовки?

Дмитрий Солошенко:

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

Слава Буштрук (Alterplay):

Стачала первую стадию прототипирования, а потом ТЗ, если надо, но, как правило, после первой стадии, понятно что «ребята молодцы» и можно работать по часам. Таблица с примерными оценками помогает достичь понимания, но опыт показывает, что это самообман. На деле потом могут быть сильные отклонения в 200-300%. Так что лучше прототипы от дизайнеров, чтобы команда дизайн и разработки более точно оценили более-менее зафиксированный проект.

Константин Кононов (Myconomy):

Описание функций приложения. Пользовательский сценарий — как правило, этого достаточно. Если заказчик не испугался — работаем глубже. Если испугался — «пройдись по рынку». А вообще ТЗ ни разу не видел, и веры ему нет :).

Нужно понимать, что РАБОЧАЯ документация создается по ОКОНЧАНИИ проекта; На старте — в лучшем случае — имеем набор хотелок. Если речь идет о предварительной оценке входящей информации и задач — достаточно описания функций = пользовательский сценарий.

Договор — на оказание услуг. Дальше — по часам. ТЗ, Схема экранов, документация, можно оформлять дополнительными соглашениями. Можно не оформлять — просто выставлять счета.

Евгений Бойченко (Live Typing):

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

Олег Капитонов (smorodina.mobi):

Какое-то описание в договор всё же надо для начала работ — а потом да, идеально сначала прототип и по нему уже уточнение стоимости в зависимости от того как изменилось первоначальное видение проекта.

Сергей Ваничкин (Badoo):

Я привык работать по ТЗ где чётко всё прописано. Без него принципиально не работаю, потом проект не сдашь. ТЗ составляю сам, спрашиваю клиента на счёт всех деталей, прошу прислать экраны, если есть, и т.д. Как правило ТЗ делается платно, и после того как оно готово, клиент может «пройтись по рынку» и прикинуть сколько будет стоить разработка. Это самый лучший из вариантов работы для фрилансера.

Дмитрий Еремеев (InstallTracker):

Есть старая поговорка: чем больше бумаги — тем чище ж**а. Но прорисовку макетов и собственно разработку ТЗ в правильных вселенных делают до, и оплачивается отдельно.

Какое-то дежавю. Будто на форуме веб-мастеров сижу и сейчас 2000 год :).

Евгений Круглов (MobiGear):

Зависит от клиента, иногда — это просто первый этап работ по контракту. Иногда — это этап работ до контракта, когда ТЗ максимально уточняется и потом включается в договор как приложение. Включает в себя все функциональные требования, список экранов (в идеале — с графическими прототипами) + требования по интеграции, если есть.

Если ТЗ уточняется и согласовывается, то, как правило, уже получено предварительное подтверждение о начале работ. Экраны могут менять по согласованию сторон. Это может привести к пересогласованию контракта, если значительно увеличит нагрузку.

Включить предварительные работы в стоимость контракта никто не запрещает, кстати. Можно неявно :).

Алексей Поимцев (Progress Engine):

Конечно, до начала :). Хотя иногда, если пока требования нечеткие и работа идет итерациями — перед каждой итерацией кусочек ТЗ. Обычно включает в себя юзкейсы в формате gherkin и мокапы.

Денис Царев (Грувител):

Зависит от клиента и отношений с ним. Бывает, что и до. Но редко. Обычно после и выделяем как отдельный этап работ — подготовительный. Мокапы, кстати, склеиваем в invisionapp и показываем на телефоне.

Дмитрий Яковюк (Funway Interactive):

В большинстве случаев составляю документ с постановкой задачи в рамках предварительной консультации, которая оплачивается отдельно. Результат ее — это (low-fidelity) прототип + набор сценариев текстом, в краткой форме. Обычно еще полученные «экранные формы» склеиваю в прототип во flinto. После этого можно адекватно оценивать проект и переходить к следующему этапу.

Алексей Поспехов (Iconic Mobile):

Все от клиента зависит. Есть клиенты со 100% пост оплатой спустя пол года. Это же бизнес вопрос а не технический.

Макс Десятых, креативный директор Redmadrobot:

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

Техническое задание на приложение

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