Проблемы с заказчиком ИТ-проекта: как урегулировать ситуацию?

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

Что написано пером, не вырубишь топором

Очень часто неприятности доставляют сторонние вендоры, с решениями которых нужно провести интеграцию, начинает обсуждение Вениамин МУСТАФИН, директор по развитию компании fuse8. Распространенная ситуация – вендор не предоставляет вовремя информацию, которая необходима разработчику. И даже наличие договора не спасает от таких историй. Несмотря на то, что в договоре с вендором прописываются, конечно же, такие моменты, как сроки выполнения работ всеми сторонами, реальность, как это часто бывает, оказывается совершенно иной. И эффективных методов воздействия на такого участника проекта, как правило, практически нет.

Вениамин МУСТАФИН (fuse8)«В качестве примера могу привести один из наших последних проектов. Мы не можем запустить его уже два месяца, но представители вендора не предоставляют протоколы, по которым нужно интегрироваться, и даже не отвечают на наши сообщения. Из-за этого страдают и наша компания как исполнитель, и клиент как заинтересованное лицо. Ситуация дошла до того, что мы решили сменить вендора на более адекватного. Его решение, может быть, и не на все 100% подходит под бизнес-задачу клиента, но в качестве временного варианта, который позволит нам вовремя запустить проект, вполне отвечает требованиям».

Договор, и в особенности техническое задание, очень важны для выстраивания отношений с заказчиком. От качества написания технического задания (ТЗ) – проработанности и детальности – зависит конечный результат, – развивает тему Евгений НУРГАЛИЕВ, директор департамента предоставления ИТ- и ИБ-услуг компании Simplity. После прочтения этого документа у заказчика должно сформироваться четкое представление о том, что он получит на выходе проекта, а у исполнителя ТЗ – не менее четко обозначиться круг работ, которые ему предстоит выполнить. В этом случае большинство конфликтов и недопонимания между заказчиком и исполнителем исключаются. Но есть ситуации, повлиять на которые даже на стадии составления договора исполнитель практически не может. Как правило, они касаются ИТ-проектов, реализуемых компаниями с госучастием, полностью государственными компаниями и компаниями, попавшими под санкции, которые должны следовать букве регламентирующих этот процесс документов: ФЗ №223(«О закупках товаров, работ, услуг отдельными видами юридических лиц») и ФЗ №44 («О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд»).

Евгений НУРГАЛИЕВ (Simplity)«Когда речь идет о проектах в рамках госзакупок, заказчик зачастую делает ТЗ максимально обтекаемым. В таких кейсах исполнителю очень затруднительно получить полную информацию о проекте и его сложности до проведения конкурса. Исполнитель реализует проект точно с теми параметрами, которые перечислены госзаказчиком в ТЗ. Но исход такого проекта не всегда результативен. Иными словами, даже максимально точное выполнение всех требований совершенно не означает, что заказчик примет проект и он будет подходить для решения его задач. Более того, в этом случае исполнителю грозят всяческие санкции в виде занесения в реестр недобросовестных компаний и т. п., хотя он не виноват».

