Работа с типовыми документами в заказной разработке

Пропустите эту главу, если работаете на стороне клиента. Или с собственной in-house командой. Или если слова «договор», «акт», «счет» вам понятны, и ясны все процедуры, которые за ними стоят.

Да, я тоже не люблю бюрократию. Но приходится. Посмотрим, какие документы возникают на разных этапах жизни проекта и как они связаны между собой. Рассмотрим работу как по Time&Material, то есть с оплатой по факту затрат, так и контракты с фиксированной стоимостью.

Смета — это, по сути, таблица, где работы оцениваются достаточно подробно, например, по страницам, по экранам или по функциям. Как правило, смета разбивается по этапам.

При подготовке сметы стоит следить за тем, чтобы остаться в рамках вилочной оценки, которую вы дали заказчику по итогу первичного обсуждения задачи. Либо у вас должны быть очень веские причины выхода за эти границы. Если какие-то функции были добавлены, лучше вынести их за смету. Или, как минимум, обозначить цветовым кодированием.

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

После того, как смета готова, надо показать её заказчику.

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

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

После такой демонстрации заинтересованный заказчик понимает, из чего именно складывается бюджет проекта и как на него можно повлиять. А именно: если что-то выкинуть, бюджет сократится, а каждая новая хотелка добавит и стоимости, и сроков. Акцентирую: заинтересованный заказчик. Когда заказчика волнует только «итого», а состав работ неинтересен, это тревожный звоночек.

Если заказчик настаивает, вы можете подписать предварительную смету как отдельное приложение к договору. Но делайте оговорку, что смета действительна при условии неизменного перечня работ, в течение ограниченного времени. Этот ход больше похож на то, будто вы договариваетесь работать по водопадной модели. И в этот момент вы явно далеки от модели Time&Material. Это можно смягчить, составляя контракты таким образом, чтобы разработка шла по этапам, спринтами. Чтобы в любой момент можно было переиграть набор функций относительно первоначальной сметы. Это делается в момент подписания приложения на конкретный спринт.

Кроме сметы обычно готовится календарный график проекта, или таймлайн. Удобно его оформлять в виде диаграммы Ганта, которая строится, например, по средним оценкам сметы. Она отражает ожидаемые сроки на каждый этап и на согласование работ. Также в таймлайне можно отразить график платежей, ожидаемые даты и суммы.

Многим заказчикам детальная разбивка по платежам очень важна, так как помогает планировать финансовую нагрузку.

Иногда менеджеру на стороне заказчика нужен документ, который он сможет положить на стол руководителю или передать в тендерный комитет компании.

Говорить мы будем именно про российское законодательство, так как международные контракты — это отдельная большая тема.

Агентству удобнее работать по Time&Material. Заказчику — когда как.

Давайте посмотрим, как срастить заказную разработку, например, по Scrum с контрактами и требованиям законодательства. Это не совсем просто и может показаться несколько громоздким.

Итак. Нам нужно узаконить итеративную разработку, когда проект запускается поэтапно. Сначала — самые важные с точки зрения бизнеса функции. Затем системно выпускаются новые версии. Состав работ можно менять на ходу: что-то убирать, добавлять или заменять на равноценные функции. Это позволяет заказчику проверить свою бизнес-идею и запустить самое важное как можно быстрее.

Поэтому мы подписываем с заказчиком рамочный контракт, где фиксируем общие условия сотрудничества. На отдельные этапы работ мы подписываем приложения к нему. Отдельно — аналитика. Отдельно — прототип, и так далее. А затем, как дело дойдет до разработки — отдельное приложение на каждый спринт. Подписали спринт, сделали, отгрузили.

Какой договор нам нужен? На оказание услуг или договор на выполнение работ (договор подряда)?

Есть простой критерий. Услуги — когда ценность имеет сам процесс. Например лечение, консультирование, обучение и т.д.

Работы — когда ценность имеет результат, то есть что-то готовое, например – дом, схема подключения коммуникаций, написанная книга.

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

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

