Разработка внутренних программных систем

Примеры задач

Внутренняя система связывает участников, данные и рабочие действия. Сначала определим один законченный процесс: от создания записи до понятного результата и ответственности за него.

Что получает команда

Объём можно ограничить одним процессом или согласованными модулями. Публичный сайт, отдельное мобильное приложение, перенос всей истории и новые интеграции оцениваются самостоятельно.

Заявка с понятным состоянием

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

1. Данные подготовлены

   Исполнитель заполняет согласованные сведения.

2. Версия подтверждена

   Ответственный проверяет данные в пределах своей роли.

3. Действие разрешено

   Система выполняет следующий шаг и сохраняет понятный статус.

Что можно проверить: Кто и на основании каких данных изменил состояние заявки; что остаётся выполнить.

Когда нужна отдельная разработка

Начнём с проверки действующих инструментов. Если задачу решает настройка существующей CRM или другой системы, учтём такой вариант при выборе.

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

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

Возможные форматы

Кабинет одного процесса. Например, создание заявки, проверка и согласованное завершение.

Развитие действующей системы. Сначала изучим её данные и правила, затем оценим новые функции и влияние изменений.

Приложение по этапам. Выделим модули, каждый из которых можно проверить и принять отдельно. Для каждого модуля заранее определим самостоятельный результат и условия использования после сдачи.

Как проходит работа

1. Описываем процесс. Уточняем роли, рабочие записи и нужный результат.
2. Согласуем правила. Определяем данные, состояния, разрешения и обязательные проверки.
3. Показываем фрагмент. Проверяем основной пользовательский сценарий до расширения.
4. Закрепляем объём. Согласуем функции, подключения, эксплуатацию и критерии сдачи.
5. Реализуем и проверяем. Испытываем действия, права, ошибки и взаимодействие с системами.
6. Передаём в работу. Готовим материалы и порядок обновления, определяем ответственных.

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

Что нужно определить до разработки

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

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

Размещение и доступ вне офиса определяются по задаче. Рабочие базы, пароли и финансовые сведения передаются отдельно от открытой формы сайта.

С какими процессами работаем

В собственном внутреннем логистическом приложении есть рабочий контур заявок и истории, приняты отдельные этапы. Разработка продолжается; полный расчёт перевозки не принят. Этот опыт не выдаём за завершённую универсальную систему.

В публичном разборе транспортных заявок показан демонстрационный сценарий подготовки карточки для диспетчера. Его статус — демонстрация. Бот расходов и времени описывает реализованный ограниченный процесс, а рабочее пространство проектов — ещё один демонстрационный пример.

Для вашей задачи определим собственные роли и критерии. Опыт другого процесса не заменяет их согласование.

Разработку ведёт Павел Лещенко. Состав работ и критерии передачи определим до начала проекта.

Как оценивается разработка

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

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

Как проверяем готовность

Приёмка опирается на действия сотрудников и данные. Само наличие экрана или скрытой кнопки не подтверждает корректность процесса и прав.

Передача и дальнейшее развитие

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

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