Transition приложений. Как мы забираем приложения в поддержку

Немного о нас, заказчике, проектах и предыстории

Команда нашей компании предоставляет сервис поддержки приложений для 80+ приложений немецкого заказчика. За 5 лет сотрудничества у нас сложились доверительные отношения. Где-то раз в год заказчик подбивает расходы, смотрит, сколько стоит наша команда и с каким качеством работает, и решает отдать нам в аутсорсинг ещё десяток-другой внутренних приложений.

Наш заказчик — крупный производитель серверов и оргтехники. Приложения, которые попадают к нам, в основном созданы для учёта, планирования продаж, заказов и отчетности на разных уровнях. Ещё у нас на поддержке внутренний корпоративный портал на SharePoint и все, что обычно бывает накручено на SharePoint в большой организации (подбор персонала, документооборот и т.д.).

Наша команда обеспечивает 2, 3, 4 линии поддержки SharePoint и приложений на .NET. Мы решаем инциденты, чиним баги и проблемы, и меняем код приложений, когда это необходимо. Разработкой с нуля мы тоже занимаемся, но это уже история другой статьи.

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

Планирование перевода услуги

Перед тем, как засесть за планирование, мы запрашиваем два документа:

1. описание сервиса по каждому приложению, включающее в себя:
   
   • краткое описание приложения: для чего оно;
   • какие бизнес-процессы автоматизирует;
   • какие примерно задачи нам предстоит делать: закрывать инциденты и делать регулярные работы по обслуживанию, мониторить, решать проблемы и т.д.
2. форму для ответов на вопросы к каждому приложению:
   
   • сколько пользователей используют приложение;
   • внутренние они или внешние;
   • есть ли ключевые пользователи;
   • сколько инцидентов решается в среднем в год и т.д.

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

После того, как в головах проясняется масштаб бедствия передаваемого объёма, самое время открывать MS Project и накидывать план.

Для каждого из передаваемых приложений мы планируем:

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

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

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

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

Транзишен на старт

После того, как план готов, договор подписан, и команда собрана, можно начинать.



Передача знаний выглядит, как любой другой проект, идущий по плану. Вы можете использовать ту методологию управления, которая вам по сердцу. Мы брали 2-х недельные скрамовские итерации, и они отлично работали. Стек документов проекта готовился по Prince 2.

Как и в любом проекте, бывает, что вдруг надо сделать то, чего нет в описании работ (ой, мы забыли, что это не один бизнес-кейс, а три). Бывает, что вы где-то недооценили сложность работы. Если вы менеджер со стажем, на этот риск у вас тоже есть буфер.

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

На выходе из проекта по переводу сервиса мы также предоставляем:

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

Кроме этого, должен состояться официальный sign-off, прием работ от менеджера проекта по переводу к менеджеру сервиса.

Менеджер сервиса, конечно, начинает работать гораздо раньше, чем к моменту sign-off. Ещё перед передачей знаний обычно вместе с ним прикидывается размер команды сопровождения, к моменту sign-off наши предположения относительно команды только подтверждаются и корректируются. Менеджер сервиса участвует в создании предварительного варианта основных процессов сервиса.

Эти процессы описывают:

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

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

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



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

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

Автор: Fkleto4ku