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

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

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

"Кто будет принимать результат?" Крайне важный вопрос, ответ на который обеспечит ответы на кучу других, связанных с приемкой: "Как...?", "Когда...?", "Где...?" и так далее.

Несмотря на кажущуюся простоту, в ответе на этот вопрос есть несколько подводных камней.

1️⃣ Принимать должен тот, у кого мотивация не в том, чтобы принять, а в том, чтобы работало далее. Если за приемку будет отвечать человек, для которого это будет просто галочка, он может сделать это спустя рукава. А далее могут возникнуть претензии к Исполнителю на этапе внедрения и эксплуатации.

2️⃣ В приемке со стороны Заказчика должен быть человек с компетенциями в ИТ. Кто-то должен квалифицированно оценить результат не только в части выполнения бизнес-функций, но и полноты технической документации, полноты исходников, исполняемых файлов, безопасности инфраструктуры. И если такого человека в штате заказчика нет, мы рекомендуем его на время приемки нанять в формате консалтинга. Так будет спокойнее Заказчику так как ответственный за приемку никогда не сможет снять с себя ответственность фразой "Я же ничего в ИТ не понимаю!"

3️⃣ Процедура приемки должна быть согласована и готовиться заблаговременно. В ГОСТ (я опять о стандартах, да) существует такая сущность как "Программа и методика испытаний". В этом документе по установленному содержанию подробнейшим образом прописываются все, что касается приемки. И Заказчик, и Исполнитель принимаю этот документ как руководящий для процедур приемки. ГОСТа не обязательно придерживаться (он все-таки носит рекомендательный характер), но какой-то определяющий процедуру приемки документ лучше всего совместно составить.

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

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