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