Всем привет! Меня зовут Татьяна, я работаю аналитиком в ГНИВЦ. Сегодня мне хочется рассказать вам, почему аналитик является скрытым руководителем проектов и как аналитику реализовать любой проект.

В статье разберём:

1. Зоны ответственности аналитика и руководителя проекта по стадиям проекта.

2. Когда аналитик = «спасатель» хаотичного проекта.

3. Как реализовать проект, даже если ты не РП.

4. Лучшие инструменты и универсальную визуализацию.

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

Фактически:

1. Аналитик отвечает за определение потребностей будущего пользователя, составление и визуализацию бизнес-процесса, проработку будущих решений.

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

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

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

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

Преимущества совмещения ролей аналитика и руководителя проекта:

1. Глубокое понимание потребностей — аналитик более точно осознаёт запросы бизнеса и конечных пользователей, что поможет руководителю чётко обозначить задачи и расставить приоритеты команде.

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

3. Быстрое решение вопросов — обладая всей необходимой информацией и полномочиями, руководитель-аналитик оперативно принимает решения относительно изменений в проекте, ускоряя процесс создания продукта.

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

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

Недостатки совмещения ролей аналитика и руководителя проекта:

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

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

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

4. Снижение гибкости в принятии решений — принятие решений и перераспределение задач внутри команды усложняется вследствие двойной нагрузки на единственного исполнителя, вынуждая искать компромисс между быстротой реакции и глубиной проработки аналитической части.

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

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

Подробно рассмотрим по стадиям проекта пересечение зон ответственности аналитика и руководителя проекта:

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

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

3. На стадии реализации аналитик может работать с приоритизацией задач и бэклогом или взаимодействовать с заинтересованными сторонами. А часто даже выполнять расчёты.

4. На стадии завершения, аналитик защищает проект перед заказчиком, как и руководитель проекта.

Нередко аналитик становится спасателем хаотичного или трудного проекта. Это может происходить по ряду причин:

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

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

3. Когда команда путается в порядке задач и функциональности, в этом случае аналитик правильно выстраивает порядок задач.

4. Когда висит угроза срыва сроков. Здесь аналитик может выступить в качестве специалиста, способного определить MVP (минимально достаточную версию продукта).

5. Если у команды трудности во взаимодействии с заказчиком или между собой. В этом случае аналитик может выступать в качестве грамотного коммуникатора.

6. Если у проектного менеджера большое количество проектов и он физически не может себе позволить глубоко погружаться в каждый из них.

7. Разработчики и РП не могут отследить всех взаимодействий на проекте.

И даже когда аналитик не руководитель проекта, он всегда может реализовать проект, если он: участвует в каждом этапе проекта и используют лучшие практики.

Участие аналитика в стадиях проекта:

1. Инициация — сбор требований, определение границ, Product Vision, конкурентный анализ.

2. Планирование и реализация — глубинный анализ требований, подготовка постановок, проработка интерфейса, реализация и тестирование.

3. Внедрение — подготовка стендов и документации.

4. Эксплуатация — техподдержка и усовершенствование системы.

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

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

1.       Product Vision.

2.       Таблица персон.

3.       Конкурентный анализ.

4.       Моделирование.

5.       Схема экранов.

6.       Прототипирование.

7.       Работа над ошибками.

8.       Эффективные коммуникации.

А что делать, если у вас стартап, где нет руководителя проектов, вы — аналитик, который дополнительно выполняет функцию руководителя проекта. И вообще, что делать — неясно. 

Все просто, необходимо начать со следующих шагов:

1. Понять суть проекта и какие цели он преследует.

2. Сформулировать для кого проект, то есть определить ключевые заинтересованные стороны.

3. Определиться с финансированием, командой, сроками.

4. Зафиксировать ограничения, определиться с задачами и критериями их достижимости.

5. Понять риски и оценить работу с ними.

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

Что ещё может помочь.

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

Вы на одной странице подсвечиваете все ключевые артефакты проекта:

1. Название.

2. Описание проблемы и её решение.

3. Целевую аудиторию.

4. Рынок и конкурентов.

5. Преимущества вашего продукта.

6. Бизнес-модель, расходы, доходы и метрики.

7. Ключевую функциональность и экраны.

 Пример реализации One Page можно посмотреть по ссылке.

Для решения любой проблемы и проекта вам в помощь лучшие инструменты и универсальная визуализация.

К лучшим инструментам относятся:

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

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

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

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

3. Таск-трекеры — фундамент разработки, когда нужно управлять временем и задачами.

Основная решаемая проблема — рассеянная информация о статусе выполнения задач, нехватка единого места для мониторинга задач и их прогресса.

4. Базы знаний — сборник статей, создаваемых для обобщения информации по проекту.

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

5. Кроссплатформенные приложения для моделирования и подготовки графиков.

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

Универсальная визуализация:

1. BPMN (Business Process Modeling and Notation[СМВ15] ) - язык универсального описания, который поможет понятно смоделировать почти любой бизнес-процессов.

Основные решаемые проблемы:

• Непрозрачность бизнес-процессов внутри компании.

• Трудности в оптимизации существующих процессов и внедрение изменений.

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

Основные решаемые проблемы:

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

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

3. Wireframe (макеты интерфейса) — схемы визуализации системы с низким уровнем детализации.

Основные решаемые проблемы:

• Недостаточно точное понимание будущей структуры веб-сайтов или приложений.

• Недостаточная детализация расположения элементов интерфейса и навигационных путей.

4. Схемы экранов — описание того, какой экран какие функции должен выполнять.

Основные решаемые проблемы:

• Незнание оптимальной компоновки содержимого на экране, затрудняющее восприятие информации пользователями.

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

5. Диаграммы сценариев использования (Use Case Diagrams), когда мы описываем какой функционал какому пользователю должен быть доступен. Данный инструмент круто использовать для создания ролевых матриц, где группы пользователей буду являться ролями, а функции – операциями, входящими в состав ролей.

Основные решаемые проблемы:

• Нарушение целостности восприятия ключевых функций разрабатываемого продукта.

• Туманность требований заказчика или разработчиков к продукту.

6. ER-модель (Entity-Relationship model), то есть модель данных, позволяющая описать концептуальную схему предметной области для любого проекта.

Основные решаемые проблемы:

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

• Наличие дублирования данных и неопределенности в хранении информации.

Выводы:

1. Аналитик имеет возможность развить навыки руководителя проекта, осваивая ключевые функции этой роли, если проявляет интерес и стремление к такому профессиональному росту.

2. Используя широкий спектр универсальных инструментов — онлайн-доски для моделирования и постановки задач, таск-трекеры, системы баз знаний и кроссплатформенные решения для построения моделей и планирования графиков, аналитик способен успешно реализовывать проекты различной сложности. Универсальная визуализация процессов (BPMN-диаграммы, диаграммы последовательностей, макеты интерфейсов, ER-модели) позволяет наглядно представить идеи и концепции клиентам и команде.

3. One-page концепция является простым и эффективным инструментом для представления и продвижения любого проекта, позволяя лаконично и доступно описать его суть и преимущества.