Индивидуальная разработка CRM и ERP систем «с нуля» под конкретного заказчика.
Доработка готовой системы под потребности клиента.
Создание нового продукта на основе типового решения.
Клиенты приходят к нам с идеей создания CRM или ERP системы или конкретными требованиями к функционалу. В ходе бесплатной консультации наш аналитик проводит предварительный аудит с выявлением процессов и потребностей вашей компании, ищет возможные решения для увеличения скорости, эффективности, удобства и формирует видение будущего проекта.
Идея и консультация
Почти всегда идея, с которой клиенты приходят к нам, требует аналитики и доработки. Эта работа необходима, чтобы на старте четко понимать, что мы имеем и в каком направлении двигаться, а также, чтобы продумать стратегию создания лучшего продукта.
На этом этапе мы проводим аналитику рынка приложений/веб-сервисов по выбранной тематике, выявляем лидеров и находим примеры плохой реализации, определяем критерии их успеха или провала. Мы изучаем продукты конкурентов с точки зрения интерфейсных решений, ориентирования на конечного пользователя, выполнения сервисом своих целей и задач и выявляем их преимущества и недостатки.
Полученные знания проецируем на будущее приложение, формируем представление о конечном продукте, о пользователях и их целях, и в результате получаем видение будущего проекта, зафиксированное в документе - project vision.
После консультации с нашим специалистом у Вас появится точное понимание, как сделать так чтобы проект выстрелил.
Приступаем к работе!
Команда разработчиков оценивает будущую CRM или ERP системы, и мы составляем предварительное коммерческое предложение на разработку.
Оценка проекта и предложение
После составления project vision проекта наша команда разработчиков оценивает примерные трудозатраты на реализацию продукта. Исходя из поставленных задач и технологических ограничений, составляется оценка количества часов, необходимых на разработку вашего продукта.
На основе полученной оценки формируется предварительное коммерческое предложение, в которое входит описание похожих проектов, реализованных нашей компанией, состав команды разработчиков и профессиональный уровень каждого участника, стоимость всего проекта с разбиением на этапы разработки.
На коммерческом предложении в дальнейшем будет основан договор.
После обсуждения деталей проекта с продукт-оунером, заказчик и команда разрабатывают архитектуру решения, описывает алгоритмы и сценарии работы в бэклоге на весь проект. Проектируем интерфейсы и возможно разрабатываем дизайн. После этого с заказчиком подписывается договор.
Бэклог и договор
Далее, команда разработчиков вместе с продукт оунером (Product Owner)* и Заказчиком составляет второй единый документ приложения - Бэклог Продукта**.
* продукт оунер – руководитель проекта
Ответственность за содержимое бэклога, его упорядочение и доступность всем членам проекта несет Product Owner. Он также ответственен за достижение максимальной ценности продукта и работы, выполняемой командой, поэтому непрерывно анализирует процесс разработки и ищет способы по улучшению продукта. Эту роль может исполнять как человек со стороны заказчика, так и сотрудник нашей компании.
**бэклог – список задач для команды разработки, которые полностью описывают проект
Документ представляет собой иерархическую структуру из пользовательских возможностей и технических требований, упорядоченных по очередности реализации, более важный функционал будет реализован раньше остальных. Каждому элементу Бэклога присваиваться описание, порядковый номер, оценка объема работы и ценность. Это позволяет просчитать окончательную стоимость разработки всего продукта.
Договор в первую очередь обеспечивает полную прозрачность проводимых работ для заказчика и позволяет ему контролировать процесс разработки на каждом этапе.Все этапы прописываются отдельно, что позволяет производить оплату выполненной работы по факту сдачи.
Бэклог – гибкий документ, который позволяет Заказчику вносить даже серьезные изменения в продукт по ходу разработки, ведь большинство новаторских идей придумываются уже в ходе выполнения проекта. Дополнительный функционал оформляется в виде доп. соглашений к договору, в которых отмечается, сдвинет ли реализация вносимых изменений сроки завершения этапов проекта.
Определение вместе с клиентом тех задач, которые необходимо реализовать на предстоящем спринте.
Планирование спринта
Сердцем Scrum* является Спринт** длительностью в одну или две недели, в течение которых создается потенциально готовая к выпуску и использованию часть продукта.
*Scrum – гибкая методология разработки, по который мы ведем проекты
** Спринт-этап в рамках которого реализуется определенная часть проекта
Обычно длительность Спринта является постоянной на протяжении всего периода разработки. Следующий Спринт начинается сразу же по окончании предыдущего.
Спринт состоит из списка того, какие функции нужно разработать и гибкого плана, служащего ориентиром в работе по проекту. Ресурсом для планирования спринта является Бэклог Продукта.
Объем работ на предстоящий Спринт определяется во время планирования Спринта в ходе совместной работы всей команды.
При планировании Спринта команда отвечает на следующие вопросы:
• Цель Спринта, или каков будет результат выполнения запланированных на него работ?
• Как будет выполняться разработка?
Завершение спринта и демонстрация клиенту результатов за неделю. Команда инспектирует себя, выявляет успешные решения/ошибки и решает вопрос о необходимых улучшениях.
Ретроспектива спринта
Каждый день в течение Спринта в определенное время проходят Скрам митинги - 15-минутные встречи/созвоны для команды разработчиков с целью синхронизации действий и создания плана работы на ближайшие 24 часа.
В конце Спринта, после демонстрации Заказчику результата работы, команда проводит ретроспективу. Ретроспектива дает команде возможность инспектировать себя и определить успешные/неудачные моменты работы. И что самое важное, в процессе ретроспективы команда находит пути улучшения качества разрабатываемого продукта и применяет их в течение следующего Спринта.
24 часа
Каждый день команда отчи -тывается продукт-оунеру о выполненных задачах.
Завершение спринта и демонстрация клиенту результатов за неделю. Команда инспектирует себя, выявляет успешные решения/ошибки и решает вопрос о необходимых улучшениях.
Конечная цель любого мобильного приложения – автоматизация бизнес-процессов, создание имиджа компании, увеличение прибыли бизнеса за счет популярности продукта в интернете