Предмет договора и порядок его исполнения

Первое, что описывается в договоре — его предмет. В случае рамочного договора он банальный: что подрядчик обязуется выполнить работы, а заказчик обязуется их принять и оплатить.

Соответственно, далее фиксируется порядок исполнения договора.

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

Запрос информации и ответственные лица

Далее должно быть описано, кто, когда и в каком порядке может запросить что-либо у другой стороны. Заказчик может запрашивать у подрядчика отчеты о ходе работ (и это правильно). А подрядчик может запросить материалы, без которых не сможет выполнить работу. Очевидно, что заказчик эти материалы должен будет предоставить в указанные сроки.

Обязательно прописывается порядок назначения ответственных лиц и их функции на проекте. Важно, чтобы с каждой стороны было одно ответственное лицо, от которого можно получить всё, что должна предоставить сторона. Кроме того, это избавляет от ситуаций, когда от пяти человек на стороне заказчика приходят письма с указаниями, которые никак друг с другом не стыкуются. Да, заказчик может обсуждать проект сколь угодно большой рабочей группой. Но он должен договориться внутри себя. За кем-то должно быть последнее слово, должен быть арбитр. И решение должно транслироваться по принципу одного окна.

Срок договора

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

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

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

Порядок расчётов, сдачи-приёмки работ и передачи прав на результат

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

Кроме того, важный момент — когда оплата считается совершенной. Тут есть два варианта:

• в момент списания денег с расчетного счета заказчика,

• в момент зачисления денег на ваш счет.

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

Далее в рамочном договоре мы фиксируем порядок сдачи-приемки работ. Общий порядок регламентируется законодательством. Но в рамочном договоре мы указываем сроки, в которые заказчик должен подписать акт сдачи-приемки или предоставить список замечаний. Это позволяет точнее планировать сроки по проекту. И предотвращает затягивание приемки работ.

Кроме того, фиксируем в договоре порядок подписания акта подрядчиком в одностороннем порядке. Это крайняя мера, и к ней лучше не прибегать. Нужна она на случай, если заказчик пропал без вести и не выходит на связь либо отказывается подписать акт, но при этом не предоставляет список доработок или замечаний. Алгоритм подписания акта в одностороннем порядке мы рассмотрим с вами, когда будем говорить подробнее о закрывающих документах.

Также в рамочном договоре фиксируется порядок передачи прав на результаты работ. Например, мы передаем исключительные права на результат работ в полном объеме.

Важные моменты:

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

• В законодательстве не определен четко момент, когда права на результат переходят заказчику. В зависимости от контекста этот может быть и момент заключения договора, и момент создания результата, и момент подписания акта сдачи-приемки работ. Поэтому в рамочном договоре мы однозначно определяем момент передачи прав по двум условиям: во-первых, работы должны быть полностью оплачены, во-вторых — приняты заказчиком.

Ответственность сторон

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

Срок действия и порядок расторжения

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

При расторжении договора мы смотрим, есть ли по нему незакрытые приложения. Если есть — готовится акт сверки с указанием выполненных, но не закрытых актами работ по приложениям. После того, как акт подписан и задолженностей у сторон друг перед другом не осталось, договор может быть без проблем расторгнут.

Заказчик может инициировать расторжение договора в любой момент. Подрядчик же может отказаться от исполнения договора в трех случаях:

• значительное нарушение заказчиком сроков оплаты;
• значительное нарушение заказчиком сроков предоставления материалов;
• вмешательство со стороны заказчика лиц, не согласованных в качестве ответственных.
  

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

Если же договориться не получилось, в рамочном договоре указано, в каком именно суде должен решаться вопрос. По умолчанию споры решаются по месту нахождения ответчика. Если контрагенты находятся в разных городах, обычно можно согласовать суд г. Москвы как компромиссный вариант.

Обмен документами и результатами работ по договору

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

А теперь — приложения

