← На главную
Когда разработчик переходит из франчайзи на фиксированную ставку или берется за реализацию отдельной крупной подсистемы, перед ним встает задача самостоятельного ведения проекта без выделенного руководителя проекта (РП). Рассмотрим пошаговый подход к организации работы над небольшим проектом в 1С: от выявления реальных потребностей заказчика до проектирования архитектуры и запуска в эксплуатацию.
1. Сбор и формализация требований: работа с заказчиками
Разберем процесс сбора требований, если нет готового технического задания. Попытка составить один всеобъемлющий опросник обычно не дает результатов, поэтому эффективнее двигаться от общего к частному через прямой диалог.
Выделим ключевые этапы выявления требований:
- Идентификация участников процесса: разделяем лиц, принимающих решения (ЛПР), и непосредственных носителей знаний (мастеров смен, технологов, диспетчеров). С ЛПР согласовываем общие цели и границы проекта, а с исполнителями разбираем ежедневные операции.
- Интервьюирование и метод последовательных вопросов: задаем вопросы «Зачем?» и «Как вы поймете, что получили нужный результат?». Это позволяет отсечь лишние «хотелки» и выявить реальную бизнес-потребность.
- Интерактивное макетирование: проектируем экранные формы будущих документов и рабочих мест непосредственно в тестовой конфигурации без реализации логики проведения. Показываем макеты пользователям — наглядный интерфейс сразу выявляет недостающие реквизиты и неудобные шаги.
- Построение сквозной цепочки данных: фиксируем связь каждого производственного события с результирующим документом или регистром системы.
2. Приоритизация задач и фиксация договоренностей
Для управления объемом доработок (Scope) задействуем систему учета задач (Task Tracker, BugBoard) и четкую классификацию входящих запросов:
- Первичное требование: базовый функционал, необходимый для старта.
- Расширение функционала: новые пожелания, возникающие в процессе работы.
- Ошибка: несоответствие реализованного функционала согласованному поведению.
Применяем приоритизацию по принципу Must / Should / Could / Won't (метод MoSCoW). В первую очередь реализуем критически важный каркас (Must have), без которого система не способна функционировать. Все новые идеи и дополнительные отчеты заносим в журнал запросов на изменение (Change Requests) и переносим на следующий этап, не раздувая текущий релиз.
Каждое устное обсуждение обязательно закрепляем коротким письменным резюме (follow-up). Формулируем тезисы однозначно, исключая двоякие трактовки, и получаем подтверждение от функционального заказчика.
3. Архитектура подсистемы и специфика платформы 1С
Проанализируем распространенную ошибку: попытку создать избыточно универсальную систему «на все случаи жизни». Закладывать универсальность стоит только тогда, когда это не требует существенного усложнения структуры метаданных и замедления разработки.
При проектировании подсистемы (например, для производственного блока в УПП или ERP) придерживаемся следующих правил:
- Слабая связанность и изоляция доработок: создаем собственные документы, справочники и регистры с префиксом подсистемы. Не перегружаем типовые документы (
ОтчетПроизводстваЗаСмену, ТребованиеНакладная) новой сложной логикой. Связь с типовым контуром реализуем через обработчики формирования типовых документов или регламентные задания. - Учет механизма учета затрат: при разработке производственных регистров учитываем режим учета базы (партионный учет или РАУЗ /
УчетЗатрат). - Оптимизация производительности и параллельности: в новых регистрах накопления располагаем измерения по убыванию селективности данных. Минимизируем объем выборок и блокировок внутри транзакций записи.
- Фоновые вычисления: длительные операции (разузлование спецификаций, подбор аналогов, расчет плановых потребностей) выносим в фоновые задания через объект
ФоновыеЗадания.
4. Организация итерационного процесса разработки
В условиях, когда разработчик совмещает роли аналитика, архитектора и программиста, классический Scrum в полной мере применить невозможно. Оптимальным решением является переход на недельные или двухнедельные итерации.
Разберем типовое распределение времени в рамках недельной итерации:
- Дни 1–2: сбор, уточнение и детализация требований на текущий спринт, создание макетов форм.
- Дни 3–4: реализация программного кода, проектирование движений регистров и модулей.
- День 5: тестирование готового функционала, сдача промежуточных результатов заказчику, планирование следующей недели.
Итерационный подход позволяет пользователям регулярно видеть работающий результат, а разработчику — оперативно корректировать курс без масштабных переделок.
5. Управление рисками проекта
Выясним основные риски, с которыми сталкивается разработчик на небольшом проекте, и способы их снижения:
- Неготовность нормативно-справочной информации (НСИ): производственный контур не может функционировать без корректных спецификаций, технологических карт и единиц измерения. Проводим аудит НСИ до начала кодинга и привлекаем технологов к выверке справочников.
- Дефицит времени у заказчика или исполнителя: фиксируем четкие контрольные точки (вехи) с датами сдачи конкретных блоков функционала.
- Сопротивление персонала внедрению: запускаем подсистему через пилотную эксплуатацию на одном ограниченном участке или цехе, после чего тиражируем решение на все производство.