Роли, определяющие темп проекта
В проекте Salesforce можно нанять выдающегося архитектора, опытную команду разработчиков и организованного менеджера проекта, но все равно отстать от графика. Частая причина — не скорость разработки, а скорость принятия решений. Разработка ждет решения, решение ждет встречи, а встреча ждет своей даты в календаре.
Поэтому полезное распределение ролей определяется не тем, кто что делает, а тем, кто что решает и с какой скоростью реакции. Обзор этапов, на которых требуется каждая роль, представлен в Руководстве по внедрению Salesforce.
Девять ролей и полномочия каждой
Executive Sponsor — разрешает конфликты между отделами, утверждает уступки по объему работ (Scope) и защищает приоритеты от параллельного давления. Если у него нет бюджетных полномочий, он не Executive Sponsor, а представитель.
Владелец процесса — определяет, как работа будет выполняться на деле после изменений, и подтверждает соответствие построенного процесса реальности. Один владелец на каждый ключевой процесс, а не комитет.
Product Owner / CRM-менеджер — управляет приоритетами в бэклоге, разрешает конкурирующие запросы и поддерживает связь между требованиями и ценностью.
Менеджер проекта — отвечает за график, взаимозависимости, риски, координацию поставщиков и отчетность.
Архитектор решения — принимает решения по модели данных, разрешениям, границам системы и способу реализации; обязан документировать рассмотренные альтернативы.
Salesforce Admin — конфигурация, среды, управление пользователями и текущее обслуживание после запуска.
Разработчик — кастомизированная логика, интеграции, автоматизированное тестирование.
Владелец данных — определяет источник истины, критерии корректной записи и кто одобряет загрузку.
Лидер по внедрению и обучению — коммуникации, ролевое обучение, управление сопротивлением и измерение использования.
В небольшом проекте один человек может выполнять две роли, но есть две пары, которые не следует объединять: архитектор и менеджер проекта (конфликт между тщательностью и скоростью), а также владелец процесса и лидер тестирования (проверяет сам себя).
Кто должен быть внутренним специалистом
| Роль | Может быть внешним поставщиком | Пояснение |
|---|---|---|
| Executive Sponsor | Нет | Требует организационных полномочий |
| Владелец процесса | Нет | Требует владения реальной работой |
| Владелец данных | Нет | Требует регуляторной и бизнес-ответственности |
| Product Owner | Частично | Возможно сопровождение, но не замена |
| Менеджер проекта | Да | Часто и приемлемо |
| Архитектор решения | Да | Желательно с внутренней поддержкой для передачи знаний |
| Admin | Да, временно | Предпочтительно передать внутреннему специалисту до Go Live |
| Разработчик | Да | Стандартно |
| Лидер по внедрению | Частично | Внутренние коммуникации должны исходить от организации |
Таблица RACI для ключевых точек принятия решений
| Решение | Ответственный (Accountable) | Консультируемый (Consulted) | Требуемое время реакции |
|---|---|---|---|
| Структура модели данных | Архитектор | Владелец процесса, Владелец данных | До одной недели |
| Изменение в объеме работ (Scope) | Executive Sponsor | Product Owner, Менеджер проекта | До одной недели |
| Приоритеты в бэклоге | Product Owner | Владельцы процессов | До двух дней |
| Определение обязательного поля | Владелец процесса | Admin | До двух дней |
| Утверждение загрузки данных | Владелец данных | Архитектор | До трех дней |
| Утверждение перехода в продакшн | Executive Sponsor | Менеджер проекта, Владелец процесса | По установленному регламенту |
| Разрешение блокирующей проблемы | Менеджер проекта | Архитектор, Admin | В тот же день |
Столбец "Требуемое время реакции" — самая интересная часть таблицы. RACI без SLA на принятие решений — это приятное описание, которое не меняет темп.
Реальная доступность — повторяющаяся ошибка в планировании
| Роль | Этап анализа требований | Этап разработки | Этап тестирования | Go Live и последующие недели |
|---|---|---|---|---|
| Executive Sponsor | Низкая, постоянная | Низкая | Средняя | Средняя |
| Владелец процесса | Высокая | Средняя | Очень высокая | Высокая |
| Product Owner | Высокая | Высокая | Высокая | Средняя |
| Admin | Средняя | Высокая | Высокая | Очень высокая |
| Владелец данных | Средняя | Низкая | Высокая | Средняя |
| Лидер по внедрению | Низкая | Средняя | Средняя | Очень высокая |
Распространенная ошибка планирования заключается в предположении, что нагрузка на владельца процесса снижается после этапа анализа требований. На самом деле она снова возрастает на этапе тестирования, именно тогда, когда сотрудник возвращается к своей повседневной работе.
Пример для иллюстрации: академический колледж
Сценарий гипотетический и предназначен для иллюстрации. Колледж внедрил систему управления абитуриентами. Команда была правильно определена на бумаге, но "владелец процесса" был руководителем отдела регистрации, который мог уделять проекту лишь два часа в неделю. Любой вопрос о статусе абитуриента ждал до утра вторника.
Через два месяца было установлено, что совокупная задержка в ожидании решений превысила задержки по всем остальным причинам вместе взятым. Решением не стало привлечение дополнительных разработчиков. Колледж назначил заместителя, которому был предоставлен явный мандат на принятие ежедневных решений до определенного уровня влияния, оставив руководителю отдела только решения, меняющие политику. Темп разработки увеличился без изменения численности команды поставщика.
Модель работы с поставщиком
Для большинства проектов достаточно трех механизмов:
- Совместный журнал решений — каждое решение с датой, ответственным, обоснованием и отклоненными альтернативами. Это единственная документация, которая остается полезной спустя два года.
- Единая точка контакта с обеих сторон — многочисленные прямые обращения участников к разработчикам являются верным способом потерять отслеживаемость.
- Циклические демонстрации с фиксированным ритмом — владелец процесса видит работающий продукт, а не презентацию. Разрыв между ожиданиями и реализацией выявляется за две недели вместо двух месяцев.
В крупных организациях требуется дополнительный уровень управления между бизнес-подразделениями, как описано в Руководстве по внедрению Salesforce на предприятиях.
Точки соприкосновения с другими этапами
Состав команды непосредственно зависит от двух факторов: результатов, необходимых на этапе анализа требований, подробно описанных в Руководстве по CRM-диагностике, и объема первой волны внедрения, который определяется правилами, приведенными в Руководстве по определению MVP. Более узкая первая волна требует меньшего количества владельцев процессов одновременно, что является самостоятельной причиной для уменьшения ее ширины.
Быстрая проверка перед началом проекта
Ответьте на четыре вопроса, используя имя и фамилию человека, а не название отдела: кто принимает решение, когда продажи и операционная деятельность не приходят к согласию; кто подтверждает, что построенный процесс соответствует реальности; кто говорит, какие данные достоверны; и кто будет поддерживать систему через год. Отсутствие ответа на один из этих вопросов — это самый большой риск в проекте, и это единственный риск, который нельзя решить деньгами.