Итак, рамочный договор мы согласовали и подписали. К нему мы будем заключать приложения на конкретные работы. Поэтому каждое приложение должно включать:

• Перечень работ. Что именно мы будем по нему делать.

• Цену за этот объем работ, и указание, в каком порядке работы будут оплачиваться.

• Сроки. Как сроки выполнения, так и приемки работ.

• Порядок выполнения и приемки работ. Что, в каком порядке и по каким шагам предполагается делать, а также в какие моменты и каким образом заказчик будет принимать работы.

Порядок передачи результата работ заказчику. По умолчанию вы должны передать результат работ заказчику в руки, под роспись, на материальном носителе. Если это не сделать — работы будут считаться не переданными, и заказчик будет вправе потребовать свои деньги обратно. Если вы хотите передавать результат, отправляя его на электронку, пропишите это в приложении. И не забудьте указать, в каком именно формате результат должен быть отправлен.

Требования к результату работ, или спецификация. Именно по ним мы потом будем проверять, сделана ли работа как надо. Нет каких-то абстрактных критериев качества. Всегда должны быть конкретные требования, которым должен соответствовать результат.

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

Так как у нас работа по спринтам, наши типовые приложения рассчитаны в первую очередь на итеративную разработку. Их у нас несколько, на все случаи жизни. Но условно их можно поделить на три блока: приложения на аналитику, на спринты разработки и на поддержку проекта.

Итак, первое приложение, которое мы будем подписывать с клиентом — это приложение на агрегацию требований. Зачастую на старте ни клиент, ни разработчик точно не знают, как и в каком виде лучше всего сделать проект, его первую версию. Поэтому надо выполнить предпроектную работу:

• выделить стейкхолдеров, составить цели проекта;

• изучить пути пользователей и привычные для них алгоритмы действий;

• поработать с семантикой и, используя метод персон, определиться с наиболее важными функциями.

Эта работа стоит денег, но она — относительно дешевая. Заказчику психологически проще оплатить первый счет, когда он в пределах 30-60 часов.

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

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

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

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

Наличие технического задания на проекте не заставляет строго следовать его букве. Конечный состав работ определяется СМЕТАМИ в приложениях на каждый отдельный спринт.

Указывайте в смете все экраны, которые планируется прототипировать, отдельными строками. Это важно, и позволит избежать лишних согласований, если по ходу заказчик попросит добавить прототипы для ещё пары страниц. Или если решит отказаться от какого-то раздела, а заодно и его прототипа.

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

При работе итерациями всё несколько сложнее. Первая версия сайта или приложения должна быть функциональной. Она должна быть «клёвенькая», а не полуфабрикат, на который жалко смотреть. Тут — работает, тут — не работает, тут — рыбу заворачивали.

Такая версия может быть разработана за несколько спринтов. То есть не факт, что итог первого же спринта пойдет реальным пользователям на боевой сервер. Да, это несколько противоречит концепции Scrum образца 2000-го года, но лучше вписывается в современные подходы и адекватнее воспринимается разработчиками и заказчиками.

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

Итак, для каждой версии проекта у нас последовательно подписываются приложения на дизайн, верстку и разработку.

Если объем работ планируется пока небольшой, то дизайн-верстку-код можно оформить одним приложением. Часто так и поступают. Если же первая версия продукта запланирована масштабная, лучше подписать эти приложения отдельными документами. Каждый этап всегда при необходимости можно раздробить ещё на подэтапы. Но не забывайте, что при этом у нас есть бэклог, в котором содержатся хотелки на следующие этапы. И, в отличие от договора, этот документ — живой.

На что надо обратить внимание при оформлении этих приложений?

Основное, в чем вы должны убедиться — что в приложение включены только те работы, которые вы действительно планируете делать на данном этапе. Это работы, которые перечислены в смете.

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

Жуткая бюрократия, именно поэтому, как только разработчик и заказчик притерлись, поняли, что от друг друга ожидать, нужно как можно быстрее переходить на Time&Material. Или смириться и плодить бумажки.

