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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Еще интересные статьи на эту тему: