Это третья статья из цикла про работу с бюджетными учреждениями. Если вы подзабыли, о чем идет речь, то можете перечитать предыдущие части (часть 1, часть 2).
Сегодня мы затронем следующие темы:
— долог путь от обещания к обязательству;
— подводные камни технического задания;
— казнить нельзя помиловать менять нельзя оставить, или как законодательство влияет на техническое задание;
— опять КОСГУ;
— и другие.

Глава 0. Скучная, но обычная

В предыдущей статье мы:

• узнали, что заказчик может тратить деньги разными способами и в соответствии с разными законами;
• убедились, что в случае закупок у единственного поставщика заказчик ограничен некоторыми предельными суммами;
• познакомились с Планом-графиком — документом, содержащим информацию о планируемых заказчиком закупках;
• выяснили, что план ФХД и План-график тесно связаны, а всеобщая информатизация приводит к странным на первый взгляд зависимостям.

Глава 1. Техническое задание — разве это важно?

Итак, получив от заказчика предложение от которого невозможно отказаться разработать для него некое программное обеспечение за определенную сумму денег, мы довели заказчика до нервного срыва предприняли некоторые изыскания с целью получения дополнительной информации. А известно ли нам, чего именно хочет заказчик?

О важности технического задания (далее — ТЗ) было сказано уже немало, поэтому ломиться в открытую дверь не будем: все вы являетесь специалистами в своей сфере и лучше многих знаете, что должно быть прописано в ТЗ.

Внесем уточнение в граничные условия: программное обеспечение, которое нам требуется разработать, — это программа копирования файлов (да-да, использована идея из вот этой статьи). Что именно необходимо уточнять перед началом работ, а что нет, и полемику, развернувшуюся вокруг, читайте там же в комментариях. Для тех, кто по каким-либо причинам прочитать эту статью не может, совсем простенький пример:

Допустим, в ТЗ указано, что программа должна работать в ОС Windows Windows XP Windows Vista Windows 7 и выше, а вот поддерживаемые файловые системы не оговорены. Чисто теоретически, можно предположить, что раз программа должна работать под конкретной операционной системой, то и проблем нет: будем ориентироваться на ntfs, fat, exfat и refs. Следует ли из условия работы программы только под ОС Windows, что такие файловые системы, как ext2/3/4, btrfs, reiserfs и прочие могут быть нами проигнорированы? Нет, не следует.

Можно возразить, что такая ситуация невероятна. А если у заказчика линукс в дуалбуте (был или есть) или состоялся переход на СПО (да, частично, да, не везде, да, кривовато — но тем не менее) — вот откуда содержащие информацию разделы с другими файловыми системами, но сама программа копирования должна работать непременно из-под Windows? В жизни всякое случается.

Конечно, при сдаче результата работ заказчику, экспертной комиссии (или уже доказывая свою правоту в суде), мы можем долго объяснять, что эти файловые системы не поддерживаются заявленной ОС нативно, что для работы с такими ФС необходимо устанавливать дополнительное программное обеспечение. А заказчик на это может возражать, что дополнительное ПО дорогое и даже несовместимо с каким-либо другим уже имеющимся ПО или оборудованием, да и вообще: заказчик не желает доустанавливать что-то там еще — он хочет, чтобы его программа просто работала. Есть ли у вас шансы доказать свою правоту? Безусловно. Не проще ли было предупредить эту проблему еще на этапе составления ТЗ? Конечно же проще.

Если речь идет о поставке компьютеров, то для заказчика, когда он только начинает переговоры с вами, может быть и простительно написать что-то вроде:

№ п/п	Наименование	Ед. измерения	Кол-во	Цена за ед., руб.	Стоимость, руб.
1	Компьютер	шт.	10	10000	100000

Но после выяснения того, что действительно нужно заказчику, спецификация вполне может принять следующий вид (цена, естественно, фантастическая, но это ведь только пример):

№ п/п	Наименование	Ед. измерения	Кол-во	Цена за ед., руб.	Стоимость, руб.
1	Системный блок «NoName» Intel Core i5-4460(3.2GHz)/8Gb/ 1Tb/GTX960-2Gb/DVD-RW/ Win10/Black	шт.	10	10000	100000

В чем еще заключается важность технического задания?
Мы много говорили об обещаниях, но только ими сыт не будешь — давайте теперь поговорим об обязательствах. Единственным (почти единственным) законным обязательством бюджетного учреждения перед вами является договор. Причем нужен именно договор на бумаге или в форме электронного документа. А как же форма сделок, которая может быть письменной или устной (статья 158 ГК РФ)? Поверьте, это не наш случай. Только договор.

