Мастер-класс: 8 бед, один ответ – корпоративное/постпроектное сопровождение

Александр Чавалах. В своем докладе «5 шагов к успеху постпроектного сопровождения. Опыт партнеров 1С» Владимир Павлов сделал акцент на нюансах, о которых практически никто не задумывается. Но именно из-за невнимания к этим нюансам заказчики остаются неудовлетворены.

Казалось бы, проект прошел хорошо, заказчики никаких претензий не предъявляют, а потом говорят: «Спасибо, до свидания!» И либо начинают сопровождать сами, либо ищут кого-то со стороны.

Никто ни с кем не поругался, проект закончился хорошо, но дальнейшего сопровождения не возникло. Я думаю, 90% проектов на рынке именно так происходит.

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

 

 

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

Но взять проект на сопровождение очень хочется. И клиент такой хороший.

Вопрос: как быть? Брать или не брать такого клиента? Или сказать: «Извини, друг, в другой раз?»

Владимир Павлов. У Гамлета есть знаменитые строки: «Быть или не быть? Вот в чём вопрос! Что благороднее: сносить ли гром и стрелы враждующей судьбы или восстать на море бед и кончить их борьбою?»

В первую очередь мы должны осознать, почему нам хочется принять этого клиента на сопровождение. Скорее всего, мы хотим расширить свои возможности и добавить к себе в портфолио новое решение. Например, часто у заказчиков используется ТОиР – это хорошее дополнение к 1С:ERP. Либо мы имеем традиционный 1С:ЗУП, но у заказчика возникает необходимость поддержать для него 1С:Аналитику, 1С:Кабинет сотрудника и так далее.

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

Как выйти из этой ситуации?

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

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

• Дальше, получив положительные ответы на эти вопросы, мы уже можем говорить о том, что начнем сопровождать.

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

Александр. Подводя итог – вы предлагаете не бояться этой истории?

Владимир. Совершенно верно. Дорогу осилит идущий. Нужно пытаться работать с этим риском.

Александр. Но к этому моменту, возможно, в компании еще не выстроена сама технология корпоративного сопровождения. Здесь наверное все-таки две ситуации.

• Одна история – когда у тебя процесс уже налажен, просто пришел неожиданный клиент.

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

Во втором случае, я бы тут еще подумал – может быть, не надо?

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

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

 

 

Александр. Переходим к следующей ситуации: «Все значительно хуже, чем предполагали». Это не продолжение предыдущей, это новая ситуация.

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

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

Обязательства взяли, ситуацию недооценили, но обратного пути уже нет. Вписались, как в предыдущем примере – и что теперь делать?

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

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

• Одна команда борется со стояком и останавливает воду любой ценой.

• Вторая команда оценивает риски и анализирует последствия.

Понятное дело, что в первую команду войдут два-три исполнителя, которые закрывают этот вопрос любой ценой, понимая, что это для нас убытки.

А вторая команда (или это просто один человек – менеджер) в спокойной обстановке начинает анализировать, почему это произошло. Анализировать по традиционному списку ТКС:

• Первое – есть ли у нас люди?

• Второе – налажено ли у нас взаимодействие с заказчиком? Почему это произошло? Может быть, взаимодействие было неправильным?

• Третий важный момент – достаточно ли у нас компетенций и ресурсов, чтобы продолжать эту деятельность, но уже не в аварийной ситуации, а на регулярной основе?

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

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

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

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

Но если мы понимаем, что в рамках сопровождения не сможем это сделать, мы должны объяснить это заказчику.

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

Александр. Но заказчики часто продавливают: «Вы тут накосячили, исправляйте бесплатно».

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

Он говорит: «Нам просто нужны консультации. Компетенции моих бухгалтеров низкие, им просто нужно отвечать, какие кнопки нажимать – простая техническая консультация до 15 минут».

А вы дальше сталкиваетесь с совершенно другими консультациями. Они спрашивают: «Как нам закрыть месяц? Почему у нас не сошлась себестоимость? Почему у нас на этих счетах после перепроведения документа задним числом какая-то неправильная цифра?» И мы попадаем в консультацию, связанную с серьезным анализом данных, которая вместо 15 минут превращается как минимум в 8 часов. Требования к специалистам вырастают, соответственно.

Поэтому часто такая ситуация бывает злодейством заказчика. Это тоже надо учитывать. И именно поэтому надо иметь детальный каталог услуг и заключать SLA более тщательно.

