Реновация интранета. Алгоритм действий

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

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

Успейте купить корпоративный пакет COSSA-2025 со скидкой!

Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

Работы по реновации включают следующие три этапа:

• подготовка;
• организация бизнес-требований, аналитика, проектирование;
• реализация плана обновления.

Этап 0. Подготовка

Подготовка к реновации начинается, когда собственно обновление ещё не стартовало. На этом этапе важно проработать и чётко зафиксировать 3 момента:

• миссия и цели;
• команда;
• бюджет.

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

Команда проекта

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

Например, в проекте для «Первой грузовой компании» коммуникация трехуровневая. Менеджер проекта общается с рабочей группой, аккаунт-менеджер общается на уровне проектного комитета, а директор агентства — на уровне управляющего комитета.

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

Стратег

Идейный вдохновитель, евангелист, который знает куда и зачем идти. Он идет впереди всех.

В нашей практике без такого человека проекты получали негативный сценарий: затухали, останавливались, пропускали этапы.

Менеджер проекта

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

IT-компетенции

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

Источник знаний

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

Владельцы разделов

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

Бюджет

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

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

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

Почему ориентация именно на три года? Как правило, таков срок жизни любого IT-проекта. Потом он требует реновации или доработки. Меняется и бизнес, и подход, и масштаб, требования, технологии.

Если рассмотреть компанию порядка 5000 сотрудников, то получается, что 54 млн — не так много. Всего две чашки в месяц на сотрудника.

Когда определились с командой и бюджетом, можно двигаться в проект.

Этап 1. Агрегация требований

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

В агрегации мы следуем двум принципам:

• собирать данные на всех уровнях структуры компании;
• применять подход персон и обстоятельств при анализе требований.

Уровни сбора требований

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

Топы говорили о задачах бизнеса. Это верхнеуровневые, глобальные задачи, они не раскрывают реального запроса. У руководителей подразделений были свои боли, страхи. Непосредственно рядовые сотрудники, для которых делается интранет, говорили о рутинных проблемах.

Работа с персонами

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

1. Persons. Акцент на человеке: кто конкретно будет пользователем. Турист хочет узнать маршрут до точки Б. Я турист-бабушка, я турист-девушка, которая боится ходить по темным улицам. «Я» сотрудника стоит на первом месте при анализе задач.

2. Jobs-to-Be-Done. Позволяет отключиться от личности и посмотреть на обстоятельства, при которых нужна функция.

Например:

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

Алгоритм сбора

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

Определение ключевой явной потребности

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

Задачи топов, запросы сотрудников и статистические данные (обращения в техподдержку, цифры и метрики) всегда нужно совмещать, подходить к задаче с разных точек. Вполне может выясниться, что слова и жизнь отличаются. И то, что руководители заявляют как «очень важное», таковым будет лишь для них. На слова надо смотреть скептично.

Интервью

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

Блок подготовки к интервью включает:

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

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

В самом интервью нужно общаться глубоко и устно. Всегда задавать вопрос: «Почему? Какие мотивы у именного такого решения задачи?».

Фиксируйте каждую деталь. Бэклог важен: потом вместо перепроверки гипотезы решения задач можно просто обратиться к зафиксированным требованиям.

Карта пользовательского опыта

На основе интервью и анализа действующих систем создается карта пользовательского опыта (CJM). Карта визуализирует путь пользователя, ожидания и барьеры на этом пути. Глобальная цель любой карты — понять в какой момент и как сделать взаимодействие сотрудника с цифровой средой наиболее удобным, улучшить цифровое пространство.

Есть разные подходы к формированию карты. Мы строим CJM из следующих блоков.

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

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

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

  Например. Когда вы подаете заявку, могут ответить сухим — «Ваша заявка принята». А могут — «Ваша заявка принята, мы обработаем ее в течение трех дней». Второе приятнее, да?

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

  Это и есть чувства и ощущения, на которые стоит обращать внимание.

• Бизнес-требования. В виде бизнес-требований оформляются функции и потребности. Это уже конкретные решения, что меняем и внедряем. Из них складывается будущая обновленная система.

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

Устав проекта

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

Устав проекта включает:

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

Дорожная карта проекта

Включает:

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

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

Зачем нужна карта?

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

Пример дорожной карты

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

Вспомогательные сущности

Дорожная карта и устав проекта — неотъемлемые документы при реновации. Но есть и дополнительные эффективные сущности-помощники.

Карта экосистемы компании

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

Например, в ПГК у менеджерского звена есть и SAP и CRM для работы со своими клиентами, но нашлось место так называемому «Интерфейсу менеджера» для работы с клиентами в личном кабинете.

Схема архитектуры нового решения

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

Этап 2. Процесс переезда

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

При выборе поэтапного переезда важно предусмотреть два момента.

1. Сквозная авторизация — пользователю достаточно авторизоваться в корпоративной системе учета (AD), и он автоматически может перейти в любую версию интранета без лишнего ввода логина и пароля на каждой из площадок.

2. Перекрестное меню — меню, объединяющее разделы нового и старого портала.

Потоки

Сам переезд мы предлагаем делать в несколько потоков.

1. Старый портал — пока еще поддерживать минимальными средствами.

2. Новый интранет:

1. Перенос простых функций as is, они не требуют переработки. Просто в них добавлен новый дизайн и контент.
2. Старт полного цикла реализации каждой функции в отдельности.
3. Разработка мобильного приложения, так как оно несколько отличается технологически.
4. Техподдержка и доработка задач из бэклога.

Определение типовой схемы релиза

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

• Взаиморасчеты с подрядчиком (Fix-price, Time&Material или Retainer). Проговорить отчетность и реперные точки, необходимые и принципиальные для закрытия этапов работ.

• Трекеры задач, состав и периодичность отчетности, документальная фиксация задач. Здесь же сразу решить, чья сторона будет вести отчетность и задачи.

• Архитектура серверов, зоны ответственности, кто осуществляет накат обновлений, доступы. Есть разные требования, к кому-то надо приезжать и работать на месте.

• Среда разработки, схема работы и зоны ответственности в системе контроля версий.

• Технические требования (платформы, ОС, разрешения и так далее).

Интеграции

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

Нас часто спрашивают, надо ли менять интеграцию. Если все работает и работа устраивает то, не рекомендуем её ломать.

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

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

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

Бэклог

Бэклог — реестр всех требований, дополнений к ним, выявленных на этапе агрегации или внедрения. Ведение бэклога — это аксиома для любого проекта. И интранета тем более, так как задачи и потребности сотрудников меняются, обновляются. В процессе переезда появляются новые «хотелки».

Ведение бэклога можно реализовать в двух форматах:

• Закрытый — через форму подачи предложений.

• Открытый — с отображением краткого статуса и обратной связью. Это высший пилотаж с большой ответственностью, так как состояние бэклога будет на виду у пользователей и станет для них показателем внимательного отношения команды проекта к заявленным новшествам.

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

Анонсы

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

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

Завершение

Что же делает реновацию успешной? И стоит ли игра свеч, раз выходит сложно и масштабно?

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

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

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

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.

Источник фото на тизере: Unsplash