Да, есть возможность поставить заказчику товар без договора и получить подписанную накладную, можно даже получить от заказчика подписанный акт выполненных работ, не имея договора на руках. Но вспомните, что одна из целей, озвученных в самой первой статье — минимизация рисков, а работа без договора эти риски при прочих равных условиях существенно увеличивает. Нет договора — есть только обещание обязательства.

Предмет договора — одно из самых важных его условий (безусловно, важными являются и другие, и о некоторых из них мы впоследствии поговорим более подробно), которое не ограничивается и не исчерпывается пунктом, содержащим слова «Заказчик поручает, а Исполнитель принимает на себя обязательства по ...», или пунктом с названием «предмет договора».

Если речь идет о поставке товара, то предмет договора будет содержаться, в том числе, в спецификации (таблица выше), а если говорить о нашем многострадальном программном обеспечении для копирования файлов к разработке которого такими темпами мы приступим не раньше, чем через парочку столетий, то предмет договора будет содержаться, в том числе, и в техническом задании. Согласитесь, «разработка программного обеспечения» — слишком общая формулировка, «разработка программного обеспечения для копирования файлов» — лишь немногим лучше. А вот если помимо этих слов договор содержит ТЗ и иную информацию, позволяющую зафиксировать в понятной для обеих сторон (а в случае возникновения сложностей — и для суда) форме, что именно обязан сделать исполнитель, то мы и получим предмет договора.

Глава 2. Техническое задание — разве это важно? — 2

А что мы так прицепились к техническому заданию? Нужно будет — потом откорректируем, много раз так делали безо всяких проблем. Ну что ж, давайте посмотрим. В процессе разработки вы обнаружили, что кое-что можно сделать гораздо проще/надежнее/быстрее и ….

Во-первых, практически все изменения в договор вносятся исключительно по соглашению сторон (да, есть еще варианты по решению суда, а кое-что можно менять и в одностороннем порядке, но это совсем другая песня), поэтому вам для внесения практически любого изменения придется заручиться согласием заказчика (что не всегда получается).

Во-вторых, а вы уверены, что вообще имеете право вносить в договор какие-либо изменения? Или что такое право есть у заказчика?

Статья 432 часть 1 Гражданского Кодекса РФ (далее — ГК РФ):
«1. Договор считается заключенным, если между сторонами, в требуемой в подлежащих случаях форме, достигнуто соглашение по всем существенным условиям договора.
Существенными являются условия о предмете договора, условия, которые названы в законе или иных правовых актах как существенные или необходимые для договоров данного вида, а также все те условия, относительно которых по заявлению одной из сторон должно быть достигнуто соглашение.»

Часть 2 статьи 34 44-ФЗ:
«2. При заключении контракта указывается, что цена контракта является твердой и определяется на весь срок исполнения контракта, а в случаях, установленных Правительством Российской Федерации, указываются ориентировочное значение цены контракта либо формула цены и максимальное значение цены контракта, установленные заказчиком в документации о закупке. При заключении и исполнении контракта изменение его условий не допускается, за исключением случаев, предусмотренных настоящей статьей и статьей 95 настоящего Федерального закона.»

Так как ТЗ (частично или полностью) является одной из составляющих предмета договора (да и вообще является неотъемлемой частью договора), то менять его нельзя. Вообще никакие условия договора менять нельзя (за некоторыми исключениями). Открываем статью 95 часть 1, которая гласит, что «изменение существенных условий контракта при его исполнении не допускается, за исключением их изменения по соглашению сторон в следующих случаях:».

Из всего перечня нас могут заинтересовать разве что следующие пункты:

• 1б) — изменение цены контракта пропорционально изменению объема товаров, работ, услуг, но не более, чем ±10%;
• 1а) — снижение цены договора без изменения объема товаров, работ, услуг (да, бывает и такое);
• 6 — изменение цены контракта и объема товаров, работ, услуг при уменьшении доведенных до заказчика лимитов бюджетных обязательств.

Обратите внимание, что для всех этих случаев необходимо соглашение сторон, а для случаев 1а) и 1б) возможность изменения условий должна быть еще и предусмотрена договором. Эти пункты достаточно интересны, а пункт 6 еще и довольно опасен — возможно, в другой раз мы поподробнее рассмотрим, как их можно использовать в своих интересах. Но вот к нашему случаю с изменением ТЗ они отношения не имеют.