Как только появилась такая ситуация, надо сразу начать переговоры о расширении SLA для гораздо более сложных услуг.

Александр. Мне понравилась идея насчет разделения на две команды, где одна команда гасит то, что произошло, а вторая команда – анализирует ситуацию, чтобы она не повторилась. В том числе, решает, что делать с этим заказчиком. Это правильная мысль.

 

 

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

Как балансировать загрузку между трудовыми ресурсами, занятыми в сопровождении и входящим потоком и плюс еще регулирование текущего потока заявок? Что с этим делать?

Владимир. Мы должны плотно работать с нашим отделом продаж и понимать прогнозный пул заказчиков по аналогии с тем, как мы понимаем свой портфель проектов.

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

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

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

Александр. Подводя итог:

• Первое – мы смотрим на текущие контракты, которые переходят в стадию сопровождения.

• Второе – смотрим на отдельно взятые продажи сопровождения, все это синхронизируем.

• Учитываем, что у нас есть возможность потенциального перераспределения ресурсов на какие-то внутренние проекты.

• И последнее – вкладываем свободные ресурсы во внутреннее обучение. Но последние два варианта – уже от безысходности. Все-таки хочется, чтобы сотрудники работали на целевого клиента.

Владимир. По поводу целевого клиента – изучайте стандарт 1С:ИТС, там есть раздел «Развитие клиента», где говорится про ежемесячные встречи сторон и предложение дополнительных услуг.

Александр. И еще, возможно, среди текущих клиентов могут оказаться потенциальные клиенты на сопровождение, которые просто еще об этом даже не задумались. Можно их оттуда вытащить.

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

 

 

Александр. Еще одна, очень распространенная ситуация – система была разработана другой командой или самим заказчиком. Хотят передать ее на сопровождение.

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

В этом случае мы получаем систему на сопровождение, но не знаем, какой там объем кастомизации.

Вопрос: как оценить влияние глубины доработок кода на стоимость поддержки? Особенно, если документации нет. Можно ли как-то формализовать процесс принятия системы на сопровождение?

Владимир. Здесь есть три варианта:

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

Александр. Но это же дико трудоемко. Мы на этом этапе просто хотим принять решение – вписываемся мы или не вписываемся? Если мы на этом этапе начнем бесплатно делать такой мегаанализ – это такое себе, честно говоря.

Владимир. Золотые руки наших программистов справятся. Они должны просто выгрузить. Это несложная штатная ситуация.

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

Другой, более простой способ – это анализ той документации, которая была в ходе проекта внедрения, если таковая существует. Мы можем взять из проекта реализованные по нему ЧТЗ и по ним провести простой анализ, который также приведется к количественной характеристике.

Ну и последний жест отчаяния: если у заказчика есть какая-то система Service Desk и там велись запросы на изменение, мы делаем реестр запросов на изменение и пытаемся оценить их с нашими экспертами, которые в этом разбираются. А сразу подключаем туда архитектора, который и скажет объем изменений.

Александр. Эта мысль мне нравится, потому что, как правило, у заказчика есть своя система Service Desk. Можно в рамках проекта запросить к ней доступ, сформировать отчет и посмотреть объем запросов – что менялось.

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

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

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

 

 

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

Как сопровождать уникальную систему, которая существует в единственном экземпляре?

Владимир. Когда это решение разрабатывалось, заказчик принимал на себя все риски. У него был любимый программист-гений, который создавал для него уникальную систему.

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

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

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

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

Более того, мы должны понять, как мы с ним взаимодействуем.

• Во-первых, взаимодействие тоже стоит каких-то денег.

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

Мы должны начать решение этой задачи с определения двух вопросов.

• Первое – готов ли заказчик платить.

• И второе – насколько мы сможем реально оценить все риски с точки зрения процессов, бизнес-результатов и всего того, что обычно бывает в проекте.

По сути, мы должны ему объявить проект принятия на сопровождение.

Александр. Итого, можно вывести два сценария развития ситуации.

• Либо это будет очень дорогой проект принятия на сопровождение.

• Либо мы предложим заказчику инициировать, если это уместно и возможно, новый проект на внедрение тиражного продукта с дальнейшей адаптацией, с документированием и прочими вещами. Но это менее вероятный сценарий, потому что сохранить, скорее всего, будет дешевле, чем инициировать новый проект. Хотя это зависит от степени устаревания старой системы. Если она на 7.7, наверное, заказчик вероятнее задумается о переходе. Но если она еще не слишком старая, и в ней все устраивает, он попытается ее сохранить.

 

 