Работа по спринтам может вестись параллельно, в несколько потоков.

Бывает, что для старта программирования по спринту нужно проделать и аналитику, и дизайн порисовать, и рисёрч какой-то провести, а ещё интеграционный протокол составить. Проблем нет, структура приложений и договора это позволяет.

В общем случае аналитика может на два спринта идти быстрее разработки. На один спринт вперед — дизайн. Программирование — догоняет. А за программированием идет опять аналитика (сбор обратной связи от пользователей и генерация новых функций).

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

Такому количеству бумаг есть разумная альтернатива.

Например. Клиенту создается канбан-доска, куда он может накидывать задачи и ставить приоритеты. Крупные задачи могут быть обработаны спринтами, мелко-срочные, которые нужно брать и делать прямо сейчас, — в порядке очереди. Бывает, что по более высокому рейту. Но по схеме T&M можно делать и проекты целиком.

В чем её особенности?

Работая в рамках T&M, заказчик может оперативно запускать в работу срочные задачи, не дожидаясь согласования кипы документов.

Оплата идет по фактической трудоемкости задач. В конечном итоге, это выгодно для заказчика, потому что подрядчику не приходится закладывать в смету свои риски. Речь, естественно, о добросовестном подрядчике и адекватном заказчике. Именно поэтому важны этапы «притирки» друг к другу.

Оплата может быть по факту готовности работ, либо можно сделать некий «депозит» от заказчика. Есть некоторый объем предоплаченных часов, и не надо ждать очередной оплаты, чтобы стартовать очередной блок работ. В большинстве случаев депозита на 40 часов достаточно.

В чем сложности с депозитом, и почему с проверенными заказчиками в итоге оказывается продуктивнее работать с оплатой постфактум? При такой организации работ учет выполненных задач, мягко говоря, трудоемкий. Сложно понять, какой акт и какой счет соответствует каким работам. Что на постоплату, что на предоплату. Ну и нужна хорошая инфраструктура по учету реальных затрат на проекте. Если её нет, у агентства очень высок риск поработать бесплатно.

Задачи могут не попадать в биллинг, затраты могут не попадать в биллинг. Потерять в биллинге задачу проще, чем обосновать расход по большому потоку работ, особенно, если задачи поступают интенсивно. Могут некорректно учитываться рейты, и срочные задачи биллиться по обычному рейту, и наоборот. Имейте хорошую систему учета.

Организуйте систему шаблонов договоров в рамках всей компании. Каждый новый договор обязательно делайте из шаблона, а не из договора от предыдущего заказчика. Это позволяет избежать накопления ошибок и их тиражирования.

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

Когда документ готов — обязательно перечитайте его ещё раз. Всё в порядке?

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

Всё окей? Отправляйте документ заказчику.

Итак, мы согласовали с заказчиком все-все документы. Сделали все работы. Но это ещё не всё. Чтобы работы считались действительно выполненными, нам надо оформить реализацию. На самом деле, здесь всё просто, и достаточно знания самых основ бухгалтерского учета.

Обратите внимание, документы, о которых пойдет речь, по большей части — типовые. Более того, у государства есть к ним свои требования, и они довольно регулярно меняются. Поэтому настоятельно рекомендую не изобретать велосипед и оформлять всю реализацию в 1С или другой подобной системе, которая своевременно обновляется сама.

По сути — это предложение заказчику оплатить определенную сумму за определенные работы по соответствующему договору или приложению.

Он нужен только для того, чтобы бухгалтерия заказчика заплатила денег. И чтобы у вас в учетной системе, например в 1С, осталась запись, что вы попросили заказчика заплатить денег.

Вообще, счет не налагает на стороны никаких обязательств. Формально задолженность заказчика перед подрядчиком возникает в момент завершения работ и выставления акта. Если вы работает по предоплате, то после получения аванса от заказчика и до выставления акта формально вы должны ему.

