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

Слабые стороны баг-трекера

Разработчиками используются системы, поддерживающие процесс разработки, чаще – баг-трекеры. Данный процесс необходим для оперативности и качества взаимодействия с пользователем. При разработке и документировании требований особое внимание уделяют их полноте и непротиворечивости, особенно, если пользователей много и они не имеют опыта в постановке задач для разработчиков. Данный процесс позволяет более точно оценить стоимость и сроки, устранить разногласия внутри команды, зафиксировать описание системы на общедоступном ресурсе. Необходимо организовать процесс тестирования на основе требований, для гарантии качества вашего продукта.

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

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

• Как повысить скорость работы команды?
• Возможно ли повышение скорости, при наличии времени для саморазвития?
• Необходимо ли увеличение численности команды или внедрение оптимизации процессов, при изменении работы с клиентами, внедрение практики, повышающей продуктивность?

Выстраивание процесса

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

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

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

Общая доска, но разные заказчики

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

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

Смотрите на готовое решение, позволяющее организовать единый процесс типовых решений по Kanban. Изоляция проектных артефактов одних заказчиков от других уже встроена в систему, что предоставляет заказчикам комфортную среду для управления требованиями и согласования их с командой разработки.  Вам необходимо пригласить заказчика в его проект кастомизации, отправив email. Функциональность поддержки  позволяет организовывать взаимодействие с конечными пользователями и мгновенно информировать о решении заявок.

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

• Как объединить разработку и поддержку
• Учимся подбирать методологию к проекту
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Постоянные улучшения и ретроспективы в Agile
• Как часто должно меняться ограничение количества незавершенной работы в Kanban?