Какой должна быть процедура приёма работ у подрядчика.




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

ОРИГИНАЛЬНЫЙ ТЕКСТ НАХОДИТСЯ ЗДЕСЬ.



На протяжении лет методики, используемые в ИТ-отраслях, постепенно менялись. Классические каскадные решения (waterfall) теряют популярность, уступая дорогу гибким решениям (agile). Последние более понятны интуитивно, динамичны и – как показывает практика – лучше подстраиваются под требования рынка.


Что лучше – Agile или Водопад?



Каждый подход имеет свои преимущества.


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

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


Принимать целиком или по частям?



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

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

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



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

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

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


В чём заключается процедура приёмки?



    Для успешного сотрудничества сторон необходимо определить срок, в течение которого заказчик должен представить поправки к проекту. Срок должен быть чётко обозначен, например, 14 или 30 дней с момента того, как работы объявлены законченными. Заодно такой способ мотивирует исполнителя выполнять работу должным образом, поскольку отсутствие обратной связи вызывает иллюзию, что всё ОК, что, в свою очередь, затрудняет принятие замечаний. Отсутствие такого срока может привести к тому, что люди будут неоднократно возвращаться к одному и тому же вопросу.

    Кто может вносить такие поправки? Было бы хорошо, чтобы процедура приёма работ не лежала непосредственно на топ-менеджерах. Хотя этот подход может казаться логичным, в реальности он значительно затрудняет сотрудничество и неоправданно затягивает процесс, поскольку у начальства обычно нет времени (а также часто и компетенции), чтобы вникать во все подробности. Для этого в договоре стоит указать, чтобы в приёмке принимало участие (простите за каламбур) лицо, уполномоченное руководством, как правило, кто-то из линейных руководителей.


Позаботься о протоколе.



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

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

Комментарий блоггера. Честно говоря, я неясно представляю, о чём идёт речь. Самому с собой подписать акт выполненных работ? В тех договорах, которые я составлял, была формулировка «подписать либо в письменном виде предоставить мотивированный отказ от подписания».

Нейросеть подсказала: в европейском законодательстве, если заказчик уклоняется от приёмки работ, договор может предусматривать право подрядчика подписать акт в одностороннем порядке — после истечения срока и повторного письменного уведомления. Такой акт фиксирует факт сдачи работ и даёт основание требовать оплату, однако не освобождает подрядчика от гарантийных обязательств и ответственности за качество. Конец комментария.

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


А как насчёт авторских прав?


Как правило, с точки зрения авторских прав ИТ-проект попадает под защиту как произведение. Это означает, что для возможности им пользоваться заказчику надо передать авторские права – либо посредством соответствующего соглашения, либо путем предоставления лицензии.


Как определить показатель того, что работа выполнена?



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

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

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

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

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


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

ЧТОБЫ БЫТЬ В КУРСЕ ПОСЛЕДНИХ НОВОСТЕЙ, ПОДПИСЫВАЙТЕСЬ НА Telegram-канал «КАРЬЕРА МЕНЕДЖЕРА И Информационные Технологии».

ВЕРНУТЬСЯ К ГЛАВНОМУ МЕНЮ