«Шеф, все пропало»? Не совсем. Статья 95 содержит, помимо прочих, часть 7, которая гласит:
«7. При исполнении контракта (за исключением случаев, которые предусмотрены нормативными правовыми актами, принятыми в соответствии с частью 6 статьи 14 настоящего Федерального закона) по согласованию заказчика с поставщиком (подрядчиком, исполнителем) допускается поставка товара, выполнение работы или оказание услуги, качество, технические и функциональные характеристики (потребительские свойства) которых являются улучшенными по сравнению с качеством и соответствующими техническими и функциональными характеристиками, указанными в контракте. В этом случае соответствующие изменения должны быть внесены заказчиком в реестр контрактов, заключенных заказчиком.»

Если заказчик не против, вы можете поставить товар, выполнить работу, оказать услугу лучшего качества. Как подтвердить, что качество улучшилось? Единого рецепта нет. С товарами, обычно, попроще: например, больший объем жесткого диска вполне можно считать улучшенной характеристикой (бывают и исключения: например, ПО, с которым работает заказчик, не видит диски больше 137 Гб — тогда вместо улучшенного качества получим нечто неработоспособное). Если же речь не о товаре, то можно попробовать получить экспертное заключение (от сторонней организации или экспертов), которое подтвердит, что что-то улучшилось.

Гораздо хуже, если от возможности изменения ТЗ будет зависеть выполнение работы в принципе, а не некоторые приятные, но необязательные бонусы, вроде повышения надежности, упрощения и убыстрения разработки и т. п. В этом случае придется что-то изобретать — не исключено, что очередные костыли.

Важное уточнение:
Существуют различные мнения по вопросу возможности изменения условий договора: одни считают, что менять нельзя только существенные условия, другие — что менять нельзя вообще ничего, третьи — что надо смотреть по ситуации, четвертые — что менять ничего нельзя только в тех договорах, которые заключены по результатам конкурентных закупок и т. д. и т. п. Также есть различные мнения по поводу того, что относится к существенным условиям договора, а что к несущественным. Одна из причин такого разнообразия — очередная криворукость законотворцев.

Есть другие способы подменить поменять ТЗ или не заметить обойти, но так делать нельзя.

Естественно, все-все-все в ТЗ или спецификацию вместить невозможно — степень детализации определяйте сами. Учитывайте, что чем жестче ТЗ, тем меньше свободы и у вас, и у заказчика, и внесение каких-либо изменений может оказаться весьма затруднительным.

А если предпочесть более свободное, рамочное, гибкое ТЗ? Впоследствии это может обернуться для вас затяжными спорами с заказчиком и проблемами при сдаче-приемке работ из-за того, что все друг друга неправильно поняли.

Глава 3. Техническое задание — разве это сложно?

Если речь идет о конкурентных закупках, то в первом приближении информацию о потребностях заказчика мы можем получить из Плана-графика (заказчики обязаны включать в ПГ некоторую базовую информацию об объекте закупки) на вкладке «Основные позиции» (если подзабыли — смотрите предыдущую статью), а полное ТЗ или спецификацию — в документации о соответствующей закупке. А как быть с простыми договорами (пп.4 и 5)?

В некоторых регионах заказчики обязаны размещать информацию о каждой планируемой закупке (даже по пп. 4, 5) на какой-либо электронной торговой площадке. Эти площадки используются далеко не везде, зависят от региона и обладают разной функциональностью. Порядок размещения информации на таких площадках определяется местным законодательством, поэтому нельзя заранее предсказать, что именно там будет указано, но кое-что интересное найтись может.
В общем же случае, единственным источником информации для нас является заказчик.

Положа руку на сердце: как часто вам встречались заказчики с идеально составленным ТЗ? Нет, усилим трагизм: часто ли вам встречались заказчики с хотя бы нормально составленным ТЗ? Впрочем, речь у нас не совсем об этом, поэтому давайте просто рассмотрим несколько типовых ситуаций.

Ситуация 1. Есть ТЗ и мы с ним согласны.
Даже обычный сбор и анализ базовой информации, необходимой для оценки имеющегося ТЗ, вполне может потребовать значительных затрат. Какой бы базовой эта информация ни была, вам все равно ее необходимо получить: встречаться и беседовать с заказчиком; возможно, тратить силы и время на помощь заказчику в заполнении опросных форм и на их последующую оценку; может быть, придется знакомиться с инфраструктурой заказчика или с некоторыми особенностями его деятельности. Естественно, вам гораздо лучше известно какой объем информации будет для вас необходимым и достаточным, и то, как этот объем получить и обработать, поэтому дальше углубляться не будем.

