В конце 1980-х годов израильский физик Элияху Голдратт в своем бизнес-романе «Цель» сформулировал «Теорию ограничений». Ее идея состоит в том, что, при приложении усилий к оптимизации управления лишь небольшим количеством аспектов бизнес-системы достигается эффект, намного превышающий результат одновременного воздействия на все проблемные области этой системы.

Элияху Голдратт разработал прикладные подходы к поиску и снятию ограничений, называемых узким бутылочным горлышком, и TOC — процессную модель, допускающую динамику изменений ограничений. Это сделало теорию популярной в финансовом секторе, где скорость реакции на изменения стоит на одном из первых мест в приоритетах топ-менеджмента.

Как в банках тестируют ПО?

Процессы цифровой трансформации банковского сектора радикально изменили список и порядок этих приоритетов. «Теория ограничений» оказалась востребована не только в классических подразделениях кредитных организаций, но и в их технологическом блоке.

Ренат Лашин, исполнительный директор АРПП «Отечественный софт», описал характер этих изменений так: «Финансовые институты, а также финтех-компании — и в мире, и в России — видят одним из конкурентных преимуществ повышение скорости вывода своих продуктов на рынок (time to market). Одними из массовых инструментов для достижения этой задачи выступают гибкие методологии разработки ПО (Agile и т.д.), которые подразумевают все более и более короткие сроки между релизами. Это, в свою очередь, приводит к формированию “узкого бутылочного горлышка” в виде бизнес-процесса тестирования этих релизов в организациях. Понятно, что оптимизация процесса тестирования становится критической бизнес-задачей уже на уровне топ-менеджмента банков. И здесь программисты волей-неволей превращаются в менеджеров».

Если поставщиком софта выступает вендор, то по запросам из финансовой организации его силами производятся многочисленные доработки, исправления и добавление нового функционала. Очередной релиз попадает на приемку в банк в группу тестировщиков, специализирующихся на решениях такого вендора в той или иной бизнес-функциональности, например в ДБО. Также в обязанности группы входит проведение исследовательских работ с данным ПО.

Никита Иванов, руководитель отдела тестирования компании InfoWatch ARMA, поделился опытом: «Моим предыдущим местом работы был банк из списка топ-3, куда я пришел несколько лет назад руководителем группы тестирования системы ДБО для юридических лиц. Задача отдела из 12 человек заключалась в том, чтобы принять от вендора очередной релиз и провести всестороннее тестирование ПО перед включением его в “боевой” IT-контур банка. На начало проекта ситуация сложилась так, что отдел имел технический долг в шесть месяцев, и ситуация могла выйти из-под контроля».

Кадры решают не все

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

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

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

«Что касается увеличения штата, то в IT-отрасли всем хорошо известен печальный кейс Фредерика Брукса, который был менеджером проекта по созданию IBM OS/360. Для ускорения разработки он предпринял попытку привлечь еще больше разработчиков, но решение это оказалось фатальным. Чтобы никто более не наступал на те же грабли, Брукс впоследствии написал серию очерков “Мифический человеко-месяц”», — рассказал Никита Иванов.

Раньше труд разработчиков оценивался в человеко-месяцах. Брукс доказал, что эта единица измерения опасна. Из нее следует, что люди и месяцы взаимозаменяемы. Это верно для рытья траншей, но даже приблизительно неверно для разработки ПО. Прежде всего из-за того, что распределение работы невозможно из-за ограничений в последовательности выполнения определенных ее участков. С приходом гибких методологий отрасль ушла от оценки задач с привязкой к реальному времени. Оценивается лишь относительная трудоемкость задач.

Добавился и острый дефицит кадров на рынке. Один лишь пример из издания vc.ru по этому поводу: 10 февраля 2022 года Альфа-Банк провел One Night Offer — мероприятие, на котором можно за вечер пройти собеседование, а на утро получить оффер для QA-инженеров уровня middle и senior. Тестировщиков явно не хватает. Дефицит IT-кадров привел к тому, что 2021 год на Западе назвали годом айтишников, а в России, по данным Минцифры, не хватает от 500 тыс. до 1 млн специалистов.

Группе тестирования ПО ничего не оставалось делать, как изучать опыт классического менеджмента и объединять его с лучшими практиками IT. В итоге более всего подошли методики Элияху Голдратта. «Бутылочным горлышком» оказались тонкости интеграции испытательных стендов с банковскими IT-системами: АБС, дополняющими ДБО сервисами и т.д.

Далее в соответствии с TOC было решено, как максимально использовать найденное ограничение. Для этого задействовали  методику «Барабан — Буфер — Канат». Ее смысл заключается в том, что вся система должна заработать в ритме, свойственном ограничению, а перед ним должен находиться оптимального объема буфер задач, гарантирующий отсутствие простоев. Это обеспечивает взаимосвязь всех элементов системы и исключает фактор внезапности. Затем были настройка распараллеливания процессов и декомпозиция ограничения на «подогораничения».

В итоге скорость тестирования без изменения количества ресурсов увеличилась до 30%, процессы можно планировать с точностью до 95%, а «хаос трансформировался в порядок».