Comments 22
Может, есть смысл называть это, как называют все - предпроектное обследование (результатом которого является согласованное ТЗ). Тогда, возможно, и вопросов у заказчика было бы меньше и по смыслу и по форме.
Согласен. Звучит неплохо. Но всё равно вызовет вопросы что это. Так же как и "препродакшен". Если вносить это в смету. Но много у кого в сметах просто ТЗ.
мне кажется можно сказать проще — то заказчик должен сформулировать собственно ЗАКАЗ, т.е. что именно он хочет закупить
и поскольку это не закупка партии туалетной бумаги или готового холодильного оборудования, а создание уникального софта со своими свойствами, эти свойства софта надо продумать, а точнее — спроектировать
и да, такой ЗАКАЗ сформировать заказчику будет непросто, каким бы брифом подрядчик не прикрывался, поэтому нужна совместная работа по подготовке ЗАКАЗа
Давайте будем аккуратны с терминологией.
По госту ТЗ составляется заказчиком. Если исполнитель хочет (а он обычно хочет), он может заказчику помочь, но оплачивать собственные функциональные обязанности с точки зрения заказчика является растратой, а если это государственное предприятие или учреждение – то коррупцией (почему-то в нашей правовой системе считается, что коррумпирован может быть только тот человек, прибавочную стоимость труда которого на 51% забирает государство).
А то, о чём вы пишете, называется проведением информационного обследования (или, если это большая работа, техническим проектом) и фактически является первым этапом работы, по результатам которого ТЗ может уточняться и дополняться.
Я работаю в коммерческом секторе. Но спасибо за уточнение. Не знал таких терминологических нюансов.
Если можно, то дайте пруф на действующий ГОСТ
По госту ТЗ составляется заказчиком.
Разработка ТЗ это стадия создания автоматизированной системы(п.3.1.) и как бы подразумевает, что его пишет исполнитель! Т.е. исполнитель исследовал предмет работ(п.1 и п.2) и теперь предлагает заказчику свое собственное видение решения его проблем. И это всё за деньги заказчика.
В СССР было именно так, ТЗ писали исполнители и заказчик его утверждал. Ведь заказчик понимает, по идее, только ту выгоду или преимущества, что даст ему реализация этого проекта, а то что под капотом он может и не знать досконально.
Если можно, то дайте пруф на действующий ГОСТ
Например, ГОСТ РВ 15.203-2001, приложение А, таблица А.1.
Честно говоря, не знаю, есть ли такая же подробная таблица, кто за что отвечает, в 34 группе гостов. Но 34 сделан из 15, и принципиальной разницы между ними нет.
Разработка ТЗ, действительно, является стадией создания автоматизированной системы, но из этого не следует, что она выполняется исполнителем.
В СССР было точно так же, как и сейчас. Фактически ТЗ обычно (но не всегда) писал исполнитель, но номинально – заказчик.
Если говорить о современном государстве, то из принципа конкурентности закупок следует, что все существенные требования к выполняемым работам должны быть описаны до выбора исполнителя. Техническое задание является одним из приложений к объявлению о закупке в адрес неопределённого круга лиц.
Ведь заказчик понимает, по идее, только ту выгоду или преимущества, что даст ему реализация этого проекта, а то что под капотом он может и не знать досконально.
Это справедливое замечание, но то, что под капотом, не обязательно (и не предполагается законодателем) описывать именно в техническом задании.
если почитать телеграм автора, он вообще в геймдеве работает
так что непонятно, зачем вы сюда всю эту галиматью с госзаказами, ФЗ, ХЗ, судами, военными ГОСТами и прикрытием жопы чиновника тащите
В целом я занимаюсь разработкой можно сказать, что AR&VR, стендовых проектов и т.п. https://noxatra.ru
Для корпораций. Делали много всякого со сбером, награду за лучшее решение в нефтегазовой промышленности получили с ГПН за VR телепортацию и так далее. Но да. Тут может быть расхождение в терминологиях из-за того что с гос. закупками я не работаю.
Но в любом случае интересно почитать и узнать новое. Это хорошо, когда статья создаёт поле для дискуссии на мой взгляд.
В заголовке или тексте статьи указано, что она относится исключительно к геймдеву? Нет. Человеку, занимающемуся геймдевом, запрещено писать о госзаказах? Нет. Читатель, интересующийся составлением ТЗ для госзаказа, обязан перед чтением статьи изучить биографию автора по его телеграму? Опять-таки нет.
Мои комментарии имеют целью не полемизировать с автором (тем более, что в целом он излагает всё верно), а сформировать у читателя статьи более корректный взгляд на поднятый вопрос, чтобы в дальнейшем не возникало проблем на ровном месте, исключительно из-за неправильно использованной терминологии.
По госту ТЗ составляется заказчиком
В случае систем автоматизации:
Задание на проектирование систем автоматизации технологических процессов составляется генеральным проектировщиком или заказчиком с участием специализированной организации, которой поручается разработка проекта
Если у заказчика нет соответствующих компетенций, он делегирует работу по проектированию организации где они есть. Т.е заказчик тут accountable, но не обязательно responsible.
Кроме того, ТЗ для гос закупок когда требования формируются, и ТЗ для разработки это два разных документа. В любом случае работать за бесплатно ни кто не обязан ни по какому ГОСТу.
Это откуда цитата?
Работать за бесплатно ни кто не обязан ни по какому ГОСТу.
Работать за бесплатно никто не обязан, но заказчик уже получил за разработку ТЗ зарплату, и не имеет юридических оснований ещё раз заплатить исполнителю.
Я бы вот на месте заказчика никогда не подписал смету, в которой есть составление ТЗ. Потому что не хотел бы дальше объясняться на эту тему с прокурором.
а по IEEE 830 требования к софту разрабатываются обеими сторонами в сотрудничестве
я вот не понимаю вот этого повсеместного стремления усложнять жизнь и работать именно с ТЗ на АС
судя по тексту автора, они в основном делают мобильные приложения, чистый софт
они не «строят» автоматизированную систему — АС на самом деле нельзя просто разработать и потом развернуть и внедрить — её можно только именно построить из людей, оборудования, процессов И софта
так что если ссылаться, то ссылаться на ГОСТ 19, ISO 29148 в части Software Requirements Specification
в ЕСПД я навскидку не вижу никаких указаний на то, кто разрабатывает ТЗ на софт, но из общей логики советской реальности это вообще делает 3-е лицо — специализированное НИИ
Завод заказывает НИР и ОКР НИИ
НИИ делает обследования и пишет ТЗ
КБ или производственная фирма разрабатывает софт
понятно, что эта модель к современной коммерческой разработке почти никак (к сожалению) не применима, института независимых проектировщиков в мелкомасштабной разработке просто не существует, а в интеграторах шаги 2 и 3 объединены в один с понятным конфликтом интересов
ЕСПД вообще никак не касается вопросов управления разработкой. Она описывает только требования к программной документации, отличающиеся от ЕСКД.
СпецНИИ в советское время согласовывало ТЗ, а заказывало в основном министерство. В советской реальности вообще роль министерств отличалась от современной, и там работали, в основном, реальные специалисты с опытом работы на предприятиях (а предприятия входили непосредственно в контур управления министерств, как сейчас в госкорпорациях).
Заказчики сидят на VC.ru, а не тут. Тут вы ломитесь в открытую дверь.
«Бизнес-требования... ТЗ». Бизнес-требования и ТЗ — это очень разные вещи.
Бизнес-требования — это требования владельцев, бизнес-архитекторов, регуляторов, законов и т.д. к организации и её организационным единицам — что они должны делать, что не должны и с каким качеством.
Примеры:
«Организация должна продавать товары с применением электронных каналов продаж»
«Организация должна информировать клиента об условиях продажи»
«Организация должна мотивировать клиента на покупку конкретного товара»
и т.д.
а ТЗ содержит уже ЗАДАНИЕ на разработку и/или проектирование/построение технического объекта (что является совсем другим предметом, чем организация) и содержит 2 части:
1. Требования к свойствам предмета поставки
2. Требования к порядку работ и процедурам разработки, сдачи, внедрения, сопровождения
Если вы поставляете морозильные камеры в ресторан, то конечно вам надо хоть немного разобраться в бизнесе и понять, зачем камеры, как они будут применяться, как заказчик измерит, что камеры работают хорошо. Но в ТЗ на закупку камер будет написано другое — а именно, характеристики камер, а не бизнеса.
Так что в догонку к предыдущим комментаторам — в разработке ПО можно даже и без ТЗ, но всё равно кто-то должен поставить бизнес-задачу в терминах измеримой цели и ограничений (железного треугольника), и само собой не в виде «цель проекта: внедрить CRM» :)
Поэтому я бы настаивал на:
Бизнес-требованиях (1 страничка) — что должен делать бизнес в интересующей нас области (capabilities), с каким качеством, с какими ограничениями (показатели процесса)
Концепция решения (3 странички) — что именно мы хотим сделать, как в целом будет устроена конструкция (бриф-архитектура), каким качеством, какими ключевыми свойствами (перечень user stories), с какими ограничениями (показатели ИТ-системы)
Бизнес-обоснование (1 страничка) — как именно это решение (2) приведёт к реализации бизнес-требованй, как именно будут окупаться вложения, какие вложения в каком графике понадобятся. Подрядчик может этого документа не видеть, но именно он определяет допустимые границы бюджета.
Концепция проекта (project) (1 страничка) — из каких очередей будет состоять разработка, какие свойства будут входить в каждую из них — например, в формате story map
Вот это всё так или иначе нужно, а ограничивать софт именно ТЗ стоит тогда, когда предельно точно известно, что именно нужно сделать и как оно должно работать — что требует детального проектирования, что увеличивает предпроект на 2-3 месяца и в общем случае не выгодно заказчику, да и подрядчику, т.к. в коммерческой разработке попытка угадать правильную работу фич в режиме Big Design Upfront ни к чему хорошему не приводит.
Думаю вы правы про VC. Просто я обычно пишу другой характер статей и в основном сюда, а такой материал на vc лучше бы подошёл наверное.
Кстати, если мы делаем компьютерные игры определённого жанра, то БТ компании, которая сама эти игры разрабатывает, продаёт и эксплуатирует, могут быть довольно простыми и устойчивыми, их не надо в каждом проекте заново изобретать:
Организация должна разрабатывать онлайн-игры в жанре X для рынка Y
Организация должна продавать эти игры
С применением каналов оплаты KO1-KON
C применением валют V2-VN
Организация должна позволять клиентам играть в игры с использованием языков интерфейса Y1-YN
Организация должна предоставлять клиентам возможность получать качество обслуживания при игре в игры на уровне, не хуже чем конкуренты Z1, Z2 и Z3
Организация должна получать, хранить и предоставлять ответственным сотрудниками информацию о фактах продаж, подписок, отказов
Организация должна предоставлять клиентам возможность обратиться с жалобой
Организация должна анализировать поток обращений клиентов
Организация должна реагировать на обращения согласно политике CP1
...
и т.д.
Почему ТЗ стоит денег?