Шестая ситуация – тоже частый случай – отсутствие документации по внедрению и информационной системе в целом.

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

Здесь – то же самое. К нам пришел заказчик, а документации на систему у него нет. Есть какая-то старая, но он говорит, что ее лучше вообще не смотреть, иначе мы запутаемся и будет только хуже. Что делать?

Владимир. Первое и главное – мы должны понять, что подразумевается под словом «документация». Документацию можно условно разделить на две части:

• Документацию, которая необходима для сопровожденцев и ИТ-специалистов – это архитектура системы и все, что описано в паспорте системы (какие используются сервера, среды, какая применяется релизная политика и т.д.).

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

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

Что касается пользовательской документации, то, с моей точки зрения – это глиняные таблички. Никто никогда не читает инструкции со скриншотами. Наиболее востребованы небольшие электронные курсы с видеороликами по 3-5 минут по наиболее частым сценариям использования системы.

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

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

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

• Второе – попытаться продать обучение на основе видеокурсов, которые заложить либо в Корпоративный университет, либо в базу знаний.

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

Александр. Но восстановление пользовательской документации и ее актуализация – это же отдельная работа? Ты же не будешь ее делать просто в рамках предконтрактной работы по сопровождению?

Владимир. Совершенно верно.

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

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

Александр. Это будет отдельный микропроект по принятию системы на сопровождение?

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

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

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

Обычно это позитивно воспринимается заказчиком и бизнесом.

И дальше мы обязательно включаем в стоимость сопровождения обучение специалистов и создание этих электронных курсов.

 

 

Александр. Седьмая ситуация – частый случай.

Команда мечтает перейти к промышленной эксплуатации, завершить проект, а заказчик все время тянет, и говорит, что мы не можем завершить. Никто претензий не предъявляет, вам говорят: «Вы молодцы, мы скоро у вас проект примем. Только нужно еще вот это чуть-чуть доделать. А потом еще вот здесь чуть-чуть переделать, тут добавить…» И так далее. Идет постоянное расширение требований – рамки проекта растут.

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

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

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

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

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

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

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

Я думаю, что в большинстве проектов люди сейчас об этом не думают. Есть РП-шник, и он работает, пока проект не будет завершен.

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

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

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

На этапе подготовки к опытной эксплуатации мы должны запустить процесс подготовки системы к сопровождению. Более того, мы должны начать ее сопровождение, потому что фаза называется «Опытная ЭКСПЛУАТАЦИЯ». Это означает, что в проекте появилась вовлеченность большого количества пользователей – команда проекта, как правило, не справится с этим. Все равно привлекать дополнительные ресурсы.

Если мы там делаем только проект, это будет бесплатно. А если мы продаем вместе и проект, и сопровождение, то уже как минимум будет существовать бюджет сопровождения.

И в какой-то момент в рамках подготовки к опытной эксплуатации мы говорим заказчику: «Помните наши договоренности? Этот прекрасный момент случился, давайте подпишем еще один договор».

Александр. Но это, конечно, сложно. Он же скажет: «Вы проект не завершили. Когда завершите, тогда будем говорить о сопровождении».

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

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

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

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

 

 

Александр. У нас осталась последняя ситуация, но мы ее уже обсудили. Не будем сейчас возвращаться.

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

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

И дальше – хорошо, если охлаждение. Как правило – расставание.

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

 

Кейс от Юрия Лазаренко. История про два договора

 

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

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

У нас был клиент, мы с ним три года сотрудничали. А потом в какой-то момент я сказал: «Ребят, мне с вами сложно, я устал, я мухожук», и мы прекратили сотрудничество.

Потом через два года они пришли к нам со словами: «Забирайте нас обратно». И тогда мы заключили с ними одновременно два договора.

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

• И второй договор – на сопровождение. Мы не знаем, что там будет, поэтому это почасовка по определенной стоимости. Условно, 3000 в час.

Мы все сделали согласно договоренности, и хотим сдать эту работу клиенту – чтобы он принял и оплатил нам работу.

Приходим на встречу с представителями клиента, и у нас идет долгая беседа. Я вижу, что они не хотят принимать – находят какие-то надуманные поводы, чтобы перенести встречу.

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

