Коротко: клиенту казалось, что баги не исправляются, и он заваливал рабочий чат новыми задачами. Мы завели отдельную доску в Jira с понятными статусами для его багов и ввели еженедельные статус-встречи по пятницам. Итог — прозрачный процесс, меньше конфликтов, совместная приоритизация задач и восстановленное доверие к команде.
Разработка мобильного приложения и веб-систем — всегда сложный и долгий процесс. Не на каждом этапе результаты очевидны: иногда заказчику кажется, что проект никуда не двигается, в то время как команда работает в поте лица.
Об одном таком кейсе из практики YuSMP Group рассказывает наш project manager — Александр Хорошко. Клиенту казалось, что баги не исправляются. Он находил и подкидывал новые ошибки в рабочий чат, требуя немедленного исполнения. Разработчики не успевали одновременно создавать новые фичи и справляться с большим объемом багов. Все это сильно осложняло работу на проекте. О том, как удалось решить ситуацию, читайте в статье.
Похожая ситуация типична для многих проектов: если процесс контроля качества и коммуникация с клиентом не выстроены, доверие падает даже при хорошей скорости разработки. Ниже — инструменты, которые сняли напряжение в этом кейсе, и ещё несколько способов показать прогресс, которые стоит взять на вооружение в своём процессе тестирования.
Проблема: клиент не видит результатов
На одном из наших проектов возникла неприятная ситуация: заказчику всё время казалось, что баги практически не исправляются. Клиент решил, что разработчики отлынивают от работы и старался продвинуть в работу еще больше задач.
Так получился замкнутый круг: команда фиксит баги -> заказчик не видит изменений -> отправляет новые баги -> разработчики не успевают и задачи копятся -> заказчик снова не видит изменений, злится и накидывает багов еще.
Почему клиенту казалось, что работы мало
Проблема почти никогда в реальном объёме работы — команда фиксила баги в срок. Дело в том, что заказчик видит только то, что ему показывают, и обычно сталкивается с тремя причинами недоверия:
- Не видно промежуточных этапов. Клиент узнаёт о статусе бага только когда тот полностью закрыт — а между «баг найден» и «баг исправлен» проходит несколько дней тишины.
- Редкая или нерегулярная коммуникация. Если статус проекта обсуждается раз в две-три недели или только по запросу клиента, у него формируется ощущение, что команда работает «в стол».
- Нет метрики прогресса, понятной без объяснений. Список задач в почте или чате не показывает динамику — сколько сделано за неделю, сколько осталось, что в приоритете.
Клиент мог написать в чат в течение недели 15–20 багов, ожидая, что их сразу возьмут в работу. Обычно без вреда для рабочего процесса за неделю разработчики фиксили 5–10 из найденных заказчиком ошибок. Чтобы рабочий процесс не нарушался, на багфиксы мы выделили 20–30% рабочего времени, остальное оставили для создания новых фичей.
Напряжение росло: мы хорошо шли по исправлениям, но клиенту казалось, что команда игнорирует большую часть багов и не справляется c проектом
Стало очевидно, что нам нужно сделать процесс максимально прозрачным: было важно, чтобы заказчик начал замечать работу команды.
Решения: отдельная доска для багов и регулярное общение
Еженедельные митинги
Договорились встречаться каждую пятницу. На митингах команда показывала краткую сводку по багам: список задач, их статус и комментарии к каждому пункту. Отдельно в этом списке отмечались баги, который клиент находил сам. На встречах мы обсуждали приоритет задач и ставили цели на будущую неделю.
Клиентская доска тестирования
Вторым решением стало создание отдельной доски в Jira для отображения клиенту багов, которые он находил. Так заказчик мог отслеживать прогресс по каждой задаче.
Доска состоит из 7 столбцов:
- To do. Здесь хранится то, что добавил клиент, но еще не смотрели тестировщики.
- Не воспроизведено. Тут остались баги, которые команда не смогла воспроизвести в системе.
- Воспроизведено. Сюда переносятся баги, которые нашли и воспроизвели.
- В работе. В этот столбец попадают баги, которые вместе с заказчиком были выбраны на еженедельном митинге. Этот столбец связан с основной таблицей, в которой разработчики проставляют рабочие статусы. Когда специалисты завершают работу, они переводят задачу в статус «Готово». На доске у клиента это автоматически переносится из столбца «В работе» в столбец «На проверке». Таким образом, задачи сразу попадают к специалистам, которые исправляют ошибки. Как только задача выполнена, она переходит в следующий столбец.
- На проверке. Заказчик мог зайти на доску и увидеть, какие баги были выполнены, а также посмотреть среду, где можно проверить багфикс. У клиента есть возможность самостоятельно протестировать систему и убедиться, что баг исправлен.
- Отложено (On Hold). В столбец попадают баги, которые были отложены «на потом» заказчиком или командой.
- Готово. В эту категорию прожект-менеджер вручную перетаскивают баги, которые клиент лично проверил и подтвердил, что ошибка исправлена.
Такая доска и еженедельные встречи — не единственные способы снять напряжение. Вот сводная таблица методов, которые помогают показать прогресс на разных типах проектов:
| Способ | Что видит клиент | Когда применять |
|---|---|---|
| Еженедельная статус-встреча | Приоритеты, статусы задач, план на неделю | Всегда, как базовый ритм коммуникации |
| Клиентская доска в таск-трекере | Статус каждого бага или задачи в реальном времени | Когда клиент сам находит и присылает баги |
| Демо промежуточных результатов | Работающий функционал, а не список задач | По итогам спринта или крупного этапа |
| Roadmap с дедлайнами | Крупные вехи проекта на таймлайне | На длинных проектах от 3 месяцев |
| Диаграмма Ганта или Hill Chart | Долю выполненной и оставшейся работы визуально | Когда нужно объяснить объём без митинга |
Ещё способы показать прогресс, которые стоит взять на вооружение
В этом кейсе хватило доски и еженедельных встреч, но на других проектах полезно комбинировать их с дополнительными форматами.
Демонстрация промежуточных результатов (демо)
Демо показывает клиенту не список задач, а работающий продукт: новую фичу, исправленный сценарий, обновлённый интерфейс. В отличие от статус-встречи, где обсуждают процесс, демо доказывает результат — это особенно важно для клиентов, которые не доверяют отчётам на словах. Для демо полезно заранее готовить короткий сценарий и показывать сначала то, что интересно клиенту, а не то, что было проще сделать команде.
Roadmap с дедлайнами
На проектах длиннее трёх месяцев одной доски с багами недостаточно — клиенту важно видеть крупные вехи, а не только текущий спринт. Roadmap с датами по каждому этапу снимает вопрос «когда будет готово» и позволяет заранее договориться о переносах, если что-то пошло не по плану.
Диаграмма Ганта или Hill Chart
Если клиенту сложно оценить объём работы по списку задач, помогает визуализация: диаграмма Ганта показывает распределение задач по времени, а Hill Chart — долю уже понятной и ещё неопределённой работы по каждой фиче. Это быстрее объясняет статус, чем текстовый отчёт, и снижает число уточняющих вопросов.
Нужна разработка под вашу задачу?
Обсудим проект и соберём команду — оценка за 2 дня, бесплатно.
Итог
В итоге процесс для заказчика стал более прозрачным и контролируемым.
Мы показали, что не игнорируем баги, а берем их в работу. Структурировали хаотичные ошибки из чата в отдельную доску: заказчик видел статус по каждой задаче и ощущал контроль над процессом.
Также клиент стал понимать реальный объем работ, который команда может выполнить за неделю — стало меньше неоправданных ожиданий.
Кроме того, на еженедельных встречах клиент совместно с PM-ом стал принимать решения, какие баги брать в работу и расставлял приоритеты.
Эти два решения сильно упростили жизнь команды и заказчика на проекте.
Если обобщить, для любого проекта — не только этого — работают три принципа:
- Показывайте промежуточные статусы, а не только финал. Доска или короткий еженедельный отчёт закрывают разрыв между «баг найден» и «баг исправлен», в котором обычно и рождается недоверие.
- Договаривайтесь о ритме коммуникации заранее. Фиксированный день и формат встречи снимают вопрос «а что вообще происходит с проектом» ещё до того, как он возникнет.
- Приоритизируйте задачи вместе с клиентом, а не за него. Совместное решение, что чинить в первую очередь, превращает заказчика из наблюдателя в участника процесса — и снимает ощущение, что его заявки игнорируют.
Частые вопросы
Как часто нужно показывать клиенту прогресс проекта?
Оптимальная частота — раз в неделю: короткая встреча или отчёт с конкретными задачами, статусами и планом на следующий период. Реже — клиент теряет ощущение контроля и начинает додумывать, что команда бездействует; чаще — статус-встречи начинают отнимать время от самой разработки.
Что делать, если клиент не верит отчётам о прогрессе?
Дать доступ к первоисточнику вместо пересказа: гостевой доступ к доске в таск-трекере, где видно статус каждой задачи, или демо-стенд, где можно проверить исправление лично. Отчёт со слов PM легко обесценить, а доску с датами и статусами — нет.
Какой инструмент выбрать для отслеживания багов вместе с клиентом?
Подойдёт любой таск-трекер с гостевым доступом — Jira, Trello, YouTrack. Важнее не бренд инструмента, а структура: отдельная доска для багов клиента, понятные статусы (например «Не воспроизведено → Воспроизведено → В работе → На проверке → Готово») и возможность самому клиенту проверить исправление в тестовой среде.
Сколько рабочего времени команды стоит выделять на багфиксы, а не на новые фичи?
На большинстве проектов достаточно 20–30% спринта. Если багов подряд несколько недель больше — это сигнал пересмотреть покрытие тестами до релиза, а не наращивать долю багфиксов до 50% и выше в ущерб развитию продукта.
Что делать, если клиент сам находит баги быстрее, чем команда успевает их фиксить?
Ввести приоритизацию на еженедельной встрече вместе с клиентом: не команда в одиночку решает, что чинить первым, а PM и заказчик — вместе, по влиянию бага на пользователей. Это снимает ощущение, что заявки «складывают в стол», даже если очередь не опустела полностью.
Помогают ли демонстрации (демо) вместо еженедельных отчётов?
Да, демо и отчёты решают разные задачи и хорошо работают вместе: демо показывает готовый результат за спринт и годится для контрольных точек, а еженедельная доска и статус-встреча — для повседневной прозрачности между демо. На быстрых спринтах (1–2 недели) можно совместить демо со статус-встречей.
Обсудим ваш проект?
Соберём команду под вашу задачу и оценим проект за 2 дня — бесплатно.
