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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    image

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

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

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

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

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

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

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

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

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

    image

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

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

    Автор: Fkleto4ku

    Only registered users can participate in poll. Log in, please.

    При аутсорсинге поддержки приложений Вы в первую очередь заинтересованы:

    • 36.3%В обеспечении бесперебойной работы приложений8
    • 4.5%В развитии приложений1
    • 36.3%В использовании процессного подхода для обеспечения предсказуемости результатов и постоянство уровня качества услуг8
    • 22.7%В сокращении затрат на поддержку приложений5
    • 0%Другое (указать в комментариях)0
    ICL Services
    98.57
    Цифровые технологии для бизнеса
    Share post

    Comments 2

      0
      «Постоянство уровня качества услуг» как раз подразумевает, что SLA содержит «обеспечение бесперебойной работы приложений».
        0
        Именно так.

      Only users with full accounts can post comments. Log in, please.