Заказать звонок
Заполните форму и мы перезвоним, чтобы ответить на все ваши вопросы!
Заказать звонок
Заполните форму и мы перезвоним, чтобы ответить на все ваши вопросы!
Как мы работаем
Методологии и технологии используемые в проектах
Методология BDD
Основная цель методологии BDD состоит в том, чтобы стимулировать общение между консультантом и разработчиком, чтобы контекст каждой функции был правильно понят всеми членами проектной команды до начала работы по разработке. Это помогает в определении сценариев для каждого бизнес-процесса, а также устраняет двусмысленность требований.
Наши принципы
На проектах мы применяем передовые мировые практики и ждем от заказчика готовности работать в рамках применяемой нами методологии управления проектом - Scrum, а также технологий и инструментов для выполнения работ.
Взаимодействие
Со стороны заказчика определяется руководитель проекта, у которого должно быть достаточно полномочий для управления приоритетами, а также административные полномочия для исполнения принятых решений в рамках проекта.
Основной формат работы - удаленный. Ключевые сотрудники заказчика должны быть готовы к удаленным коммуникациям, а также иметь интернет, микрофон, наушники, и веб-камеры.
Основной формат работы - удаленный. Ключевые сотрудники заказчика должны быть готовы к удаленным коммуникациям, а также иметь интернет, микрофон, наушники, и веб-камеры.
Формирование совместной команды
Все сотрудники заказчика, которые в дальнейшем будут поддерживать систему, должны быть включены в совместную команду и переданы в оперативное управление исполнителю. Они должны работать на равных с сотрудниками исполнителя, выполняя все те требования, которые предъявляются и к сотрудникам исполнителя.
Исключение: наличие договора SLA сроком на один год c нами.
Исключение: наличие договора SLA сроком на один год c нами.
Архитекторы системы - команда БИТ:ERP
Мы не осуществляем разработку по "функциональным требованиям" сформулированными заказчиком. Мы настаиваем на формате работы, когда заказчик формулирует проблему (бизнес-задачу) в терминах своей прикладной области, а мы предлагаем оптимальное решение с точки зрения конфигурации и платформы.
В частности, это означает, что мы не принимаем к разработке требования в формате "добавить реквизит на форму", или "добавить субконто". Мы выясняем, "для чего" заказчик решил, что это нужно сделать, а далее, предлагаем реализацию в системе.
Это не означает, что мы не аргументируем свой выбор заказчику, но мы считаем, что решение по реализации в системе должны принимать специалисты знающие систему, а не специалисты знающие бизнес.
В частности, это означает, что мы не принимаем к разработке требования в формате "добавить реквизит на форму", или "добавить субконто". Мы выясняем, "для чего" заказчик решил, что это нужно сделать, а далее, предлагаем реализацию в системе.
Это не означает, что мы не аргументируем свой выбор заказчику, но мы считаем, что решение по реализации в системе должны принимать специалисты знающие систему, а не специалисты знающие бизнес.
Минимальные изменения типовой конфигурации
Это означает, что на проекте мы во всех случаях стараемся с помощью параметрической настройки системы реализовать бизнес-процессы заказчика. В случае необходимости, предлагая вносить изменения в процессы, в соответствии с лучшими практиками, заложенными в типовое решение.
В случаях, когда функционал типовой конфигурации не соответствует потребностям заказчика (как правило это бывают операции в рамках основного бизнеса заказчика), мы разрабатываем функционал в виде отдельной подсистемы, который далее генерирует в фоновом режиме типовые документы, чтобы не нарушать нормальное функционирование основных блоков.
В случаях, когда функционал типовой конфигурации не соответствует потребностям заказчика (как правило это бывают операции в рамках основного бизнеса заказчика), мы разрабатываем функционал в виде отдельной подсистемы, который далее генерирует в фоновом режиме типовые документы, чтобы не нарушать нормальное функционирование основных блоков.
Технологии выполнения работ
Разработка через поведение
BDD - Behavior Driven Development
BDD - Behavior Driven Development
Все разработки выполняются в соответствии с принципами BDD. Задача представляется в виде описания пользовательского поведения на языке Gherkin. Это позволяет получить не только работающий код, но и сразу готовый автоматизированный тест для проверки корректности работы функционала.
Мы не оказываем услуг по подготовке классических ТЗ.
Мы не оказываем услуг по подготовке классических ТЗ.
Формализация бизнес-процессов в формате EPC
(Event-driven Process Chain)
(Event-driven Process Chain)
Автоматизируемые процессы описываются в виде цепочки функций и событий. Каждая функция связана с конкретным объектом системы, и профилем пользователя, который выполняет данную функцию в рамках системы
Событийно-ориентированная архитектура
В частности, это означает отказ от обменов по расписанию Данные между базами должны передаваться на скорости близкой к реальной по мере их появления. Для обеспечения необходимой надежности и скорости мы используем брокер сообщений RabbitMQ. Обычно мы используем БИТ:Адаптер 3.
Методология BDD
Основная цель методологии BDD состоит в том, чтобы стимулировать общение между консультантом и разработчиком, чтобы контекст каждой функции был правильно понят всеми членами проектной команды до начала работы по разработке. Это помогает в определении сценариев для каждого бизнес-процесса, а также устраняет двусмысленность требований.