Ситуация 2. Заказчик разработал свое ТЗ (достаточно вменяемое), и даже имеет наглость смелость на нем настаивать, но в этом ТЗ нас не все устраивает.
Помимо всего вышеперечисленного вам необходимо учесть затраты на обсуждение и осуществление корректировки ТЗ (если заказчик в принципе допускает корректировку).

Ситуация 3. ТЗ есть, но без слез на него не взглянешь.
Здесь возможны два основных варианта. Если заказчик понимает всю правду про свое ТЗ и согласен на любые корректировки, то все сведется к ситуации 4, которую мы рассмотрим чуть ниже. А вот если не понимает или понимает, но корректировку делать не хочет (или не может), то вам придется потратить немало сил на переубеждение заказчика (или тех вышестоящих инстанций, которые такое ТЗ придумали и теперь стоят на своем). Кстати, то, что вы убедили заказчика (или вышестоящую инстанцию) в необходимости корректировки ТЗ здесь и сейчас, совсем не означает, что вам дадут работать спокойно потом: заказчик еще до подписания договора может неоднократно требовать внести изменения в ТЗ, а после подписания — требовать сделать «как надо», а не как прописано в «этом дурацком ТЗ».

Также вместо базовой информации, возможно, придется собирать и оценивать гораздо больший ее объем: раз у заказчика не хватило сил даже на написание более-менее приличного ТЗ, то что говорить о качестве той информации, которую он может предоставить? Можно нарваться на такие сюрпризы… Скорее всего, в вашей практике не один раз встречались ситуации, когда, казалось бы, само собой разумеющееся оказывалось чем-то противоположным. Самые простые бытовые примеры: подключение заказчику интернета при отсутствии компьютеров и иных устройств, способных этим интернетом воспользоваться (заказчик-то был уверен, что нужен только интернет!), или установка wi-fi роутера при в принципе отсутствующем интернете (ведь заказчик был уверен, что wi-fi = интернет), или приобретение программного обеспечения без учета минимальных системных требований. Но это очень простые примеры, в которых заказчик — ССЗБ. А если не проверив очевидную (для вас, но не для заказчика!) информацию, крайним окажетесь вы?

Ситуация 4. ТЗ у заказчика нет, и все, что он может — это произнести/прочитать по бумажке/изобразить языком жестов (нужное подчеркнуть) то, что ему надо.
Ситуация совсем не редкая, и не стоит про себя (или вслух) сетовать на глупых заказчиков — фантазия государства настолько безгранична, а вера в возможности собственных граждан так велика, что директор какой-нибудь сельской школы вполне может оказаться перед необходимостью благоустройства территории, капитального ремонта здания и создания сайта (и это при наличии интернета, зависящего от направления ветра). Причем все это надо сделать еще вчера и, желательно, без денег.
Первой реакцией может быть как «опять из заказчика клещами вытягивать информацию, самому себе писать ТЗ и т. д.», так и «это же здорово: сам себе задачу ставь и сам же выполняй — что может быть лучше». Что ж, не будем спорить ни с одной из точек зрения — все они имеют право на существование.

В общем, в ситуациях 1 и 2 просто еще раз подумайте, так ли все это на самом деле просто и незатратно, а в ситуациях 3 или 4 прежде всего ответьте сами себе на один вопрос: оно вам надо? Да, вот так — прямо в лоб. Вы ведь просто можете отказаться, причем не потратив ни капли сил/нервов/времени на оценку и корректировку явно бредового ТЗ или на написание его с нуля.

Глава 4. Опять КОСГУ

Итак, заказчик замучен до смерти выпотрошен полностью хватается за сердце при вашем упоминании предоставил нам необходимую информацию, мы ее должным образом оценили и дополнили собранной собственноручно, довели (или не довели, потому что посчитали ненужным) до идеального состояния план ФХД и План-график (попутно замеряя время, насколько оперативно происходят процессы как внутри организации-заказчика, так и при взаимодействии с вышестоящими инстанциями), прояснили неоднозначные моменты и почти согласовали ТЗ, и вдруг … оказалось, что статья КОСГУ не соответствует предмету договора и ТЗ.

Во-первых, не вдруг, т.к. о возможности такого варианта мы с вами уже говорили в самой первой статье (глава 5, ситуация 3). Во-вторых, о том, что в план ФХД и План-график могут вноситься изменения, мы осведомлены, и осознаем, что при длительных переговорах с заказчиком собранная нами информация нуждается в периодической актуализации.