«Если мы можем предложить заказчику свой вариант договора, над которым поработали наши юристы, это замечательно, – поддерживает обсуждение Дмитрий РОССИХИН, директор RDN Group. – Но существуют тендеры, где договоры предусмотрены заранее и в строго определенной форме. И если интегратор хочет поучаствовать в таком тендере, ему придется вынужденно соглашаться на договор заказчика, с жесткими условиями. В этом случае при взаимодействии с заказчиком приходится использовать и другие инструменты». «Договор – это одно, а реальность – совсем другое». Такие рассуждения приходится слышать очень часто, – комментирует ситуацию Татьяна КАРХАЛЕВА, адвокат, партнер, управляющий IP- и ИТ-практикой адвокатского бюро RBL. – Это очень распространенная проблема. Избежать ее можно только одним путем: составить договор таким образом, чтобы он отражал именно те конкретные работы, которые берется делать исполнитель, и чтобы работать по договору было удобно всем. Именно поэтому юристов целесообразно подключать к работе над ИТ-проектом с самого начала, еще на этапе составления договора. При этом договор и все сопровождающие его документы должны быть написаны просто и понятно для всех сторон. Поэтому, если в договоре вы встретите что-то непонятное вам, знайте, что это не просто сложная формулировка, это неправильно составленный договор». Стейкхолдеры, ЛПР, etc.: кого нужно знать в лицо? ИТ-проект или его часть подрядчиком уже выполнены, работу можно сдавать. Но не так всё просто. Практически все ИТ-интеграторы, особенно в проектах с крупными заказчиками, знакомы с ситуациями, когда результаты проекта оценивает и работу принимает не сам заказчик, а внезапно возникающий так называемый «теневой» стейкхолдер. И очень осложняется дело, когда практически под самый запуск продукта стейкхолдер настаивает на реализации каких-то своих идей и внесении нужных именно ему изменений. Как правило, стейкхолдер не был вовлечен в проект изначально, не понимает, как принимались решения в рамках проекта, не разбирается во многих других важных моментах. «Обычно в самом начале проекта мы составляем таблицу всех возможных стейкхолдеров на стороне компании-заказчика, знакомимся со всеми, кто принимает конечное решение, фиксируем их требования, интерактивно демонстрируем им промежуточные результаты, – делится опытом Вениамин МУСТАФИН (fuse8). Такая схема снимает возможный риск очень долгой сдачи проекта, и в 90% случаев клиенты соглашаются на нее. Второй и вполне реальный риск, влияющий на процесс принятия ИТ-проекта – смена руководства в структурах заказчика. И такое периодически происходит как в коммерческих организациях, так и в госкомпаниях и государственных структурах. Зачастую решения об интеграции принимаются одним из «лиц принимающих решение» (ЛПР). Но после смены руководства новое ЛПР пытается показать свою значимость: начинает проводить аудит ИТ-проектов, выполненных предыдущей командой, итогами которого, как правило, остается недовольно. В адрес интегратора отправляются угрозы признать продукт несоответствующим ТЗ, отказаться от оплаты работ или провести оплату по фактическим затратам и даже подать в суд. «В таких случаях от всяческих неприятностей интегратора способны защитить только договор с максимально детализированным ТЗ, а также участие проект-менеджера, который получал акты по промежуточным этапам работ, максимально подробно фиксировал их, вел официальную переписку с заказчиком и т. д.», – уверен Евгений НУРГАЛИЕВ (Simplity). ТЗ: дьявол в деталях Спикеры круглого стола уже не раз поднимали тему о том, что именно техническое задание является важнейшей частью договора и именно от его правильного составления и тщательной проработки во многом зависит успех проекта. Правда, уверены эксперты, учесть в ТЗ все возможные изменения, которые захочется сделать заказчику, нереально. А они могут быть как совсем простыми, так и серьезными, требующими значительных дополнительных трудовых, временных и финансовых затрат. Как быть в этой ситуации? Каждая ИТ-компания предлагает свой, годами испытанный на прочность и правильность лайфхак. Какие-то решения можно принимать с клиентом по ходу разработки, говорит Вениамин МУСТАФИН (fuse8). Но кардинальные изменения в требованиях ТЗ с клиентом проговариваются отдельно: оформляются как change request, заносятся в дополнительный договор. В такой ситуации клиент ясно понимает, за какие изменения он платит. Естественно, такие ситуации требуют системной работы на проекте сильного аккаунт-менеджера – ведь клиент может и не согласиться с изменениями.

Вениамин МУСТАФИН (fuse8)«В ходе реализации проекта клиент нередко хочет что-нибудь добавить, улучшить и, конечно же, получить всё это в рамках обозначенного в договоре бюджета. Отследить все эти моменты, остановить такие попытки способен сильный руководитель проекта, который очень хорошо знаком и с договором, и с ТЗ. Все идеи такого рода, которые мы получаем от заказчиков в ходе проекта, собираем в бэклог, благодаря чему можем предложить клиенту какие-то важные для него дополнительные работы, естественно, за дополнительный бюджет».

