Управление правовыми рисками проекта

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

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

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

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

Сейчас мой опыт внедрения уже три года. Я внедряю, в том числе, ERP-системы, и постоянно обучаюсь. У нас в ИнфоСофт есть корпоративный университет, где обучают линейных руководителей – затачивают именно под то, как правильно управлять проектами и людьми для нашей компании.

Мы сегодня поговорим:

• О причинах возникновения правовых рисков на проектах – почему они появляются, и почему мы их пропускаем.

• О том, как этими правовыми рисками управлять.

• В каких бизнес-процессах возникают правовые риски.

• И какие документы являются необходимыми (и достаточными) для управления правовыми рисками.

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

Конечно, если развить у себя эти навыки, контролировать правовые риски на проекте станет гораздо проще – вы будете просто их видеть. Но в большинстве организаций ситуация выглядит так:

• Юристы не понимают, что происходит на проектах. Даже если юрист работает в проектной сфере, он обычно подключается только на этапе согласования договора с контрагентом, и сразу после этого его работа заканчивается – он возвращается к своей операционной работе, переключается на другие задачи и забывает о проекте. Очень редко юрист после заключения договора приходит и спрашивает: «Ребята, как у вас дела, все ли в порядке?» Если у вас есть такой юрист, переучивайте его в РП-шника – это реально работает.

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

• Еще одна проблема – это «сложности перевода». Руководитель проекта постоянно находится в коммуникации. С одной стороны, ему нужно работать с командой, которая говорит на своем ИТ-шном птичьем языке, и если он технарь, то он их понимает. И одновременно ему нужно «переводить» этот язык контрагенту – например, бизнес-подразделениям заказчика, если мы говорим про заказную разработку, где РП-шнику нужно участвовать в переговорах с сотрудниками служб заказчика или его юристами. Это очень сложно, особенно сейчас, когда на ИТ-компании ложится дополнительная ответственность – например, чтобы пользоваться ИТ-льготами, нужно указывать в договоре с заказчиком определенные формулировки: «адаптация», «модификация», «разработка». Большинство программистов не отличают «адаптацию» от «модификации» – им это вообще не нужно знать. А руководителю проекта знать нужно, потому что руководство сверху заставляет его соблюдать требования по льготируемой выручке, и ему нужно объяснить это контрагенту.

• Как результат, возникает ситуация, когда юристы «не смогли» и РП «не смог» – лошадка проекта «сдохла» где-то на этапе идентификации правовых рисков.

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

На картинке изображено «Колесо обозрения на Набережной» в Новосибирске, но в контексте нашего разговора это колесо будет иллюстрировать цикл управления правовыми рисками.

Этот цикл описан в PMBOK – он состоит из пяти этапов, перечисленных на слайде, и осуществляется непрерывно.

Но, как правило, руководитель проекта пропускает первые два этапа – идентификацию и управление правовыми рисками.

И только на третьем этапе – когда уже что-то произошло – привлекается юрист. Но в этот момент проект уже «заваливается на одно крыло». Конечно, юрист вам поможет, но хотелось бы, чтобы этого не происходило.

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

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

Почему-то многие думают: «Если возникнут проблемы, мы пойдем в суд». Но при этом не учитывают, что правовое регулирование ИТ-деятельности появилось сравнительно недавно – буквально лет десять назад. И судья – она прежде всего юрист, а потом уже судья. Она ничего не понимает в разработке.

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

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

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

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

Когда нужна идентификация рисков

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

• Если речь идет о заказной разработке, то я считаю, что оценивать контрагента нужно еще до заключения договора – на этапе пресейла. Приведу пример из практики. Мы приходим на пресейл, нам продажники передают клиента: компания из списка РБК-500 хочет внедрить тиражное решение и тиражировать его на все свои филиалы. Однако в ходе пресейла выясняется, что заказчик-то из РБК-500, а договор мы будем заключать с малоизвестной организацией, никак с этим заказчиком не связанной. А если учесть, что работы нужно сдавать этому крупному заказчику, вполне вероятно, что проект в таких условиях мы не сдадим никогда, и денег, возможно, тоже не получим. Причем там еще и деньги планировалось заплатить только в самом конце, после завершения всех работ. Наверное, в современном мире такой проект был бы крайне некомфортным для ИТ-интегратора.

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

