Всем привет, меня зовут Дядиченко Григорий и я технический продюсер. Я в аутсорсе в роли фрилансера, аутсорс студии, заказчика и подрядчика уже 6 лет. В 2017 году я ушёл с последней постоянной работы и занимаюсь подрядом в том или ином виде. Сегодня хочется обсудить техническое задание. Почему оно стоит денег? Зачем вообще нужно качественное тз? Если вам интересна данная тема — добро пожаловать под кат.
Периодически я сталкиваюсь с непониманием заказчиков на тему того, почему в смете есть оценка составления ТЗ. "Вы же пытаетесь обезопасить себя, почему за наш счёт", "да нам вообще не нужно ТЗ", "этот документ для вас, а не для нас", "да составить тз — это час работы менеджера" и другие фразы, которые возникают в ходе переговоров. И заказчиков можно понять. Но возникают такие фразы, на мой взгляд, из-за непонимания что такое хорошее ТЗ, какую функцию оно выполняет и какие задачи решает и почему его составление занимает минимум неделю.
Для чего нужно ТЗ?
Если мы берём честную работу, где никто никого не хочет обмануть, первый и важный шаг — договориться что делается. Причём конкретно и однозначно. Многие заказчики боятся, что их кто-то пытается обмануть, обсчитать и надурить. Особенно это видно с неопытными заказчиками, которые не разбираются в рынке, в его расценках, в том как формируется цена и так далее.
Любой добросовестный подрядчик будет всегда настаивать на грамотном составлении ТЗ. Так как заказчик часто:
Не знает чего хочет и это нужно уточнять
Не может учесть все детали из-за недостатка экспертизы в области
Не разбирается в экспертизах имеющихся у подрядчика и что он предлагает и на каком уровне качества
Не представляет как строится процесс разработки и не понимает как списывается бюджет
Я в своей работе исторически не люблю T&M (Time and material или почасовую оплату), так как считаю её неправильной с точки зрения мотивации. Я работаю только по предварительной оценке проекта, которая делается с фиксированной суммой и не пересматривается без доп. работ. В чём же проблема T&M?
Когда оплата идёт по "отчётам о потраченном времени" возникает некоторый конфликт интересов. Исполнитель не заинтересован делать работу быстрее, так как оплачиваются часы. А заказчик начинает нервничать, ставить трекеры и всячески следить за подрядчиком думая, что он накручивает часы.
Если же работать с фиксированным бюджетом. То исполнителю выгодно сделать проект быстрее. Защиту на тему качества проекта как раз обеспечивает ТЗ, которым заказчик обосновывает что "мы договаривались вот так". И адекватный заказчик понимает, что если исполнитель выполнил работу быстрее он не "обманщик и накрутил бюджет", а молодец. Так как если на берегу все договорились на цену и сроки. Они всех устроили. То дальше нет никакой разницы как именно исполнитель добился результата. Оплата за результат этим и прекрасна в отличии от оплаты часов.
ТЗ — это половина реализации проекта. С чётким и однозначным ТЗ, где каждая сторона понимает что она получает, где учтены возможности систем, их ограничения. Сделать проект — дело техники. С такими проектами ты просто прям на берегу декомпозируешь всё на задачи, у тебя есть чёткая диаграмма Ганта для построения роадмапа реализации проекта. И вы просто делаете то, о чём договорились.
Без грамотно составленного ТЗ в опасности находится так исполнитель, так как требования начнут придумываться на ходу, так и заказчик. Причём в случае наличия договора — в особенности заказчик. Так как функция о которой "он думал что очевидно что она нужна", но её нет в ТЗ сделана не будет. И не будет оценена. Что создаёт не нужные никому споры и конфликты.
Почему ТЗ это не один день менеджера?
Мы разобрали зачем оно надо. А почему всё же оно стоит денег? Давайте разберём процесс грамотного составления ТЗ. Причём разберу я для небольшого проекта со сроком продакшена в 1-2 месяца. Разобьём составление ТЗ на этапы.
Сбор бизнес требований, проектировка, составление мокапов
Пред. защита технического задания перед заказчиком
Отработка комментариев
Защита технического задания перед заказчиком
Поговорим про сбор бизнес требований. Заказчик не знает конкретно чего он хочет и как это делается. Чаще всего он не эксперт в технологии, которой вы будете реализовывать проект. Не знает тонкостей и нюансов. Да что уж там, многие не знают ограничений федеральных законов в РФ, политики сторов и прочее. Да и не должны.
Поэтому сбор бизнес требований, проектировка и составление мокапов — это первоочерёдная задача. Она заключается в том, что с заказчиком проводится ряд интервью, составляется ряд брифов уточняющих детали проекта и обычно этот процесс занимает от недели. Так как суть этого этапа собрать все нужные функции, объяснить все нюансы реализации заказчику, чтобы прийти к единому пониманию того, что конкретно нужно сделать. Чаще всего базовый пример подобных обсуждений.
Вам нужна аналитика в приложении? С разметкой или просто по запускам?
Если проект заказчика собирает персональные данные. Вы ориентируетесь на рынок РФ или на европу? Там есть нюансы законадательства на тему обработки персональных данных.
Вы учитываете в сроках, что выкладка на IOS может занимать две недели?
Для распознавания голоса мы можем предложить разные апи. Вот выбор доступных провайдеров с их плюсами и минусами, и расценками.
Если проект нужно сдать не "вчера" я ещё предпочитаю составлять UX Wireframe приложения, которое в дальнейшем является ТЗ для дизайна на реализацию экранов интерфейса. И позволяет разработке сразу на кубиках собирать интерфейс.
По сути этап со сбором требований — это самый важный этап подготовки к проекту и препродакшена. Так как задача обеих сторон прийти к единому пониманию и единым ожиданиям. Исполнитель же тратит большое количество времени на интервью, консультирование заказчика, уточнение, переписки и т.п. Это не один день работы. А любая работа должна оплачиваться.
Дальше идёт пред. защита ТЗ. Вы всё обсудили, уточнили и вот у вас есть первая версия ТЗ. А теперь его надо ещё раз обсудить. Проследить чтобы заказчик его прочитал. Если у заказчика не возникнет вопросов и комментариев — это как минимум странно. Так как ещё раз повторюсь — с добросовестными заказчиками и подрядчиками основная цель прийти к единому пониманию, что получает заказчик за свои деньги. Поэтому заказчик должен понимать, что написано в ТЗ.Что ничего не забыли и всё учли. Чтобы избежать конфликтов в дальнейшем.
Дальше у нас отработка комментариев. Это по сути тот же сбор требований только быстрее и короче, так как обычно при хорошо проведённом этапе сбора комментарии идут уже в нюансах, а не "всё не так, давай по новой".
И основная защита ТЗ. Где все снова его читают. И вносят последние коррективы.
И как можно посмотреть на процесс — это довольно большая работа, которая выгодна всем. Так как бывают недобросовестные подрядчики, которые при нечётком ТЗ говорят "мы об этом не договаривались". Бывают недобросовестные заказчики, которые наоборот на неопытного исполнителя начинают навешивать кучу дополнительных задач или скажем не принимать результат работ, так как "это не совсем то, что мы хотим увидеть". Возникают конфликты и недопонимания. Когда все обсуждено и все обо всём договорились, то всем всегда понятно "почему тут надо расширить бюджет" или "почему эта функция не входит в рамки проекта".
Поэтому составление ТЗ — это тот процесс, на котором нельзя экономить и не стоит на него забивать. И именно поэтому он стоит денег. Так как он защищает обе стороны любых работ.
Рекомендации по ТЗ
Из опыта хочется ещё добавить несколько рекомендаций по составлению ТЗ.
Всегда прописывайте число итераций в работах связанных с дизайном, артом, 3д моделированием и т.п.
В разработке обычно при наличии опыта трудно найти место "вкусовщине". Я в ТЗ прописываю даже фреймрейт с которым будет работать итоговое приложение. Поэтому там всё однозначно. А вот с контентом фантазия заказчика может разгуляться не на шутку. И какие-то простые (и часто ни на что не влияющие) вещи можно делать месяцами. Поэтому стоит прописать число итераций.
Это защищает и заказчика, так как адекватный подрядчик откажется от работ, когда они станут коммерчески не выгодны, и что важнее, если договор отказаться не позволяет, больше не будет с вами работать. И по понятным причинам подрядчика. Так как заказчики плохо считают ваши расходы и чаще всего не интересуется, что есть дизайнер, у него есть ставка часа, и 50 перерисовок того, что им не нравится — это другой бюджет. А в случае профессиональной команды чаще всего "не нравится" означает непонимание заказчиком чего он хочет и как следствие невозможности это объяснить.
Для удобства я веду такие вещи в таблице выше. Чтобы отслеживать итерации и комментарии. А так же результаты разных итераций контента.
Всегда прописывайте условия эксплуатации приложения.
Браузеры, операционные системы, устройства. Для той же дополненной реальности условия освещения. Если это всё прописано и обговорено с заказчиком — это снимает очень много конфликтов. Так как не возникает "неожиданностей". Просто на старте обговаривается всё. Так как скажем разработка под интернет эксплорер или же чтобы приложение работало на какой-то неизвестной модели телефона — это другие косты. Другие требования к тестированию проекта, к разработке, к поддержке. И когда заказчик придёт и скажет, что у его друга у которого какой-нить Fly проект не работает — можно будет сослаться на ТЗ и предложить доп. бюджет. А заказчик изначально будет понимать, что так как у него на мобильное приложение бюджет очень сжатый, то реализация будет с такими оговорками. Или наоборот, что бюджет соответствующий, но подрядчик теперь должен сделать так, чтобы на этом телефоне Fly всеми правдами или неправдами функционал работал.
Не забывайте про поддержку.
Разделим поддержку на два вида поддержки: гарантийная и сервисная.
Гарантийная поддержка — это простой формат поддержки. Там нет чётких сроков решения проблем. Проблемы решаются в "разумные сроки", так как их решение зависит от того, когда будут свободны специалисты в команде. Это исправление багов в системе.
Когда система сдана и протестирована, баги не найдены в рамках гарантии, то дальше все исправления всегда вносятся за доп. оплату. Причин у этого много. Браузеры обновляются, операционные системы обновляются. Фреймворки обновляются. Поэтому проблемы с проектом это далеко не всегда вина разработчика. У меня однажды было, что через день после релиза проекта вышла новая версия айос и сафари, где изменили принцип получения доступа к камере телефона. Так что всякое бывает. Гарантийная поддержка обеспечивает решение таких проблем в течении срока гарантии. Да и в целом багов.
Сервисная поддержка — это дорогой формат поддержки. Там есть приоритеты заявок, у подрядчика чаще всего должен быть менеджер, который является первой линией поддержки. Есть штрафы за несоблюдение сроков. И благодаря тому, что некоторые проблемы должны правится в рамках суток на такой поддержке должны сидеть свободные сотрудники. Поэтому она дороже. Так как сотрудник должен быть свободен, чтобы переключиться на вашу проблему.
Не забывайте обсуждать сроки и наличие такой поддержки. Это всегда влияет на оценку проекта. И если поддержка не прописана в ТЗ, то в дальнейшем для вас (как заказчика) это может привести к непредвиденному увеличению бюджета. Ну и подрядчикам не стоит забывать это проговаривать, чтобы не возникало лишних недопониманий.
В заключении
Спасибо за внимание. Надеюсь данная статья поможет кому-то в понимании вопроса "зачем нужно ТЗ и почему оно стоит денег". Всем добросовестных заказчиков и подрядчиков.
А так же я веду свой небольшой блог в телеграм. Подпишитесь, если вам интересна тема Unity и игровая разработка.