Дмитрий РОССИХИН (RDN Group)«На сложных проектах наша компания всегда назначает администратора. В его обязанности входит фиксация всех договоренностей с заказчиком, периодическое протоколирование статусов проекта, проведение совещаний, и не только с функциональным заказчиком, но и с бизнесом. Часто бизнес хочет того, что функциональный заказчик не предусмотрел в ТЗ. И здесь именно тотальное протоколирование способно спасти ситуацию».

«Наш лайфхак, так называемый административный ресурс, – хорошее отношение с акционерами или с принимающими решения лицами высокого статуса, заинтересованными в проекте, – делится опытом Евгений НУРГАЛИЕВ (Simplity). – Но если в процессе составления ТЗ начинают появляться функциональные требования, которые в корне меняют весь проект, причем требования эти меняются в течение недели, месяца, это явно говорит о том, что клиент не знает, чего он хочет. Скорее всего, планируемое ИТ-решение заказчику не нужно, а необходимость его внедрения вызвана какими-то внешними факторами. И факторы эти могут быть самыми разными. К примеру, одному из руководителей понравилась CRM-система, внедренная в знакомой ему компании, и он захотел такую же у себя. Но, так как бизнес-процессы в его компании были другими, CRM-система у него работать не смогла. Партнер, который ее внедрял, выполнил всё строго по ТЗ, и претензий к нему, как выявил проведенный нами аудит, быть не может. Все претензии нужно адресовать функциональным подразделениям заказчика, которые не смогли сформировать свои бизнес-требования. Обычно такие ситуации заканчиваются тем, что после внедрения решения заказчик, потративший достаточно большие деньги, отправляет его в долгий ящик». Фактически любой серьезный проект в процессе его реализации сопровождается появлением со стороны заказчика новых требований: перед ним открываются какие-то новые горизонты, хочется реализовать что-то дополнительное. Например, на этапе сдачи работ он может сформировать большое количество замечаний. Чаще всего ситуации возникают спонтанно: пока проект реализовывался, заказчик захотел каких-то доработок, новых технологий. В договоре, естественно, учесть всего невозможно, как бы тщательно он ни был продуман, прокомментировал Евгений ОСЬМИНИН, директор по развитию цифровой трансформации компании «РДТЕХ». Но у исполнителя, естественно, это неизбежно вызывает стресс, поскольку такие изменения ведут к увеличению себестоимости, объемов и т. д. «Случаи, когда заказчик сознательно выбирает такую стратегию, всеми силами затягивая сроки подписания, возникают куда реже, – поясняет он. – В рамках фиксированного объема работ заказчик хочет, условно говоря, реализовать проект развития. В принципе такие поползновения можно купировать еще на ранней стадии, на этапе согласования условий договора, поэтому мы установили соответствующие фильтры, проводим аналитику в процессе формирования ТЗ. Ну и на этапе согласования требований необходимо максимально тщательно, насколько возможно, фиксировать условия договора».

Евгений ОСЬМИНИН («РДТЕХ»)«Формируя основной договор, стремимся с максимальной точностью прогнозировать возможные потребности заказчика в рамках развития его системы, и фиксируем потенциальный круг работ в качестве дополнительных в рамках проектов развития или с выходом на отдельный договор. Таким образом, мы упреждаем возникающий у заказчика соблазн включить в основной договор дополнительные работы. Помимо того что такой подход снижает обозначенные риски, он еще и очень позитивно сказывается на лояльности заказчиков и формировании будущих проектов развития».

«Проблемы с другими подрядчиками интеграционных проектов – очень распространенная ситуация, – говорит Дмитрий РОССИХИН (RDN Group). – Например, они могут отставать от графика выполнения работ по внедрению своей системы, интеграцию с которой мы должны провести. И в этом случае помочь заказчику, пойти ему навстречу – еще один важный шаг к созданию лояльных отношений».