• Третий вариант идентификации рисков – в процессе реализации самого проекта. Вроде мы обо всем договорились, заключили договор и пошли реализовывать проект. Здесь тоже могут возникнуть самые неожиданные риски. У нас был случай, когда директор компании, он же спонсор проекта, просто пропал – перестал отвечать на звонки и письма. Руководитель проекта начал бомбить по всем другим заинтересованным сторонам, и получил ответ, что человек в отпуске, а когда вернется – неизвестно. Вопрос: что делать? Право первой подписи – у директора, доверенности ни на кого другого нет. Мы нашли выход из ситуации – использовали ЭЦП, но понимали, что могут возникнуть вопросы. Причем через полгода человек вернулся, но мы так и не узнали, где он был, хотя у нас были определенные догадки. Учитывайте, что такие ситуации случаются, и задача руководителя проекта здесь – придумать, что делать. Потому что с правовой точки зрения классического выхода здесь нет: если доверенность не выдана, а человек ушел, юридически проект останавливается.

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

Как управлять риском: без чего нельзя обойтись

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

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

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

• Крайне важно указывать в договоре сроки согласования проектной документации или другие детали из порядка взаимодействия сторон. Конечно, переносить в тело договора весь устав – не всегда оправдано. Но можно прописать, что проектная документация от 10 листов согласовывается 2 дня. 20 листов – 3 дня и так далее. Тогда у вас уже будет поле для проведения переговоров и взаимодействия с клиентом.

• Еще одна важная правовая конструкция – встречное исполнение. Мы привыкли, что исполнитель в проекте должен делать, а заказчик принимать результат. Но на самом деле договор двусторонний, и у каждой стороны есть свои права и обязанности. Например, заказчик должен: подписывать проектные документы; предоставлять информацию; ходить на встречи и делать все, что вам нужно для ведения проектной деятельности. Это называется встречным исполнением. Поэтому, если проект переходит в правовую плоскость, и нам по нему приходится отстаивать свои права, то, в соответствии с гражданским законодательством, если заказчик не предоставляет встречное исполнение, это является грубым нарушением договора подряда и основанием для его расторжения. Поэтому, прописав в договоре сроки согласования проектной документации, вы кладете в договор жирный козырь. Это действительно хорошо работает – не только юридически, но и психологически. Когда вы в переговорах напоминаете заказчику: «По договору вы должны были подписать эти документы еще две недели назад» – он обычно начинает относиться к этому вопросу серьезнее.

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

Отдельно хочу сказать про устав проекта и описание в нем порядка взаимодействия сторон. У меня нет конкретной рекомендации, нужно ли закреплять эту информацию как приложение к договору, но мы в ИнфоСофт закрепляем. Мы провели огромную методологическую работу и разработали порядок взаимодействия сторон, который по нашему мнению покрывает все возможные ситуации на любом из этапов проекта. При этом за все время проекта (допустим, год-два для крупных корпоративных проектов) мы этот порядок взаимодействия не меняем – один раз согласовали его с конкретным заказчиком и по нему живем.

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

Несколько слов про переписку.

• ИТ-шники любят использовать для всех переписок Telegram, но для договоренностей с заказчиком это, как оказывается, не всегда оправданно. Пару лет назад Верховный суд признал Telegram недостаточно достоверным источником для того, чтобы переписка по нему признавалась доказательством в суде. Во-первых, потому что в переписке Telegram вы можете удалить сообщения не только свои, но и адресата – частично или полностью. Из-за этой технической возможности достоверность даже скрина с телефона ставится судом под вопрос. Во-вторых, ваш адресат может скрыть свой номер, и там будет какая-нибудь «СчастливаяКиска28» без фотографии и других опознавательных признаков – вы никогда не докажете, что это главный бухгалтер. Даже если фотография будет, суд вообще не обязан идентифицировать кого-то по лицу, тем более, что много случаев, когда вы переписываетесь с человеком, а потом оказывается, что у него фотография 15-летней давности. В целом вы можете использовать Telegram для общения по проекту, но я не рекомендую рассчитывать на то, что эти договоренности потом смогут вернуть человека в ту позицию, в которой он должен быть.

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

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

