Организация совместной разработки в BPMSOFT и последующая гарантийная поддержка
Или как получить систему, в которую можно вносить изменения, не потеряв гарантию на проектное решение от наемной команды.
Для того, чтобы внедрить новую систему силами наемной команды и передать на развитие собственной команде разработки, необходимо договориться о том, как подрядчик будет выполнять свои гарантийные обязательства и обеспечить для этого все необходимое. Если внести изменения в схему (объект, карточку редактирования, процесс), то можно столкнуться с ситуацией, в которой подрядчик посчитает случай негарантийным, так как по результатам внедрения была передана другая функциональность.
Организация совместной разработки требует дополнительных затрат и соблюдения договорённостей, которые позволят развивать систему и иметь возможность проверить, являются ли выявленные баги частью функциональности внедренной наемной или собственной командой и организовать их оперативное исправление.
Организация совместной разработки требует дополнительных затрат и соблюдения договорённостей, которые позволят развивать систему и иметь возможность проверить, являются ли выявленные баги частью функциональности внедренной наемной или собственной командой и организовать их оперативное исправление.
1.1 Необходимые договоренности до начала разработки
До старта внедрения новой системы необходимо определить блоки функциональности, которые будут обеспечивать выполнение необходимых бизнес-процессов.
Например, для CRM системы основными блоками функциональности могут быть «Контакты», «Контрагенты», «Лиды», «Продажи», «Договоры», «Заказы», «Интеграции с другими системами».
В рамках проекта с одним блоком функциональности не должно работать больше одной команды, чтобы уменьшить вероятность сдвига сроков проекта из-за конфликтов кода и сложности определения зон ответственности за исправление багов.
Отличным способом для визуального оформления договоренностей будет подготовка карты функциональности, которая покажет выделенные блоки функциональности и зоны ответственности каждой команды.
На основании сформированных договоренностей также получится уточнить план проекта, и определить порядок реализации блоков для того, чтобы можно было как можно раньше начать по ним развитие системы.
Например, для CRM системы основными блоками функциональности могут быть «Контакты», «Контрагенты», «Лиды», «Продажи», «Договоры», «Заказы», «Интеграции с другими системами».
В рамках проекта с одним блоком функциональности не должно работать больше одной команды, чтобы уменьшить вероятность сдвига сроков проекта из-за конфликтов кода и сложности определения зон ответственности за исправление багов.
Отличным способом для визуального оформления договоренностей будет подготовка карты функциональности, которая покажет выделенные блоки функциональности и зоны ответственности каждой команды.
На основании сформированных договоренностей также получится уточнить план проекта, и определить порядок реализации блоков для того, чтобы можно было как можно раньше начать по ним развитие системы.
Для формального закрепления договоренностей между командами разработки необходим регламент совместной разработки, который должен содержать детальную информацию:
1.Инфраструктура сред.
2.Порядок разработки.
3.Правила и ограничения, принимаемые командами разработки.
4.Иерархия пакетов.
1.Инфраструктура сред.
- Где находятся среды разработки каждой команды.
- Какие настройки должны быть выполнены для переменных окружения.
- Информация об общей среде тестирования.
- Информация о промышленной среде.
2.Порядок разработки.
- Кто осуществляет архитектурный контроль.
- Правила работы с общим / частными репозиториями кода.
- Правила подготовки релиза каждой командой.
3.Правила и ограничения, принимаемые командами разработки.
4.Иерархия пакетов.
1.2 Каким требованиям должна отвечать собственная команда разработки
Закрепление зон ответственности и соглашений о порядке совместной разработки помогает определить объемы задач для каждой команды разработки, но, кроме этого, необходимо убедиться, что собственная команда достаточно квалифицирована для того, чтобы развивать систему и поддерживать её в рабочем состоянии.
Примерами критериев, которые служат для определения возможностей собственной команды могут послужить следующие пункты:
Примерами критериев, которые служат для определения возможностей собственной команды могут послужить следующие пункты:
Умение следовать регламенту совместной разработки будет являться основным показателем, который определит количество проблем, с которыми придется столкнуться в ходе внедрения системы.
Если собственная команда будет пытаться нарушать его, например, внося изменения сразу на промышленной среде, игнорируя согласованный порядок разработки, то это может привести к сдвигу сроков и нарушению в работе функциональности, которую разрабатывает внешняя команда.
Если собственная команда будет пытаться нарушать его, например, внося изменения сразу на промышленной среде, игнорируя согласованный порядок разработки, то это может привести к сдвигу сроков и нарушению в работе функциональности, которую разрабатывает внешняя команда.
Знание лучших практик работы с платформой поможет собственной команде более точно оценивать сроки и трудозатраты, необходимые для реализации фич. Также это поможет понять, насколько адекватна оценка работ подрядчика и предлагаемые им решения.
Сертификация вендора поможет подтвердить, что у команды достаточно навыков для того, чтобы вести разработку собственного решения и понимания архитектуры платформы. Ну и бонусом это повысит авторитет команды в глазах подрядчика и поможет наладить коммуникации.
1.3 Как организовать коммуникации в ходе разработки
Одних письменных договоренностей и уверенности в компетенциях команды разработки недостаточно для того, чтобы команды успешно взаимодействовали между собой. Для того, чтобы проблемы не всплывали только при релизе функциональности, а могли бы выявлены оперативно, необходимо наладить регулярное взаимодействие между командами.
Для этого можно использовать любые проектные техники, которые подходят к выбранному способу ведения проекта:
Для этого можно использовать любые проектные техники, которые подходят к выбранному способу ведения проекта:
- ежедневные / еженедельные статусы по задачам;
- информационные меморандумы, отражающие текущее состояние проекта;
- архитектурные комитеты;
- другие варианты.
1.4 Как принять систему в гарантийную поддержку
После завершения всех работ внешней команды разработки, остается вопрос о том, как продолжать развитие системы и сохранить возможность внешней команды выполнять гарантийные обязательства. Общая рекомендация состоит в том, чтобы:
- иметь среду, которая будет соответствовать состоянию системы на момент передачи её подрядчиком в эксплуатацию
- иметь отдельные среды тестирования и промышленную, которые будут использоваться для дальнейшего развития системы.
2. Алгоритм составления запроса по гарантии
1
Разворачивается «эталонная» среда на стороне Заказчика, которая соответствует системе на момент передачи её на гарантию.
2
К среде подключаются необходимые тестовые контуры интеграции для тестирования. В идеале также с «эталонными» настройками, которые соответствуют моменту передачи системы.
3
Заказчик получает карт-бланш на изменения на всех остальных средах.
4
Если Заказчик считает, что нашел баг, то должен воспроизвести его на «эталонной» среде.
5
Исполнитель исследует подтвержденный баг и подготавливает решение.
6
Заказчику передаются обновленные пакеты для «эталонной» среды и описание решения, которое Заказчик должен применить на других своих средах.
7
Заказчик самостоятельно применяет решение на других средах.
Автор: Алексей Егоров
Другие статьи в разделе "Мнение эксперта"
Мы публикуем интересные статьи наших экспертов в области CRM, BPM, HRM.