Организация совместной разработки в BPMSOFT и последующая гарантийная поддержка

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

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

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

1.1 Необходимые договоренности до начала разработки

1.2 Каким требованиям должна отвечать собственная команда разработки

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

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

1.3 Как организовать коммуникации в ходе разработки

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

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

1.4 Как принять систему в гарантийную поддержку

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

2. Алгоритм составления запроса по гарантии

1
Разворачивается «эталонная» среда на стороне Заказчика, которая соответствует системе на момент передачи её на гарантию.
2
К среде подключаются необходимые тестовые контуры интеграции для тестирования. В идеале также с «эталонными» настройками, которые соответствуют моменту передачи системы.
3
Заказчик получает карт-бланш на изменения на всех остальных средах.
4
Если Заказчик считает, что нашел баг, то должен воспроизвести его на «эталонной» среде.
5
Исполнитель исследует подтвержденный баг и подготавливает решение.
6
Заказчику передаются обновленные пакеты для «эталонной» среды и описание решения, которое Заказчик должен применить на других своих средах.
7
Заказчик самостоятельно применяет решение на других средах.

Автор: Алексей Егоров