5 минут
Как мы выстраивали процессы при работе с вендорским ПО
Внедрение вендорского ПО часто воспринимается как быстрый способ получить готовую ИТ-систему, где качество и дальнейшая поддержка остаются зоной ответственности поставщика. Но на практике такой подход не всегда закрывает все риски на стороне заказчика.
Задача
К нам обратился отдел взыскания крупного российского банка. Разработку системы полностью выполнял вендор, а со стороны клиента в проекте участвовал только аналитик.
Работа строилась по водопадной модели: сначала собирали требования, затем проектировали решение, разрабатывали, тестировали и только после этого внедряли изменения. Из-за такой последовательности новые функции выходили реже, а сроки поставок сильно зависели от завершения каждого предыдущего этапа.
Подразделению банка нужен был новый функционал для повышения эффективности взыскания.
Задержка внедрения напрямую влияла на бизнес-показатели. При просрочке кредита или процедуре банкротства банк формирует резервы под возможные риски. Чем дольше не запускается нужный функционал, тем дольше часть средств остается вне оборота.
Базовая версия системы была готова, но последующие доработки сдвинули сроки запуска. Из-за этого план по взысканию выполнили не полностью, а часть ожидаемых средств не вернулась в оборот. При таком сценарии возрастал и другой риск: если новый функционал не подтвердит ожидаемую эффективность, расходы на разработку могут не окупиться.
Клиент обратился в SimbirSoft за специалистом по обеспечению качества, чтобы наладить работу с вендором и ускорить выпуск обновлений.
На старте выделили несколько задач:
- выстроить процессы внутри команды клиента и во взаимодействии с поставщиком;
- улучшить описание требований, чтобы бизнес-заказчик и вендор понимали их одинаково;
- зафиксировать единые критерии готовности продукта;
- сократить количество доработок и переносов релизов;
- сделать поставки функционала регулярными;
- снизить расходы на разработку.
Решение
После анализа потребностей клиента и технических заданий мы выявили несколько системных проблем:
- требования описывались неоднозначно, из-за чего стороны по-разному понимали будущий функционал;
- риски не учитывались при планировании, что приводило к срыву сроков;
- прототипы и дизайн-макеты не готовились, поэтому согласование решений занимало больше времени;
- договоренности с совещаний не фиксировались в едином формате;
- при оценке сроков учитывались только работы вендора, без времени аналитиков на подготовку требований и проверку результата;
- база знаний была плохо структурирована, поэтому поиск нужной информации занимал много времени.
Эти проблемы стали основой для дальнейшей поэтапной настройки процессов.
Коммуникация и процессы
На первом этапе мы помогли выстроить взаимодействие между клиентом и вендором. После подготовки первоначального технического задания команда стала отдельно обсуждать детали с заинтересованными сторонами.
Требования начали дополнять диаграммами и передавать бизнес-заказчику на согласование. Все спорные вопросы разбирались совместно с представителем бизнеса и аналитиком вендора. По итогам встреч договоренности фиксировали письменно, а техническое задание обновляли до передачи задачи в работу.
Такой подход помог сделать требования более точными, учесть важные нюансы заранее и снизить риск дорогостоящих доработок.
Дополнительно QA-специалиста подключили к разбору обращений из технической поддержки. Это позволило быстрее находить причины проблем и понятнее описывать их для вендора.
Оценка трудозатрат
Мы пересмотрели подход к оценке задач. Раньше фактические сроки могли отличаться от плановых почти в два раза: требования уточнялись уже в процессе работы, а итоговый функционал не всегда соответствовал реальным бизнес-процессам.
Например, документ должен пройти согласование в течение 7 дней и попасть на подпись ответственному сотруднику из другого подразделения. Если этот сотрудник в отпуске, возникает риск просрочки. Такие сценарии раньше не учитывались заранее.
В новую оценку добавили время на подготовку и согласование технического задания, анализ возможных рисков и тестирование перед передачей функционала пользователям.
База знаний
Мы обновили базу знаний, потому что прежняя структура не позволяла быстро находить нужные материалы и затрудняла обмен информацией между командами.
Что изменили:
- добавили раздел «Команда» с контактами, ответственными лицами и связями между участниками;
- создали раздел «Процессы» с правилами работы, инструкциями и описанием порядка ведения задач;
- структурировали задачи: добавили ссылки на систему управления задачами, разделение по спринтам, кварталам и функциональным блокам;
- открыли вендору доступ на чтение к нужным разделам, чтобы сократить количество уточнений и ускорить разработку.
В результате база знаний стала понятнее, а команда и вендор получили единый источник актуальной информации.
Результаты
Со временем аналитик команды и представитель бизнес-заказчика выстроили понятный формат работы. Количество встреч сократилось, а технические задания стали поступать вендору уже в согласованном и понятном виде.
Это повлияло на скорость и качество выполнения задач:
- доля задач на доработку снизилась с 55% до 5–10%;
- через квартал объем замороженных средств уменьшился на 18%;
- через год показатели вышли на допустимый уровень.
Регулярные поставки функциональности и улучшение финансовых показателей позволили бизнес-заказчику увереннее планировать дальнейшую работу.