Опасности совмещения ролей в проекте: аналитик и руководитель проекта
В современных IT-компаниях часто встречаются случаи совмещения ролей в команде. Это происходит не только в небольших компаниях, где очевидны ресурсные ограничения, но и в крупных. Казалось бы естественным разделить роли в команде для повышения эффективности. Однако, потребность в аналитике растет, и часто на проектах можно встретить специалиста, совмещающего аналитика и руководителя проекта (PM). А в продуктовых компаниях такое совмещение перерастает в отдельную должность - Product owner.
В статье мы рассмотрим причины возникновения такого явления и ошибки, которые необходимо избежать, если вы практикуете или только планируете подобное совмещение.
Зоны ответственности
Аналитик - управляет информацией;
PM - ответственный за управление проектом.
В стандартном проекте оба специалиста участвуют на всех его этапах: от предпродажной подготовки до внедрения.
Рис. 1 — Этапы проектаПри этом аналитик по отношению к PM относится к внутренним сотрудникам проекта:
Рис. 2 — Проектная командаОбе роли несут четко определенные ответственности:
Ответственность PM
- РЕЗУЛЬТАТ - достижение целей проекта, разработанные решения проблем;
- БЮДЖЕТ - соблюдение установленных рамок расходов;
- СРОКИ - соблюдение графика времени.
Ответственность аналитика
- КАЧЕСТВО ТРЕБОВАНИЙ - извлечение, формализация, управление, передача требований;
- КОММУНИКАЦИЯ - командная работа и отношение с клиентом;
- ОЦЕНКА И СРОКИ - соблюдение установленных трудозатрат аналитики.
Основные причины совмещения ролей:
- Финансы - сокращение финансовых расходов;
- Операционное управление - задачи координируются быстрее;
- Принятие решений - решения принимаются быстрее.
Бонусом можно выделить заимствование опыта и быстрый профессиональный рост специалиста, который в одних проектах совмещает роли, а в других исполняет их по отдельности: как аналитик перенимаешь опыт PM’а, и наоборот.
9 ошибок совмещения ролей
Я готов взять еще один проект!
Ожидание: у тебя, как у аналитика, завершается один проект, и тебе дают новый, где ты аналитик и PM одновременно.
Реальность: Соотношение общение/администрирование:
PM: 70% / 30%
Аналитик: 30% / 70%
Вывод: был один проект, стало два.
Стремление к совершенству
Ожидание: аналитик генерирует новые идеи и функционал, которые улучшили бы систему.
Реальность: чтобы вписаться в бюджет, часть функционала нужно исключить.
Вывод: сосредоточиться на релизе определенной версии, удовлетворяющей требованиям и бюджета и бизнеса клиента.
Не детализировать ТЗ
Ожидание: я быстрее объясню все разработчикам и не буду тратить время на детализацию ТЗ. Достаточно подробного прототипа.
Реальность: высокие требования к администрированию и управлению. Не все в команде поймут задумки с полуслова.
Вывод: грамотная документация – это четко поставленные задачи, которые нужно держать в голове всей команды. Разработчик должен уметь продуктивно использовать ТЗ, а не постоянно спрашивать аналитика.
Частое переключение между проектами
Ожидание: быстрый темп разработки и ведение нескольких проектов требуют постоянного переключения.
Реальность: рваная загрузка; сложно оценивать свою производительность; сложно переключаться; страдает менеджмент и администрирование.
Вывод: Нужно внедрить:
- Календарь мероприятий;
- Приоритезация;
- Выделение ограниченного объема времени на свои задачи;
- Сокращение количества проектов
Передавать право принятия решений
Ожидание: аналитик часто советуется с разработчиками о возможных решениях в проекте.
Реальность: аналитик спрашивает команду, советуется, уточняет технические вопросы. Если роль аналитика преобладает, то его авторитет как PM’а падает.
Вывод:
- Решения по проекту принимает PM;
- Решения должны нести волевой характер;
- Публично роль аналитика включается кратковременно.
Не делиться всей информацией
Ожидание: как руководитель ты концентрируешь всю информацию у себя и не делишься с командой, компенсируя стремление удержать власть.
Реальность:
- Если ты заболеешь или уволишься, другие члены команды не владеют всей информацией;
- Время на передачу информации и контакты;
- Недостатки переключения между проектами
Вывод: у команды должна быть вся информация для самостоятельной работы. Плановые митинги по схеме: апдейты, статусы, вопросы и проблемы.
Оптимистичная оценка своих трудозатрат
Ожидание: как PM я оцениваю свою роль аналитика в проекте слишком оптимистично.
Реальность: рваная загрузка; нарушение сроков и трудозатрат.
Вывод: закладывать запас по срокам.
Исполнять обязанности QA
Ожидание: выполняя две роли и неся ответственность за качество проекта, включаешься в процесс приемки и проверяешь не только за разработчиками, но и за QA.
Реальность:
- Понижение компетенции QA в глазах команды и его демотивация;
- Перерасход бюджета;
- Переработка
Вывод: разделение обязанностей: если обнаружен баг, пропущенный QA, то сообщить ему об этом лично
Переработка
Ожидание: осознавая свою значимость и ответственность, ты считаешь необходимым больше работать.
Реальность:
- Ухудшение здоровья;
- Профессиональное выгорание;
- Ошибки администрирования и управления;
- Необходимость для компании оплачивать твои переработки.
Вывод:
- 40 часовая рабочая неделя;
- Компенсация переработок отдыхом;
- Обязательный отпуск!
Итого: как распределяем роли
Известно среднее количество проектов, которые одновременно может вести аналитик либо PM в одной роли:
Аналитик
- 1-2 крупных проекта по 5-10 человек;
- 2-4 средних проекта по 2-5 человек.
PM
- 2-3 крупных проекта по 5-10 человек;
- 3-5 средних проекта по 2-5 человек.
Что касается совмещения ролей, то таких проектов должно быть в 2 раза меньше:
- 1 крупный проект по 5-10 человек;
- 2 средних проекта по 2-5 человек.
В статье представлен личный опыт и знания автора. Возможно, эти знания помогут вам избежать серьезных проблем с совмещением.
