{"id":14293,"url":"\/distributions\/14293\/click?bit=1&hash=05c87a3ce0b7c4063dd46190317b7d4a16bc23b8ced3bfac605d44f253650a0f","hash":"05c87a3ce0b7c4063dd46190317b7d4a16bc23b8ced3bfac605d44f253650a0f","title":"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043d\u043e\u0432\u044b\u0439 \u0441\u0435\u0440\u0432\u0438\u0441 \u043d\u0435 \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0432 \u043d\u0438 \u043a\u043e\u043f\u0435\u0439\u043a\u0438","buttonText":"","imageUuid":""}

Как наглядно показать клиенту прогресс: кейс YuSMP Group

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

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

Общий вид таблицы с багами, которую видит клиент

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

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

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

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

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

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

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

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

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

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

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

Доска с багами для клиента соединена с доской разработчиков через столбец "В работе".

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

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

Итог

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

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

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

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

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

0
4 комментария
Дима

а что за канбан система используется?

Ответить
Развернуть ветку
Александр Хорошко

Если речь про то, какое ПО используется - то это Jira, в ней отлично настраиваются несколько досок для одного проекта

Ответить
Развернуть ветку
Artem Sovetnikov

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

Ответить
Развернуть ветку
Александр Хорошко

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

Из-за этого возникает 2 момента:
1. Клиент ждёт к сроку фичи (предположим, что успеваем)
2. Клиент ждёт багфиксы (а вот тут уже не успеваем)

Вот и получается, что приходится либо брать все багфиксы и тормозить разработку фичей (что сорвет сроки), либо вклинивать часть багфиксов в свободное время (что вызовет гнев заказчика, мол мало багов фиксится).

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

Ответить
Развернуть ветку
1 комментарий
Раскрывать всегда