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

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

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

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

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

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

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

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

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

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

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

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

Стратег

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

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

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

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

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

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

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

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

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

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

История из практики

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

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

Бюджет

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

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

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

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

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

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

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

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

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

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

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

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

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

История из практики № 1

Сотрудники компании N в один голос говорили, что им нужен расчет и согласование «важных показателей».

Спросили у представителей IT-блока — такие функции ни в одной системе не реализованы и в планах пока нигде не стоят.

Спросили у топ-менеджмента, те ответили — да, это важная приоритетная задача. Зеленый свет!

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

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

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

История из практики № 2

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

Изучили пользователей, пообщались с сотрудниками, руководителями, директором по продажам, построили CJM, реализовали прототип, дизайн.

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

И тут он говорит:

— Я просил сделать сайт «продающим», а вы сделали сайт, после просмотра которого мне хочется взять трубку и мгновенно позвонить!

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

— Моя компания — бутик в своей сфере, мне нужны только платежеспособные клиенты, которые готовы потратить на меня много денег. И они должны понимать это сразу, а не после разговора с менеджером! Сайт должен отсечь всех ненужных и на выходе получить готовый заказ с итоговой ценой, чтобы менеджеру оставалось только выставить счет на оплату. Я не хочу раздувать штат и тратить время своих драгоценных специалистов на общение со всеми подряд.

Мораль: обязательно пообщайтесь с руководителями и не постесняйтесь задать ему глупые вопросы на уточнение.

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

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

• Persons. Акцент на человеке, кто конкретно будет пользователем. Турист хочет узнать маршрут до точки Б. Я турист-бабушка, я турист-девушка, которая боится ходить по темным улицам. «Я» сотрудника стоит на первом месте при анализе задач.
• Jobs-to-Be-Done. Позволяет отключиться от личности и посмотреть на обстоятельства, при которых нужна функция.
  Например:
  «Когда я не знаю, как добраться до места, и хочу узнать маршрут до точки Б»
  «Когда я хочу по дороге увидеть все достопримечательности, и хочу узнать маршрут до в точки Б»
  «Когда я тороплюсь, и хочу узнать самый короткий маршрут до точки Б» — скорее всего проще спросить у прохожих.
  «Когда я экстремально быстро хочу узнать маршрут до травмпункта» — скорее я позвоню в скорую.
  «Когда я плохо ориентируюсь на местности и мне лучше идти по главным улицам, чтобы не сбиться с маршрута до точки Б»

История из практики

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

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

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

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

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

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

История из практики

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

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

Интервью

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

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

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

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

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

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

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

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

• Персонажи и этапы. Они выделены на предыдущей стадии, остается их структурировать. Помните, что этапы в жизни не всегда последовательны.
• Цели, барьеры, опасения, инструменты, чувства. На каждом этапе варианты достижения цели разные. Не всегда самый простой путь доходит до пользователя. Поэтому дополнительно говорим про опасения, конкретные барьеры, инструменты и идеи.
  Особое внимание уделяйте чувствам людей, которые оказываются на каждом из этапов.
  Например. Когда вы подаете заявку, могут ответить сухим — «Ваша заявка принята». А могут — «Ваша заявка принята, мы обработаем ее в течение трех дней». Второе приятнее, да?
  А еще лучше — «В течение часа с вами свяжется специалист, ответственный за вашу заявку. Если торопитесь — позвоните ему сейчас, вот номер». Совершенно другой подход и ощущение, хотя казалось бы мелочь.
  Это и есть чувства и ощущения, на которые стоит обращать внимание.
• Бизнес-требования. Функции и потребности оформляются в виде бизнес-требований. Это уже конкретные решения, что меняем и внедряем. Из них складывается будущая обновленная система.

История из практики

Для дочки АФК Система мы реализовывали процесс сдачи авансового отчета. У компании много торговых представителей в разных точках России, они перманентно находились в командировке. Возникала потребность сдавать авансовые отчеты вовремя: выслать документы, подписать у бухгалтера, руководителя, провести в 1С. Пока предыдущий отчет не сдан, новый транш не выдается. Разумеется, было много ошибок, документы терялись, затраты на корреспонденцию росли, сотрудники были недовольны.

Мы предложили решение состоящее из двух релизов:

• Документация. Сотрудник заполнял форму, она уходила в 1С, он подписывал сформированный документ и отправлял по почте.
• Электронная цифровая подпись. Не нужно ждать, когда документы придут почтой/курьером, они сразу подписаны. Новый транш денег приходит быстро.

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

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

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

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

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

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

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

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

Включает:

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

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

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

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

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

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

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

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

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

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

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

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

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

История из практики

Старая архитектура


Новая архитектура

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

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

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

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

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

Потоки

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

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

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

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

• Взаиморасчеты с подрядчиком (Fix-price, Time&Material или Retainer). Проговорить отчетность и реперные точки, необходимые и принципиальные для закрытия этапов работ.
• Трекеры задач, состав и периодичность отчетности, документальная фиксация задач. Здесь же сразу решить, чья сторона будет вести отчетность и задачи.
• Архитектура серверов, зоны ответственности, кто осуществляет накат обновлений, доступы. Есть разные требования, к кому-то надо приезжать и работать на месте.
• Среда разработки, схема работы и зоны ответственности в системе контроля версий.
• Технические требования (платформы, ОС, разрешения и т.д.).

История из практики

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

Интеграции

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

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

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

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

Бэклог

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

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

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

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

Анонсы

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

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

Завершение

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

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

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