Внедрение типовых решений часто приводит к кастомизации, то есть доработке типового продукта под потребности конкретного заказчика. Разработчики продуктов на базе типовых решений постоянно сталкиваются с различиями в процессах, особенностях использования этих продуктов, изменениями в законодательстве.

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

Чтобы выстроить эффективный процесс качественной доработки типовых решений, используйте Kanban, который состоит из нескольких простых шагов.

Сперва вам нужно собрать все требования в общем бэклоге, включая заявки, дефекты и доработки по новым требованиям.

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

Далее необходимо визуализировать процесс разработки на Kanban доске, то есть сделать прозрачными все этапы работ, включая сведения о том, кто чем занят. Это позволит понять на какой стадии находится требование, куда уходит время.

канбан доска 1с

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

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

После выполнения этих шагов команде остается анализировать и выявлять возникающие проблемы, обсуждать их на ретроспективах и совместными усилиями вырабатывать шаги по их устранению. В первую очередь необходимо сфокусироваться на устранении потерь, связанных с лишними действиями, которые не приносят ценности (пользы) заказчику, сокращать количество ручного тестирования и т.п. Devprom ALM следит за актуальностью документации, автоматически вычисляет среднее время решения заявки или реализации требования и позволяет следить за изменением эффективности вашей команды.

среднее время цикла

С одной стороны, для организации работы команды нужна общая Kanban-доска, но с другой - каждое внедрение требует индивидуального набора проектных артефактов.

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

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

Попробуйте Kanban!

Если вы не смогли найти рецепт для решения вашей задачи, то просто напишите нам или позвоните, мы проведем для вас бесплатное демо возможных вариантов ее решения.