Вопрос экономии всегда актуален для бизнеса. Особенно если решить его можно за счёт налогов и взносов. В этом году лидерами по налоговым «скидкам» стали IT-компании, но чтобы получить их, нужно выполнить ряд условий. Одно из таких — вступление в реестр отечественного ПО.
Для вступления в реестр есть важный пункт — наличие сайта с описанием функционала приложения и ценами для каждой отдельной комплектации. Кто-то садится разрабатывать сайт самостоятельно, большинство же выбирает не тратить время на эту задачу и нанимает подрядчика. Возникает вопрос: какой договор с ним составить?
О чём в статье:
Про договоры с подрядчиками
Судебная практика неоднозначна. Иногда суды считают, что достаточно составить договор подряда, некоторые ссылаются на договор оказания услуг, а третьи вовсе настаивают на смешанном. Есть даже вариант с авторским заказом, если договор заключается с физлицом.
Хорошо, здесь мы поняли, что единых правил нет, и в каждом отдельном случае нужно выбирать тип договора по ситуации, учитывая судебную практику. А что дальше?
ШВЕЙНЫЙ БИЗНЕС. ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Дальше подготовка и проверка договора — довольно сложный и трудоёмкий процесс. Сначала нужно выбрать тип договора (с этим определились выше), подобрать пункты, которые хотите в нём отразить и прописать все составляющие сухим юридическим языком.
Но какой бы договор вы ни выбрали, в любом случае к нему нужно подготовить техническое задание, оно же ТЗ, которое является неотъемлемой частью. Ниже будет о том, как правильно его составить.
3 причины составить техническое задание
1. Самое простое — защитить себя.
ТЗ поможет согласовать и закрепить на бумаге договоренности по срокам и порядку внесения правок. Позволит детально прописать объём работ, элементы сайта и ожидаемый функционал. В случае спора вы всегда сможете ссылаться на подписанный документ, использовать его в качестве аргумента в переписке с исполнителем и, если понадобится, как доказательство в суде.
2. Понять и зафиксировать цену.
В задании чётко прописывается прайс всех работ: разработка сайта, его отдельных элементов и даже техническое сопровождение. Это важно не только в контексте полной стоимости работы, но и в ситуации, когда стороны решают прекратить работу в середине проекта, и нужно понять, кто и кому сколько должен.
3. Нужно заменить или добавить исполнителей.
Если вы разошлись с прежним исполнителем или просто хотите поручить разработку различных модулей сайта разным подрядчикам, то техническое задание очень важно прописать детально, чтобы чётко понимать, кто и над какой частью трудится, и как они стыкуются между собой.
Что ТЗ даёт исполнителю
Если заказчик потребует то, что не указано в техническом задании, можно отказать ему в дополнительных неоплачиваемых работах. Если после этого он откажется от оплаты по договору, можно взыскать деньги через суд.
2. Возможность сделать проект быстрее и качественнее.
В хорошем ТЗ указаны структура сайта, необходимые функции и элементы на каждой странице. Если задание структурировано и понятно, то можно спланировать нагрузку и избежать ошибок.
Как написать понятное ТЗ, разделы. Советы от экспертной группы Бизнес-аналитика SDC
Что указать в техническом задании
Технические особенности
— Десктопная или мобильная версия.
Для этого стоит заранее изучить свою аудиторию и выдвинуть гипотезу, с какого устройства ваш сайт будут посещать чаще. После этого можно сверстать сайт под конкретные устройства.
Важно выбрать удобную админку, с которой в дальнейшем смогут работать ваши сотрудники. Например WordPress, Битрикс или Joomla. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP, а у клиента сервер на .NET.
Если сайт будет поддерживать большое количество браузеров (особенно старых), это может существенно увеличить стоимость разработки и лишить вас самых актуальных фишек. Если урезать — можете лишиться части своей аудитории. Нужно найти баланс.
Структура
Чтобы работать со структурой было проще, рекомендуем составить блок-схему. Она покажет точное расположение элементов, взаимодействие страниц и ожидаемые сценарии использования. Юридическая сила у схемы такая же, как у текста. Помочь с разработкой блок-схемы может специализированный сервис. У нас, кстати, есть один на примете.
— Хедер (шапка сайта).
Верхняя часть с логотипом, меню, контактами и разной графикой.
— Футер (подвал сайта).
Нижняя часть, содержащая правовую информацию, карту сайта, счётчики.
— Сайдбары (боковые панели).
Вертикальные панели по бокам страницы — колонки, содержащие определённый набор функциональных блоков (виджетов).
— Различные всплывающие окна, формы и подсказки.
Элементы сайта, возникающие при контекстных действиях пользователя.
Дизайн сайта
Зачастую дизайн сайта формируется из уникальных страниц — макетов, из которых будут формироваться остальные однотипные страницы.
Будьте готовы к тому, что эта часть станет самой спорной и требующей большого числа согласований. Рекомендуем зафиксировать и описать каждую страницу в ТЗ для сайта.
Функциональность
Если сайт предполагает функциональность, не привязанную к конкретной странице (например, блок с комментированием), или планируется интеграция с другими сервисами (соцсети, CRM, уведомления в мессенджеры), нужно закрепить это отдельно.
Сценарии использования
Если дизайн нестандартный, вы хотите, чтобы пользователи заходили в нужные разделы, или сайт определённым образом реагировал на действия пользователей — нужно указать это в ТЗ. Возможно, разработчики найдут наиболее эффективное решение задачи ещё на этапе планирования.
Наиболее популярные сценарии — заполнение формы обратной связи и создание заявки в CRM компании, а также всплывающий чат поддержки. Если это не сделать сразу, то потом придётся потратить кратно больше денег и времени на разработку.
Прототип
Если создание ТЗ вызывает сложности, или в сети уже есть хороший прототип, можете указать ссылку на него и предложить исполнителю сделать похожий. Но помните о рисках нарушения авторских прав, о них мы когда-то писали тут. А если кто-то украл сайт у вас, то пригодится эта статья.
Более наглядный и однозначный способ: исполнитель рисует эскизы каждой страницы, например здесь, и прилагает их к техническому заданию. Клиент видит, как будет выглядеть интерфейс будущего сайта и до финального этапа говорит, что ему нравится, а что стоит изменить.
Что в итоге
На определённом этапе почти каждому бизнесу понадобится сайт. Может быть вы захотите сэкономить на налогах и взносах как IT-компания, может захотите упростить документооборот, разместив оферту на странице, а может вам просто нужна страница для рекламы, привлечения клиентов из соцсетей и размещения статей.
Чтобы не тратить время на разработку правовых документов и пролистывание десятков страниц в поисках нужного ответа, обратитесь в Кнопку. Наши юристы помогут с грамотным составлением документов и дадут личные консультации конкретно по вашему вопросу. Познакомиться с услугами можно на этой странице. Там же вы найдёте услугу по вступлению в реестр отечественного ПО.
Но составлять конкретное техническое задание для сайта нужно будет самостоятельно. Чтобы избежать лишних нервов, трат или потери времени, рекомендуем составить подробное ТЗ с описанием всех пожеланий и подписать его с исполнителем. Если вы учтёте рекомендации из статьи, то сможете сделать это максимально эффективно.
Другие материалы на тему составления ТЗ можно почитать тут:
— Что такое структура сайта, для чего она нужна, и как её создать.
— Требования к структуре официального сайта образовательной организации.
Источник: knopka.com
Техническое задание на тендер
Чтобы корректно определить задачи перед исполнителем, заказчик разрабатывает техническое задание. От правильности составленного техзадания зависит, будет ли удовлетворён заказчик результатом исполнения контракта. Разберёмся в основных вопросах, связанных с составлением технического задания для тендера.
Техническим заданием (ТЗ) называется документ, в котором описаны требования, предъявляемые заказчиком к товарам, работам или услугам. В ТЗ содержатся подробное описание и характеристики товара/работ/услуг и сроки поставки/выполнения/оказания.
Помимо термина «техническое задание», для обозначения требований заказчика к товарам (работам, услугам) также используются названия «спецификация», «проектно-сметная документация» и тому подобные.
Требования к техническому заданию законодательством не регламентируются, однако Федеральным законом от 5 апреля 2013 года № 44-ФЗ установлены чёткие правила к описанию объекта закупки. Согласно положениям указанного закона, ТЗ должно содержать показатели, с помощью которых определяется соответствие закупаемых товаров (работ, услуг) требованиям, установленным заказчиком (ч. 2 ст. 33). Кроме того, для этих показателей должны быть указаны минимальные и/или максимальные значения, а также значения, которые не меняются.
Техническое задание используется в документах при формировании начальной или максимальной стоимости контракта, в закупочной документации и заявке на участие в тендере, а также в качестве раздела контракта или приложения к контракту
Для участия в закупках, размещения документации и заключения контракта необходима электронная подпись. Мы предлагаем удобные варианты тарифов, подходящие не только для участия в тендерах, но и для работы на госпорталах, отчётности в контролирующие ведомства, ведения ЭДО.
Как составляется ТЗ на тендер
За формирование ТЗ отвечает контрактная служба (контрактный управляющий). При этом к составлению техзадания рекомендуется привлечь юристов и экспертов, имеющих необходимый опыт в конкретной области закупок. Документ с ТЗ утверждается руководителем заказчика или другим уполномоченным лицом.
Техзадание прилагается к извещению в виде отдельного электронного документа «Описание объекта закупки». Оно отличается в зависимости от объекта заказа. При закупке товара заказчик указывает в техзадании наименование продукции, место поставки, а также сроки и условия поставки. В качестве источников для описания объекта можно использовать:
- государственные стандарты;
- рекламу и каталоги;
- публичные оферты;
- исполненные контракты;
- официальные информационные источники уполномоченных органов и др.
Как правило, документ с ТЗ содержит таблицу с характеристиками. Указывая характеристики, необходимо учитывать нормирование. Предельные характеристики обозначены в специальном перечне товаров, работ и услуг (Постановление Правительства Российской Федерации от 2 сентября 2015 года № 927). На его основе заказчики формируют свои списки и устанавливают требования к количеству и наивысшей цене товаров, а также к их свойствам. Перечень характеристик зависит от категории товара.
Образец бланка для технического задания на тендер
Образец технического задания
для тендера (вариант 1)
Источник: astral.ru
Каким должно быть ТЗ на Корпоративную ИС?
Представьте, что у вас есть корпоративная информационная система в развитие которой вкладывается 200+ млн. рублей ежегодно. С момента внедрения документация на систему превратилась из одного Технического задания на 600 страниц в 300 Технических заданий, у каждого из которых есть дополнение в количестве от 1 до 10 штук, и теперь она занимает объем 3 офисных шкафов и это ещё не конец… Фабрика по производству ПО исправно и ритмично (с периодичностью в месяц) выпускает обновление системы и документирует изменения.
Ребята, которые разрабатывали 34-й ГОСТ явно не рассчитывали на то, что дело может принять такой оборот. Да и книги по гибким методологиям разработки тоже не дают каких-то рекомендаций как с этим быть.
Всё что нам казалось не очень важным тогда, со временем и в масштабе приобрело вид серьезной проблемы.
- Как в этом объеме документов найти те, что описывают работу определенного функционала системы?
- Как из 20 найденных документов, описывающих Как дорабатывали функционал за последние 5 лет, понять его устройство сейчас?
- Как за списком требований «сделать, добавить…» рассмотреть заложенную бизнес-логику?
Часть №1 “Разработка ТЗ”
«Заказчик: Ребята, это фигня какая-то, ничего не работает.
Разработчики: У нас всё сделано согласно ТЗ.»
Технические задания к КИС выглядели как систематизированные перечни требований. Разработать формы, создать поля такого-то типа, такой-то размерностью и логикой формирования… Отличный документ для разработчика, который быстро превращается в чек-лист того, что нужно сделать и проверки что сделано.
Была у этого одна проблема, если сравнить разработку КИС с постройкой ракеты, то это выглядело так, нужные детали создали, а в отдельных местах собирать и присоединять их не стали, так как не было сказано: а) что это нужно сделать, б) как нужно собрать.
При попытке запустить такую ракету в космос она взрывается, с КИС же:
«Заказчик: Ребята, это фигня какая-то, ничего не работает. Разработчики: У нас всё согласно ТЗ».
Чем больше был размах функционала КИС, тем больше аналитики залипали в детали, и тем чаще теряли виденье задачи целиком.
Итог: Заказчик недоволен и считает, что мы плохие Аналитики… и он прав.
Документ составлен для Разработчиков, а подписывается под ним Заказчик. Всё что в нём изложено «какие поля добавить и т.д.» его не интересует, он в этом не понимает и не должен разбираться, ему интересно получить работающее ИТ-решение его бизнес-задачи. Когда Заказчик ставит подпись на ТЗ он верит, что получит именно последнее.
Я прихожу к директору, я говорю:
— Кто сшил костюм? Кто это сделал? Я ничего не буду делать, не буду кричать, я только хочу в глаза ему посмотреть.
Выходит сто человек. Я говорю:
— Ребята, кто сшил костюм?
Они говорят:
— Мы!
Я говорю:
— Кто это «мы»?
Они говорят:
— У нас узкая специализация. Один пришивает карман, один — проймочку, я лично пришиваю пуговицы. К пуговицам претензии есть?
— Нет! Пришиты насмерть, не оторвёшь! Кто сшил костюм? Кто вместо штанов мне рукава пришил? Кто вместо рукавов мне штаны пришпандорил?
Кто это сделал?
Они говорят:
— Скажите спасибо, что мы к гульфику рукав не пришили.
Представляете? Их – сто, а я – один. И все стоят, как пуговицы: насмерть. И я сказал:
— Привет, ребята! Вы хорошо устроились!
Аркадий Райкин
Новый шаблон ТЗ мы разбили на две части: первая для Заказчика, вторая для Разработчиков.
Первую часть ТЗ разрабатывал Бизнес-аналитик с Заказчиком с установкой ни в чем себе не отказывать. На выходе этого полета фантазии идеальный описанный и иллюстрированный вариант выполнения бизнес-операции Заказчика с использованием КИС. Оно состояло из бизнес-сценария и системных сценариев использования (use cases).
Дальше мечта бизнеса спускалась на бренную землю возможностей КИС, где Системный аналитик, Архитектор и Главный разработчик думали над тем как сказку сделать былью. Из горнила рождалась вторая часть ТЗ, которая трассировала бизнес-логику в требования к системе.
После появления второй части и подтверждения «Разработкой», что всё будет работать как описано в первой, Заказчик подписывал первую часть ТЗ и только её.
Пример бизнес-сценария
Пример системного сценария
Так был дан ответ на вопрос «Как за списком требований «сделать, добавить…» рассмотреть заложенную бизнес-логику?».
Часть №2 “Внесение изменений в ТЗ”
«Собери общую картину работы функционала из 20 документов (Пазл 18+)»
Документ №1 (основное ТЗ): Сделать поле №1.
Документ №2 (Дополнение №1 к ТЗ): Сделать поле №2.
Документ №3 (Дополнение №2 к ТЗ): Внести изменения в поле №1, сделать поле №3.
Документ №4 (Сменился РП по направлению, поэтому создано новое ТЗ): Внести изменения в поле №2 и поле №3.
Документ №5 (Дополнение №1 к новому ТЗ): Внести изменение в поле №3 и №1, сделать поле №4.
Документ №6 (Новый РП нашел основное ТЗ, Дополнение №3 к основному ТЗ): Внести изменение в поле №2 и поле №4.
…
Вот что собой представлял набор документации по функционалу. Новый шаблон ТЗ имел все шансы повторить участь предшественника, в качестве решения выбрали «переписывать слова в песне». С каждым новым изменением основное ТЗ переписывалось.
Мотив: у нас всегда один актуальный документ.
Нарисовалась проблема. Заказчик начал грустить, что из-за одного нового поля, он должен перечитывать весь документ, чтобы поставить на нем свою подпись. Представим, что одно ТЗ в среднем это 40 страниц, а в месяц Заказчик получает около 10 таких документов (фабрика же / быстрая разработка …).
Вернули дополнения к ТЗ и в них стали указывать, что на что меняем в основном ТЗ или какой новый раздел в него добавляем. Заказчик согласовывает дополнение к ТЗ на 2-3 страницы, а на его основании происходило обновление основного ТЗ. На выходе всё тот же один единственный документ, который описывает актуальное состояние ИТ-решения.
Пример внесения изменений в основное ТЗ с помощью дополнения
Так мы ответили на второй вопрос «Как из 20 найденных документов, описывающих Как дорабатывали функционал за последние 5 лет, понять его устройство сейчас?».
Часть №3 “Навигация по ТЗ”
Для навигации по техническим заданиям мы использовали реестр ТЗ, изначально предназначенный для резервирования номеров под ТЗ и указания исторической информации:
- Подразделения заказавшего разработку
- Заказчика в подразделении, который формулировал и ставил задачу
- Руководителя проекта нашего отдела, который отвечал за реализацию
- Системного аналитика подрядчика, написавшего ТЗ для разработчиков
Вот такое решение для последнего вопроса «Как в этом объеме документов найти те, что описывают работу определенного функционала системы?».
Каким должно быть Техническое Задание?
Один всегда актуальный документ. Достаточно прочитать только его, чтобы понять как устроен бизнес-процесс и его автоматизация. Чтобы найти нужные ТЗ в них есть метки в виде названия функционала КИС, бизнес-процессов и процедур, которые оно затрагивает.
Шаблон Технического Задания
Поделитесь какое ТЗ у вас, под какие задачи оно у вас настроено и как с ними справляется.
Что почитать по теме
- Применение Сценариев использования (use case) при разработке ТЗ
- Что такое Use Case и зачем они нужны?
- Книга Алистера Кокберна «Writing Effective Use Cases» на русском языке
- Техническое задание на сайт
- Техническое задание на сайт. Практика
- Описание процесса разработки ПО в компании Nevlabs с примером ТЗ (размещен на сайте компании)
- как написать ТЗ
- как написать техническое задание
- каким может быть ТЗ
- техническое задание образец
- как обновлять ТЗ
- обновление технического задания
- навигация по ТЗ
- навигация по техническим заданиям
- корпоративные ИС
- Анализ и проектирование систем
- Проектирование и рефакторинг
- Управление разработкой
Источник: habr.com