Административное закрытие проекта Курс “Завершение проекта” Административное закрытие проекта Оглавление Введение 3 Термины, используемые в лекции 3 Менеджерские роли по Адизесу 3 Типы проектов 7 Внутренний проект 7 Подрядные услуги коммерческому проекту 7 Подрядные услуги для госсектора 8 № 44-ФЗ 8 № 223-ФЗ 8 Вычитываем договор 9 Сдача-приемка работ 9 Не предусмотрено авансирование 11 Постоплата 12 Длительная приемка со стороны Заказчика 13 Скрытые недостатки 13 Права и обязанности исполнителя 14 Старт работ после передачи материалов 15 Приостановка работ при невозможности осуществления работ 15 Исполнитель обязан выполнять работы с надлежащим качеством. 16 Изменение договора 16 Форс-мажоры 17 Разрешение споров 18 Досрочное расторжение договора 18 Соглашение о конфидециальности Защита неисключительных прав 19 20 2 Административное закрытие проекта СОК с сотрудником Гарантийные обязательства 21 21 Гарантийные обязательства при наличии работ с участием производителя ПО, поставщика товара 23 Гарантийные обязательства при наличии работ с участием субподрядчика 24 Соглашение об уровне услуг (Service level agreement, SLA) 24 Привлечение субподрядчиков 26 Кадровая борьба 27 Удаленная работа 27 Штрафные санкции 28 Выводы 28 Введение На этой мы поговорим о том, как происходит административное закрытие проекта, на что нужно обращать внимание в договоре и как избежать самые популярные ловушки. На этой лекции вы узнаете: 1. про менеджерские роли по Адизесу 2. какие бываю типы проектов и чем они отличаются 3. как правильно вычитывать договор 4. какие формулировки встречаются в договоре и как их интерпретировать Термины, используемые в лекции Соглашение об уровне услуг (Service level agreement, SLA) - сли в договоре предусмотрена гарантированная скорость реакции на устранение инцидентов, это говорит о том, что договор не ограничивается проектом и предполагает сервисное обслуживание. 3 Административное закрытие проекта Менеджерские роли по Адизесу Вам может быть знаком Ицхак Адизес – один из ведущих западных бизнес-консультантов и автор многих книг о менеджменте. Он, в частности, ввел модель PAEI. Суть модели PAEI в том, что для успешного создания и развития бизнеса необходимы четыре личностных качества менеджера: ● производитель результатов — Producer. Сосредоточен на результате, эксперт в своей области, знает все нюансы. ● администратор — Administrator. Отвечает за организацию работы, следование процессам. Любит, когда все структурировано и разложено по полочкам. ● предприниматель — Entrepreneur. Рискованный, любит смотреть в завтрашний день, сосредоточен на стратегических задачах. Как правило менее организован и близок к тем, кого мы называем «творческими» ● интегратор – Integrator. Объединяет людей в сплоченные команды, сфокусирован на коммуникациях. Рассудителен и справедлив. Проекты – это часть бизнеса компании, соответственно эта модель с некоторыми обобщениями применима к области управления проектами. Проблема, которую выделяет Адизес, заключается в том, что невозможно найти в одном человеке всех четырех качеств. Успешен тот бизнес, в котором ключевыми ответственными закрываются все четыре блоки. Наверняка вам известен пример Стива Джобса и Стива Возняка. Первый замыкал на себя блоки предпринимателя и интегратора, второй – производителя результатов. Ярко выраженного администратора на начальных порах у них не было. Но давайте вернемся к нашей теме. Я предлагаю следующий подход. Он не универсальный, его нужно адаптировать под реалии вашей организации, но тем не менее это концепция поможет определить, как сплотить команду и понимать, от кого каких действий ожидать: 1. Интегратор – это полностью роль менеджера проектов. Вы должны быть в этом сильны. Ранее мы обсуждали что большая часть работы МП это коммуникации, что как раз соотносится с ролью интегратора в модели Адизеса. 4 Административное закрытие проекта 2. Администратор – качества администратора должны быть развиты в менеджере проектов, но в отличии от интегратора, это не его единоличная роль. Как в правило в компании существует роль администратора проектов, с которым вы делите задачи. При старте своего нового проекта обязательно учтите в матрице ролей и полномочии разграничения ответственности между этими двумя ролями. 3. Производитель результатов – это в бОльшей степени тимлид по разработке либо технический менеджер. Если вы откроете PMBOK то обнаружите, что область знаний «Содержание проекта» самая короткая и простая. Она почти полностью сводится к делегированию задач на технических специалистов и рассматривает лишь инструменты управления содержанием, такими как ИСР, которые вы изучали на предыдущих уроках. 4. Предприниматель – как правило, в парадигме управления проектами это менеджер по продажам, либо аккаунт-менеджер, либо спонсор проекта. Это тот, кто приносит новые задачи и активности на проработку интегратору для превращения идеи в проект. Хорошо, если у вас развиты предпринимательские качества, но хорошим РП можно быть и без них. Теперь про управление проектами. Руководитель проектов– главное ответственное лицо. Как соотнести модель Адизеса с парадигмой управления проектами? Итак, для чего я привожу эту модель? Давайте вынесем из рассмотрения производителя результатов и предпринимателя, коими в проекте являются тимлид по разработке и аккаунт-менеджер. Классические задачи управления проектом преимущественно подпадают под роли интегратора (то есть коммуникатора) и администратора. И эти роли очень разные. Давайте я попробую провести аналогию со спортом и станет понятнее. Задачи интегратора – это задачи аэробные, где важна динамика, скорость принятия решений, открытость к коммуникациям, готовность к конфликтным переговорам. Задачи администратора – как статические упражнения, требуют неспешности, внимательности, готовности к монотонной работе. В администрировании проектов нет места креативности, дизайн-мышлению и прочим околотворческим подходам. Администрируя проект, т.е. оформляя его закрытие документально, в вас должен вселиться внутренний нотариус и не выходить, пока административные задачи не будут выполнены. К ним могут относиться: 5 Административное закрытие проекта 1. Изучение конкурсной документации 2. Вычитка договора 3. Составление официальных писем, резюме встреч, протоколов и иного 4. Подготовка закрывающих актов 5. Формирование отчетности для руководства На старте работы менеджером проектов меня выбивало из колеи, когда после утренних планерок, активных переговоров с командой и заказчиком, за рабочим столом меня ждал совершенно иной пласт работ – выверка документации и проверка отчетности в бизнес-системах. Разный характер задач приводил к потере продуктивности и стрессу. Разобраться с этой ситуацией мне помогла книга Люси Джо Палладино «Максимальная концентрация». Приведенная парабола демонстрирует закон Йеркса — Додсона. Закон гласит, что результат (в данном случае, внимание) улучшается при повышении мотивации (или возбужденности) до известного предела. Когда уровень мотивации становится слишком высоким, результат ухудшается. Вершина параболы — пиковое состояние, в котором соотношение возбужденности и внимания оптимально. Зоны концентрации различаются в зависимости от вида деятельности. И тут все стало на свои места. Быстрая смена деятельности ведет к когнитивной перегрузке: 6 Административное закрытие проекта находясь на внешней встрече с руководством, где вы обсуждаете начало нового перспективного проекта, уровень мотивации поднимается до высоких отметок. И если сразу после встречи вам нужно вернуться и спокойно подготовить отчетный документ по другому проекту, вы можете обнаружить что перевозбуждены для такой монотонной работы. Подробнее о концентрации и техниках, как ее сохранять, вы можете изучить в озвученной мной книге. На моей практике, при введении нескольких проектов одновременно, я стараюсь администрирующие задачи выносить в отдельные дни. Если в проекте это допустимо, то в пятницу – когда наименьшее количество совещаний. В этом блоке я хотел бы подытожить – задачи по администрированию нужно выполнять неспешно, вдумчиво, с готовностью к монотонной работе. И эта лекция, в определенной степени будет такой же. Типы проектов Давайте начнем с того, что проект может быть инициирован в компании разными способами: 1. Внутренний проект администрирования) (наименьший уровень 2. Подрядные услуги коммерческому сложности администрирования) заказчику 3. Порядные услуги для госсектора администрирования проектов) (высокий сложности (средний уровень уровень сложности Внутренний проект Если вам передали внутренний проект, то есть стейкхолдерами являются представители вашей организации, договорной работы как таковой не будет. Вместо договора у вас будет Устав, также предполагается соблюдение политик и процедур компании. Исключением являются случае, при которых вам необходимо привлечь внешнюю экспертизу, что означает договорную работу с подрядчиками. Подрядные услуги коммерческому проекту Большая часть лекции посвящена этому формату работы – вы с проектной командой осуществляете ИТ-услуги для внешнего заказчика. Началом проекта 7 Административное закрытие проекта служит договор, а устав может быть приложением к нему. Далее мы разберем основные положения договора, отличим хороший договор от плохого. А так как данный курс посвящен завершению проекта, примеры будем рассматривать в контексте того, что большая часть работ по договору выполнена, но по тем или иным причинам в него нужно внести корректировки. Подрядные услуги для госсектора В проекте предполагается сложная договорная работа. Как правило, крупные проекты отыгрываются посредством тендеров, а они в свою очередь регламентируются двумя федеральными законами – 44-ФЗ и 223-ФЗ. Первый подробно описывает и строго регламентирует правила закупок, а второй устанавливает общие принципы и основные требования к торгам. № 44-ФЗ Закон действует на закупки всех госзаказчиков, строго описывает этапы торгов: от планирования до заключения контракта, регламентирует порядок, сроки госзакупок, требования к участникам и действия государственных организаций на каждом этапе. У заказчиков по 44-ФЗ есть четкий план проведения тендера, а у нас— уверенность, что с победителем заключат сделку и оплатят контракт в срок. Нарушение закона для госзаказчиков грозит административными взысканиями и отменой уже проведенной закупки, а для участников — включением в реестр недобросовестных поставщиков с запретом участвовать в госзакупках на два года. Как вы видите, в данном законе все очень строго. Проекты должны выполняться в соответствии с тем, что было оговорено в конкурсной документации. На первой лекции мы обсуждали, что заказная разработка программного обеспечения плохо управляема по каскадной методологии. Помножив это на строгость 44-ФЗ, мы получаем тяжелый проект с весьма значительными рисками. Искренне надеюсь, что вашим первым проектом не станет доведение до завершения чужого проекта, который был выигран по 44-ФЗ. № 223-ФЗ Закон устанавливает только общие особенности проведения торгов и обязывает заказчиков составить свое положение о закупках, которое регулирует закупочную деятельность. В положении заказчик прописывает, какими способами будет 8 Административное закрытие проекта проводить торги, в какие сроки, устанавливает требования к участникам, к форме заявки и т.д. Под закон попадают следующие предприятия: ● госкорпорации и компании, в которых более 50 % имущества принадлежит государству ● естественные монополии, например РЖД ● организации, которые занимаются регулируемой деятельностью, например энергетикой, теплоснабжением, обращением с твердыми бытовыми отходами, ● бюджетные и унитарные учреждения, которые проводят закупку за счет грантов, средств субподряда, подаренных и собственных денег. Закон дает заказчику определенную свободу действий, он мягче 44-ФЗ. Чтобы участвовать в торгах по 223-ФЗ, сначала нужно ознакомиться с положением о закупке конкретного заказчика. Закрепим: если после трудоустройства первым вашим проектом окажется госзаказ, либо компания, доля госучастия в которой выше 50 процентов, обязательно уточните у руководства, был ли проект получен в результате торгов по 44-ФЗ или 223-ФЗ. И в таком случае первый риск, который необходимо внести в реестр рисков на стадии Планирования – это возможность непопадания в сроки. Данный риск должен быть нивелирован на самой ранней стадии проекта. Вычитываем договор Так как мы изучаем администрирование проекта в контексте его завершения, исходим из прежнего сценария: вам передали проект, договор уже был заключен. Давайте посмотрим, какие положения из договора могут теперь привести к проблемам? Сдача-приемка работ В предыдущей лекции мы касались тестирования. Его можно условно назвать технической сдачей работ. В организационном плане необходимо еще посмотреть в контракте на следующие важные критерий: 1. Согласованы ли отчетные документы при проведении процедуры приемки результатов работ клиенту? 9 Административное закрытие проекта Если в контракте оговорены нагрузочное, интеграционное, пользовательское и регрессионное тестирование, то ваша задача как менеджера проектов организовать данные виды процедур и получить итоговые протоколы с подписью всех заинтересованных сторон. 2. Получив протоколы по всем типам приемо-сдаточных испытаний, вы можете поставить задачу бухгалтерии выпустить a. финансовый акт b. счет-фактуру c. счет на оплату Как правило, в Договоре предусмотрены сроки, в которые Заказчик обязуется рассмотреть результаты работ, подписать акт либо выпустить мотивированный отказ. Основанием является несоответствие выполненных работ оговоренным в Договоре и Техническом задании. Формулировка в договоре может выглядеть следующим образом: “В случае если по истечении 10 календарных дней, Заказчик не возвратит Исполнителю подписанный Акт, либо не направит мотивированный отказ по его корректировке, Акт будет считаться подписанным (согласованным) Заказчиком без претензий, а Работы, соответственно, принятыми Заказчиком в полном объеме, согласно требованиям соответствующего Заказа”. Если с клиентом коммуникация построена нормально, а работы выполнены качественно, проблем возникнуть не должно. Однако бывают случаи, при которой заказчик затягивает срок выпуска актов, не выдвигая конкретных вопросов/замечаний. Давайте рассмотрим некоторые причины: ● готовится внедрение смежной системы, и клиент хочет провести дополнительное интеграционное тестирование вместе с новой системой (даже если контракт такого не подразумевал) ● Представитель клиента покидывает компанию, и не хочет ставить лишних подписей Разберем первую ситуацию подробнее, она часто встречается. Например, вы разработали ПО и успешно продемонстрировали его в своем тестовом контуре и прошли все испытания. Заказчик по каким-то причинам не может обеспечить перевод продукта в свою инфраструктуру. Соответственно, не подписывает акты и 10 Административное закрытие проекта не готов оплачивать работу. Что можно предпринять? Вы можете предложить заказчику реструктурировать договор через дополнительное соглашение, указав отдельным оплачиваемым договорным этапом работу Исполнителя по переводу в промышленный контур. Таким образом, Заказчик сможет заплатить вам условные 80% от стоимости работ, однако он будет подстрахован, так как не все обязательства с вашей стороны исполнены. Если же вы столкнулись с немотивированным затягиваем и не можете согласовать компромиссные варианты – предупредите клиента, что выпускаете акт и просите сформулировать возражения в письменном виде в ответ на акт. Важно: выпускайте акт, только если действительно уверены, что работы выполнены, промежуточные итоги тестирования пройдено, все приемо-сдаточные испытания выполнены и у вас есть подтверждение в виде протоколов. Если заказчик все-таки сформулирует мотивированный отказ и найдет недостатки в работах, в договоре также наверняка прописан срок, в который Исполнитель обязуется исправить найденные недостатки. И если вы с этим сроком не справитесь, появляется риск штрафных санкции со стороны заказчика. Не предусмотрено авансирование Не прописан аванс в проекте. Если проектная команда стартовала работы без авансовых выплат, скорее всего, финансовая служба рассчитала кредитную линию под проект. 11 Административное закрытие проекта Рассмотрим пример. Вы заключились 15 января сроком на 1 (один) год на исполнение работ без аванса, постоплата равна 5 к.д. с даты подписания Акта о выполненных работах. Стоимость контракта – 30 млн без НДС, себестоимость 26 млн. Для простоты предположим, что вся себестоимость нужна в начале проекта, а ключевая ставка равна 12% годовых. Выходит, что к концу проектная процент по открытой кредитной линии составит около 3 млн рублей! Конечно, в реальной ситуации вам не нужно кредитовать сразу всю себестоимость и есть много других факторов. Однако понимая важность себестоимости денег, вам все будет легче обосновать запрос авансирования проекта заказчику. Обнаружив отсутствие аванса, обязательно сверьте бюджет проекта на предмет того, были ли данные издержки заложены предыдущим менеджером. В больших компаниях отсутствие авансирования это просто издержки, но для небольшой компании при высокой ключевой ставке такая экономика в проекте может поставит организацию на грань выживания. В связи с этим, кстати, очень важно устранение кейса «приемка до последнего замечания», которую мы проходили в первой лекции. Если вы взяли в работу проект, в котором была посчитан такой несправедливый порядок взаиморасчетов, настаивайте на доп. соглашении, чтобы погасить часть издержек. Особенности кредитования бизнеса заказчик, как правило знает не хуже нас, и может пойти на встречу. Наиболее выгодным порядком взаиморасчетов при твердой цене контракта для Исполнителя, является поэтапное закрытие работ с авансированием по каждому этапу. То есть, при каскадном выполнении Проектирования, строительно-монтажных и пуско-наладочных работ, Исполнителю необходимо договориться об авансировании каждого этапа. 12 Административное закрытие проекта Постоплата Помимо отсутствия аванса, в договоре может быть предусмотрена долгая постооплата – 30, 45, 60 календарных дней. Это увеличивает кредитную нагрузку в проект. Если вы обнаружили подобный пункт, а ситуация позволяет заключить дополнительное соглашение, попробуйте этого добиться. Особенно это может быть эффективно в сценарии, когда Заказчик просит выполнить небольшую доработку, которая формально не входит в скоуп работ. В таком случае вы можете 1. Оценить стоимость потенциальной доработки 2. Оценить выгоду от сокращения кредитной линии Предложить заказчику выполнить данные работы при встречном запросе на сокращение периода постоплаты. Длительная приемка со стороны Заказчика В договоре может существовать пункт следующего содержания: “Заказчик рассматривает результат услуг в течение 30 (тридцати) рабочих дней с момента его получения от Исполнителя.” Если прибавить к этому длительную постооплату, деньги от заказчика вы можете увидеть спустя три месяца после сдачи работ, что опять же приводит к издержкам на кредитование. Отработать этот пункт можно по аналогии с предложенным ранее вариантом. То есть сравнить сумму на кредитование с суммой потенциальной небольшой «фичи», которую вы можете предложить заказчику в обмен на корректировку приемки результата услуг. Однако, есть редкие кейсы, когда долга приемка заказчиком может быть полезна. Предположим, по контракту вам необходимо завершить проект к 1 февраля, однако вы понимаете, что есть мелкие доработки, которые суммарно выводят срок завершения проекта на 1 марта. Заказчик категорически не согласен продлевать срок работ. Предложите ему продлить срок приемки результата работ. На это он может согласиться. Тогда вы, со своей стороны можете выпустить акт и рассчитывать на устранение небольших доработок параллельно с приемкой работ заказчиком и это не будет нарушением условий контракта. Однако, делайте так, что если уверены в том, что доработки действительно небольшие и вы точно успеете сделать их за это прибавочное время. 13 Административное закрытие проекта Скрытые недостатки В договоре может быть прописано подобное: “При обнаружении недостатков в результатах работы, выполненной Подрядчиком, включая недостатки, обнаруженные впоследствии и (или) в процессе эксплуатации Системы, Подрядчик по требованию Заказчика обязан безвозмездно переделать результат работ и устранить недостатки.” И (или) такое: “Заказчик, принявший работу без проверки, вправе в дальнейшем ссылаться на недостатки работы, в том числе на те, которые могли быть установлены при обычном способе ее приемки (явные недостатки). Подписание Заказчиком акта сдачи-приемки выполненных работ без указания в нем недостатков не лишает Заказчика права в дальнейшем предъявлять возражения по объему, стоимости и качеству работ.” Это кабальные условия. В сущности, из них следует, что приемка работ не значила прекращения обязательств по контракту, и в любой момент Заказчик может вернуться с запросом на изменения. Доказать через год, что те или иные недостатки не были обнаружены в период сдачи системы и могли возникнуть по вине Заказчика в ходе эксплуатации, почти невозможно. Если есть возможность повлиять на данные пункты, согласуйте формулировку подобного вида: “Заказчик, обнаруживший в течение 20 календарных дней после приемки услуг отступления в них от настоящего договора или иные недостатки, которые не могли быть установлены при обычном способе приемки (скрытые недостатки), обязан известить об этом Исполнителя в течение 10 (десяти) календарных дней с момента их обнаружения.” Что делать если вам передали договор с такими условиями? Если же вам передали проект с подобными формулировками в договоре, а изменить текст договора не представляется возможным, обратитесь к коллегам из сервисного или операционного подразделения компании, предусмотрев возможность выделить заранее инженеров технической поддержки системы на разумный срок. 14 Административное закрытие проекта Права и обязанности исполнителя В очередной раз напомню, что коммуникации – это 90% работы менеджера проекта. Но коммуникации неэффективно выводить на одной лишь харизме, или упорстве. Для того, чтобы вам хватало аргументов для поиска компромиссов, нужно очень хорошо понимать нюансы заключенного договора. Даже если договор заключали не вы, при внимательной вычитке вы сможете определить неблагоприятные пункты, которые могли привести к одной из озвученных в первой лекции проблем при завершении проекта. И соответственно, аргументированно донести свою позицию до заказчика. Давайте разберем это детально в следующих пунктах. Старт работ после передачи материалов Если для проекта требуется предварительная передача вводных данных от Заказчика, необходимо привязать дату старта работ к дате предоставления соответствующих материалов. В договоре это может выглядеть так: «Исполнитель обязуется выполнить услуги в течение 91 (девяносто одного) календарного дня с даты предоставления вводных материалов, в соответствии с Приложением №1» В Приложении №1 может указано все, без чего команда не сможет начать: архитектурные планы, доступы к сетевой инфраструктуре и иное. Если такой пункт прописан, Заказчик должен передать данные в явном виде, а Исполнитель подтвердить, что вводные переданы. Если этого сделано не было, и вы готовы идти формальным путем на эскалацию – старт работ можно считать не случившимся. Если доводим чужой проект, в котором подобное произошло, ничто не мешает вам восстановить хронику событий, приложить соответствующие переписки и установить, что фактически при условной дате старта работ в 01 января, вводная документация от клиента была передана 01 марта, таким образом Исполнитель имеет право запросить Дополнительное соглашение на продление, если вы испытываете проблемы в исполнении обязательств в срок. Приостановка работ при невозможности осуществления работ В условиях санкции на этот кейс нужно обратить внимание. При старте проекта необходимо провести сессию с командой и определить риски, связанные с 15 Административное закрытие проекта введенными или предполагающимимся к введению санкции на то или иное ПО или железо. Если у вас в контракте прописано внедрение современных телекоммуникационных систем, с очень высокой вероятностью такие системы могут внедрить ряд компании, которые ушли с российского рынка (Циско, Хуавей). Однако санкции затрагивают и менее очевидные вещи, вплоть до ПО по дизайну интерфейсов (Миро) и работе с дистрибутивами (GitLub). В договоре может быть описано так: “Стороны установили, что в случае издания актов органа государственной власти или органа местного самоуправления, ограничивающих или запрещающих ввоз оборудования и (или) ПО на территорию РФ, в результате которого исполнение обязательств Исполнителя становится невозможным полностью или частично, обязательства Исполнителя прекращаются полностью или в соответствующей части с момента издания соответствующего акта органа государственной власти или органа местного самоуправления.” Исполнитель обязан выполнять работы с надлежащим качеством. В контракте могут быть прямо прописаны требования к квалификации и необходимому вовлечению проектной команды в работу над проектом с разной степенью интенсивности контроля. В договоре это может быть так: “Исполнитель обязуется выполнять работы и оказывать услуги по настоящему договору качественно, в порядке и в сроки, установленные настоящим Договором и Приложениями к нему” С одной стороны, это усложняет менеджеру проектов планирование на начальных стадиях. С другой стороны, подобный механизм служит дополнительным контролем эффективности работы проектной команды. Если в корпоративной культуре компании-исполнителя предполагается удаленная работа, в заказчике такое может быть запрещено. Таким образом, в качестве решения может быть высадка проектной команды непосредственно в офисе заказчика. Это может звучать тяжело, но на практике такой подход существенно облегает работу менеджера проектов по контролю производительности команды. Изменение договора Одна из первых когнитивных ошибок, которую допускают начинающие менеджеры проектов – это неосознание возросшего уровня полномочий при возросшем уровне 16 Административное закрытие проекта ответственности. Став менеджером проектов, для вас не может быть отговорок вида «мне дали тех людей, которые были доступны» и «поставили те сроки, которые были определены выше». “Рамки Проекта, а также другие требования к результату работ по настоящему Договору изложенные в Приложениях и Дополнительных соглашениях к Договору, могут дополняться и изменяться в установленном порядке по взаимному соглашению Заказчика и Исполнителя, путем заключения Дополнительных соглашений к Договору.” Менеджмент – это искусство возможного. Нереалистичные сроки необходимо пересматривать с педантичностью юриста, слабых членов команды – выявлять, отправлять на обучение или расставаться. Это то, что отличает менеджера проектов от координатора. То же касается договора. В коммерческом договоре через дополнительное соглашение, при наличии аргументов и убедительности, можно изменить почти любое условие. Сроки можно продлить, а состав работ – уточнить и заменить формулировки на соответствующие реалиям. Не забывайте об этом, когда будете вести свой проект. Форс-мажоры До 2020-го года я формально относился к содержаниям и формулировкам относительно форс-мажорных обстоятельств. Однако, во время первого локдауна, я столкнулся с тем, что Заказчик запретил приостанавливать работы на объекте в центре Москвы. Его мотивация была следующей: при задержке выполнения работ, в нужное время представительство компании не сможет перейти в новое арендуемое помещение в одной из башен Москва-сити. Как следствие – очень большие издержки из-за арендной оплаты одновременно в двух помещениях. У руководителя проекта KPI был напрямую завязан на своевременный релокейт сотрудников, и никакие аргументы он слышать не хотел, даже когда в городе началась первая паника из-за распространения коронавируса. Так как первые меры, принимаемые властями, интерпретировались неоднозначно, Заказчик счел что риски по неисполнению договора – это риски Исполнителя, т.к. прямо в договоре не было указано иного. Этот кейс дался тяжело мне и юристам компании. Проведя переговоры на топ-руководством, мы не добились компромисса, и Заказчик требовал выполнения 17 Административное закрытие проекта работ в срок. Исполнили работ были крайне демотивированы и я каждый день опасался за их здоровье (в тот момент никто не знал, насколько смертельным будет верус и вообще, то что мы в начале долгого пути и удаленной работы). К счастью, Управляющая компания здания отнеслась к надвигающейся пандемии серьезнее, и выпустила приказ о приостановке всех работ и ограниченном входе в здание. На сегодняшний день различные компании выработали подходы к форс-мажорным обстоятельствам: ● Часть компании в явном виде внесла в типовые формы контрактов, что всплеск (локальный или федеральный) пандемии COVID-19 не может являться основанием для признания нарушения сроков форс-мажором. ● Часть компании сделала аналогичные оговорки в отношении периодов мобилизации. Это значит, что вы как организация, обязаны своевременно заменить исполнителя, и такая замена не должна повлечь за собой затягивания сроков контракта. Надеюсь, что на момент изучения данного материала, подобные инциденты вернутся на уровень теоретических. Если нет, обязательно проговаривайте, даже на стадии завершения проекта, были ли данные форс-мажорные обстоятельства фактором задержки срока исполнения обязательств по договору. Таким образом вы убережёте компанию от штрафных санкции Разрешение споров Выполняя географически распределенный проект, обратите внимание на подсудность, указанную в договоре – нейтральной является формулировка «Спор по месту обращения Истца». Это позволит уберечь вас и ваших юристов перемещаться на географически удаленные субъекты, если спор путем переговоров разрешить не удалось. Досрочное расторжение договора Если завершение проекта из «нормального», перевалило «долгосрочное» или «ликвидацию», необходимо заранее вычитать порядок расторжения договора и обсудить условия с юристами. В нашем блоке Завершения проекта мы предполагаем, что вы доводите чужой проект. Вряд ли клиент согласится менять 18 Административное закрытие проекта условия этого раздела в преддверии расторжения. Пример справедливого расторжения: “В случае расторжения настоящего Договора Заказчик направляет Исполнителю письменное уведомление о расторжении Договора за 15 (Пятнадцать) календарных дней до предполагаемой даты расторжения Договора. Исполнитель обязан в течение 7 (Семи) рабочих дней со дня фактического прекращения выполнения работ, который определен Заказчиком, согласно полученному уведомлению о расторжении договора, составить и предоставить Заказчику акт о фактически выполненной работе с указанием перечня результатов фактически выполненной работы и их цены, приложить все отчетные документы, на момент прекращения выполнения работы и приложить счет на оплату. В этом случае сдача-приемка фактически выполненной работы осуществляется Сторонами в соответствии с положениями раздела 2 настоящего Договора. По результатам сдачи-приемки фактически выполненных работ Заказчик производит оплату.” Соглашение о конфидециальности Соглашение о конфиденциальности может быть оформлено как в подпункт в договоре, либо отдельным документом. К конфиденциальной информации относится следующая информация: 1. любые сведения (научно-технические, технологические, производственные, юридические, финансовые, иные), имеющие действительную или потенциальную коммерческую ценность в силу их неизвестности третьим лицам 2. списки клиентов, поставщиков и подрядчиков; маркетинговая информация, прогнозы, сведения о конъюнктуре рынка; бухгалтерские и финансовые документы; прайс-листы; планы производства, продаж, развития, методы ценообразования, платежи; знания и опыт реализации товаров, работ и услуг; деловая переписка; сведения о заключенных договорах, их содержании, предложения по их заключению; корпоративная структура, распределение должностных и функциональных обязанностей, внутренние и внешние связи, методы управления; кадры, их подбор. 3. информация в сфере интеллектуальной деятельности, в т.ч. неопубликованные научно-технические результаты, технические решения, 19 Административное закрытие проекта методы; не обеспеченные патентной защитой способы использования технологических процессов и устройств. К конфиденциальной информации не относится: 1. информация, на момент заключения настоящего Соглашения уже известная Принимающей стороне 2. информация, которая самостоятельно разработана Принимающей стороной без использования Конфиденциальной информации Раскрывающей стороны; 3. информация, которая получена на законных основаниях от третьих лиц без ограничений в ее использовании, либо которая до передачи ее Раскрывающей стороной находилась на законных основаниях у Принимающей стороны; 4. информация, которая разрешена к раскрытию неограниченному кругу лиц письменным разрешением Раскрывающей стороны. В СОК также определяются способы использования и хранения конфиденциальной информации. В зависимости от случая, в СОК с заказчиком и подрядчиком, вы можете выступать как раскрывающей, так и принимающей стороной. Вы принимающая сторона, если заказчик в ходе работ предоставляет вам доступ к информации, которая имеет, действительную или потенциальную коммерческую ценность. Случай, если вы раскрывающая сторона, рассмотрим в следующей главе. Защита неисключительных прав Если в процессе реализации совместных проектов вы, как раскрывающая сторона разработаете программное обеспечение (включая прототипы), необходимо понимать, передаете ли вы исключительные права на результат своих работ. ● Если вы разрабатываете уникальный проект для нужд заказчика и в ходе работ вами не используются активы организации, представляющие коммерческую ценность (ноу-хау), в договоре может быть предусмотрена передача исключительных прав на результат работ. Это значит, что вы не сможете использовать наработки, исходный код и иные материалы для повторного использования в других проектах. ● Если в ходе работ используется знания, подпадающие под определение «ноу-хау» и (или) защищены патентном, в договоре необходимо прописать 20 Административное закрытие проекта в СоК необходимо прописать сохранение за собой исключительных прав. Принимающая сторона обязуется не копировать, декомпилировать, дизассемблировать или проводить обратный анализ такого программного обеспечения. Важно: секретом производства (ноу-хау) признаются сведения любого характера (производственные, технические, экономические, организационные и другие) о результатах интеллектуальной деятельности и о способах осуществления профессиональной деятельности, имеющие действительную или потенциальную коммерческую ценность вследствие неизвестности их третьим лицам. СОК с сотрудником Сотрудники, которые работают в штате организации, как правило уже подписали необходимое соглашение о неразглашении на стадии трудоустройство. Однако, не забывайте о необходимости подписать СоК, если подключаете внешних специалистов, т.е. фрилансеров или аутсорсеров. Зачастую, внешнего специалиста невозможно даже надлежащим образом технически проинтервьюировать, не разгласив конфиденциальную информацию. Задумайтесь о подписании СоК уже на этапе переговоров со специалистом. Форма такого соглашения почти наверняка будет у вашей организации. Как правило, СоК заключается сроком на 5 лет, и под конфиденциальной информацией подразумевается любая информация, которая имеет действительную или потенциальную коммерческую ценность в силу неизвестности ее третьим лицам. Гарантийные обязательства Один из первых пунктов договора, в который стоит заглянуть после приемки чужого проекта, находящегося на стадии завершения, это гарантийные обязательства. Как правило, гарантийный срок на услуги составляет двенадцать месяцев от даты подписания акта выполненных работ. Пример стандартной формулировки ответственности в течение гарантийного срока: “В случае, если в течение гарантийного срока будет выявлено несоответствие выполненных работ требованиям настоящего Договора по причине невыполнения 21 Административное закрытие проекта и/или ненадлежащего выполнения Исполнителем своих обязательств по настоящему Договору, Исполнитель обязуется собственными силами, без привлечения дополнительных ресурсов Заказчика, и в оговоренные Сторонами сроки устранить дефекты, вызванные некачественным выполнением его части работ. При этом срок предоставляемой Исполнителем гарантии продлевается на период устранения недостатков.” Возникает несколько вопросов: ● Кем и почему выявляется «несоответствие» выполненных работ, если приемо-сдаточные испытания были проведены и результат работ принят? ● Что такое ненадлежащее выполнение Исполнителем обязательств? ● Какие сроки считаются «оговоренными»? Нечеткость определения гарантийных обязательств приведет к тому, что бремя по доказательству отсутствия вины Исполнителя будет лежать на вас, как руководителе проекта. Представим себе ситуацию: клиент в ярости звонит вам с раннего утра, и сообщает что разработанное приложение не работает, доступа к нему нет. Путем созвона с проектной командой, в данной ситуации в довольно быстро сможете понять, что полное отсутствие доступа к порталу с огромной долей вероятности говорит о проблеме в сетевой доступности, а не ошибке самого приложения. Те из вас, кто обладает технологической экспертизой, могут знать, что техническая поддержка подразделяется на 1-ую, 2-ую и 3-ую линию поддержки. ● Первая линия ТП отвечает за фиксацию инцидента, описание ошибки (со слов пользователя), определение процедуры эскалации. Специалист на этом этапе из описания ошибки должен примерно понимать, в чем может быть проблема. Ошибку пользователя (не туда нажимает) он должен уметь решить сам, если что-то сложнее - эскалировать задачу профильному специалисту. ● Вторая линия поддержки отвечает за кейсы средней сложности, сбор логов, проведение несложных технических процедур: ping сетевого адреса, рестарт тех или иных компонентов системы, ручное бэкапирование. 22 Административное закрытие проекта Если в компании нет сервисной поддержки, в контракте необходимо в явном виде обозначить, что первая и вторая роли технической поддержки должны быть в зоне ответственности Заказчика. В клиенте должны быть люди, обладающие достаточной экспертизой, чтобы понять, в чем примерно проблема, убедиться, что проблема не вызвана действиями сотрудников Заказчика – собрать логи и передать инцидент на 3-ую линию. При таком порядке пример, показанный выше, не произойдёт. Уже на этапе предварительного анализа, будет понятно, что проблема в зоне ответственности клиента. Если заказчик звонит напрямую вам и вываливает проблему, по всей видимости данные понятия не были определены в договоре. Остается вопрос 3-ей линии. Если клиент провел предварительный анализ, исключил сетевые проблемы, действия пользователя, и полагает что ошибки действительно в коде, собранные сведения о проблеме он структурированно передает вам, и это уже подпадает под понимание стандартного Гарантийного соглашения. Но и здесь есть оговорки. По возможности, внести в контракт следующие оговорки. Условия гарантии, предусмотренные настоящим разделом Договором, не должны распространяться на случаи несоответствия выполненных работ, если такое несоответствие стало причиной: ● Внесения Заказчиком изменений в результат работ, противоречащих документации, принятой от Исполнителя Заказчиком в качестве результата работ в рамках настоящего Договора; ● Неработоспособности или ненадлежащей работоспособности оборудования, информационных систем, сетей и иных составляющих инфраструктуры Заказчика, связанной с использованием результата работ по настоящему Договору; ● Эксплуатации Системы способом, запрещенным документацией, принятой от Исполнителя Заказчиком в качества результата работ в рамках настоящего Договора. Я ни в коем случае не призываю вас саботировать выполнение обязательств по гарантийной поддержке. Практика говорит, что в большинстве случаев ошибки возникают в связи с несанкционированным изменением продукта. Т.е. заказчик решил провести небольшую доработку своими силами, не привлекая вас. Разработчик поправил код, все развалилось. В договоре должно быть однозначно указано, что гарантия не распространяется, в случае если такое изменение было 23 Административное закрытие проекта выявлено. Отследить это достаточно просто на основании логов и собранных данных от второй линии поддержки. Гарантийные обязательства при наличии работ с участием производителя ПО, поставщика товара Если при исполнении обязательств вы передавали стороннее ПО (предположим, 1С Битрикс) либо поставляли оборудование, убедитесь, что объем гарантийной поддержки производителя учтен в рамках ваших гарантийных обязательств. Важно: проекты в заказчике инициируются, как правило, по CAPEX бюджету (капитальные расходы), в то время как покупка ежемесячной или ежегодной гарантийной поддержки от производителя, как правило, по бухгалтерскому учету относится к операционным расходам, т.е. OPEX. Даже если сумма ежемесячной платы за продление лицензии номинальна, заказчика нужно заранее уведомить, чтобы он смог заложить операционные расходы в бюджет. Гарантийные обязательства при наличии работ с участием субподрядчика Здесь все относительно просто – гарантийные обязательства между субподрядчиком и подрядчиком должны быть полностью зеркальны обязательствам между подрядчиком и Заказчиком. Об этом отдельно в следующей подглаве расскажу подробнее. Соглашение об уровне услуг (Service level agreement, SLA) Если в договоре предусмотрена гарантированная скорость реакции на устранение инцидентов, это говорит о том, что договор не ограничивается проектом и предполагает сервисное обслуживание. Напомню. Проект — это временное мероприятие с целью создания уникального продукта или результата. Однако учитывая сложность современных ИТ-систем, клиенту может быть нужно не только внедрение продукта, но и сопровождение, которое было прописано сразу в контракте. Если вам передали проект, в котором предусмотрены гарантийные обязательства с согласованным уровнем услуг, необходимо обратиться к руководству с запросом на сервисного менеджера (или 24 Административное закрытие проекта инцидент-менеджер), если контакты такового не были переданы вам вместе с проектом. Поддержка на условиях 24х7 c классификацией инцидентов на 4 (четыре) базовых уровня: Рассмотрим пример. У меня был проект по внедрению HD Wi-Fi (Wi-fi высокой плотности) для крупного московского торгового центра. Огромное количество точек доступа (их было сотни на каждом этаже) было обусловлено идеей мониторить маршруты передвижения посетителей и извлекать дополнительную бизнес-ценность из этих данных. К слову, этот проект был до массового тренда на онлайн-шоппинг, до пандемии само собой. Я вот рассказываю вам этот пример, и не могу даже вспомнить, когда последний раз был в торговом центре. Ну не об этом сейчас. Проект осуществлялся по каскадной методологии, мы последовательно покрывали зоны от паркинга, и нескольких этажей, до зоны фудкорта. Wi-fi точки могут быть довольно капризной вещью при массовом использовании, и в проекте было предусмотрено разделение зон ответственности между командой внедрения, которую возглавлял я, и командой сопровождения, которую возглавлял сервис-менеджер. Как только зона паркинга была оснащена и приемо-сдаточные испытания проведены, я результаты протокола передавал в сервисный отдел и с этого момента данная зона становилась зоной ответственности сервисного менеджера. 25 Административное закрытие проекта Закрепим: Если вы понимаете, что в проекте предполагается сопровождение одновременно со внедрением системы, подумаете надо подобным разделением зон ответственности. Привлечение субподрядчиков Вы не раз столкнетесь с необходимостью привлекать субподрядные/аутсорсинговые организации и управлять их работой. В контексте администрирования данных работ важно помнить следующее правило: Договорные обязательства между субподрядчиком и подрядчиком (вами) должны быть абсолютно зеркальны обязательствам между подрядчиком и заказчиком. На практике добиться этого требования сложно. Предположим, вы ведете комплексный проект по внедрению информационной системы, и в вашем договоре с заказчиком обозначено большое количество штрафных санкции, расширенная гарантийная поддержка, размытые требования. В масштабе всего проекта такие требования могут быть допустимыми для вашей организации, однако при зеркалировании тех же условии на подрядчика, который, предположим, выполняет задачи по дизайну и верстке, бюджет на такие работы может показаться субподрядчику несопоставимы с теми рисками, которые вы в него зеркалируете. Универсального подхода тут нет. С одной стороны, действительно, если субподрядчик задействован в объеме 5% от вашего объема обязательств, зеркалировать размеры штрафных санкции в него кажется непропорциональным. С другой стороны, нередки ситуации, при которых у вас с заказчиком заключен контракт с твердой ценой, сроками и зафиксированным объемом работ, а в то же время подрядчик по мере декомпозиции работ, пересматривает сроки и бюджет, мотивируя это тем, что постоянно всплывают новые вводные. Попытаюсь привести признаки, по которым вы сможете понять, что в вашем проекте такая ситуация. Предположим, компания взяла на себя определенный объем обязательств «под ключ», где 90% - известные для организации работы, 10% - нишевые неизвестные работы. Например, вам нужно создать ИС для больницы и, в частности, провести интеграцию с отраслевой медицинской системой. Субподрядчики, обладающие экспертизой в данного рода интеграциях, прекрасно понимают свое относительно уникальное положение на рынке и недостаточность вашей экспертизы. В таких случаях следует очень внимательно отнестись к 26 Административное закрытие проекта процедуре контрактования, и детально прописать в каких случаях возможен и в каких невозможен запрос на изменение содержания работ и сроков. Кадровая борьба На стадии завершения проекта заказчик определил наиболее эффективных и ценных исполнителей в вашей проектной команде. Этого не случается сплошь и рядом, однако не лишним будет ввести соответствующую оговорку о недопустимости переманивания сотрудников друг у друга. Формулировка может выглядеть так: “Стороны обязуются не предпринимать каких-либо действий, направленных на привлечение работников другой Стороны настоящего Договора, и не принимать их на работу на постоянной или временной основе без письменного согласия другой Стороны. Данное обязательство вступает в силу с момента подписания настоящего Договора и действует вплоть до истечения пяти лет с даты его прекращения.” Руководство этот шаг с вашей стороны точно оценит. Удаленная работа В наше время все чаще проектные команды географически распределены. Какое-то время назад этот аспект работы слабо регулировался, и, если у сотрудника был технический доступ к производству работ, на его местонахождение закрывали глаза. Однако мы повсеместно видим стремление регулировать понимание дистанционной работы. В некоторых заказчиках удаленная работа может быть запрещена на уровне контракта по соображениям безопасности. При этом в вашей проектной команде специалист, которого нельзя заменить оперативно, работает удаленно. Как подойти к решению данного вопроса? Вы можете прописать в договоре условие, согласно которому, вместо физического нахождения проектной команды определяются IP-адреса, с которых проектная команда может осуществлять деятельность, запрашивать доступ к тестовым и продуктовым средам. Сотрудника обязать выполнять работу не со своего личного ПК, а виртуальной машины, размещенной на ваших корпоративных мощностях. Таким образом, никакие данные не могут храниться и передаваться локально, доступ будет защищенным и отслеживаемым при помощи корпоративных системных администраторов. 27 Административное закрытие проекта Это не является полным решением, т.к. физически сотрудник по-прежнему работает удаленно, однако такие меры повышения уровня защиты могут убедить заказчика пойти на встречу и разрешить подобный формат работы. Штрафные санкции Если при завершении проекта вы понимаете, что штрафные санкции неизбежны, попробуйте предложить клиенту вместо штрафа – выполнение определенных работ, в рамках отдельного соглашения, на эквивалентную сумму. В договоре может существовать подобна формулировка: «Зачет встречных однородных требований письменному соглашению Сторон» производится исключительно по Даже если такой формулировки нет, это можно прописать в Дополнительном соглашении. Обсуждая дополнительный объем работ, рассматривайте такие работы как «задел» на апсейл (допродажу) в этом клиенте. Например, если вы разработали мобильное приложение, можете предложить ТЗ-Концепцию на развитие продукта. Если вы выполнили инфраструктурный проект (модернизация ЛВС/ЦОД), можно предложить выполнение аудита по информационной безопасности (если в вашей организации есть подобная квалификация). Таким образом, штраф как негативный инцидент преобразуется в возможность осуществить новый проект в клиенте. Выводы Сегодняшняя лекция представляет из себя относительно разрозненное описание кейсов, которые могут вам встретиться при администрировании проекта, находящегося на стадии завершения. Пусть вас не смущает эта разрозненность она вполне соответствует духу работы руководителя проектов, которому нужно быть немного бухгалтером, юристом, специалистом по госзакупком и кем еще придется, в зависимости от уникальности проекта. Хорошая новость в том, что каждая предметная область не требует досконального изучения. Держите в голове роли «интегратора» и «администратора», и помните, что бОльшая часть задач решается коммуникациями, объединением людей и делегированием им задач и полномочий (т.е. интегрирующего стиля), и некоторая часть задач требует неспешного изучения, вычитки нюансов и вдумчивого принятия решений. 28 Административное закрытие проекта 29 Административное закрытие проекта 30
