Содержание:

Руководитель проекта в ИТ и, конечно, в сфере внедрения 1С — ключевая фигура в команде. От руководителя проекта зависит не только успех самого проекта в целом, но и впечатления клиента от внедряемого функционала и от компании-интегратора. Начинающие РП часто совершают типичные ошибки, которые могут привести к затягиванию сроков, перерасходу бюджета и конфликтам с клиентом. Давайте рассмотрим ошибки, которые чаще всего совершают начинающие специалисты. Возможно, этот текст поможет вам их избежать в процессе изучения профессии и настройки функционала.

1.    Неясная цель предлагаемого проекта

Одна из самых критичных ошибок — начать проект без четко зафиксированной цели. Формулировка типа «внедрить 1С: УНФ» или «перейти с Excel на 1С» — не цель. Цель должна быть измеримой и понятной:
«В течение 3 месяцев перевести учет продаж и закупок в 1С: УНФ с минимальной остановкой бизнес-процессов».

Если при общении с клиентом вы не понимаете, чего же хочет клиент – переспросите. Не получается устно выяснить, что же хочет клиент – попробуйте решить вопрос письменно. Например: подготовьте подробное описание решения и отправьте клиенту на согласование.

2.    Недооценка предпроектного обследования системы

Многие РП спешат начать внедрение, чтобы быстрее показать результат коллегам и клиенту. Не торопитесь. Продумайте и обговорите все моменты, изучите текущие процессы клиента. «Сюрпризы», которые выясняются уже в ходе выполнения работы, не порадуют ни вас, ни команду, ни самого клиента. Вы же не хотите столкнуться с неучтёнными схемами работы, нестандартной логикой или отсутствием первичных документов.

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

Конечно, даже полноценный разбор всех бизнес-процессов заказчика не дает 100% гарантии, что где-то в середине работы вас не ожидает «неприятный сюрприз», но, по крайней мере, таких негативных моментов будет намного меньше.

3.    Игнорирование управления ожиданиями клиента

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

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

4.    Слабое управление командой разработки

Часто начинающий РП либо не контролирует разработчиков и аналитиков, либо делает это слишком формально (одним сообщением в мессенджере). В итоге задачи висят неделями, а сам руководитель узнает о проблеме от клиента.

Чтобы избежать таких ситуаций, не надейтесь на память. Всегда фиксируйте все задачи, а также ожидаемые по ним сроки исполнения в системе учета задач (Jira, Trello, ПланФикс, Bitrix24). В вашей компании наверняка уже внедрено какое-то ПО из этого списка.

Кроме этого, ведите ежедневный/еженедельный контроль прогресса. А так же, обеспечивайте прозрачность: заказчик должен видеть текущий статус проекта.

Даже если что-то пойдет не так – заказчик узнает об этом заранее, а не в те сроки, когда он уже ожидает увидеть готовый функционал.  

5.    Реализация изменений в проекте

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

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

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

Если РП не знает, что делает конкретная подсистема 1С, как работает распределение расходов или учет серий, он не может корректно спланировать работы и оценить риски. Это ведет к постоянным доработкам и провалам по срокам.

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

7.    Некачественное тестирование и передача проекта в работу

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

Перед тем как сдать проект, нужно:

• Делать финальное тестирование по сценарию, согласованному с заказчиком;
• Обучать пользователей, передавать инструкции;
• Проводить запуск в режиме опытной эксплуатации.

8.    Роль руководителя проекта

Хороший РП в 1С — это не просто координатор. Это человек, который одновременно понимает бизнес заказчика, знает продукт и управляет процессами внедрения. Избегая типичных ошибок, вы укрепите доверие клиента, упростите работу команде и сэкономите десятки часов на доработки и исправления.

Специалист компании ООО "Кодерлайн"

Марина Анапольская