Помните, мы с вами говорили о важности статьи КОСГУ? Если забыли — можете перечитать. Несмотря на то, что она больше не должна указываться в плане-графике и ряде других финансовых документов, ее роль в бухгалтерском учете никто не отменял. И стадия формирования и обсуждения технического задания как раз подходит для того, чтобы разобраться со статьей КОСГУ — ведь именно сейчас мы окончательно согласовываем предмет договора.

Если несоответствие статьи КОСГУ предмету договора это ошибка (как чисто техническая, так и просто следствие неправильного применения классификатора), то нас ждет увлекательный и, скорее всего, довольно медленный процесс внесения изменений в план ФХД и/или План-график — в зависимости от того, где допущена ошибка.
Если несоответствие явилось следствие уточнения предмета договора и согласования ТЗ, то нас вновь ждет процесс внесения изменений. Например, было решено, что на создаваемое программное обеспечение заказчику необходимы все-таки исключительные права — в результате, статья КОСГУ с 226 должна поменяться на 320.

А если заказчик вносить изменения отказывается? Тогда есть несколько возможных причин:

1. Кто-то в прошлом (на этапе планирования, формирования бюджета или еще каком-нибудь) указал неправильную статью КОСГУ при планировании, а внесение изменений теперь займет слишком много времени, да и заказчика по голове не погладят.
2. Содержание работ поменялось внезапно — либо в ходе обсуждения ТЗ, либо просто по очередному ценному указанию вышестоящих инстанций — а время идет, и слишком много бумаг необходимо переделывать…
3. У заказчика есть деньги, которые надо потратить именно по этой статье КОСГУ — и точка. Такое бывает.
4. Заказчику не может внести/поменять статью КОСГУ на нужную потому, что… денег у него нет.

С точки зрения минимизации рисков ни одна из вышеперечисленных причин нас устроить не может — это вообще не должно быть нашей заботой. Если статьи КОСГУ (действительная, и та, которую мы считаем нужной) не совпадают (например, вам предлагают разработать ПО, а расходы планируют осуществить по статье 310, или поставить компьютеры по статье 226), то не стесняйтесь спросить у заказчика, чем вызван такой странный выбор (возможно, не все так страшно, как кажется), и если вас объяснение не удовлетворит — это повод задуматься

А если заказчик менять статью КОСГУ отказывается, но поработать хочется? О том, к чему с большой вероятностью приведут вышеописанные ситуации, и что этому можно противопоставить — в одной из следующих статей. А соглашаться на такие условия работы или нет — решение будет зависеть только от вашей оценки рисков.

А если мы статью КОСГУ так достоверно и не знаем? По плану ФХД и Плану-графику определить не получилось, а заказчик ничего не объясняет, либо делает это неубедительно? Да и как проверить, что он говорит правду?

Что ж, в то время, когда наша космические корабли бороздят просторы Вселенной, людям надо верить на слово, потому что принципу добросовестности сторон придается большое значение… Нет, сдаваться рано:

1. Если закупка выполняется в рамках каких-то глобальных проектов (муниципальных, субъектовых, государственных программ), то дополнительную информацию, как правило, можно найти в нормативных правовых актах об утверждении этих проектов.
2. Универсальный способ: официальное письмо и в адрес заказчика, и в адрес его учредителя, с просьбой подтвердить, что на интересующую вас закупку предусмотрена такая-то сумма по такой-то статье расходов за счет такого-то источника финансирования. Про подобное письмо мы уже упоминали в одной из предыдущих статей. Скажете, что это бред, и незачем нервировать заказчика? Возможно, работать-то вам. И оценивайте риски именно со своей колокольни.

А если получить достоверную информацию так и не удалось, а способ с официальным запросом по каким-либо причинам неприемлем? Что ж, дальнейшие грамотные действия (как при заключении договора, так и при его исполнении) помогут избежать некоторых часто возникающих проблем или хотя бы смягчить возможные потери, но об этом — в другой раз.

Заключение

1. Техническое задание — это стильно, модно, молодежно реально важно:
2. Не всегда техническое задание можно изменить;
3. Техническое задание требует затрат в любом случае — оценивайте их приемлемость для вас заранее;
4. Статья КОСГУ тесно связана с предметом договора;
5. Нежелание заказчика менять статью КОСГУ — повод задуматься.

В следующих сериях

• почему мы остались без договора;
• всегда ли виноват заказчик;
• открытые данные спешат на помощь;
• договор и магические сущности;
• алло, мы ищем таланты нам нужен директор;
• договор — миф или реальность;
• и снова КОСГУ;
• где деньги;
• и другое.