Аналитика на грани компетенций
Большие проекты требуют вовлечения множества команд и разных специалистов. В идеальном мире, если в работе задействованы несколько команд, проект проходит гладко: все соблюдают сроки, качественно прорабатывают задачи и общаются «на одном языке». В реальной жизни — процессы усложняются, а работа становится менее эффективной.
Например, у аналитиков часто возникает проблема контекста. Как его собирать, анализировать, поддерживать актуальность? Чтобы решить эту задачу, приходится выходить за рамки своей компетенции: планировать и организовывать взаимодействие внутри и между командами проекта. В статье разберём, как подготовиться к крупным проектам внедрения и решать сложность контекста на таких проектах.
Привет! Я Саша, аналитик внедрения Naumen Contact Center. За 2 с лишним года, что работаю в компании, я участвовал в большом количестве проектов, где взаимодействовал со специалистами из разных команд и решал задачи от проработки отчётности до пилотирования и полного внедрения контактного центра.
Я часто встречался с проблемой контекста — когда нет полной картины проекта и понимания, как выглядят процессы, как работают разные части системы, чем занимаются команды на проекте. Контекст нужен, чтобы выполнить задачу клиента и разработать оптимальное решение. Я научился эффективно решать эту проблему. Расскажу об этом на примере одного из крупных проектов внедрения и поделюсь чек-листом с подсказкой, как действовать аналитику на разных этапах проекта.
Особенности проектов внедрения
Мы внедряли контактный центр крупному заказчику. На проекте я занимал роль главного аналитика — составлял требования, прорабатывал решения, занимался написанием документации.
Для мэтча в терминологии, сначала расскажу, что для чего нужны проекты внедрения и что понимаю под крупным проектом.
Продукт не всегда учитывает все требования бизнеса, поскольку клиенты решают одну и ту же задачу по-разному. Также существуют ограничения и особенности инфраструктуры, которые необходимо учитывать. Именно этими вопросами и занимается команда внедрения — вырабатывают решение, которое адаптирует продукт под конкретные задачи клиента.
Наш проект состоял из трёх этапов:
1. Продажа — первичное определение потребностей клиента, фиксация скоуп задач и работ, заключение договора.
2. Само внедрение — сбор требований формирование полной картины проекта. Далее — настройка системы и само внедрение, подготовка документов и сдача проекта в эксплуатацию.
3. Передача проекта на техническую поддержку разработанного функционала.
Проекты можно делить по разным критериям: бюджету, временным рамкам или количеству задействованных специалистов. В нашем понимании большой проект — тот, в котором участвуют более четырёх команд. Думаю, у вас возникает вопрос: «Всего четыре команды, в чём проблема управления контекстом?». Да, кажется, что участников немного, но в крупных проектах структура более сложная.
Структура нашего проекта выглядела так.
Над проектом работали четыре команды, но в действительности гораздо больше: команда бизнеса разбивалась на подразделения, каждое подразделение подключало свою команду разработки и имело особенности в процессах. Появились специалисты информационной безопасности, команда продаж и технической поддержки. Подключились вендоры и другие сторонние команды.
Каждый блок — отдельная команда, и четыре группы превратились в сложную структуру. Чтобы в ней не возник хаос, мы справились с неопределенностью: определили зоны ответственности, подключили дополнительных к специалистов к проекту, составили запасной план на случай форс-мажора и наладили коммуникацию между участниками.
Чтобы проверить успешность проекта на любом этапе, все контрольные точки я свёл в чек-лист. Надеюсь, он поможет и вам :)
Пройдемся подробнее по всем пунктам.
Определение зоны ответственности
Одной из задач на проекте была настройка интеграций и их тестирование. На проекте мы занимались тестированием интеграций. Задача техническая, но аналитик обладает компетенцией сделать запросы и проверить на соответствие постановке. Появилась проблема: кому отдать эту задачу? Аналитику, который писал постановку и знает, что ожидает клиент? Инженеру, который разрабатывал и настраивал интеграцию?
Мы распределили эту задачу аналитику, так как его экспертиза поможет нам проверить корректность настройки, отловить скрытые особенности решения и сделать заметки для методики испытаний. Как мы к этому пришли: в начале проекта определили, какие компетенции есть в команде, и зафиксировали, какие задачи специалисты могут взять на себя. Это помогло более гибко использовать ресурс.
Зоны ответственности определили, но компетенций текущих специалистов может не хватит, тогда важно учесть следующий поинт в чек-листе — подключить дополнительных участников.
Проработка дополнительных ролей
На нашем проекте у аналитика была общая задача крупная задача — обладать полным контекстом всего проекта. Для этого важно было определить риски и погрузиться в документацию. Он читал документы и встретил там требования по информационной безопасности. Компетенцией в этой области аналитик не обладал и потратил много времени на изучение. Что в итоге? Дедлайн по задаче сдвинут, мотивация упала.
Решение: подключить специалиста определенного профиля. Это мы учли на этапе планирования следующей задачи — подсветили команде риск нарушения сроков из-за недостаточной компетенции и выделили две дополнительные роли — специалиста по информационной безопасности и технического писателя.
Кажется, что уже всё учли — план есть, зоны ответственности определили, специалистов узкого профиля подключили. А что если важный участник проекта выпадет из процесса и заберёт с собой контекст? Мы продумали и такую возможную проблему.
Составление запасного плана
Чтобы составить план проекта, мы представили его схематично на диаграмме Ганта и всё продумали до мелочей — задачи, время, связи и последовательность. И разделили проект на смысловые блоки как явно выделенные, так хаотичные. В каждом блоке присутствовали критические задачи, которые влияли на весь проект.
Так случилось, что аналитик с максимальным контекстом заболел на важном этапе проекта. Мы учли риск заранее — продублировали роли и выделили двух аналитиков. Первый управлял контекстом и следил за ходом проекта, второй — выполнял аналитические задачи или заменил первого при форс-мажоре.
Руководитель проекта сопротивлялся, так как это увеличивало объём ресурсов, но остановка проекта из-за сыгранного риска оказалась бы страшнее.
Риски учли. Как связать всё это воедино?
Взаимодействие между командами
Здесь я выделил четыре важных момента.
1. Проект — огромный контекст, который разделён по командам и участникам. Аналитику важно собрать его воедино и держать в актуальном состоянии. Для этого мы в начале проекта определили формат и способ фиксации договоренностей.
Использовали специальные системы управления проектом — Jira и Redmine, и определили регламент заполнения. Это помогало отследить «здоровье проекта» с погрешностью в день.
Не рекомендую фиксировать важные вопросы устно или в мессенджерах, так как договоренности могут потеряться.
Определён формат фиксации договоренности
2. На проекте аналитики проводили много созвонов с целью узнать, где найти тот файл, который обсуждали ранее. Когда мы это осознали, договорились о едином месте хранения информации. Это минимизировало количество таких встреч, появилось больше времени на решение основных задач.
Определено общее место хранения контекста
3. На нашем проекте было две инфраструктурные команды со стороны клиента и исполнителя. Для полной картины и максимального контекста важно было взаимодействовать через команду внедрения. Но из-за дополнительного звена в коммуникациях время на решение затягивается — возникали петли или лишние итерации.
Как мы с этим справились: связали две команды напрямую и по необходимости приглашали участника из внедрения. Это помогло не только грамотно спланировать ресурсы, но и эффективно выстроить собственный рабочий процесс и высвободить время от проработки лишнего контекста.
Проработана карта коммуникаций
4.На проекте мы выявляли требования отчетности с двумя командами клиента. Одна команда вела отчетность в Excel и требовала перенести шаблоны в систему в виде отчетов. Вторая — с помощью BI-системы и для них было достаточно предоставить информацию о способе подключения к базе данных. Для нас важно было найти общее решение. Нам долго не удавалось склонить первую команду к использованию BI. Но на общей встрече вторая команда своим примером смогла заинтересовать коллег. В итоге прорабатывалось одно общее решение через использование BI системы.
Если бы общей встречи не было, нам бы пришлось прорабатывать множество отчетов, тратить на это большое количество ресурсов. Поэтому сейчас мы стараемся заранее спланировать встречи со всеми участниками проекта — ведь общий контекст формируется, когда все участники взаимодействуют в одном поле.
Назначены общие регулярные встречи
А теперь пройдитесь по всем пунктам своего проекта и, если на каждом вы поставили галочку, с уверенностью скажите себе: «Отлично сработано, парень!» :)
