Здравствуйте, в этой статье мы постараемся ответить на вопрос: «Составляем техническое задание для закупок по 44-ФЗ». Если у Вас нет времени на чтение или статья не полностью решает Вашу проблему, можете получить онлайн консультацию квалифицированного юриста в форме ниже.
За формирование ТЗ отвечает контрактная служба (контрактный управляющий). При этом к составлению техзадания рекомендуется привлечь юристов и экспертов, имеющих необходимый опыт в конкретной области закупок. Документ с ТЗ утверждается руководителем заказчика или другим уполномоченным лицом.
Этапы составления техзадания
- Подготовить список терминов, понятий и сокращений, используемых в документе.
- Указать полную информацию о заказчике:
- наименование организации;
- адрес организации или подразделения, отвечающего за госзакупку;
- режим рабочего дня, согласно внутреннему трудовому распорядку.
- если закупка совместная — права и обязанности каждого заказчика;
- если закупка централизованная — сведения об уполномоченном органе (ч. 1 ст. 26);
- в случае привлечения экспертов — порядок их работы.
Для чего нужно техническое задание?
Техническое задание не менее значимо, чем юридический акт, в деле закрепления прав и обязанностей сторон — заказчика и исполнителя.
Фактически это инструкция для разработчиков, конструкторов и других непосредственных создателей конечного продукта. Но по сути техническое задание, определяя жёсткие требования к каждой детали, делает сотрудничество заказчика и исполнителя безопаснее и комфортнее.
Когда каждая мелочь регламентирована, всё на своих местах, все при своих полномочиях и обязанностях, остаётся мало пространства для нечестного манёвра и недопонимания. Идеально, когда его вообще не остаётся.
Более того, конкретное и целостное техническое задание — это первый шаг к качественному результату. Чтобы продукт работал чётко, без сбоев, да и просто безопасно — это тоже периодически стоит на повестке — все его элементы должны быть продуманы. Тщательно и скрупулезно.
Техническое задание — основа как простых односложных продуктов, так и высоконагруженных систем. В каждом случае сценарии функционирования должны быть предусмотрены. Любое действие пользователя должно быть предугадано, и ответом на него должен быть полезный результат.
Именно для того, чтобы работа с конечным продуктом вызывала положительный отклик пользователя и решала его задачи, необходимо проработать идею и детали проекта на самой ранней стадии.
Наличие у заказчика обстоятельного технического задания сокращает вероятность проблем в разработке.
Если вы хотите получить качественный сайт за свои деньги, подойдите к составлению ТЗ ответственно. Все “серые” зоны, всё, что не предусмотрено тз может быть истолковано не так, как вы себе это представляете. Если для вас очевидно, что на сайте должно быть несколько способов доставки — это не значит, что это же очевидно для исполнителя.
- А если хотите получить крутой и функциональный сайт без составления огромного ТЗ, быстро и качественно, оставляйте заявку и наши менеджеры свяжутся с вами в течение часа.
Как распознать качественное ТЗ
- С первых страниц понятно, какую функцию выполняет приложение
Попросите постороннего человека прочитать ТЗ и описать приложение в общих чертах. У него это должно легко получиться.
- Перечислены поддерживаемые устройства и операционные системы
Если вы планируете пользоваться приложением на iOS 7, попросите исполнителя прописать это в ТЗ. Тогда он сможет сразу предупредить вас, что поддержка этой операционной системы в современных реалиях невозможна. Представляете, если бы это обнаружилось только по итогу работ?
- Детально описаны все экраны и кнопки
В ТЗ зафиксировано, сколько экранов в приложении, как происходит переход между ними и какое действие выполняет та или иная кнопка.
- К каждому экрану нарисована схема
Она поможет представить, как экран будет выглядеть в готовом продукте и станет основой для дальнейшей разработки дизайна.
- Не используются отсылки к сторонним продуктам при описании функций
Слова «как в инстаграме» или «как в фэйсбуке» абсолютно не подходят для ТЗ. Любой продукт может измениться во время разработки вашего приложения, и отсылка будет вести в никуда. К тому же она может быть по-разному трактована вами и исполнителем.
- Прописано поведение приложения для нестандартных ситуаций
Отсутствие интернета, неправильный ввод данных или попытка загрузить слишком большое изображение не должны привести к поломке приложения.
Очень важный, и при этом часто описываемый чисто формально раздел. Хотя, на мой взгляд, это самый важный раздел ТЗ, без него мы просто не понимаем, о чем вообще создаваемая система.
Давайте сначала определим, что такое «объект автоматизации». Если мы автоматизируем склад или завод, отдел бухгалтерии, то все понятно. А если, например, создаем новую социальную сеть, то объекта как бы и нет. Но на самом деле, под объектом скорее имеются в виду автоматизируемые процессы. И даже в случае со складом мы же автоматизируем не сам склад (как можно автоматизировать хранение коробок?), а складские процессы.
Если выполнять данный раздел формально, то он будет очень похож на описание назначения системы, и в ТЗ появится еще одно озеро воды, но так и не будет понятно, а что должна делать система.
В данном разделе следует приводить:
- Описание заказчика: виды деятельности заказчика, количество филиалов, сотрудников. Конечно, характеризовать заказчика нужно в той части, которая непосредственно касается создаваемой системы.
- Сведения о пользователях системы: виды пользователей, какую роль играет система для разных пользователей.
- Описание автоматизируемых объектов. Например, если мы автоматизируем склад, до должны описать, какой он площади, сколько проходов, какая ширина проходов, какие стеллажи, имеется ли отдельная зона сборки, сколько работает человек и какие у них обязанности. Тогда мы поймем, что конкретно автоматизируем, как должен выглядеть складской процесс, и какое оборудование используется.
- Описание автоматизируемых процессов. Конечно, не стоит в ТЗ расписывать процессы подробно. Но привести общие сценарии — обязательно. Только тогда нам становится ясно, какие должны иметься функции.
- Перечень документов, в которых приводится подробное описание объекта автоматизации.
Как составить техническое задание на закупку: пошаговая инструкция
Чтобы составить техзадание, нужно последовательно проработать каждый из его разделов. Приводим этапы разработки технической документации на госзакупку.
Шаг 1. На этом шаге нужно составить терминологический список, в котором для исключения разночтений формулируются определения и сокращения понятий, используемых в ТЗ.
Шаг 2. Подробное описание заказчика:
- наименование (официальное название фирмы и ее организационно-правовая форма);
- адрес (фирмы или ее подразделения, ответственного за госконтракт);
- график работы, предусмотренный режимом предприятия-заказчика.
Шаг 3. Включение в ТЗ следующих сведений о закупке:
- совместная или нет; в первом случае нужно прописать права и обязанности всех заказчиков (ПП от 28.11.2013 № 1088);
- централизованная или нет; в первом случае указываются данные об уполномоченном органе (ч. 1 ст. 26 закона № 44-ФЗ);
- привлекаются ли эксперты, в каком порядке они работают.
Шаг 4. Указание следующих данных о госзакупке:
- как определяется поставщик (ч. 1 ст. 24);
- почему был выбран именно этот способ его определения (ч. 5 ст. 24).
Техзадание составляет исполнитель
Техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» — это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.
Хорошее ТЗ всегда составляет исполнитель – проект-менеджер или разработчик. Очевидно, что веб-разработчик понимает в создании сайтов больше, чем владелец бизнеса, поэтому описывать проект придется ему.
Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Отлично, одобряю». Он тоже должен участвовать в процессе:
- познакомить исполнителя с компанией, продуктами и целевой аудиторией;
- объяснить, зачем ему сайт;
- рассказать, чего хочет, поделиться идеями;
- показать примеры сайтов, которые можно взять за образец;
- ответить на любые вопросы исполнителя.
Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?». Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему. В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, т.к. получится под 50 страниц и решил разбить ее на 2 части:
- В первой части «Разработка Технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение Технического задания, дам некоторые рекомендации по формулировке требований.
- Вторая часть «Разработка Технического задания. Как формулировать требования?» будет полностью посвящена выявлению и формулировке требований к информационной системе.
Для начала надо разобраться, какой в действительности вопрос интересует тех, кто спрашивает «Как разработать техническое задание?» Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания. О каких вариантах я говорю:
- Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;
- Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную IT-службу. Решили поступить так: разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
- Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.
- IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:
- Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;
- Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
- Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);
- Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.
- Возможны и другие, реже встречающиеся варианты;
Думаю, сейчас у читателя должны возникнуть вопросы:
- А почему нельзя разрабатывать Техническое задание всегда одинаково?
- Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
- Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
- Как понять, хорошо составлено Техническое задание или нет?
- За чей счет должно оно разрабатываться, да и нужно ли оно вообще?
А нужно ли вообще техническое задание? А Технический проект?
Не перегрелся ли я? Разве такое возможно, вообще без Технического задания? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого». Золотые ведь слова, ко всему подходят. Так что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.
А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.
Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.
Что такое техническое задание (ТЗ)?
Техническим заданием называется служебный документ с описанием правил выполнения работы и требований к исполнителю.
Почему важно зафиксировать весь процесс работы в виде технической документации?
- В ТЗ прописаны договоренности между исполнителем и заказчиком, которые сложно выразить в договоре из-за использования специфической IT-терминологии.
- Это сэкономит время на коммуникациях: зафиксированные технические решения избавят от многочисленных пересказов, подтверждений, путаницы в показаниях.
- Документ позволит четко разделить зоны ответственности между сторонами проекта.
- ТЗ дает возможность проанализировать будущий проект и выявить проблемы на стадии планирования.
- Правильно составленное задание сделает поведение всех участников работы предсказуемым и избавит от возникновения многочисленных недоразумений.
- С юридической точки зрения, наличие этого документа облегчит сторонам разрешение спорных моментов.
- Техзадание делает возможным финансовое планирование, что является залогом успешного бизнеса. Заказчику будет заранее видно, на что расходуются его средства.
Что дает сторонам каждый раздел ТЗ:
|
Раздел ТЗ |
+ Для Заказчика |
+ Для Разработчика |
|---|---|---|
|
Определение цели |
Осознание задач, которые решает проект или его доработка |
Понимание сути задачи |
|
Описание продукта |
Представление о том, каким будет готовый продукт |
Уверенность в правильном понимании конечного результата |
|
Сроки выполнения |
Ориентирование в сроках работ и получения планируемых результатов |
Оценка трудозатрат и потребности в ресурсах |
|
Бюджет проекта |
Определение более-менее точной суммы затрат и планирование бюджета |
Согласованный учет всех работ проекта |
|
Перечень работ |
Подробное описание работ и каждого этапа реализации проекта |
Ведение работ по установленной технологии. Возможность отказаться от работ, не предусмотренных заданием, либо включить их в ТЗ за доплату |
|
Оценка результата работ |
Проверка работы проекта по программе тестирования на соответствие требованиям задания |
Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ |
|
Обслуживание проекта |
Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта |
Выполнение работ с учетом обслуживания проекта в перспективе |
|
Выявление проблем |
Планируемые доработки проекта |
Доработка в соответствии с новыми потребностями |
Пример составления ТЗ на программное обеспечение
Нужно создать ПО. Технические требования — ниже.
Описание: программа для поиска статей по ключевому слову на всех авторитетных сайтах, адреса авторитетных сайтов прописывать нужно вручную.
Что должно делать ПО: после ввода ключевого слова находит статьи на сайтах, которые внесены заранее в качестве авторитетных источников, выводит список совпадений в таком формате:
- Линк
- Название статьи
- Лид-абзац
Если больше 10 совпадений, нужно разделить на страницы — по 10 на каждой.
Технические требования: язык программирования — любой, не принципиально. Главное, чтобы программу потом можно было доработать и вывести в качестве онлайн-сервиса. В идеале сервис должен искать за 10 секунд.
Сроки: до 15.09.2018.
О важности технического задания говорить уже не приходится.
Если Вы сотрудничаете со специалистами на аутсорсе, то рано или поздно перед Вами встанет задача прописать техзадание.
Даже если Ваше первое ТЗ получится не слишком удачным и понятным исполнителю, не расстраивайтесь и не отказывайтесь от этой затеи.
Основными преимуществами ТЗ являются:
- универсальность (работает в разных сферах);
- достоверность (при любых конфликтах сторон можно прочитать условия, на которых изначально была построена работа);
- облегчение жизни как заказчику, так и исполнителю (первый сразу прописывает все свои требования, а второй в любой момент может перечитать текст и найти ответы на многие вопросы).
Техническое решение или ТР
А вот та самая часть, которую многие совсем не понимают. Кроме технического задания (в котором может быть просто 3-4 пункта пожеланий на салфетке из кафе), может быть еще техническое решение. Оно чаще всего гораздо важнее чем ТЗ и сильнее влияет на конечный результат.
Техническое решение — пишет как раз Разработчик, где описывает то как он видит решение, что предлагает.
Зачем это нужно? Чтобы исключить разное понимание условий и снизить риски расхождения ожиданий.
Пример для понимания. Заказчик дает ТЗ «Я хочу есть», а Исполнитель предлагает ТР «На вот яблоко». Далее может быть 3 сценария: Заказчик соглашается, корректирует/просит предложить что-то еще или отказывается от дальнейшего общения 🙂
Чаще всего Заказчик либо принимает решение, либо просит что-то поправить и затем принимает решение.