Если вы работает по постоплате и выставляете акт одновременно со счетом на оплату, то задолженность возникает в момент выставления счета, но только потому, что вы при этом сразу выставили и акт.

Ещё раз: после того, как вы выставили счет, заказчик ещё вам ничего не должен (если, конечно, вы в договоре не прописали обратного).

Наверное, самый важный документ в документообороте. А важный он потому, что только если вы подписали акт, это значит, что работы вы выполнили, и деньги на самом деле заработали. Акт подтверждает факт выполнения работ и приемку работ заказчиком. Сделали работы — отправьте акт. Тут же. Не через неделю, а сразу, как провели демо.

Обратите внимание, что при поэтапной работе актом закрывается не весь договор, а конкретный этап. Так что к одному договору у вас может быть много актов.

В акте должно быть однозначно понятно, за что он. Указывайте договор, номер приложения, к которому относится акт. Или, например, номер и название спринта.

В отличие от счетов, акт не может быть на предоплату или постоплату. Акт составляется на весь объем работ по этапу. Если бухгалтерия заказчика просит сделать акт на предоплату, его можно оформить, но в таком случае в акт должна попасть именно часть конкретных работ на данную сумму.

Если вы выставляете акт на работы по приложению Time&Material, там, кроме всего прочего, надо отдельными строками расписать все работы. Если вы используете тикет-систему, то зачастую достаточно указывать номера выполненных задач.

Дело в том, что при техподдержке вы просто забираете задачи в работу, и если их не расписать в акте — будет непонятно, за что именно платил заказчик и выполнены ли реально эти работы. Особенно может быть весело через полгодика, по проекту с большим объемом мелких задач. Разобрать такую путаницу без корректно оформленных актов практически нереально.

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

Отправляем скан акта заказчику по электронной почте. Обратно получаем от него подписанный скан, также по электронной почте. После этого акт считается подписанным, только надо, чтобы такая возможность была предусмотрена в договоре. Оригиналы, естественно, отправляем курьером или почтой. Но ЭДО рулит.

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

К счастью, такое случается крайне редко. Бухгалтерии заказчика акт нужен не меньше, чем вам. Без него невозможно списать оплату на расходы и, соответственно, уменьшить налоги.

Если всё плохо, и надо подписать акт в одностороннем порядке, действуем следующим образом:

Отправляем скан заказчику. Печатаем три оригинала. Два из них отправляем заказчику заказным письмом с описью и уведомлением. Подшиваем опись с отметкой почты к оставшемуся акту. Ждем срок, который есть у заказчика на согласование акта по договору. Убеждаемся, что замечаний к работам и подписанный акт заказчик не прислал. Визируем акт «Подписан в одностороннем порядке».

Как всё-таки сделать, чтобы заказчики подписывали акты и возвращали вам?

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

Во-вторых, если не уверены — не начинайте следующий этап, пока нет подписанного заказчиком акта. Договором это должно быть предусмотрено. Пока акт не подписан, заказчик может прислать правки по этапу. Если торопитесь, пусть даже из лучших побуждений, то можете поймать пачку комментариев к дизайну на середине верстки.

Вы либо работаете в том ритме, в каком идет документооборот, либо работаете по Time&Material, либо берете на себя риски, работая на опережение. Разумны ли эти риски — зависит от заказчика и от того, есть ли у вашей команды альтернативные проекты, готовые к старту прямо сейчас.

В-третьих, подписывайте документы по сканам или ЭДО. Зафиксируйте возможность в договоре. К счастью, большинство компаний научились это делать. Берегите деревья.

Оригиналы мы отправляем почтой или курьером. Периодически проверяем, вернулись ли они нам. Тормошим заказчика, если оригиналов что-то долго нет. Для этого у нас есть специальный реестр. Часто по оригиналам эффективнее запрашивать бухгалтерию заказчика, чем менеджера на его стороне.

