Содержание:
Между бизнесом и IT-направлением случаются разногласия: у первых есть свое представление о продукте, а вторые видят трудности, которые могут помешать его реализации.
О том, как находят общий язык бизнес и IT в Газпромбанке, рассказал лидер проектов розничного бизнеса на сайте банка Виктор Бунин.
Проблема: Сырая задача
Было. Бизнес придумывал идею, писал требования к задаче, потом архитектор рисовал концептуальный дизайн — и только после этого задача попадала в команду развития веб-проектов. Из-за этого часто возникали недопонимания: бизнес мог быть не в курсе, что ту или иную идею реализовать не получится. Много времени тратилось на поиск компромисса.
Другой пример: дизайнер делает финальную версию макета и передает ее разработчику, но макет возвращают обратно, так как предложенный интерфейс невозможно создать за обговоренные командой сроки. Дизайнер забирает макет обратно и дорабатывает его. Время идёт, и сроки запуска сдвигаются.
Стало. Взаимодействие между бизнесом и IT улучшилось, когда появились Value Streams, где задача совместно прорабатывается на ранних этапах.
В каждом Value Stream помимо архитектора, дизайнера и продакт-оунера есть представители от бизнеса и команды разработки. Вместе они прорабатывают задачу на ранних этапах. Так обратная связь приходит раньше, процесс движется быстрее и комфортнее для всех участников — недопониманий не остается, а сроки запуска задачи легко спрогнозировать.
Читай также: Что такое Value Streams и зачем они нужны банку
Проблема: Недостаточно времени
Было. Заказчик приходил к командам разработки с большим списком бизнес-требований — после их анализа создавали новую функциональность или улучшали старую. Подобные проекты требовали много времени — специалисты тратили на разработку 1–5 месяцев. Нужно было найти такое решение, чтобы как можно скорее отдавать в релиз новую функциональность.
Стало. Теперь команда разрабатывает MVP-решение — продукт с ограниченным количеством функций, который можно предложить клиентам и постепенно дорабатывать.
Например, команде поставили задачу: сделать так, чтобы после того, как клиент оформит заявку на дебетовую карту, ему предложили заполнить форму на потребительский кредит.
Есть два варианта реализации. Первый — быстрый, но менее удобный для клиента: в форму заявки для оформления кредита автоматически переносятся данные из заявки на дебетовую карту, а недостающие поля заполняет клиент. Создать функцию, которая перенесет данные из одной формы в другую, несложно.
Второй вариант — удобный для клиента Газпромбанка, но более трудоемкий. Он предполагает создание новых сервисов — с их помощью можно запрашивать информацию о клиенте из внутренних систем банка, например, зарплатные начисления и место работы, а затем вносить их в форму для потребительского кредита. Пользователь ничего не заполняет: достаточно нажать на кнопку «Узнать решение по кредиту» — и банк сам внесет недостающие данные и сформирует заявку на кредит.
Чтобы создать новые сервисы, требуется больше времени — у бизнеса его нет Поэтому команда разработки делает первый вариант задачи и сразу выпускает его в релиз. Это временное решение, которым все довольны: бизнес получил дополнительные заявки на потребительский кредит, а команда — время, чтобы внедрить более удобное решение и новые сервисы.
Проблема: Не устраивает результат
Было. Бизнес-требования готовились в отрыве от реализации. Бизнес-аналитик мог заложить формы и процессы, которые сложно или невозможно реализовать.
Стало. Появился этап прототипирования. Почти по всем задачам команда сайта готовит макеты. В момент их создания выявляется много нюансов, которые не предвиделись на этапе написания бизнес-требований.
Этап прототипирования показывает заказчику, будет ли процесс работать, какие усилия нужно приложить и что получится на выходе. А еще экономит время всех участников процесса и помогает договориться на ранних этапах.
Например, подготовка макетов по задаче «Подача заявки на ипотечный кредит с созаемщиками» помогла скорректировать бизнес-требования.
Сначала бизнес хотел, чтобы клиент при заполнении заявки на ипотечный кредит вносил данные в одну форму, а при выборе созаемщика появлялась дополнительная. Предполагалось, что как только клиент внесет и сохранит информацию о созаемщике, сайт вернет его к заполнению заявки на ипотечный кредит. При этом пользователь мог изменять сохраненные данные, например удалять созаемщика.
После отрисовки макетов стало очевидно: для реализации такого сценария потребуется промежуточное хранение данных по созаемщикам, чтобы пользователь мог вернуться и продолжить заполнять форму или скорректировать информацию. Но сохранять данные заявки без значительных доработок было невозможно.
Поэтому команда предложила отправлять данные в бэк-систему последовательно: сначала информацию о клиенте, затем о каждом созаемщике. Такое решение сократило время на разработку.
Без этапа прототипирования разработчики бы только в процессе узнали, что реализовать задачу невозможно. Они бы потратили время впустую, а бизнес не получил решение в срок.
Проблема: Сложно договориться
Было. Иногда обсуждение на рабочих встречах было безрезультатным — бизнес-заказчик и IT-специалисты не могли договориться о решении, которое бы всех устроило. Случались ситуации, когда команда разработки соглашалась на невыполнимую задачу только потому, что специалисты не находили нужные аргументы. По этой же причине проводили повторные встречи. На это уходило много времени.
Стало. Команду разработки обучили навыкам тайм-менеджмента, управления конфликтами и аргументации на дополнительных курсах в Газпромбанке.
После этого у рабочих встреч появилась структура: помимо основной темы сотрудники начали обсуждать дополнительные вопросы, которые помогают лучше понять задачу.
Навыки управления конфликтами позволили проводить встречи продуктивно — теперь сотрудники менее эмоционально реагируют на спорные вопросы и больше сосредоточены на доводах.
Навыки аргументации помогли наглядно доносить точку зрения о задаче до заказчика и достигать компромисса по дедлайнам. Благодаря этому удалось сэкономить время на дополнительных встречах и уделить его рабочим процессам.
Проблема: Подходит не каждая методология разработки
Было. Применяли Scrum — по этой методологии управления команда работала так:
- создавала список требований к продукту — бэклог — и обсуждала его;
- планировала двух-трехнедельные рабочие марафоны — спринты;
- в ходе спринтов выполняла часть задач, а в конце проводила ретроспективу — встречу, на которой обсуждала, что сделано хорошо и что можно улучшить к следующему спринту.
На первых порах методология помогала решать задачи, но затем команда расширилась — и некоторые практики перестали работать.
Если строго следовать Scrum, то команда должна проводить ретроспективы раз в две недели — в конце каждого спринта. В больших коллективах такое обсуждение идет больше двух часов — это непродуктивная трата времени.
Похожая ситуация с планированием задач в спринтах. Когда задач было 10–15 — планирование занимало час. Но когда их стало свыше 30–40 — процесс растягивался до двух часов и более.
Стало. Одну команду разделили на две. Первая переключилась на работу с задачами Value Streams, а вторая продолжает заниматься развитием платформы сайта. Такой подход привел к более эффективному распределению задач и возвратил гибкость — часть команды вернулась к работе по Scrum.
В команде, где осталось больше специалистов, перестали строго следовать одной методологии разработки. Например, оставили ретроспективы, но стали проводить их реже — раз в три месяца. Такой подход частичного отхода от методологии называется ScrumBut.
Читай также: Как адаптировать Scrum под цели команды.
Газпромбанк постоянно развивается и расширяется, поэтому растет потребность в новых сотрудниках. Если хотите помогать в развитии сайтов одного из крупнейших банков в России — приглашаем посмотреть открытые вакансии.
