Как управлять проектами 1С: практическое руководство

Управление проектом 1С — это не только контроль программистов. Это согласование бизнес-требований, управление изменениями, приёмка результата и сопровождение пользователей после запуска. Большинство провалов проектов связано не с качеством кода, а с размытыми требованиями, отсутствием ответственного со стороны заказчика и слабым контролем промежуточных этапов.

Под проектом 1С обычно понимают три типа работ: внедрение типового решения с нуля, переход на новую конфигурацию или версию, а также крупная доработка действующей системы. У каждого типа свои риски, но структура управления общая: фиксация целей, планирование, итерационная реализация, тестирование, запуск и стабилизация.

Материал ориентирован на руководителей проектов и владельцев бизнеса, которые заказывают работы у интегратора или управляют внутренней командой. Описанные приёмы применимы как к небольшим доработкам на 2–3 месяца, так и к внедрениям на десятки рабочих мест.

Как определить границы и цели проекта

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

Отдельно зафиксируйте, что в проект не входит. Список исключений защищает обе стороны: заказчик не ждёт лишнего, исполнитель не получает бесконечных «а сделайте ещё». Каждое новое пожелание в ходе проекта оформляйте как отдельное изменение с оценкой влияния на сроки и стоимость.

Определите измеримые критерии успеха: количество переведённых операций, доля документов, введённых в системе, время выполнения ключевых операций. Без таких критериев приёмка превращается в спор ощущений.

Какие роли должны быть в команде

Минимальный состав работающей команды: руководитель проекта, аналитик или методист, разработчик и ключевой пользователь со стороны заказчика. В малых проектах один человек может совмещать роли, но роль ключевого пользователя нельзя отдавать исполнителю — иначе некому будет принимать работу.

Ключевой пользователь — это сотрудник заказчика, который знает реальные бизнес-процессы и имеет полномочия отвечать на вопросы аналитика. Самая частая причина срыва сроков — аналитик неделями ждёт ответов на вопросы о том, как компания фактически оформляет возвраты или согласует цены. Назначьте такого человека официально и выделите ему рабочее время на проект.

Со стороны заказчика также нужен спонсор — руководитель, способный принимать решения по спорным вопросам и выделять ресурсы. Если все решения принимает только исполнитель, проект превращается в самоуправляемую разработку, результат которой редко совпадает с ожиданиями.

Как выбрать подход: типовое решение или доработка

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

Практическое правило: сначала проверьте, закрывает ли типовой функционал потребность хотя бы на 80–90%. Если да — проще изменить регламент работы, чем код. Дорабатывайте только то, что даёт измеримый эффект или требуется законодательно.

Сравнение подходов

Типовая конфигурация без изменений

Быстрый старт, дешёвые обновления. Ограничение: придётся подстроить процессы под логику программы.

Типовая + расширения конфигурации

Доработки вынесены в расширения, обновления проходят проще. Подходит для большинства проектов. Ограничение: не все механизмы доступны через расширения.

Глубокая доработка конфигурации

Максимальное соответствие процессам. Ограничение: дорогие обновления, зависимость от конкретных разработчиков, риск накопления ошибок.

Как планировать этапы и контролировать сроки

Разбивайте проект на этапы продолжительностью 2–6 недель, каждый из которых завершается видимым результатом: согласованное техническое задание, работающий прототип, готовый блок функционала, перенесённые данные. Этап «разработка идёт» без промежуточного результата — признак потери контроля.

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

Контролируйте проект короткими регулярными встречами: еженедельный статус с фиксацией сделанного, планов и блокирующих вопросов. Требуйте демонстрации работающего функционала, а не только словесных отчётов — в 1С показать результат можно почти всегда.

1. 1
   Согласуйте с исполнителем перечень задач этапа и критерии приёмки каждой
2. 2
   Получите оценку трудоёмкости и сроков в письменном виде
3. 3
   Назначьте тестировщика со стороны заказчика на время завершения этапа
4. 4
   Примите работу по критериям, зафиксируйте замечания списком с приоритетами
5. 5
   Только после устранения критичных замечаний подписывайте акт этапа

Как организовать тестирование и приёмку

Тестирование на реальных сценариях — обязательная часть проекта. Составьте тест-кейсы из повседневных операций: провести документ, закрыть месяц, сформировать регламентированный отчёт, выполнить обмен с другой системой. Каждый кейс должен иметь ожидаемый результат, с которым сравнивается фактический.

Тестируйте на копии рабочей базы или на данных, максимально близких к реальным. Тесты на трёх тестовых документах не выявляют проблемы производительности и ошибки в обменах, которые всплывают на полном объёме данных.

Опытная эксплуатация — период, когда ограниченная группа пользователей работает в новой системе параллельно со старой или на выделенном участке. Это последний рубеж защиты: ошибки, найденные здесь, исправляются дёшево, после полного запуска — дорого и болезненно.

Контрольные точки

Как проверить готовность к запуску

Перенос данных

Норма

Остатки и справочники в новой системе сходятся со старой по контрольным отчётам

Тревожный признак

Расхождения списываются на «особенности округления» без анализа

Ключевые операции

Норма

Все тест-кейсы пройдены, критичные замечания закрыты

Тревожный признак

Запуск планируется с известными ошибками в основных операциях

Пользователи

Норма

Пользователи обучены и выполнили свои операции в тестовой базе

Тревожный признак

Пользователи увидят систему впервые в день запуска

Типичные ошибки и риски

Самая дорогая ошибка — начинать разработку до согласования требований. Доработка, сделанная «как поняли», переделывается за счёт сроков и нервов обеих сторон. Вторая по ущербу ошибка — отсутствие резервных копий и тестовой среды: любая доработка сначала разворачивается на копии, и только после проверки переносится в рабочую базу.

Что делать после запуска

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

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

Частые вопросы

Можно ли вести проект 1С без технического задания?

Формально можно, но риски несёт заказчик. Без ТЗ невозможно объективно принять работу и оспорить перерасход бюджета. Минимальная замена полноценному ТЗ — постановка задач по каждой доработке с описанием сценария и ожидаемого результата.

Как понять, что смета исполнителя завышена?

Попросите детализацию по задачам с оценкой в часах и обоснованием сложности. Завышенные позиции обычно не выдерживают вопроса «что именно входит в эту оценку». Для крупных проектов имеет смысл получить альтернативную оценку у независимого специалиста.

Что делать, если проект застрял на этапе согласования требований?

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

Нужно ли обучать пользователей до запуска?

Да, и практически, а не лекцией. Каждый пользователь должен самостоятельно выполнить свои типовые операции в тестовой базе. Пользователи, впервые увидевшие систему в день запуска, — главный источник аврала первой недели.

Как контролировать проект, если я не разбираюсь в 1С технически?

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

Когда проект считается завершённым?

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