Как интерпретировать данный перечень
Десять ошибок, представленных ниже, упорядочены не по частоте их возникновения, а по последовательности появления на временной шкале проекта. Для каждой ошибки указаны три ключевых аспекта: ранний признак, который можно выявить в реальном времени; превентивное действие; и этап, после которого корректировка значительно удорожается. Основная идея проста — практически каждая из этих ошибок обходится очень недорого, если устранить её в течение двух подходящих недель.
1. Начало с перечня функций вместо процесса
Признак: Документ требований структурирован как таблица желаемых возможностей, но ни одна строка не описывает бизнес-результат.
Фактическое развитие событий: Проект создает систему, соответствующую списку функций, но не меняет способ работы. Год спустя руководство спрашивает, что изменилось, и не получает измеримого ответа.
Предотвращение: Каждое требование связывается с процессом, который оно обслуживает, и с метрикой, которая должна измениться. Требование, не отвечающее на эти два вопроса, переносится в лист ожидания. Перечень артефактов, предотвращающих данную ситуацию, подробно описан в руководстве по анализу требований CRM.
2. Отсутствие единого владельца процесса
Признак: На совещания приходят четыре сотрудника из одного отдела, и ни один из них не уполномочен сказать: «Так будет сделано».
Фактическое развитие событий: Каждое решение принимается в компромиссной форме, пытаясь угодить всем, что приводит к созданию двух параллельных путей вместо одного. Система становится вдвое сложнее, чем необходимо.
Предотвращение: За каждым процессом закрепляется имя одного человека. Рекомендованное распределение ролей подробно описано в руководстве по ролям в проекте Salesforce.
3. Откладывание архитектурных решений на потом
Признак: Команда активно разрабатывает экраны, тогда как вопрос «каков источник истины для данных о клиенте» остается открытым.
Фактическое развитие событий: Когда решение наконец принимается, оно противоречит уже реализованному. Часть работы оказывается бесполезной, и первоначальная оценка проекта теряет актуальность.
Предотвращение: В начале проекта определяются три-пять решений, изменение которых будет дорогостоящим – основная модель данных, источник истины, модель разрешений – и назначается дата их принятия до начала разработки.
4. Импорт задолженностей старой системы
Признак: Спецификация миграции включает все поля из предыдущей системы, в том числе те, названия которых заканчиваются на «_old_2».
Фактическое развитие событий: Новая платформа запускается с двумя сотнями полей, которые никто не поддерживает, отчетами, основанными на недостоверных данных, и пользователями, которые делают вывод, что новая система также несерьезна.
Предотвращение: Каждое переносимое поле должно иметь владельца и подтвержденное использование за последний год. Остальные данные переносятся в читаемый архив, а не в действующую систему.
5. Измерение прогресса по закрытым историям
Признак: Еженедельный отчёт показывает высокий процент завершения, но никто ещё не смог выполнить полный сквозной процесс.
Фактическое развитие событий: Проект выглядит успешным на графиках до недели перед запуском, а затем выясняется, что все части работают по отдельности, и никто не проверял их интеграцию.
Предотвращение: Определяется веха «первый сквозной действующий процесс» как можно раньше, даже если он охватывает только один сценарий. До её достижения проценты завершения не являются информативными.
6. Обязательные поля как замена дисциплины данных
Признак: Экран создания записи включает двенадцать обязательных полей, из которых по трём никто не знает, кто должен указывать их значения.
Фактическое развитие событий: Пользователи выбирают первое значение в списке, чтобы продолжить. Отчеты получают полностью заполненные, но при этом абсолютно неверные данные.
Предотвращение: Требования обязательности применяются только к полю, необходимому для принятия решения в момент его запроса. Поля, которые требуются на более поздних этапах процесса, становятся обязательными на этих этапах.
7. Создание автоматизации до стабилизации процесса
Признак: Существуют три механизма автоматизации, работающие с одним и тем же объектом, и никто не знает порядок их выполнения.
Фактическое развитие событий: Непредвиденные побочные эффекты, циклы обновлений и, главное, невозможность изменить процесс без опасения что-либо нарушить.
Предотвращение: Ручной или полуавтоматический процесс выполняется в течение нескольких недель, прежде чем он будет полностью автоматизирован. Автоматизация фиксирует решение — важно, чтобы это решение было верным.
8. UAT, выполняемое теми, кто разрабатывал систему
Признак: Сценарии тестирования были написаны той же командой, что и вела разработку, и они охватывают в основном штатный ход событий.
Фактическое развитие событий: Проблемы, возникающие в производстве, как правило, связаны с исключительными случаями — отмены, возвраты, дублирование клиентов, пользователь, покинувший процесс на полпути.
Предотвращение: Тестирование выполняется сотрудниками, участвующими в процессе, на данных, максимально приближенных к реальным, с чётко определённой ответственностью за утверждение или отклонение результатов.
9. Обучение как разовое мероприятие
Признак: План внедрения включает два семинара за неделю до запуска, и после этого ничего не запланировано.
Фактическое развитие событий: Пользователи изучают экраны, а не процессы, забывают информацию в течение двух недель и обращаются к коллегам или к таблицам Excel. Уровень использования постепенно снижается, оставаясь незамеченным.
Предотвращение: Обучение по ролям, максимально приближенное к моменту, когда сотрудник фактически будет выполнять действия, с доступной точкой поддержки в первые недели.
10. Отсутствие владельца после запуска в продуктив
Признак: В плане проекта отсутствует пункт, описывающий, кто будет управлять системой на третий месяц.
Фактическое развитие событий: Запросы на изменения копятся без ответа, мелкие неполадки становятся обходными рабочими процедурами, и система быстро устаревает.
Предотвращение: Операционное владение, механизм обработки запросов и регулярный цикл выпуска обновлений определяются до запуска, а не после. В крупных организациях это обычно осуществляется через структурированную модель управления, как описано в руководстве по внедрению Salesforce в корпоративной среде.
Стоимость корректировки в зависимости от стадии
| Ошибка | Корректировка на этапе спецификации | Корректировка на этапе разработки | Корректировка после запуска в продуктив |
|---|---|---|---|
| Неверная модель данных | Изменение в схеме | Повторная разработка объекта | Внутренняя миграция и полное повторное тестирование |
| Отсутствие владельца процесса | Назначение | Остановка и повторные решения | Поддержка двойного процесса бесконечно |
| Задолженность от старой системы | Фильтрация списка полей | Очистка перед загрузкой | Очистка в действующей системе |
| Лишние обязательные поля | Решение на этапе проектирования интерфейса | Изменение конфигурации | Очистка накопленных некорректных данных |
| Отсутствие операционного владельца | Определение в плане | Наём или обучение | Восстановление доверия пользователей |
Пример для иллюстрации: Средняя страховая компания
Сценарий гипотетический и предназначен для иллюстрации. Страховая компания запустила Salesforce для управления агентами. Через три месяца выяснилось, что процент обновления записей агентов низок. Проверка не выявила ни одной технической неисправности: одновременно были обнаружены три из вышеуказанных ошибок — излишние обязательные поля в экране создания, отсутствие владельца процесса найма агентов и обучение, проведенное за два месяца до того, как первые новые агенты начали работать с системой.
Коррекция не была технической. Удалены шесть обязательных полей, назначен единый владелец процесса из операционного отдела, и обучение разделено на короткие сегменты, рассылаемые в течение недели, когда каждая группа приступала к работе. Единственное необходимое архитектурное изменение заключалось в отсрочке обязательности двух полей до более позднего этапа процесса.
Что делать с этим списком
Просмотрите десять ошибок и для каждой из них отметьте, существует ли у вас сейчас соответствующий ранний признак. Три или более признаков в проекте, который ещё не запущен, являются поводом для кратковременной остановки и корректировки, а не для ускорения. Те же три признака в уже работающей системе оправдывают тщательную диагностику, прежде чем добавлять новые возможности поверх нестабильной основы.