Немного о нас, заказчике, проектах и предыстории
Команда нашей компании предоставляет сервис поддержки приложений для 80+ приложений немецкого заказчика. За 5 лет сотрудничества у нас сложились доверительные отношения. Где-то раз в год заказчик подбивает расходы, смотрит, сколько стоит наша команда и с каким качеством работает, и решает отдать нам в аутсорсинг ещё десяток-другой внутренних приложений.
Наш заказчик — крупный производитель серверов и оргтехники. Приложения, которые попадают к нам, в основном созданы для учёта, планирования продаж, заказов и отчетности на разных уровнях. Ещё у нас на поддержке внутренний корпоративный портал на SharePoint и все, что обычно бывает накручено на SharePoint в большой организации (подбор персонала, документооборот и т.д.).
Наша команда обеспечивает 2, 3, 4 линии поддержки SharePoint и приложений на .NET. Мы решаем инциденты, чиним баги и проблемы, и меняем код приложений, когда это необходимо. Разработкой с нуля мы тоже занимаемся, но это уже история другой статьи.
За эти 5 лет мы проводили передачу знаний 4 раза, и у нас сложился опыт, которым хочется поделиться. Внутренние практики, как планировать передачу, чтобы потом укладываться в бюджет и график, и избегать проблем в будущем, когда сервис запустится.
Планирование перевода услуги
Перед тем, как засесть за планирование, мы запрашиваем два документа:
- описание сервиса по каждому приложению, включающее в себя:
- краткое описание приложения: для чего оно;
- какие бизнес-процессы автоматизирует;
- какие примерно задачи нам предстоит делать: закрывать инциденты и делать регулярные работы по обслуживанию, мониторить, решать проблемы и т.д.
- форму для ответов на вопросы к каждому приложению:
- сколько пользователей используют приложение;
- внутренние они или внешние;
- есть ли ключевые пользователи;
- сколько инцидентов решается в среднем в год и т.д.
Также мы запрашиваем весь набор имеющейся документации, код и все записи об инцидентах, если есть возможность их увидеть. Просим сделать несколько обзорных презентаций по каждому приложению, где можно задать вопросы тем, кто в нем разбирается.
После того, как в головах проясняется масштаб бедствия передаваемого объёма, самое время открывать MS Project и накидывать план.
Для каждого из передаваемых приложений мы планируем:
- регулярные сессии передачи знаний;
- разворачивание среды разработки для приложения, разбор кода;
- написание или допиливание документации (бизнес-процессы, тест-планы и т.д.);
- ревью инцидентов и проблем, создание базы знаний по инцидентам;
- работу над инцидентами в текущей группе поддержки (они делают работу – мы смотрим);
- передачу полученных знаний команде поддержки;
- работу под присмотром текущей группы поддержки (мы делаем работу – они страхуют).
Планирование перевода сервиса похоже на обычный план проекта. Трудность в том, что ту грань, до которой вы дойдете в разборе приложения, вы устанавливаете себе сами. Насколько тщательно будет разбираться код, насколько серьезно нужно понимать бизнес-процессы, насколько точно вы собираетесь воспроизводить среду, в которой работает приложение. У меня нет особенных рекомендаций, где нужно остановиться. Мы останавливаемся тогда, когда в общем, как устроено понятно, а в деталях мы в состоянии разобраться самостоятельно. Эти детали – как раз то, что будет отличать вас первые полгода — год от текущего провайдера сервиса. Сначала вы будете решать задачи дольше, иногда сильно дольше. Нужно объяснять заказчику, что сервис сначала будет очень медленным, если передача знаний будет недорогой, и наоборот. Искать золотую середину лучше вместе с заказчиком, учитывая его бюджет и важность бесперебойной работы приложений.
Помимо плана этот этап подразумевает создание реестра рисков, на которые мы заложились в оценке.
Важно: весь необходимый объем информации нужно доводить до всех заинтересованных людей вовремя. Отдавать на сторону сервис бывает очень некомфортно, особенно в первый раз. Важно, чтобы люди научились вам доверять, для этого ваши действия должны стать для них максимально понятными и прозрачными. Отчеты о состоянии работ должны идти регулярно. Если вы не укладываетесь в срок, или накосячили, заказчик должен узнать об этом как можно скорее.
Транзишен на старт
После того, как план готов, договор подписан, и команда собрана, можно начинать.
Передача знаний выглядит, как любой другой проект, идущий по плану. Вы можете использовать ту методологию управления, которая вам по сердцу. Мы брали 2-х недельные скрамовские итерации, и они отлично работали. Стек документов проекта готовился по Prince 2.
Как и в любом проекте, бывает, что вдруг надо сделать то, чего нет в описании работ (ой, мы забыли, что это не один бизнес-кейс, а три). Бывает, что вы где-то недооценили сложность работы. Если вы менеджер со стажем, на этот риск у вас тоже есть буфер.
Но есть трудность, с которой мы столкнулись только на проекте передачи знаний: сильное сопротивление. Внутри заказчика среда не гомогенная, часто находятся люди, которые не очень рады решению руководства отдать проекты в аутсорсинг. Часто текущий провайдер услуг бойкотирует передачу документации, не приходит на сессии по передаче знаний или рассказывает вам не все, что вы должны знать. В этом случае все, что вы можете сделать — эскалировать, и, если ничего не происходит, увеличить стоимость транзишена. Эту ситуацию и пути работы с ней нужно обговаривать до того, как передача знаний началась, конечно, в реестре рисков этот пункт должен быть.
На выходе из проекта по переводу сервиса мы также предоставляем:
- рекомендации по изменению кода;
- заполненный чеклист готовности к старту сервиса: что сделано, что не сделано из запланированного и почему;
- предварительный вариант основных процессов работы нового сервиса;
- реестр рисков нового сервиса, с облегченными планами, конечно;
- выученные уроки: что шло не так и как в это не вляпаться в следующий раз.
Кроме этого, должен состояться официальный sign-off, прием работ от менеджера проекта по переводу к менеджеру сервиса.
Менеджер сервиса, конечно, начинает работать гораздо раньше, чем к моменту sign-off. Ещё перед передачей знаний обычно вместе с ним прикидывается размер команды сопровождения, к моменту sign-off наши предположения относительно команды только подтверждаются и корректируются. Менеджер сервиса участвует в создании предварительного варианта основных процессов сервиса.
Эти процессы описывают:
- как часто проверяются журналы событий;
- как работать, если для закрытия тикета нужна помощь другой команды;
- как правильно закрывать тикеты в системе и многое другое, без чего сервис не будет работать, как часы.
Первые месяцы сервиса эти процессы будут отлаживаться и меняться. Из предварительного варианта они разовьются в законченные работающие версии. Это ещё один инструмент прозрачности: что бы мы ни делали, мы предсказуемы для заказчика.
Когда мы обучаем команду сервиса и пробуем предоставлять сервис под присмотром текущей службы сопровождения, нагрузка менеджера сервиса порой становится даже больше, чем у менеджера проекта по переводу. Ну и, конечно, он должен обговорить SLA и написать контракт на предоставление сервиса. Так что, можно сказать, менеджер сервиса работает, не покладая рук, в течение всего проекта по переводу сервиса.
Чтобы проблем было ещё меньше, в передаче знаний в обязательном порядке участвуют люди, которые будут потом работать в команде сервиса. Это ядро будущей команды. После завершения проекта перевода они помогают команде освоить новые знания.
Когда сервис немного устаканивается, где-то через 3-6 месяцев, мы запускаем процесс улучшения сервиса. В его основе лежит канбан. Этот процесс помог нам удешевить сервис в полтора раза, но это уже тема следующей статьи.
Автор: Fkleto4ku
Автор: ICLServices