Дмитрий РОССИХИН (RDN Group)«Мы должны были внедрить у заказчика CRM-систему, а подрядчик ERP-системы, интеграция с которой была предусмотрена договором, отставал по срокам внедрения. И, поскольку наша компания имела с этим заказчиком очень хорошие отношения и была заинтересована в скорейшем запуске проекта, наша команда начала заранее прописывать со стороны CRM-системы все интеграции, чтобы к моменту реализации ERP-системы генеральным подрядчиком уже было готово частное техническое задание (ЧТЗ), и мы совместными усилиями могли бы, не откладывая, приступить к его реализации».

Но сделать так удается не всегда. И если заказчик не принимает работы, однозначного ответа на вопрос «что делать?» не существует. Ответ, полагает спикер, может заключаться в выстраивании со стороны компании-исполнителя системной работы с заказчиком, системы регулярного менеджмента, которая включает в себя договоры с тщательно проработанными рисками, умение вести конструктивные переговоры с заказчиком–договариваться, идти на компромиссы и т. д. Совместная команда как залог успеха Пожалуй, самым целесообразным шагом является выстраивание партнерских отношений с заказчиком, включение его в свою команду, уверена Елена БАЙРАМОВА, заместитель руководителя по работе с ключевыми клиентами компании Simpl. Пока заказчик и интегратор находятся, условно говоря, по разные стороны баррикад, они никогда не смогут прийти к единой цели. Заказчик будет искать какие-то уловки, а интегратор – способы от них избавиться. Поэтому очень важно на самых первых этапах договориться с заказчиком о единой цели, о распределении ролей в общей команде. Вместе с заказчиком нужно провести риск-сессию, прописать в каком-то формате все риски, которые могут быть связаны и со сменой ЛПР, и с интеграцией с другими вендорами, а также с не всегда четко прописанными в ТЗ требованиями, и провести мероприятия по митигации всех выявленных рисков.

Елена БАЙРАМОВА (Simpl)«Чтобы избавиться от рисков изменения требований, мы применяем итеративный подход в разработке: даем работу заказчику по частям, по этапам, проводим для него демо-дни. Для того чтобы “выровняться” с другими системами в рамках интеграции, формируем совместно с заказчиком нашу дорожную карту и, сверяясь с дорожными картами реализации других систем, проводим ее корректировку».

Проекты, реализуемые единой, так называемой гибридной командой заказчика и интегратора, всегда более эффективны, поддержал тему Дмитрий РОССИХИН (RDN Group). К тому же, считает он, нельзя забывать, что за любой проблемой всегда стоит человек. И прежде, чем применять какие-то юридические методы воздействия, нужно попытаться понять интересы этого человека и как их закрыть взаимовыгодно или с минимальными потерями для какой-то из сторон. С юридической стороны все документы должны быть составлены предельно грамотно. И всё это не исключает параллельно проводимой системной работы с заказчиком. Всегда получается некая многослойная конструкция, включающая все эти составляющие. И чем больше проект, тем сложнее получается такая система, резюмировал спикер. Регуляторы и санкции как отражение новой реальности Крупные ИТ-проекты могут длиться годами. Как отражается на их работе деятельность Минцифры РФ и прочих регуляторов ИТ-рынка, и какую роль играют изменения в своде отечественного законодательства? Поднимает новую проблему Андрей ВИНОГРАДОВ, главный редактор “IT Expert”, модерирующий круглый стол. Ведь, условно говоря, приходится начать ИТ-проект в одном мире, продолжить в другом и завершить в третьем. Насколько успешно удалось избежать проблем, связанных с трансформациями самого рынка ИТ-услуг после ухода западных вендоров? И не грозит ли рынку засилье серых схем, которыми, по некоторым данным, пользуются порядка 80-85% разработчиков? Действия регуляторов вполне могут скорректировать какие-то параметры проекта, особенно если он долгосрочный, продолжает дискуссию Евгений ОСЬМИНИН («РДТЕХ»). Например, сначала случилась история с пандемией COVID-19, затем пошел процесс импортозамещения, санкционное давление, и на этом фоне был запущен проект цифровой трансформации. Регуляторные изменения целесообразно рассматривать как некий частный случай проявления новой реальности, в которой нужно учиться жить и заказчикам, и интеграторам. Как правило, с теми заказчиками, которые попадают под регуляторные механизмы, можно еще на старте проекта договориться о каких-то параметрах, учесть законодательные изменения, фиксировать их. Заказчик должен понимать, что он с исполнителем плывет в одной лодке и работает на достижение одной цели. И если внешние обстоятельства изменились, сторонам нужно договариваться. Каждый случай индивидуален, уверена Татьяна КАРХАЛЕВА (RBL).

