Урок 2 из 8 · 20 мин · обновлено
Как устроен проект внедрения 1С: этапы и роли
Как создают и внедряют программы: этапы проекта от обследования до сопровождения, чем последовательный подход отличается от гибкого, кто работает в проекте 1С — заказчик, ключевые пользователи, руководитель проекта, аналитик, разработчик, тестировщик — и где в этом аналитик.
Как создают программы
Любая программа проходит похожий путь: понять задачу, спроектировать решение, сделать, проверить, научить людей и поддерживать. В мире 1С чаще говорят не «разработка», а внедрение: обычно берут типовую конфигурацию и настраивают и дорабатывают её под компанию.
Этапы проекта внедрения
- Обследованиекак сейчас
- Проектированиекак будет, требования
- Разработканастройка и доработки
- Тестированиеи обучение
- Запуски сопровождение
- Обследование — изучить, как компания работает сейчас: процессы, документы, проблемы.
- Проектирование — описать, как будет: процессы «как будет», требования, техническое задание.
- Разработка и настройка — включить нужные возможности типовой конфигурации, сделать доработки, перенести данные.
- Тестирование и обучение — проверить, что всё работает по требованиям, научить пользователей.
- Опытная эксплуатация и сопровождение — работа в новой системе сначала под присмотром команды проекта, потом — поддержка и развитие.
Выделенные этапы — главная зона аналитика. Но он нужен и дальше: отвечает разработчикам на вопросы, проверяет результат, помогает с обучением.
Два подхода к проекту
- Последовательный («водопад») — сначала всё обследовать и описать, согласовать техническое задание, потом делать. Подходит, когда задача понятна и меняться не будет: например, переход на новую типовую конфигурацию с чётким набором участков.
- Гибкий — делать короткими циклами по 2–4 недели: описали небольшую часть, сделали, показали пользователям, поправили. Подходит, когда требования уточняются по ходу.
На практике в проектах 1С часто смешивают: общий план и ключевые требования — заранее, детали — по ходу работы.
Кто работает в проекте
Со стороны заказчика:
- спонсор — руководитель, который платит за проект и принимает главные решения;
- ключевые пользователи — опытные сотрудники, которые лучше всех знают свой участок: главный бухгалтер, руководитель склада. Они рассказывают, как всё устроено, и принимают результат.
Со стороны исполнителя — партнёра 1С или внутреннего IT-отдела:
- руководитель проекта — сроки, бюджет, договорённости;
- аналитик или консультант — процессы, требования, настройка типовых возможностей;
- разработчик — доработки конфигурации;
- тестировщик — проверка; в небольших проектах это делает аналитик.
Цена ошибки
Ошибку в требованиях, найденную на этапе проектирования, исправляют одной строкой в документе. Та же ошибка после запуска — это переделка кода, новые тесты, исправление уже введённых данных и переобучение людей. Поэтому основная ценность аналитика — найти недопонимание до того, как начали делать.
Попробуйте сами. «ДомТорг» переходит на новую типовую конфигурацию для торговли. Распределите действия по этапам проекта: обучение менеджеров работе с заказами; интервью с руководителем склада; перенос остатков из старой программы; описание процесса возврата товара «как будет»; ответы на вопросы пользователей в первый месяц работы.
Решение
- Интервью с руководителем склада — обследование.
- Описание процесса возврата «как будет» — проектирование.
- Перенос остатков из старой программы — разработка и настройка: подготовка данных к запуску.
- Обучение менеджеров — тестирование и обучение.
- Ответы на вопросы в первый месяц — опытная эксплуатация и сопровождение.
Аналитик так или иначе участвует во всех пяти действиях, но первые два — его главная работа.
Мини-тест: проверьте себя
Закрепите урок: несколько вопросов, разбор ответов — в конце.
-
На каком этапе аналитик выясняет, как сейчас работает компания?
Обследование — первый этап проекта: интервью, документы, наблюдение за работой. От него зависит всё остальное.
-
Кто такие ключевые пользователи?
Ключевой пользователь — главный источник знаний о процессе и тот, кто подтверждает: «да, так нам удобно».
-
Почему ошибку в требованиях выгоднее найти до разработки?
Чем позже найдена ошибка, тем больше работы приходится переделывать: код, тесты, инструкции, данные.