Всем привет, меня зовут Дядиченко Григорий и я технический продюсер. Я в аутсорсе в роли фрилансера, аутсорс студии, заказчика и подрядчика уже 6 лет. В 2017 году я ушёл с последней постоянной работы и занимаюсь подрядом в том или ином виде. Сегодня хочется обсудить техническое задание. Почему оно стоит денег? Зачем вообще нужно качественное тз? Если вам интересна данная тема — добро пожаловать под кат.
Периодически я сталкиваюсь с непониманием заказчиков на тему того, почему в смете есть оценка составления ТЗ. "Вы же пытаетесь обезопасить себя, почему за наш счёт", "да нам вообще не нужно ТЗ", "этот документ для вас, а не для нас", "да составить тз — это час работы менеджера" и другие фразы, которые возникают в ходе переговоров. И заказчиков можно понять. Но возникают такие фразы, на мой взгляд, из-за непонимания что такое хорошее ТЗ, какую функцию оно выполняет и какие задачи решает и почему его составление занимает минимум неделю.
Для чего нужно ТЗ?
Если мы берём честную работу, где никто никого не хочет обмануть, первый и важный шаг — договориться что делается. Причём конкретно и однозначно. Многие заказчики боятся, что их кто-то пытается обмануть, обсчитать и надурить. Особенно это видно с неопытными заказчиками, которые не разбираются в рынке, в его расценках, в том как формируется цена и так далее.
Любой добросовестный подрядчик будет всегда настаивать на грамотном составлении ТЗ. Так как заказчик часто:
Не знает чего хочет и это нужно уточнять
Не может учесть все детали из-за недостатка экспертизы в области
Не разбирается в экспертизах имеющихся у подрядчика и что он предлагает и на каком уровне качества
Не представляет как строится процесс разработки и не понимает как списывается бюджет
Я в своей работе исторически не люблю T&M (Time and material или почасовую оплату), так как считаю её неправильной с точки зрения мотивации. Я работаю только по предварительной оценке проекта, которая делается с фиксированной суммой и не пересматривается без доп. работ. В чём же проблема T&M?
Когда оплата идёт по "отчётам о потраченном времени" возникает некоторый конфликт интересов. Исполнитель не заинтересован делать работу быстрее, так как оплачиваются часы. А заказчик начинает нервничать, ставить трекеры и всячески следить за подрядчиком думая, что он накручивает часы.
Если же работать с фиксированным бюджетом. То исполнителю выгодно сделать проект быстрее. Защиту на тему качества проекта как раз обеспечивает ТЗ, которым заказчик обосновывает что "мы договаривались вот так". И адекватный заказчик понимает, что если исполнитель выполнил работу быстрее он не "обманщик и накрутил бюджет", а молодец. Так как если на берегу все договорились на цену и сроки. Они всех устроили. То дальше нет никакой разницы как именно исполнитель добился результата. Оплата за результат этим и прекрасна в отличии от оплаты часов.
ТЗ — это половина реализации проекта. С чётким и однозначным ТЗ, где каждая сторона понимает что она получает, где учтены возможности систем, их ограничения. Сделать проект — дело техники. С такими проектами ты просто прям на берегу декомпозируешь всё на задачи, у тебя есть чёткая диаграмма Ганта для построения роадмапа реализации проекта. И вы просто делаете то, о чём договорились.
Без грамотно составленного ТЗ в опасности находится так исполнитель, так как требования начнут придумываться на ходу, так и заказчик. Причём в случае наличия договора — в особенности заказчик. Так как функция о которой "он думал что очевидно что она нужна", но её нет в ТЗ сделана не будет. И не будет оценена. Что создаёт не нужные никому споры и конфликты.
Почему ТЗ это не один день менеджера?
Мы разобрали зачем оно надо. А почему всё же оно стоит денег? Давайте разберём процесс грамотного составления ТЗ. Причём разберу я для небольшого проекта со сроком продакшена в 1-2 месяца. Разобьём составление ТЗ на этапы.
Сбор бизнес требований, проектировка, составление мокапов
Пред. защита технического задания перед заказчиком
Отработка комментариев
Защита технического задания перед заказчиком
Поговорим про сбор бизнес требований. Заказчик не знает конкретно чего он хочет и как это делается. Чаще всего он не эксперт в технологии, которой вы будете реализовывать проект. Не знает тонкостей и нюансов. Да что уж там, многие не знают ограничений федеральных законов в РФ, политики сторов и прочее. Да и не должны.
Поэтому сбор бизнес требований, проектировка и составление мокапов — это первоочерёдная задача. Она заключается в том, что с заказчиком проводится ряд интервью, составляется ряд брифов уточняющих детали проекта и обычно этот процесс занимает от недели. Так как суть этого этапа собрать все нужные функции, объяснить все нюансы реализации заказчику, чтобы прийти к единому пониманию того, что конкретно нужно сделать. Чаще всего базовый пример подобных обсуждений.
Вам нужна аналитика в приложении? С разметкой или просто по запускам?
Если проект заказчика собирает персональные данные. Вы ориентируетесь на рынок РФ или на европу? Там есть нюансы законадательства на тему обработки персональных данных.
Вы учитываете в сроках, что выкладка на IOS может занимать две недели?
Для распознавания голоса мы можем предложить разные апи. Вот выбор доступных провайдеров с их плюсами и минусами, и расценками.
Если проект нужно сдать не "вчера" я ещё предпочитаю составлять UX Wireframe приложения, которое в дальнейшем является ТЗ для дизайна на реализацию экранов интерфейса. И позволяет разработке сразу на кубиках собирать интерфейс.
По сути этап со сбором требований — это самый важный этап подготовки к проекту и препродакшена. Так как задача обеих сторон прийти к единому пониманию и единым ожиданиям. Исполнитель же тратит большое количество времени на интервью, консультирование заказчика, уточнение, переписки и т.п. Это не один день работы. А любая работа должна оплачиваться.
Дальше идёт пред. защита ТЗ. Вы всё обсудили, уточнили и вот у вас есть первая версия ТЗ. А теперь его надо ещё раз обсудить. Проследить чтобы заказчик его прочитал. Если у заказчика не возникнет вопросов и комментариев — это как минимум странно. Так как ещё раз повторюсь — с добросовестными заказчиками и подрядчиками основная цель прийти к единому пониманию, что получает заказчик за свои деньги. Поэтому заказчик должен понимать, что написано в ТЗ.Что ничего не забыли и всё учли. Чтобы избежать конфликтов в дальнейшем.
Дальше у нас отработка комментариев. Это по сути тот же сбор требований только быстрее и короче, так как обычно при хорошо проведённом этапе сбора комментарии идут уже в нюансах, а не "всё не так, давай по новой".
И основная защита ТЗ. Где все снова его читают. И вносят последние коррективы.
И как можно посмотреть на процесс — это довольно большая работа, которая выгодна всем. Так как бывают недобросовестные подрядчики, которые при нечётком ТЗ говорят "мы об этом не договаривались". Бывают недобросовестные заказчики, которые наоборот на неопытного исполнителя начинают навешивать кучу дополнительных задач или скажем не принимать результат работ, так как "это не совсем то, что мы хотим увидеть". Возникают конфликты и недопонимания. Когда все обсуждено и все обо всём договорились, то всем всегда понятно "почему тут надо расширить бюджет" или "почему эта функция не входит в рамки проекта".
Поэтому составление ТЗ — это тот процесс, на котором нельзя экономить и не стоит на него забивать. И именно поэтому он стоит денег. Так как он защищает обе стороны любых работ.
Рекомендации по ТЗ
Из опыта хочется ещё добавить несколько рекомендаций по составлению ТЗ.
Всегда прописывайте число итераций в работах связанных с дизайном, артом, 3д моделированием и т.п.
В разработке обычно при наличии опыта трудно найти место "вкусовщине". Я в ТЗ прописываю даже фреймрейт с которым будет работать итоговое приложение. Поэтому там всё однозначно. А вот с контентом фантазия заказчика может разгуляться не на шутку. И какие-то простые (и часто ни на что не влияющие) вещи можно делать месяцами. Поэтому стоит прописать число итераций.
Это защищает и заказчика, так как адекватный подрядчик откажется от работ, когда они станут коммерчески не выгодны, и что важнее, если договор отказаться не позволяет, больше не будет с вами работать. И по понятным причинам подрядчика. Так как заказчики плохо считают ваши расходы и чаще всего не интересуется, что есть дизайнер, у него есть ставка часа, и 50 перерисовок того, что им не нравится — это другой бюджет. А в случае профессиональной команды чаще всего "не нравится" означает непонимание заказчиком чего он хочет и как следствие невозможности это объяснить.
Для удобства я веду такие вещи в таблице выше. Чтобы отслеживать итерации и комментарии. А так же результаты разных итераций контента.
Всегда прописывайте условия эксплуатации приложения.
Браузеры, операционные системы, устройства. Для той же дополненной реальности условия освещения. Если это всё прописано и обговорено с заказчиком — это снимает очень много конфликтов. Так как не возникает "неожиданностей". Просто на старте обговаривается всё. Так как скажем разработка под интернет эксплорер или же чтобы приложение работало на какой-то неизвестной модели телефона — это другие косты. Другие требования к тестированию проекта, к разработке, к поддержке. И когда заказчик придёт и скажет, что у его друга у которого какой-нить Fly проект не работает — можно будет сослаться на ТЗ и предложить доп. бюджет. А заказчик изначально будет понимать, что так как у него на мобильное приложение бюджет очень сжатый, то реализация будет с такими оговорками. Или наоборот, что бюджет соответствующий, но подрядчик теперь должен сделать так, чтобы на этом телефоне Fly всеми правдами или неправдами функционал работал.
Не забывайте про поддержку.
Разделим поддержку на два вида поддержки: гарантийная и сервисная.
Гарантийная поддержка — это простой формат поддержки. Там нет чётких сроков решения проблем. Проблемы решаются в "разумные сроки", так как их решение зависит от того, когда будут свободны специалисты в команде. Это исправление багов в системе.
Когда система сдана и протестирована, баги не найдены в рамках гарантии, то дальше все исправления всегда вносятся за доп. оплату. Причин у этого много. Браузеры обновляются, операционные системы обновляются. Фреймворки обновляются. Поэтому проблемы с проектом это далеко не всегда вина разработчика. У меня однажды было, что через день после релиза проекта вышла новая версия айос и сафари, где изменили принцип получения доступа к камере телефона. Так что всякое бывает. Гарантийная поддержка обеспечивает решение таких проблем в течении срока гарантии. Да и в целом багов.
Сервисная поддержка — это дорогой формат поддержки. Там есть приоритеты заявок, у подрядчика чаще всего должен быть менеджер, который является первой линией поддержки. Есть штрафы за несоблюдение сроков. И благодаря тому, что некоторые проблемы должны правится в рамках суток на такой поддержке должны сидеть свободные сотрудники. Поэтому она дороже. Так как сотрудник должен быть свободен, чтобы переключиться на вашу проблему.
Не забывайте обсуждать сроки и наличие такой поддержки. Это всегда влияет на оценку проекта. И если поддержка не прописана в ТЗ, то в дальнейшем для вас (как заказчика) это может привести к непредвиденному увеличению бюджета. Ну и подрядчикам не стоит забывать это проговаривать, чтобы не возникало лишних недопониманий.
В заключении
Спасибо за внимание. Надеюсь данная статья поможет кому-то в понимании вопроса "зачем нужно ТЗ и почему оно стоит денег". Всем добросовестных заказчиков и подрядчиков.
А так же я веду свой небольшой блог в телеграм. Подпишитесь, если вам интересна тема Unity и игровая разработка.
Комментарии (22)
vadimr
10.01.2023 10:08+3Давайте будем аккуратны с терминологией.
По госту ТЗ составляется заказчиком. Если исполнитель хочет (а он обычно хочет), он может заказчику помочь, но оплачивать собственные функциональные обязанности с точки зрения заказчика является растратой, а если это государственное предприятие или учреждение – то коррупцией (почему-то в нашей правовой системе считается, что коррумпирован может быть только тот человек, прибавочную стоимость труда которого на 51% забирает государство).
А то, о чём вы пишете, называется проведением информационного обследования (или, если это большая работа, техническим проектом) и фактически является первым этапом работы, по результатам которого ТЗ может уточняться и дополняться.
DyadichenkoGA Автор
10.01.2023 10:10Я работаю в коммерческом секторе. Но спасибо за уточнение. Не знал таких терминологических нюансов.
ChePeter
10.01.2023 11:53Если можно, то дайте пруф на действующий ГОСТ
По госту ТЗ составляется заказчиком.
Разработка ТЗ это стадия создания автоматизированной системы(п.3.1.) и как бы подразумевает, что его пишет исполнитель! Т.е. исполнитель исследовал предмет работ(п.1 и п.2) и теперь предлагает заказчику свое собственное видение решения его проблем. И это всё за деньги заказчика.
В СССР было именно так, ТЗ писали исполнители и заказчик его утверждал. Ведь заказчик понимает, по идее, только ту выгоду или преимущества, что даст ему реализация этого проекта, а то что под капотом он может и не знать досконально.
vadimr
10.01.2023 12:48Если можно, то дайте пруф на действующий ГОСТ
Например, ГОСТ РВ 15.203-2001, приложение А, таблица А.1.
Честно говоря, не знаю, есть ли такая же подробная таблица, кто за что отвечает, в 34 группе гостов. Но 34 сделан из 15, и принципиальной разницы между ними нет.
Разработка ТЗ, действительно, является стадией создания автоматизированной системы, но из этого не следует, что она выполняется исполнителем.
В СССР было точно так же, как и сейчас. Фактически ТЗ обычно (но не всегда) писал исполнитель, но номинально – заказчик.
Если говорить о современном государстве, то из принципа конкурентности закупок следует, что все существенные требования к выполняемым работам должны быть описаны до выбора исполнителя. Техническое задание является одним из приложений к объявлению о закупке в адрес неопределённого круга лиц.
Ведь заказчик понимает, по идее, только ту выгоду или преимущества, что даст ему реализация этого проекта, а то что под капотом он может и не знать досконально.
Это справедливое замечание, но то, что под капотом, не обязательно (и не предполагается законодателем) описывать именно в техническом задании.
beskov
11.01.2023 05:08если почитать телеграм автора, он вообще в геймдеве работает
так что непонятно, зачем вы сюда всю эту галиматью с госзаказами, ФЗ, ХЗ, судами, военными ГОСТами и прикрытием жопы чиновника тащите
DyadichenkoGA Автор
11.01.2023 05:15В целом я занимаюсь разработкой можно сказать, что AR&VR, стендовых проектов и т.п. https://noxatra.ru
Для корпораций. Делали много всякого со сбером, награду за лучшее решение в нефтегазовой промышленности получили с ГПН за VR телепортацию и так далее. Но да. Тут может быть расхождение в терминологиях из-за того что с гос. закупками я не работаю.
Но в любом случае интересно почитать и узнать новое. Это хорошо, когда статья создаёт поле для дискуссии на мой взгляд.
vadimr
11.01.2023 10:07+1В заголовке или тексте статьи указано, что она относится исключительно к геймдеву? Нет. Человеку, занимающемуся геймдевом, запрещено писать о госзаказах? Нет. Читатель, интересующийся составлением ТЗ для госзаказа, обязан перед чтением статьи изучить биографию автора по его телеграму? Опять-таки нет.
Мои комментарии имеют целью не полемизировать с автором (тем более, что в целом он излагает всё верно), а сформировать у читателя статьи более корректный взгляд на поднятый вопрос, чтобы в дальнейшем не возникало проблем на ровном месте, исключительно из-за неправильно использованной терминологии.
beskov
11.01.2023 23:55по крайней мере в ней указано, что она про софт, а не про ПАК, АС, ИС, ГАС и прочих гавриков
funca
10.01.2023 13:27По госту ТЗ составляется заказчиком
В случае систем автоматизации:
Задание на проектирование систем автоматизации технологических процессов составляется генеральным проектировщиком или заказчиком с участием специализированной организации, которой поручается разработка проекта
Если у заказчика нет соответствующих компетенций, он делегирует работу по проектированию организации где они есть. Т.е заказчик тут accountable, но не обязательно responsible.
Кроме того, ТЗ для гос закупок когда требования формируются, и ТЗ для разработки это два разных документа. В любом случае работать за бесплатно ни кто не обязан ни по какому ГОСТу.
vadimr
10.01.2023 13:35Это откуда цитата?
Работать за бесплатно ни кто не обязан ни по какому ГОСТу.
Работать за бесплатно никто не обязан, но заказчик уже получил за разработку ТЗ зарплату, и не имеет юридических оснований ещё раз заплатить исполнителю.
Я бы вот на месте заказчика никогда не подписал смету, в которой есть составление ТЗ. Потому что не хотел бы дальше объясняться на эту тему с прокурором.
funca
10.01.2023 13:40Заказчик обычно это юридическое лицо, при чем тут зарплата?
vadimr
10.01.2023 13:43Притом, что у юридического лица есть (или должны быть) конкретные физические лица, ответственные за подписание ТЗ, и составление ТЗ – это их оплаченная из фонда заработной платы служебная обязанность.
beskov
11.01.2023 04:52а по IEEE 830 требования к софту разрабатываются обеими сторонами в сотрудничестве
beskov
11.01.2023 05:02я вот не понимаю вот этого повсеместного стремления усложнять жизнь и работать именно с ТЗ на АС
судя по тексту автора, они в основном делают мобильные приложения, чистый софт
они не «строят» автоматизированную систему — АС на самом деле нельзя просто разработать и потом развернуть и внедрить — её можно только именно построить из людей, оборудования, процессов И софта
так что если ссылаться, то ссылаться на ГОСТ 19, ISO 29148 в части Software Requirements Specification
в ЕСПД я навскидку не вижу никаких указаний на то, кто разрабатывает ТЗ на софт, но из общей логики советской реальности это вообще делает 3-е лицо — специализированное НИИ
Завод заказывает НИР и ОКР НИИ
НИИ делает обследования и пишет ТЗ
КБ или производственная фирма разрабатывает софт
понятно, что эта модель к современной коммерческой разработке почти никак (к сожалению) не применима, института независимых проектировщиков в мелкомасштабной разработке просто не существует, а в интеграторах шаги 2 и 3 объединены в один с понятным конфликтом интересов
vadimr
11.01.2023 08:57+1ЕСПД вообще никак не касается вопросов управления разработкой. Она описывает только требования к программной документации, отличающиеся от ЕСКД.
СпецНИИ в советское время согласовывало ТЗ, а заказывало в основном министерство. В советской реальности вообще роль министерств отличалась от современной, и там работали, в основном, реальные специалисты с опытом работы на предприятиях (а предприятия входили непосредственно в контур управления министерств, как сейчас в госкорпорациях).
beskov
11.01.2023 04:47Заказчики сидят на VC.ru, а не тут. Тут вы ломитесь в открытую дверь.
«Бизнес-требования... ТЗ». Бизнес-требования и ТЗ — это очень разные вещи.
Бизнес-требования — это требования владельцев, бизнес-архитекторов, регуляторов, законов и т.д. к организации и её организационным единицам — что они должны делать, что не должны и с каким качеством.
Примеры:
«Организация должна продавать товары с применением электронных каналов продаж»
«Организация должна информировать клиента об условиях продажи»
«Организация должна мотивировать клиента на покупку конкретного товара»
и т.д.
а ТЗ содержит уже ЗАДАНИЕ на разработку и/или проектирование/построение технического объекта (что является совсем другим предметом, чем организация) и содержит 2 части:
1. Требования к свойствам предмета поставки
2. Требования к порядку работ и процедурам разработки, сдачи, внедрения, сопровождения
Если вы поставляете морозильные камеры в ресторан, то конечно вам надо хоть немного разобраться в бизнесе и понять, зачем камеры, как они будут применяться, как заказчик измерит, что камеры работают хорошо. Но в ТЗ на закупку камер будет написано другое — а именно, характеристики камер, а не бизнеса.
Так что в догонку к предыдущим комментаторам — в разработке ПО можно даже и без ТЗ, но всё равно кто-то должен поставить бизнес-задачу в терминах измеримой цели и ограничений (железного треугольника), и само собой не в виде «цель проекта: внедрить CRM» :)
Поэтому я бы настаивал на:Бизнес-требованиях (1 страничка) — что должен делать бизнес в интересующей нас области (capabilities), с каким качеством, с какими ограничениями (показатели процесса)
Концепция решения (3 странички) — что именно мы хотим сделать, как в целом будет устроена конструкция (бриф-архитектура), каким качеством, какими ключевыми свойствами (перечень user stories), с какими ограничениями (показатели ИТ-системы)
Бизнес-обоснование (1 страничка) — как именно это решение (2) приведёт к реализации бизнес-требованй, как именно будут окупаться вложения, какие вложения в каком графике понадобятся. Подрядчик может этого документа не видеть, но именно он определяет допустимые границы бюджета.
Концепция проекта (project) (1 страничка) — из каких очередей будет состоять разработка, какие свойства будут входить в каждую из них — например, в формате story map
Вот это всё так или иначе нужно, а ограничивать софт именно ТЗ стоит тогда, когда предельно точно известно, что именно нужно сделать и как оно должно работать — что требует детального проектирования, что увеличивает предпроект на 2-3 месяца и в общем случае не выгодно заказчику, да и подрядчику, т.к. в коммерческой разработке попытка угадать правильную работу фич в режиме Big Design Upfront ни к чему хорошему не приводит.DyadichenkoGA Автор
11.01.2023 05:11Думаю вы правы про VC. Просто я обычно пишу другой характер статей и в основном сюда, а такой материал на vc лучше бы подошёл наверное.
beskov
11.01.2023 05:22Кстати, если мы делаем компьютерные игры определённого жанра, то БТ компании, которая сама эти игры разрабатывает, продаёт и эксплуатирует, могут быть довольно простыми и устойчивыми, их не надо в каждом проекте заново изобретать:
Организация должна разрабатывать онлайн-игры в жанре X для рынка Y
-
Организация должна продавать эти игры
С применением каналов оплаты KO1-KON
C применением валют V2-VN
Организация должна позволять клиентам играть в игры с использованием языков интерфейса Y1-YN
Организация должна предоставлять клиентам возможность получать качество обслуживания при игре в игры на уровне, не хуже чем конкуренты Z1, Z2 и Z3
Организация должна получать, хранить и предоставлять ответственным сотрудниками информацию о фактах продаж, подписок, отказов
Организация должна предоставлять клиентам возможность обратиться с жалобой
Организация должна анализировать поток обращений клиентов
Организация должна реагировать на обращения согласно политике CP1
...
и т.д.
klis
Может, есть смысл называть это, как называют все - предпроектное обследование (результатом которого является согласованное ТЗ). Тогда, возможно, и вопросов у заказчика было бы меньше и по смыслу и по форме.
DyadichenkoGA Автор
Согласен. Звучит неплохо. Но всё равно вызовет вопросы что это. Так же как и "препродакшен". Если вносить это в смету. Но много у кого в сметах просто ТЗ.
beskov
мне кажется можно сказать проще — то заказчик должен сформулировать собственно ЗАКАЗ, т.е. что именно он хочет закупить
и поскольку это не закупка партии туалетной бумаги или готового холодильного оборудования, а создание уникального софта со своими свойствами, эти свойства софта надо продумать, а точнее — спроектировать
и да, такой ЗАКАЗ сформировать заказчику будет непросто, каким бы брифом подрядчик не прикрывался, поэтому нужна совместная работа по подготовке ЗАКАЗа