Хорошо, если эту работу менеджер проекта может кому-то делегировать. Всё же мы digital-проекты делаем, управляем требованиями, дизайнерами, программистами, а не в коллекторском агентстве долги по документам выбиваем. Но если делегировать это не на кого, получение всех необходимых документов — головная боль руководителя проектов.

Отражает все работы, закрытые актами, и все оплаты от заказчика за определенный период. Период выбираете вы сами, какой вам нужен. Можно оформлять как по отдельному договору, так и по всем договорам заказчика разом.

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

Обратите внимание, что предоплата за этап вносится в акт сверки как аванс. Это значит, что она считается задолженностью подрядчика перед заказчиком. Если вы считаете, что ничего не должны заказчику, а акт сверки показывает обратное – ищите, какой акт вы забыли выставить или провести.

Акт сверки также подписывается сторонами. Важно: подписание акта сверки значит, что вы согласны с тем, что там написано. Перед тем, как подписывать акт сверки, полученный от контрагента, стоит сформировать свой такой же и убедиться, что, во-первых, данные сходятся, а во-вторых, что они сходятся с вашим представлением о реальности. Если в акте сверки заказчика указано, что вы ему должны, а в вашем всё по нулям, скорее всего, у него не хватает оригиналов актов. Разбирайтесь, каких именно, и отправляйте ему.

У нас остался один документ, который является неотъемлемой частью оформления реализации, но который большинство IT-компаний практически не используют.

Счет-фактура. Выставляется, если компания является плательщиком НДС. Она очень нужна заказчику, чтобы он мог предъявить НДС к возмещению в налоговую.

Если подрядчик платит НДС, то по каждой полученной предоплате от заказчика он обязан выписать счет-фактуру на полученный аванс. А потом еще фактуру на постоплату, если она была.

Вообще, в сфере заказной разработки программного обеспечения счета-фактуры используются крайне редко, так как компании применяют специальные режимы налогообложения. Упрощенную или патентную систему.

Причина простая. Платить НДС выгодно только в том случае, когда у вас много расходов, по которым ваши поставщики также платят НДС. Тогда вы можете уменьшить свой НДС на НДС, уплаченный поставщикам, и не так уж много в итоге отдать государству.

У IT-компаний основная статья расходов — заработная плата, по которой, естественно, НДС не платится. Так что единственный способ платить НДС в этом случае — это увеличивать на него стоимость своих услуг. Понятно, что продать работы на 20% дешевле и объяснить заказчику, почему НДС нет, проще, чем продать их же, докинув НДС сверху.

Акт финальных доработок — это не тот акт, что в 1С и для бухгалтерии, а, скорее, вариант дополнительного соглашения с заказчиком. Возможность его применения вам надо предварительно зафиксировать в договоре.

Такой акт финализирует список правок по этапу от заказчика. Вы запрашиваете от заказчика полный список правок, которые он хочет внести по этапу, чтобы его принять. По факту выполнения данных доработок этап считается принятым заказчиком автоматически.

Важно, чтобы формулировки в акте финальных доработок были максимально конкретными и однозначными.

Итак. У нас есть пачка бюрократии, через которую приходится продираться:

1. Рамочный договор с общими условиями.

2. Приложение на каждый этап работ, если работаем по фиксированной цене.

3. Или приложение о работе по Time&Material.

4. Акты сдачи-приемки. Каждое приложение обязательно закрываем актом, выставляя акт сразу, как только показали результат клиенту.

5. Счета. Либо на весь этап. Либо на предоплату-постоплату.

6. На случай чего — акт финальных доработок.

Бережем деревья, используем ЭДО. Всё просто!

Другие главы книги, которые мы ранее публиковали:

• Картина мира digital-проекта
• Прогулка по картине мира
• Делегирование. Основы
• Фальшивые автобусные остановки. Контрольные точки. Рисерч
• Правила письменной контрацепции. Как ставить задачи и не поубивать друг друга
• Стратегии заказной и продуктовой разработки.