Разработка мобильного приложения и веб-систем — всегда сложный и долгий процесс. Не на каждом этапе результаты очевидны: иногда заказчику кажется, что проект никуда не двигается, в то время как команда работает в поте лица.

Об одном таком кейсе из практики YuSMP Group рассказывает наш project manager — Александр Хорошко. Клиенту казалось, что баги не исправляются. Он находил и подкидывал новые ошибки в рабочий чат, требуя немедленного исполнения. Разработчики не успевали одновременно создавать новые фичи и справляться с большим объемом багов. Все это сильно осложняло работу на проекте. О том, как удалось решить ситуацию, читайте в статье.

Проблема: клиент не видит результатов

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

Так получился замкнутый круг: команда фиксит баги -> заказчик не видит изменений -> отправляет новые баги -> разработчики не успевают и задачи копятся -> заказчик снова не видит изменений, злится и накидывает багов еще.

Клиент мог написать в чат в течение недели 15–20 багов, ожидая, что их сразу возьмут в работу. Обычно без вреда для рабочего процесса за неделю разработчики фиксили 5–10 из найденных заказчиком ошибок. Чтобы рабочий процесс не нарушался, на багфиксы мы выделили 20–30% рабочего времени, остальное оставили для создания новых фичей.

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

Стало очевидно, что нам нужно сделать процесс максимально прозрачным: было важно, чтобы заказчик начал замечать работу команды. 

Решения: отдельная доска для багов и регулярное общение

Еженедельные митинги

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

Клиентская доска тестирования

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

Доска состоит из 7 столбцов:

• To do. Здесь хранится то, что добавил клиент, но еще не смотрели тестировщики.
• Не воспроизведено. Тут остались баги, которые команда не смогла воспроизвести в системе.
• Воспроизведено. Сюда переносятся баги, которые нашли и воспроизвели.
• В работе. В этот столбец попадают баги, которые вместе с заказчиком были выбраны на еженедельном митинге. Этот столбец связан с основной таблицей, в которой разработчики проставляют рабочие статусы. Когда специалисты завершают работу, они переводят задачу в статус «Готово». На доске у клиента это автоматически переносится из столбца «В работе» в столбец «На проверке». Таким образом, задачи сразу попадают к специалистам, которые исправляют ошибки. Как только задача выполнена, она переходит в следующий столбец.
• На проверке. Заказчик мог зайти на доску и увидеть, какие баги были выполнены, а также посмотреть среду, где можно проверить багфикс. У клиента есть возможность самостоятельно протестировать систему и убедиться, что баг исправлен.
• Отложено (On Hold). В столбец попадают баги, которые были отложены «на потом» заказчиком или командой.
• Готово. В эту категорию прожект-менеджер вручную перетаскивают баги, которые клиент лично проверил и подтвердил, что ошибка исправлена.

Итог

В итоге процесс для заказчика стал более прозрачным и контролируемым.

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

Также клиент стал понимать реальный объем работ, который команда может выполнить за неделю — стало меньше неоправданных ожиданий.

Кроме того, на еженедельных встречах клиент совместно с PM-ом стал принимать решения, какие баги брать в работу и расставлял приоритеты.

Эти два решения сильно упростили жизнь команды и заказчика на проекте.