• Небольшой совет: указывайте в теле письма наименования вложений – так, чтобы они совпадали с реальными названиями прикрепленных документов. Потому что судебное заседание длится 15 минут и за это время вы в лучшем случае успеете предоставить бумаги. Суд не будет заходить в почтовый ящик и смотреть, что там во вложениях. Пользуйтесь встроенной функцией Windows – вызывайте в контекстном меню файла кнопку «Отправить», тогда вложения сами прописываются в письмо. Дополняете текст, и будет вам счастье.

• Если основные решения по проекту у вас принимаются в ходе онлайн-совещаний, учтите, что видеозаписи не принимаются судом – как раз-таки потому, что суды очень загружены. Конечно, протащить можно, но это очень трудозатратно. Эти видеозаписи вы делаете для себя. Поэтому я фанат того, чтобы после встречи с клиентом тезисно закреплять, о чем вы договорились. Здесь вам видеозапись поможет, потому что вы всегда можете вернуться, если что-то упустили. Но надеяться на то, что вы записали кого-то на видео, а потом покажете это судье, не стоит. Суд длится 15 минут, и суды перегружены. Тем более, если мы говорим про центральные регионы – Москва, Московская область – там вообще сейчас стараются очно судебные заседания не проводить, поэтому видео вам в суде не поможет.

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

Сдача работ

Следующий риск, с которым мы можем столкнуться на проекте – это проблема сдачи работ.

Самая страшная картинка для руководителя проекта или аналитика, который сдает задачу: не так страшны первые 90% проекта, как вторые 90% проекта.

Мы вроде обо всем договорились, все сделали, теперь это надо как-то сдать. Что здесь поможет?

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

• Еще один лайфхак, позволяющий сдать работу, не подписывая акт выполненных работ – это промежуточные закрывающие документы. Например, у нас в компании используется «Ведомость функциональных разрывов по этапу моделирования». В ней нет цены, но это и неважно с правовой точки зрения. С правовой точки зрения важно, что заказчик подписался под описанными там функциональными разрывами, увидел себя в этом бизнес процессе. Ему не страшно – он не видит, что это 5 миллионов стоит. Он видит свою боль, которая каким-то образом разрешится на следующих этапах, и подписывает это. Если ведомость функциональных разрывов указана в задании или договоре в качестве отчетного документа по конкретному этапу, суд говорит: «Вы же этап приняли, отчетный документ подписали, значит работы выполнены». Поэтому подписать акт выполненных работ намного проще. У тебя сильная позиция – ты приходишь и говоришь: «Ребята, мы с вами подписали ведомость. Теперь нужно подписать акт, и это реально стоит столько денег, сколько мы договаривались». Очень помогает. Пользуйтесь.

Каким образом идентифицировать риски

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

• Первое – управляющий комитет проекта. Его нужно проводить регулярно – как минимум, раз в месяц. И со стороны контрагента помимо руководителя проекта на этом управляющем комитете обязательно должен быть куратор. Если куратор не ходит на УКП, возникает вопрос, что у заказчика с проектом, какова его ценность. Может быть проект им больше не нужен, а вы генерите затраты. Есть риск, что проект просто не закончится для вас ничем хорошим. УКП и протоколы УКП – это еще один из способов разрешить какие-то сложные ситуации и закрепить договоренности. Выносите туда все, о чем вы не можете договориться в обычной проектной деятельности, и закрепляете. Хорошо работает.

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

• Еще один важный момент – обратная связь 360 с клиентом. У нас менеджер по качеству раз в два месяца звонит сотрудникам заказчика, которые отвечают за функциональные блоки, и опрашивает их: как идет проект, нет ли сложностей, всем ли они довольны. Даже если клиент с вами каждый день общается, он может рассказать менеджеру по качеству такое, о чем вам не говорил – собраться с мыслями и выдать новую информацию. А еще это способ узнать об изменениях внутри заказчика. Недавно мы были на конференции в Омске, и там девушка рассказывала, что когда на проекте сменился финансовый директор, функциональный заказчик по блоку, аналитик не придал этому значение и просто забыл сообщить об этом руководителю проекта. А через два месяца, когда они пришли этот блок сдавать, всей команде пришлось работать сверхурочно и генерить дополнительные затраты. В данном случае, обратная связь 360 помогла бы.

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

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

Вывод

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

И обучайте своих руководителей проекта работать с правовыми рисками. Им это пригодится.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.