Русфинанс Банк — это лидер по автокредитованию в России (по версии Frank RG), который входит в международную группу Société Générale. С одной стороны, мы можем смотреть на опыт разных стран, применять инструменты, которые используют наши коллеги не только во Франции, но по всему миру, с другой — для нас разработка и запуск любого нового ИТ-продукта, сервиса и даже фичи — это всегда челлендж, в том числе связанный с разными уровнями согласования проектов.
В своё время, в попытке сократить time-to-market, нам удалось попробовать и внедрить разные Agile-практики. Что ожидаемо, самой жизнеспособной из них оказался SCRUM.
В начале 2020 года мы начали масштабировать SCRUM, изучили фреймфорк LeSS и выстроили процессы взаимодействия офлайн, но пандемия внесла свои коррективы: в марте нас перевели на удалённый формат работы. Пришлось всё экстренно перестраивать.
Под катом мы расскажем о том, какие задачи нам пришлось решить, как в этом нам помогли инструменты SCRUM и LeSS и что из этого получилось.
Конечно, пандемия повлияла на показатели бизнеса. Дилерские центры, в которые клиенты приходили приобретать автомобиль в кредит, закрылись, и наши продажи снизились.
Но времени переживать не было: чтобы нарастить бизнес и помочь партнёрам, мы перевели взаимодействие с клиентом в онлайн.
В начале (назовём это время «до пандемии») вся команда сидела вместе, на стене висела физическая доска с задачами, а планирование и ретроспектива проходили в кабинете «при закрытых дверях». Мы просто старались следовать AGILE Манифесту и SCRUM Гайду.
Но со временем команда начала разрастаться. К нашей московской development team присоединились ребята, находящиеся в Самаре. Это внесло некоторые коррективы в устоявшийся мир и подтолкнуло изобретать обходные пути. Так, мы стали чаще использовать видео-конференции и Skype for Business, а для проведения daily поставили возле физической доски веб-камеру. Но даже несмотря на то, что команда была распределена между Москвой и Самарой, она, по сути, оставалась офлайн.
У нас была возможность вешать правила взаимодействия, которые были на виду и помогали в работе (например, правила проведения планирования, daily, грумминга, ретро). Каждый мог обратить на них внимание.
В онлайне этого не было, и нам пришлось искать другие подходы к использованию лучших практик/инструментов.
Оказалось, что это не такой уж и тривиальный процесс. Банк активно и давно вёл работы по переходу на Flex-офис, что позволило большинству уйти в онлайн безболезненно. Но ИТ — это отдельный мир: нам сложно взять тоненький ультрабук на 13” и уйти работать в кафе, нам нужны мощные производительные компьютеры, мониторы с большой диагональю и, желательно, в количестве не менее двух штук.
Что уж говорить про возможность удалённо подключаться к серверам — информационная безопасность в любом банке максимально важна, но это требует дополнительных согласований, настроек, использования криптографии и так далее.
Ну и, конечно, нельзя опустить человеческий фактор. Да, ИТ-специалисты любят посидеть в тишине, большинство из них были рады возможности работать из дома, сидя в комфортных для себя условиях, но личная коммуникация — это то, чего сильно не хватает. Вопросы, которые раньше можно было легко решить, обменявшись парой слов с коллегой, в формате общения через Skype, Slack решать стало сложнее.
Например, как передавать и брать слово, как модерировать беседу с таким количеством участников? В офлайне это происходило органично, так как все видели друг друга, а в онлайне мы моментально потеряли всю невербалику.
Для решения проблемы с модерацией мы предложили следующее: каждый из сотрудников по очереди (на два дня) становился ведущим на daily scrum. Таким образом, все могли прочувствовать всю сложность коммуникации «с другой стороны» и понять, как лучше вести себя на онлайн-обсуждениях, чтобы всем участникам было комфортно.
Кроме того, мы решили проблему «тишины»: когда непонятно, кто должен отвечать на вопрос, обращённый к команде в целом (команда более чем на 50 процентов состояла из новых сотрудников, которые определённо сталкивались с дискомфортом в таких ситуациях). В этом случае модератор обращался по имени к одному из участников и спрашивал его мнение. Таким образом и «старички» не перетягивали на себя одеяло при принятии решений, и новые сотрудники могли высказываться в комфортном для себя режиме.
И наоборот: мы предложили «стоп-слово», которое останавливает затянувшуюся и ушедшую от темы дискуссию. Когда кто-то произносит «фалафель», все должны замолчать, запарковать вопрос, который требует дальнейшего отдельного обсуждения, и вернуться к теме встречи.
Переход в «полный онлайн» у нас начался достаточно плавно: сначала все встречи, которые оставались очными, мы увели в онлайн — планирование, daily, грумминг, ревью спринта, ретроспектива. Вся коммуникация пошла через Skype for Business (к счастью, в банке он был внедрён достаточно давно).
Далее встал вопрос о том, что делать с физической доской. Достаточно быстро мы пришли к решению, что JIRA вполне позволяет сделать онлайн-доску со схожей визуализацией без особых сложностей. Это решение было на поверхности, поскольку JIRA мы используем давно для ведения Product Backlog и Sprint Backlog. Перемещение стикеров из WIP в DONE для общего удобства на себя брал ведущий, который и транслировал доску в Skype for Business.
Самым сложным, наверное, оказалось перевести в онлайн ретроспективу. В мире «до пандемии» проведение ретроспективы было целым ритуалом — заранее подготовленные упражнения, отрисованные флипы, купленные пончики/пицца/сладости — был огромный простор для фантазии. Мы пытались использовать всё, чтобы поддерживать в команде здоровую и дружескую атмосферу. Поэтому при переходе в онлайн оказалось, что инструментов для подобного SCRUM-мероприятия не так уж много. Мы перепробовали много инструментов: и IdeaBoardz, и Miro, и Mural, и FunRetro, и некоторые другие.
В итоге остановились на TeamRetro. Это удобная площадка с возможностью отправки итогов ретро на почту или в нужный канал в Slack, а также, с прочими фишками и «плюшками». Функционал действительно похож на многие другие платформы, но дело в нюансах, которые существенно упрощают работу: проведение голосований, подготовка карточек, механизм автоматической группировки. В общем, нам понравилось.
Кстати, про Slack: с уходом в «полный онлайн» этот канал коммуникации для нас обрёл вторую жизнь. Мы подключили в него наших партнёров для обсуждения и оперативного решения вопросов, а также другие команды, которые вместе с нами работают над одним продуктом в рамках LeSS, и пересмотрели структуру каналов, чтобы не перемешивать вопросы бизнеса с вопросами разработки или окружений.
С партнёрами также пришлось искать инструменты взаимодействия: Trello — для разбора багов и доработок на стороне партнёра, Slack — для оперативного взаимодействия и ответа на вопросы 24/7, ZOOM, Skype — для проведения встреч.
Все доработки и баги на стороне партнёра/подрядчика мы заводим в Trello, чтобы мониторить их статусы. У нас 8 колонок: «Новое», «В процессе», «Готово», «Тест», «Ожидание прод», «Прод», «Завершено (не требует выноса)», «Hold». Данные статусы позволяют отслеживать, где сейчас находится задача, а также своевременно заявлять о новых инцидентах. Доступ в Trello есть и у нас, и у партнёра, в случае изменения статуса на почту приходит уведомление.
С переходом в онлайн бизнес-аналитикам стало сложнее собирать информацию. Не всегда было легко договориться о скайп-встрече, а переписка по почте занимала слишком много времени. В итоге, процесс получения данных стал менее оперативным и начал занимать больше времени, чем в офлайне.
Пришлось вводить регулярные Zoom и Skype-конференции с конечными пользователями, с нашими клиентами (в данном случае автодилерами). Они шарили с нами экраны компьютеров, наглядно поясняли, в чём у них проблемы. Исходя из полученных объяснений бизнес-аналитики делали выводы и выстраивали бизнес-процессы.
При переходе в онлайн необходимо было чётко разделять истории в Product Backlog и Sprint Backlog. Поэтому мы приняли решение разделить работу с историей на фазы «Discovery», «Delivery», «On Prod».
Это пример фазы «Discovery», выполненной в спринте. По результатам данного этапа принимается решение, нужно ли идти в «Delivery» или оставить идею нереализованной.
В масштабируемом SCRUM (LeSS) нужна согласованная работа нескольких команд над одним продуктом, а именно — сервисом автокредитования. Проверка гипотез, разработка и оптимизация настолько большого количества фич просто невозможна силами одной команды. Четыре Scrum-команды фактически формировались онлайн во время пандемии, но это тоже отдельная история.
Все команды работают над продуктом Car Loan (Автокредит). Онлайн-заявка — это одна из его фич. Команды занимаются разработкой API для интеграции с ПО/CRM партнёров для получения заявок и оформления кредитных сделок, разработкой и внедрением новых услуг и сервисов для клиентов (например, «Пролонгация КАСКО онлайн», «Сниженная ставка по онлайн кредитованию»), интеграцией с внешними системами для оптимизации процесса заполнения данных клиентом, например, с сервисом ЕСИА. Все задачи направлены на увеличение воронки заявок и конверсии заявок в кредиты. У команд стоят общие коммерческие KPI, поэтому каждый заинтересован делать то, что принесёт результат.
Команды работают не только над новыми фичами и улучшением процесса, но и постоянно вносят изменения в уже реализованные доработки, исправляя баги как с «Прода», так и с «Теста».
В команде тестирования приоритеты переключились на задачи из-за возросших темпов разработки онлайн-сервисов. В связи с этим в начале пандемии возник небольшой аврал, но потом нагрузка выровнялась.
В целом во время пандемии количество задач существенно не изменилась, но появилась возможность распределить нагрузку в течение дня. Например, работать с более крупными перерывами, растягивая рабочий день.
Оценить свою производительность нам было достаточно сложно. Изначально у нас в команде разработки было всего пять человек. Точнее, даже четыре с половиной, так как один участник был частично загружен административными вопросами.
За три месяца мы набрали ещё пять человек — поэтому сравнение результатов «до» и «после» нужно проводить с учётом как увеличения численности участников команд, так и времени, затраченного на их обучение, адаптацию и погружение в новых условиях.
Но у нас есть хорошая метрика под названием «достижение целей спринта». Раньше (где-то до июня) мы успешно справлялись лишь с одной из трёх запланированных целей, а за июль достигли процентов 90.
Ещё один важный показатель — решение задач, связанных с покрытием технического долга: рефакторинг, исправление неоптимальной реализации и так далее. Если команда перегружена, времени на это выделять не удаётся, и всё откладывается в долгий ящик.
У нас за последние полтора-два месяца получилось решить немало таких задач: мы много где отказались от legacy и даже смогли кое-что полностью переписать, применив новые технологии (например, React).
За 5 месяцев до пандемии мы сделали 146 историй/задач/багов. За 3 месяца в изоляции сделали 198 историй/задач/багов. С уходом в онлайн команда не только не потеряла в эффективности, а наоборот, стала ещё более собранной и производительной.
В своё время, в попытке сократить time-to-market, нам удалось попробовать и внедрить разные Agile-практики. Что ожидаемо, самой жизнеспособной из них оказался SCRUM.
В начале 2020 года мы начали масштабировать SCRUM, изучили фреймфорк LeSS и выстроили процессы взаимодействия офлайн, но пандемия внесла свои коррективы: в марте нас перевели на удалённый формат работы. Пришлось всё экстренно перестраивать.
Под катом мы расскажем о том, какие задачи нам пришлось решить, как в этом нам помогли инструменты SCRUM и LeSS и что из этого получилось.
Снижение офлайн-продаж
Конечно, пандемия повлияла на показатели бизнеса. Дилерские центры, в которые клиенты приходили приобретать автомобиль в кредит, закрылись, и наши продажи снизились.
Но времени переживать не было: чтобы нарастить бизнес и помочь партнёрам, мы перевели взаимодействие с клиентом в онлайн.
Переход в онлайн за один день?
В начале (назовём это время «до пандемии») вся команда сидела вместе, на стене висела физическая доска с задачами, а планирование и ретроспектива проходили в кабинете «при закрытых дверях». Мы просто старались следовать AGILE Манифесту и SCRUM Гайду.
Но со временем команда начала разрастаться. К нашей московской development team присоединились ребята, находящиеся в Самаре. Это внесло некоторые коррективы в устоявшийся мир и подтолкнуло изобретать обходные пути. Так, мы стали чаще использовать видео-конференции и Skype for Business, а для проведения daily поставили возле физической доски веб-камеру. Но даже несмотря на то, что команда была распределена между Москвой и Самарой, она, по сути, оставалась офлайн.
У нас была возможность вешать правила взаимодействия, которые были на виду и помогали в работе (например, правила проведения планирования, daily, грумминга, ретро). Каждый мог обратить на них внимание.
В онлайне этого не было, и нам пришлось искать другие подходы к использованию лучших практик/инструментов.
ИТ-подразделение совсем не Flex
Оказалось, что это не такой уж и тривиальный процесс. Банк активно и давно вёл работы по переходу на Flex-офис, что позволило большинству уйти в онлайн безболезненно. Но ИТ — это отдельный мир: нам сложно взять тоненький ультрабук на 13” и уйти работать в кафе, нам нужны мощные производительные компьютеры, мониторы с большой диагональю и, желательно, в количестве не менее двух штук.
Что уж говорить про возможность удалённо подключаться к серверам — информационная безопасность в любом банке максимально важна, но это требует дополнительных согласований, настроек, использования криптографии и так далее.
Ну и, конечно, нельзя опустить человеческий фактор. Да, ИТ-специалисты любят посидеть в тишине, большинство из них были рады возможности работать из дома, сидя в комфортных для себя условиях, но личная коммуникация — это то, чего сильно не хватает. Вопросы, которые раньше можно было легко решить, обменявшись парой слов с коллегой, в формате общения через Skype, Slack решать стало сложнее.
Например, как передавать и брать слово, как модерировать беседу с таким количеством участников? В офлайне это происходило органично, так как все видели друг друга, а в онлайне мы моментально потеряли всю невербалику.
Для решения проблемы с модерацией мы предложили следующее: каждый из сотрудников по очереди (на два дня) становился ведущим на daily scrum. Таким образом, все могли прочувствовать всю сложность коммуникации «с другой стороны» и понять, как лучше вести себя на онлайн-обсуждениях, чтобы всем участникам было комфортно.
Кроме того, мы решили проблему «тишины»: когда непонятно, кто должен отвечать на вопрос, обращённый к команде в целом (команда более чем на 50 процентов состояла из новых сотрудников, которые определённо сталкивались с дискомфортом в таких ситуациях). В этом случае модератор обращался по имени к одному из участников и спрашивал его мнение. Таким образом и «старички» не перетягивали на себя одеяло при принятии решений, и новые сотрудники могли высказываться в комфортном для себя режиме.
И наоборот: мы предложили «стоп-слово», которое останавливает затянувшуюся и ушедшую от темы дискуссию. Когда кто-то произносит «фалафель», все должны замолчать, запарковать вопрос, который требует дальнейшего отдельного обсуждения, и вернуться к теме встречи.
Плавный переход в «полный онлайн»
Переход в «полный онлайн» у нас начался достаточно плавно: сначала все встречи, которые оставались очными, мы увели в онлайн — планирование, daily, грумминг, ревью спринта, ретроспектива. Вся коммуникация пошла через Skype for Business (к счастью, в банке он был внедрён достаточно давно).
Далее встал вопрос о том, что делать с физической доской. Достаточно быстро мы пришли к решению, что JIRA вполне позволяет сделать онлайн-доску со схожей визуализацией без особых сложностей. Это решение было на поверхности, поскольку JIRA мы используем давно для ведения Product Backlog и Sprint Backlog. Перемещение стикеров из WIP в DONE для общего удобства на себя брал ведущий, который и транслировал доску в Skype for Business.
Ретроспектива
Самым сложным, наверное, оказалось перевести в онлайн ретроспективу. В мире «до пандемии» проведение ретроспективы было целым ритуалом — заранее подготовленные упражнения, отрисованные флипы, купленные пончики/пицца/сладости — был огромный простор для фантазии. Мы пытались использовать всё, чтобы поддерживать в команде здоровую и дружескую атмосферу. Поэтому при переходе в онлайн оказалось, что инструментов для подобного SCRUM-мероприятия не так уж много. Мы перепробовали много инструментов: и IdeaBoardz, и Miro, и Mural, и FunRetro, и некоторые другие.
В итоге остановились на TeamRetro. Это удобная площадка с возможностью отправки итогов ретро на почту или в нужный канал в Slack, а также, с прочими фишками и «плюшками». Функционал действительно похож на многие другие платформы, но дело в нюансах, которые существенно упрощают работу: проведение голосований, подготовка карточек, механизм автоматической группировки. В общем, нам понравилось.
Общение с партнёрами
Кстати, про Slack: с уходом в «полный онлайн» этот канал коммуникации для нас обрёл вторую жизнь. Мы подключили в него наших партнёров для обсуждения и оперативного решения вопросов, а также другие команды, которые вместе с нами работают над одним продуктом в рамках LeSS, и пересмотрели структуру каналов, чтобы не перемешивать вопросы бизнеса с вопросами разработки или окружений.С партнёрами также пришлось искать инструменты взаимодействия: Trello — для разбора багов и доработок на стороне партнёра, Slack — для оперативного взаимодействия и ответа на вопросы 24/7, ZOOM, Skype — для проведения встреч.
Все доработки и баги на стороне партнёра/подрядчика мы заводим в Trello, чтобы мониторить их статусы. У нас 8 колонок: «Новое», «В процессе», «Готово», «Тест», «Ожидание прод», «Прод», «Завершено (не требует выноса)», «Hold». Данные статусы позволяют отслеживать, где сейчас находится задача, а также своевременно заявлять о новых инцидентах. Доступ в Trello есть и у нас, и у партнёра, в случае изменения статуса на почту приходит уведомление.
С переходом в онлайн бизнес-аналитикам стало сложнее собирать информацию. Не всегда было легко договориться о скайп-встрече, а переписка по почте занимала слишком много времени. В итоге, процесс получения данных стал менее оперативным и начал занимать больше времени, чем в офлайне.
Пришлось вводить регулярные Zoom и Skype-конференции с конечными пользователями, с нашими клиентами (в данном случае автодилерами). Они шарили с нами экраны компьютеров, наглядно поясняли, в чём у них проблемы. Исходя из полученных объяснений бизнес-аналитики делали выводы и выстраивали бизнес-процессы.
Разработка онлайн и разделение на команды
При переходе в онлайн необходимо было чётко разделять истории в Product Backlog и Sprint Backlog. Поэтому мы приняли решение разделить работу с историей на фазы «Discovery», «Delivery», «On Prod».
Это пример фазы «Discovery», выполненной в спринте. По результатам данного этапа принимается решение, нужно ли идти в «Delivery» или оставить идею нереализованной.
В масштабируемом SCRUM (LeSS) нужна согласованная работа нескольких команд над одним продуктом, а именно — сервисом автокредитования. Проверка гипотез, разработка и оптимизация настолько большого количества фич просто невозможна силами одной команды. Четыре Scrum-команды фактически формировались онлайн во время пандемии, но это тоже отдельная история.
Все команды работают над продуктом Car Loan (Автокредит). Онлайн-заявка — это одна из его фич. Команды занимаются разработкой API для интеграции с ПО/CRM партнёров для получения заявок и оформления кредитных сделок, разработкой и внедрением новых услуг и сервисов для клиентов (например, «Пролонгация КАСКО онлайн», «Сниженная ставка по онлайн кредитованию»), интеграцией с внешними системами для оптимизации процесса заполнения данных клиентом, например, с сервисом ЕСИА. Все задачи направлены на увеличение воронки заявок и конверсии заявок в кредиты. У команд стоят общие коммерческие KPI, поэтому каждый заинтересован делать то, что принесёт результат.
Команды работают не только над новыми фичами и улучшением процесса, но и постоянно вносят изменения в уже реализованные доработки, исправляя баги как с «Прода», так и с «Теста».
Результаты работы в онлайн за 3+ месяца
Тестирование
В команде тестирования приоритеты переключились на задачи из-за возросших темпов разработки онлайн-сервисов. В связи с этим в начале пандемии возник небольшой аврал, но потом нагрузка выровнялась.
В целом во время пандемии количество задач существенно не изменилась, но появилась возможность распределить нагрузку в течение дня. Например, работать с более крупными перерывами, растягивая рабочий день.
Разработка
Оценить свою производительность нам было достаточно сложно. Изначально у нас в команде разработки было всего пять человек. Точнее, даже четыре с половиной, так как один участник был частично загружен административными вопросами.
За три месяца мы набрали ещё пять человек — поэтому сравнение результатов «до» и «после» нужно проводить с учётом как увеличения численности участников команд, так и времени, затраченного на их обучение, адаптацию и погружение в новых условиях.
Но у нас есть хорошая метрика под названием «достижение целей спринта». Раньше (где-то до июня) мы успешно справлялись лишь с одной из трёх запланированных целей, а за июль достигли процентов 90.
Ещё один важный показатель — решение задач, связанных с покрытием технического долга: рефакторинг, исправление неоптимальной реализации и так далее. Если команда перегружена, времени на это выделять не удаётся, и всё откладывается в долгий ящик.
У нас за последние полтора-два месяца получилось решить немало таких задач: мы много где отказались от legacy и даже смогли кое-что полностью переписать, применив новые технологии (например, React).
За 5 месяцев до пандемии мы сделали 146 историй/задач/багов. За 3 месяца в изоляции сделали 198 историй/задач/багов. С уходом в онлайн команда не только не потеряла в эффективности, а наоборот, стала ещё более собранной и производительной.