Татьяна КАРХАЛЕВА (RBL)«Список форс-мажорных обстоятельств, которые указываются в договорах, начал расширяться с пандемийных событий. Именно тогда и юристы, и ЛПРы начали внимательно изучать этот раздел договора, в который обычно заглядывали мимоходом. Все стали еще более точными и внимательными в этой части после февральских событий 2022 года».

На фоне февральских событий, за которыми последовало прекращение поддержки продуктов со стороны западных вендоров, на рынке сложилась нервная, даже паническая ситуация. Стала абсолютно непонятной экономика услуг, вспоминает Евгений ОСЬМИНИН («РДТЕХ»): «На рынке действительно появился ряд компаний, которые хотели воспользоваться ситуацией, не оценивая свои возможности, войти в рынок, за счет агрессивного демпинга. Уход вендора не только нарушил систему ценообразования, но и фактически разрушил систему сертификации специалистов. К примеру, несмотря на то, что у нас в компании один из лучших в России центров поддержки Oracle, с достаточно серьезными компетенциями, позволяющими решить большинство проблем заказчиков, в первые «санкционные» месяцы мы видели определенные риски, что потребовало некоторого время для их оценки. Тем не менее, ЛПРы некоторых компаний решили также со своей стороны воспользоваться ситуацией и сэкономить запланированный бюджет, заключив договора с новыми компаниями, предлагающими услуги поддержки по очень привлекательным ценам. Однако через некоторое время рынок расставил все по своим местам. С проблемами столкнулись и заказчики, и исполнители, многих из которых уже не существует. Хотя, справедливости ради, стоит отметить, что для нескольких новых компаний подобная ситуация, хотя и стала не самым удачным опытом, позволила выйти на рынок». Затронутая модератором круглого стола тема серых схем оказалась актуальна. «Они используются только для того, чтобы, образно выражаясь, поддержать штаны, не остановить деятельность своей организации, – высказывает мнение Евгений НУРГАЛИЕВ (Simplity). Но все участники рынка отчетливо понимают связанные с этим риски. Например, поддержка таких схем обесценивает гарантию компании-производителя на закрытие хотя бы базовых уязвимостей ИБ, угрозы в отношении которой многократно усилились после февральских событий. Если раньше ИБ считалась падчерицей ИТ-службы, то теперь практически все крупные компании постоянно находятся под атаками хакеров – как мелких вредителей, так и профи, и в любом случае идут параллельные процессы по переходу на отечественное ПО. Да, тяжелые, со скрипом, но идут». «Всех занимает вопрос – вернутся ли на российский рынок западные вендоры?» – подливает масла в огонь дискуссии Евгений ОСЬМИНИН («РДТЕХ»). По его прогнозам, произойдет это, при условии сохранения текущей конъюнктуры рынка, во втором-третьем квартале 2025 года. А значит, у отечественных ИТ-компаний есть еще примерно год, чтобы выстроить ландшафт нового рынка, сделать его конкурентоспособным. Таким образом, возвратившиеся блудные сыны будут вынуждены искать место на уже сформировавшемся рынке.