Как я за неделю перешёл от использования Jira к её администрированию

Раньше я работал с Jira преимущественно как пользователь. Но в некоторых наших проектах накопилось много задач и багов, поэтому команде разработки и QA становилось всё сложнее в них ориентироваться. Кроме того, руководителям не хватало прозрачности: со стороны периодически могло казаться, что отдел разработки и QA недостаточно загружен, хотя реальную картину по текущим задачам было трудно быстро увидеть. Я предложил техническому директору перевести проекты из team-managed в company-managed, объяснил преимущества для компании и после согласования получил необходимые права для настройки. За неделю я: • разработал единый workflow и настроил переходы между статусами; • унифицировал screens и fields; • удалил устаревшие и неиспользуемые workflows и schemas; • настроил отдельные поля для баг-репортов вместо хранения всей информации в Description; • создал JQL-фильтры и дашборды для отображения прогресса и загруженности отдела; • добавил автоматические уведомления менеджерам о новых задачах; • настроил автоматическое назначение исполнителей при переходах между статусами; • начал структурировать задачи по компонентам. В результате задачи теперь корректно переходят между исполнителями. Например, при передаче задачи на тестирование Jira автоматически назначает нужного специалиста — раньше после изменения статуса исполнитель нередко оставался прежним. Дашборды позволяют быстрее показать руководителям прогресс и текущую загрузку отдела, а единые схемы можно повторно использовать при создании новых проектов. Для самого крупного проекта я уже создал компоненты и начал распределять по ним задачи и баги. Следующий этап — настроить роли и права, сформировать группы Dev и Managers, подключить к Jira команду внедрения и создать для неё отдельную доску внутри проекта. При работе я использовал нейросеть как вспомогательный инструмент: она помогла быстрее разобраться в структуре Jira, точнее настроить переходы и составить JQL-запросы для фильтров. Но выбор архитектуры и внедрение изменений оставались отдельной практической задачей, требующей понимания процессов команды. Для меня этот опыт стал хорошим напоминанием: иногда улучшение работы QA начинается не с нового автотеста, а с наведения порядка во всём процессе разработки. #Jira #QualityAssurance #ProcessImprovement #QA