Комплексные проекты. Автоматизация "для" и "в интересах" бизнеса.

Наши преимущества

Одно из наших преимуществ - мы Не являемся "евангелистами 1С:Підприємство", и предлагаем бизнесу этот продукт в случае оптимальности решения в конкретных условиях заказчика и для тех задач, где 1С:Підприємство действительно сейчас справляется лучше всего. Мы разрабатываем для наших клиентов IT-решения с учетом преимуществ каждой из платформ в отношении конкретной решаемой задачи (готовые или разработку с нуля, в зависимости от условий проекта). Платформы, которые мы в основном используем: Node.JS, .NET, 1С:Підприємство.

У нас большой опыт разработки и внедрения систем класса ERP, CRM, ECM и др. Мы используем этот опыт для создания SaaS-сервисов и Web-приложений, решающих реальные бизнес-задачи.

Методологии, которые мы используем

Сегодня для реализации проектов мы используем Agile / Scrum методологию. При этом в некоторых случаях это может быть гибридная модель - при необходимости используются преимущества элементов каскадной методики Waterfall. Если кратко:

На этапе согласования целей и функционального объема проекта мы очерчиваем границы проекта, относительно которых и делаем предположение о его бюджете. В каскадных проектах этот этап обычно называют функциональными требованиями или техническим заданием. Далее ведется итерационная разработка продукта, вы сможете контролировать результат каждые 2 недели. Важным этапом в реализации проектов на базе 1С:Підприємство является их внедрение (опытная и промышленная эксплуатация) и дальнейшее сопровождение.


Давайте постараемся дать некоторые пояснения к данным термина сквозь призму привычных терминов и 1С:Підприємство понятий.

Роли в SCRUM:

Владелец продукта - 1 человек со стороны заказчика. Получает требования к системе от функциональных руководителей, собирает свою команду внутри компании и вместе определяют общий список требований к проекту и их важность. Получает задачи с проставленной оценкой трудозатрат от скрам-команды и вместе со своей внутренней командой определяет чьи и какие задачи войдут в следующую версию. Обсуждает детали и текущие вопросы от Скрам-команды (с владельцами процесса) при реализации текущей версии.

Скрам мастер Менеджер проекта - может быть как сотрудником отдела продаж, так и одним из участников команды. Проводит коммуникацию с Владельцем продукта (по телефону, скайпу, эл. почте т.д.). Организовывает встречи Скрам-команды и Владельца продукта. Следит за регламентом ведения собраний (место, время, план, итог). Координирует работу команды (назначает собрания, следит за временем). Организовывает ретроспективу и демонстрацию версии.

Скрам-команда - Собирается впервые, когда инициирован процесс (подписан договор). Участники команды могут быть вовлечены параллельно не более чем в 2 проекта. В команду входят разработчики и аналитик/и.

Артефакты в SCRUM:

Беклог продукта - это список требований к продукту, в нем должны быть зафиксированы пользовательские требования (список того, что хочет получить Владелец продукта, формулировка требований должна быть понятна для Владельца продукта), их важность (определяет Владелец продукта, при необходимости совместно с Аналитиком).

Беклог спринта - все требования из беклога продукта разбиваются на задачи для реализации.

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

Процессы работы:

Составление списка требований к продукту - в период интервьюирования клиента (с Владельцем продукта, владельцами процессов) по требованиям к продукту вся Скрам-команда не собирается, только Аналитик. Требование заказчика – минимально завершенное требование с точки зрения клиента, которое формулирует Аналитик. Критериями разбивки одного требования на задачи является – объект/механизм. Сдача разработок клиенту осуществляется по его требованиям, а не по задачам разработки.

Составление списка задач к спринту - Готовый список требований к продукту Скрам-команда детализирует на задачи и формирует список требований к версии (отбираются по функциональности и важности для Владельца продукта). Документ со списком задач по требованиям должен быть понятным для Владельца продукта и представлен в виде древовидной структуры с отображением иерархии.

Демонстрация версии - На демонстрации версии присутствует вся Скрам-команда, Менеджер проекта (при необходимости), Владелец продукта и владельцы процессов (при необходимости). Разработки по версии показываются в рабочей базе клиента.

Ретроспектива - Ретроспектива с Владельцем продукта предполагает выяснение какие из разработок активно используются, а какие «не прижились» и почему.