Содержание:
2. Недооценка предпроектного обследования системы
3. Игнорирование управления ожиданиями клиента
4. Слабое управление командой разработки
5. Реализация изменений в проекте
6. Недостаток знаний в области возможностей и ограничений типовых конфигураций системы
7. Некачественное тестирование и передача проекта в работу
8. Роль руководителя проекта
Руководитель проекта в ИТ и, конечно, в сфере внедрения 1С — ключевая фигура в команде. От руководителя проекта зависит не только успех самого проекта в целом, но и впечатления клиента от внедряемого функционала и от компании-интегратора. Начинающие РП часто совершают типичные ошибки, которые могут привести к затягиванию сроков, перерасходу бюджета и конфликтам с клиентом. Давайте рассмотрим ошибки, которые чаще всего совершают начинающие специалисты. Возможно, этот текст поможет вам их избежать в процессе изучения профессии и настройки функционала.
1. Неясная цель предлагаемого проекта
Одна из самых критичных ошибок — начать проект без четко зафиксированной цели. Формулировка типа «внедрить 1С: УНФ» или «перейти с Excel на 1С» — не цель. Цель должна быть измеримой и понятной:
«В течение 3 месяцев перевести учет продаж и закупок в 1С: УНФ с минимальной остановкой бизнес-процессов».
Если при общении с клиентом вы не понимаете, чего же хочет клиент – переспросите. Не получается устно выяснить, что же хочет клиент – попробуйте решить вопрос письменно. Например: подготовьте подробное описание решения и отправьте клиенту на согласование.
2. Недооценка предпроектного обследования системы
Многие РП спешат начать внедрение, чтобы быстрее показать результат коллегам и клиенту. Не торопитесь. Продумайте и обговорите все моменты, изучите текущие процессы клиента. «Сюрпризы», которые выясняются уже в ходе выполнения работы, не порадуют ни вас, ни команду, ни самого клиента. Вы же не хотите столкнуться с неучтёнными схемами работы, нестандартной логикой или отсутствием первичных документов.
Поэтому, уделите время полноценному проектному обследованию (интервью, сбор документов, анализ текущих регламентов), и только потом — ставить задачи на настройку и доработку.
Конечно, даже полноценный разбор всех бизнес-процессов заказчика не дает 100% гарантии, что где-то в середине работы вас не ожидает «неприятный сюрприз», но, по крайней мере, таких негативных моментов будет намного меньше.
3. Игнорирование управления ожиданиями клиента
Начинающие РП часто не фиксируют договоренности в письменном виде. Клиент запоминает устные обещания, а потом требует их реализации без дополнительной оплаты. Или — ожидает невозможное в рамках базовой конфигурации. Нет гарантии, что на слух клиент понял вас правильно. Он мог и просто не понять, и принять желаемое за действительное.
После телефонного звонка или проведения совещания с несколькими участниками, всегда фиксируйте, что обсуждалось и к какому итогу пришли. И отправляйте этот протокол встречи всем участникам совещания, плюс указывайте дату, когда это совещание проходило.
4. Слабое управление командой разработки
Часто начинающий РП либо не контролирует разработчиков и аналитиков, либо делает это слишком формально (одним сообщением в мессенджере). В итоге задачи висят неделями, а сам руководитель узнает о проблеме от клиента.
Чтобы избежать таких ситуаций, не надейтесь на память. Всегда фиксируйте все задачи, а также ожидаемые по ним сроки исполнения в системе учета задач (Jira, Trello, ПланФикс, Bitrix24). В вашей компании наверняка уже внедрено какое-то ПО из этого списка.
Кроме этого, ведите ежедневный/еженедельный контроль прогресса. А так же, обеспечивайте прозрачность: заказчик должен видеть текущий статус проекта.
Даже если что-то пойдет не так – заказчик узнает об этом заранее, а не в те сроки, когда он уже ожидает увидеть готовый функционал.
5. Реализация изменений в проекте
Изменения в проекте неизбежны: клиент захотел новую форму, бизнес-процесс изменился, бухгалтер уволился. Возможно множество самых разнообразных причин, которые повлекут за собой изменения в проекте. Новички либо соглашаются на любые изменения бесплатно, либо конфликтуют с клиентом. Каждый из вариантов не самый желательный.
Поможет обойти эту проблему механизм фиксации изменений: реестр изменений, где будет указано, что изменилось относительно первоначального плана и когда и с кем это было согласовано. При этом важно обязательно объяснять клиенту, что любая правка влияет на сроки и бюджет проекта.
6. Недостаток знаний в области возможностей и ограничений типовых конфигураций системы
Если РП не знает, что делает конкретная подсистема 1С, как работает распределение расходов или учет серий, он не может корректно спланировать работы и оценить риски. Это ведет к постоянным доработкам и провалам по срокам.
Если вы планируете работать с той или иной конфигурацией, обязательно изучите предварительно ее структуру конфигурации, принципы работы ключевых блоков. А в идеале хорошо, если у вас есть опыт настройки типовых механизмов и понимание, когда нужна доработка, а когда можно обойтись настройкой.
7. Некачественное тестирование и передача проекта в работу
Плохое тестирование — один из главных источников проблем после запуска. Начинающие РП часто передают проект на продуктивный контур без чек-листа, не обеспечив ни регламентов, ни обучения пользователей. При таком раскладе велик шанс срыва сроков внедрения и поток обращений в поддержку.
Перед тем как сдать проект, нужно:
- Делать финальное тестирование по сценарию, согласованному с заказчиком;
- Обучать пользователей, передавать инструкции;
- Проводить запуск в режиме опытной эксплуатации.
8. Роль руководителя проекта
Хороший РП в 1С — это не просто координатор. Это человек, который одновременно понимает бизнес заказчика, знает продукт и управляет процессами внедрения. Избегая типичных ошибок, вы укрепите доверие клиента, упростите работу команде и сэкономите десятки часов на доработки и исправления.
Специалист компании ООО "Кодерлайн"
Марина Анапольская