За годы работы наша команда неоднократно участвовала в разработке и внедрении учётных систем — от автоматизации отдельных бизнес-процессов до комплексных решений, охватывающих финансы, склад, закупки, продажи, производство и управленческий учёт. И почти всегда результат такого проекта зависит не столько от того, насколько хорошо программисты пишут код, сколько от того, насколько правильно построен сам процесс разработки.
Собственная система или адаптация готового решения
Когда компания решает создать собственную учётную систему с нуля, самая частая ошибка — воспринимать это как простую разработку программного обеспечения по принципу «вот наши процессы, вот список функций — сделайте нам систему». Между идеей и готовой системой есть цепочка этапов: обследование, формализация требований, проектирование, приоритизация, разработка, тестирование, приёмка и последующее сопровождение. И ответственность за результат лежит не только на подрядчике.
Прежде чем начинать разработку, стоит ответить на базовый вопрос: действительно ли компании нужна собственная система. У большинства бизнесов уже есть готовые продукты — ERP, CRM, складские и бухгалтерские платформы, отраслевые решения. Если стандартный функционал закрывает 70–90% потребностей, часто экономически целесообразнее адаптировать готовую учётную платформу, чем строить новую.
Собственная разработка оправдана тогда, когда бизнес-процессы существенно отличаются от типовых, нужна специфическая логика расчётов, есть особые требования к интеграциям или компания сознательно хочет полностью контролировать архитектуру и дальнейшее развитие продукта. Важно сразу понимать: разработка с нуля — это не разовая покупка программы, а создание информационной системы, которую дальше нужно поддерживать, развивать, тестировать, защищать и адаптировать к изменениям бизнеса.
Кто за что отвечает
Одно из ключевых условий успешного проекта — чёткое распределение ответственности между заказчиком и исполнителем.
На стороне заказчика. Заказчик лучше всех знает собственный бизнес. Поэтому на его стороне должен быть человек, который понимает бизнес-процессы предприятия, может объяснить, как процесс работает сейчас и как он должен работать после автоматизации, определяет приоритеты, согласует изменения и принимает результаты разработки. В зависимости от масштаба компании это может быть Product Owner, руководитель проекта или бизнес-аналитик — но роль должна быть реальной, а не формальной. Если подрядчик вынужден сам выяснять, как работает предприятие, у кого спрашивать информацию и кто принимает решения, проект быстро начинает буксовать.
На стороне исполнителя. Со стороны разработчика должна быть понятная структура ролей: руководитель проекта, бизнес-аналитик, разработчики, QA, при необходимости — архитектор, DevOps, UI/UX. Заказчику не обязательно ежедневно общаться с каждым разработчиком, но должен быть прямой канал коммуникации с командой или руководителем проекта. Когда между заказчиком и командой стоит несколько уровней менеджмента, информация искажается, а простые вопросы превращаются в долгие согласования.
Как выбрать подрядчика
Мы советуем начинать не с вопроса «сколько стоит час работы». Первое, на что стоит смотреть, — как подрядчик подходит к проекту ещё до начала разработки. Опытный исполнитель не обещает после короткого звонка «да, мы всё сделаем, вот смета». Он задаёт вопросы: как построены процессы сейчас, кто пользователи системы, какие объёмы данных, какие нужны интеграции, где возникают проблемы, какие документы формируются, кто согласует операции, какие данные должны попадать в бухгалтерский и управленческий учёт, какие требования к ролям и доступам. Чем сложнее система, тем больше таких вопросов должно возникнуть до оценки.
Опыт именно в учётных системах. Разработать веб-приложение и построить систему, которая корректно ведёт остатки, проводки, взаиморасчёты, себестоимость и историю операций, — разные задачи.
Аналитическая компетенция. Если коммуникация сводится к «пришлите нам список функций» — это тревожный сигнал. Исполнитель должен помогать переводить бизнес-процессы в функциональные требования системы.
Прозрачность процесса. Заказчик должен в любой момент понимать, что разрабатывается сейчас, что запланировано дальше, какие задачи в работе и что уже принято.
Постепенный результат. Для большой учётной системы подход «встретимся через год, когда всё будет готово» — один из самых рискованных.
Права на результат. Договоритесь заранее и письменно: кому принадлежит исходный код, где он хранится, передаётся ли документация, сможете ли вы привлечь другого подрядчика на доработку без полного переписывания.
И не стоит выбирать подрядчика только по самой низкой ставке. Разница в стоимости часа обычно значительно меньше, чем стоимость ошибочных требований, переделок и месяцев простоя.
Этап 1. Предпроектное обследование
Разработку учётной системы не стоит начинать сразу с кода. Первый этап — предпроектное обследование. Его цель — понять, что именно автоматизируем, для кого, зачем и каким должен быть результат.
На этом этапе анализируются организационная структура, роли пользователей, основные бизнес-процессы, документооборот, справочники и нормативно-справочная информация, учётные регистры, отчётность, интеграции с другими системами, источники и потребители данных, права доступа, объёмы операций и проблемы текущего учёта.
Исследовать нужно не только то, как процесс описан в регламентах, но и то, как он реально происходит в компании. Очень часто эти две картины различаются.
Результат обследования — не фраза «мы всё поняли», а зафиксированная модель будущей системы: основные модули, процессы, роли, интеграции, ограничения и приоритеты, а также backlog верхнего уровня с предварительными оценками. С этим документом заказчик может работать даже с другим подрядчиком.
Этап 2. Не большое ТЗ, а управляемая система требований
После обследования возникает соблазн написать техническое задание на несколько сотен страниц и только потом начать разработку. Для больших систем это редко эффективно: пока ТЗ пишут, требования успевают измениться, а заказчик окончательно понимает, чего хотел, только увидев рабочий экран.
Мы отдаём предпочтение декомпозиции. Сначала формируется общий backlog — перечень функциональных и технических задач. А уже перед реализацией конкретной задачи готовится её мини-ТЗ: что нужно сделать, какой процесс автоматизируется, кто пользователь, какие входные данные, какая бизнес-логика выполняется, какой ожидается результат, какие исключения и ограничения и как проверить, что задача выполнена правильно. Это документ объёмом полстраницы — страница, а не недели работы аналитика наперёд.
Этап 3. Agile и разработка короткими итерациями
Для больших учётных систем хорошо работает итеративный подход. Backlog разбивается на приоритеты и спринты по одну-две недели. В рамках спринта команда реализует конкретный блок: часть складского учёта, закупки, документооборот или отдельную интеграцию. В конце спринта результат демонстрируется заказчику на рабочей системе, а не в виде отчёта.
Если что-то пошло не туда, заказчик узнаёт об этом через две недели, а не в конце проекта. Планирование спринта, демо и короткая ретроспектива — это не бюрократия, а механизмы, которые держат постоянный поток информации между командой и заказчиком.
Роль руководителя проекта заказчика: формирование и приёмка задач
Это критически важная часть, и именно здесь проекты чаще всего буксуют. Представитель заказчика должен быть полностью вовлечён с обеих сторон процесса.
На входе он участвует в формировании задач: проверяет, что мини-ТЗ описывает процесс так, как он реально должен работать, дополняет деталями от предметных экспертов — кладовщика, бухгалтера, оператора — и расставляет приоритеты в backlog.
На выходе он принимает разработку по критериям приёмки, а не «на глаз»: принято или не принято, с конкретной причиной. Без этого шага за несколько месяцев накапливается объём «вроде бы готового», что на самом деле не работает в боевом процессе.
Распределение простое: заказчик отвечает за бизнес-приоритеты и ответы на вопросы о процессе, исполнитель — за техническую реализацию и оценку сложности. Когда заказчик говорит «нужно автоматизировать перемещение товара между складами», команда задаёт уточнения: какие склады, какие типы перемещений, нужно ли резервирование, какие документы создаются, кто их согласует, как меняются остатки, нужна ли интеграция. Нормальная постановка задачи рождается именно на стыке бизнес-экспертизы заказчика и технической экспертизы исполнителя.
Архитектура: закладывать запас на будущее
Типичная ошибка — проектировать систему исключительно под сегодняшние потребности. Если сегодня в системе 20 пользователей, это не значит, что через три года их не будет 200. Если сейчас одна интеграция — через год их может быть десять.
Поэтому ещё на этапе архитектуры стоит продумать масштабируемость, производительность, безопасность, разграничение доступов, резервное копирование, журналирование операций, интеграционные API, структуру данных и возможность расширения функциональности. Не обязательно строить сложную enterprise-архитектуру с первого дня — но она не должна создавать технический долг уже на старте.
Критерии приёмки задач
Ещё одна проблема больших проектов — нечёткое понимание того, когда задача считается выполненной. Для каждой функциональности должны существовать критерии приёмки: какие сценарии должны работать, какие данные формируются, какие документы создаются, какие проверки выполняются, какие роли имеют или не имеют доступ, какой результат получает пользователь.
Это нужно не только заказчику. Для разработчика чёткие критерии приёмки означают, что он тоже понимает, какой результат считается готовым.
Что заказчик получает в результате
Правильно организованная разработка — это не просто «программа, которая работает». В результате компания получает управляемую информационную систему, в которой понятно, какие бизнес-процессы автоматизированы, как построена система, кто имеет доступ к данным, какие интеграции используются, как развивать функциональность, как тестировать изменения и кто отвечает за поддержку. Знания о системе не должны оставаться исключительно в голове одного разработчика.
На наш взгляд, главные правила можно сформулировать просто. Заказчик не может полностью передать ответственность за результат подрядчику. Подрядчик отвечает за технологию, архитектуру, качество кода, процесс разработки и реализацию согласованных требований. Заказчик отвечает за то, чтобы в проекте был человек, который знает бизнес, принимает решения, определяет приоритеты и имеет достаточно полномочий. Лучшие результаты мы видели там, где со стороны заказчика был вовлечён сильный руководитель проекта или Product Owner, а команда разработки могла напрямую общаться с людьми, которые знают процессы предприятия. Тогда разработка перестаёт быть передачей бесконечного списка заданий «на сторону» и становится совместной работой над продуктом, которая позволяет создавать учётные системы, реально работающие на бизнес и развивающиеся вместе с ним.