Мы включили хладнокровие, и когда он назначил нам еще одну встречу – а это четыре часа – мы пришли вдвоем. Два сотрудника, стоимость часа каждого стоит три тысячи. Мы пришли, четыре часа пообщались и по окончании месяца выставили им счет по другому договору на восемь часов наших сотрудников.

Он сначала спросил: «Что это?» Я говорю: «Мы вам все сделали. Формально у нас все готово, вы по каким-то надуманным причинам не хотите принимать работу. Мы на вас потратили 8 часов, вот вам счет за сопровождение». Это было немного жестоко, но я понимаю, что человек поступает некрасиво, и я решил тоже поступать не совсем красиво.

Вишенкой на торте был случай, когда мы опять пришли вдвоем, чтобы сдать работу самому директору, который нам подножки ставил. Он опоздал на встречу на два с половиной часа, и мы выставили им счет за два с половиной часа сидения в офисе. Он возмутился: «Но вы же сидели и ничего не делали. Почему вы взяли с нас денег?» – «Потому что мы сидели и ничего не делали, а могли бы заработать в другом месте».

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

И еще он понял, что к нам на кривой козе не подъехать. Потому что у нас два договора: согласно одному договору мы ждем деньги, а согласно другому – вам придется заплатить, если мы ждем.

Это сработало.

Александр. Хорошо, что это сработало, но обычно все не так просто. Вы сейчас с этим заказчиком в хороших отношениях?

Юрий. Да.

Александр. Интересно, почему он при таких жестких условиях продолжил с вами работать и остался довольным. Это, скорее, уникальная история.

Юрий. Мы с ними работали с 2015 года по 2019, потом ушли, когда поняли, что не можем работать на тех условиях, которые были раньше, а в 2021 вернулись.

Между 2019 и 2021 годами они поменяли три команды. И поняли, что если будут менять дальше, у них развитие остановится.

С 2015 по 2019 мы им и веб-порталы, и даже свой Excel с нуля написали в 1С – чего только не было. А с 2019 по 2021 другие команды сделали в 10 раз меньше и хуже.

И они поняли – да, с нами тяжело, но лучше с нами. Это обходится дешевле – переделывать не приходится. Поэтому мы сотрудничаем до сих пор.

 

Выводы

 

 

Александр. Выводы, которые хочется сделать из этого.

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

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

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

Второй вывод – надо создавать две команды. Не только проектную команду, но и команду по сопровождению со своей структурой, компетенциями, инструментарием и так далее. Это важно.

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

Это очень сложная задача. Нужна большая насмотренность, большая статистика – как минимум, эту информацию уже нужно начать собирать.

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

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

Как минимум у вас всегда должен быть свой Service Desk, а еще вы можете работать параллельно в Service Desk системе заказчика – возможно, интегрировать ее со своей системой.

 

Комментарий от Владимира Конырева

 

Поделюсь рядом подходов, которые мы используем при переходе из проекта в сопровождение.

Первое. Мы в договоре и план-графике проекта часто закладываем в конце такой этап, как «Техническая поддержка». И оцифровываем его в часах. Допустим, если мы работаем на результат, мы определили там 5-6-7 этапов, где четко обозначили, что будет результатом. Пользователи обучены, там 20 отчетов разработано и так далее. А в конце – техническая поддержка и в часах. Это позволяет четко обозначить заказчику, что до этого работали мы на результат, который заранее определили. А все, что было выявлено сверх того, что мы договорились, переходит в техническую поддержку. Такая техническая поддержка в часах уже позволяет описать границы стоимости и времени выполнения работ.

Второй момент. Я уверен, что у всех в юридических договорах есть пункт: «в случае несогласия заказчика в подписании акта он должен подготовить полный, исчерпывающий, непротиворечивый…» Это стандартный блок, я думаю он в договоре у всех есть. На этом тоже нужно делать акцент. Однозначно.

Безусловно, это еще зависит от заказчика, от проекта, от психологии. Кто-то манипулирует, заранее роет ямы. Тут уже нужно смотреть и включать софт-скилы.

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

Директор поворачивается на руководителя проекта: «Действительно такой пункт есть в договоре?» Тот говорит: «Да» – «Так что мы здесь копии ломаем?» Расписался и все. Т.е. вопрос в том, с кем ты общаешься.

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

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

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

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

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

 

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

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