27.06.2011, 19:40 | #7 |
Участник
|
Спасибо за ответы, задача в принципе состоит из нескольких вещей:
1. Уменьшить время от озвучивания клиентом задачи, то воплощения ее в ЦРМ. 2. Уменьшить количество людских ошибок при переносе настроек. 3. Уменьшить трудозатраты на разработку требований. 4. Сохранить качество на высоком уровне. В рамках разработки можно выгружать кастомизации и крепить их к проекту, ложить в свн. Это оправданно и нужно. Но часто задачи по поддержке достаточно просты, например добавить поле на форму. Для этого выгружать настройки из црм, крепить к проекту и коммитить в свн достаточно долго. Накладные расходы по времени больше времени решения задачи, поэтому хотелось бы иметь автоматизированный тул, который сам бы отслеживал и версионировал изменения в ЦРМ в привязке к задаче клиента. В рамках проекта или поддержки. Как это обычно выглядит у нас: 1. Клиент говорит "У меня поменялся бизнес-процесс. Вместо кнопки А должна быть кнопка Б и делать она должна не Г а Д". 2. Консультант формулирует и передает задачу разработчику. 3. Разработчик делает задачу 4. Консультант проверяет на тесте (если есть необходимость подключается еще кто-то протестировать полноценно, если задача сложная) 5. Разработчик переносит на продакт У некоторых клиентов переносится несколько требований сразу, формируется т.к. называемый релиз. Зависит от размера клиента, некоторым нормальные процессы разработки и поддержки не под силу . Самые узкие места процесса обычно в таком случае - качественное ведение списка задач и перенос настроек. Так, как, например разработчик мог сделать задачу и уже сесть за следующую, пока консультант протестирует. Потом ему надо возвращаться к задаче и вспоминать что же он там сделал и что ему надо перенести. А так, например, при подтверждении консультантом, разработку мог бы перенести и специалист поддержки, не обладающий, например, такой квалификацией как программист. Кроме этого не хотелось бы, например, перекидывать все настройки, а только дельту и иметь возможность отката настроек - возврата системы в предидущее состояние до релиза. У меня была также идея написать приложение в котором программист перед разработкой фиксировал какие объекты системы (сущности, плагины и т.д.) заденет разработка, они бекапились и после разработки формировался бы пакет для переноса на другой ЦРМ. Такая схема, правда, не исключает людских ошибок. Многое из этого уже есть в ЦРМ 2011, к сожалению далеко не все клиенты пока перешли, а если быть точнее - только 1 перешел, 1 планирует, остальные пока не собираются и может и не соберутся. Вопрос следующий - кто какой процесс использует для разработки и как вы управляете средами (Разработки\Тестирования\Рабочая среда) и как и когда (по требованию клиента, после разработки и т.д.) переносите настройки между ними?
__________________
Внедренец Microsoft Dynamics CRM Последний раз редактировалось Савран Роман; 27.06.2011 в 19:44. |
|
|
|