Начало диалога: часть 1, часть 2, часть 3, часть 4.
Важное предупреждение. Все примеры, приведённые в статье, не отражают реальные ситуации, относящиеся к конкретным лицам, и являются плодом художественного вымысла. Все возможные совпадения случайны, но лишь подтверждают актуальность этих примеров.
ALM: Необходимо обеспечить гибкость разработки…
PM: Способ управления описанным риском — например, создание рабочих прототипов элементов будущего программного обеспечения, закрывающих логически завершённые этапы целевого бизнес-процесса и учитывающее ранее принятые концептуальные направления.
Тем не менее даже рабочие прототипы:
• еще далёки от решения для промышленного применения,
• создание прототипов тоже требует времени и трудозатрат.
ALM: Не всякая программа допускает наличие всего лишь прототипа. Я бы как-то побоялся лететь на самолёте, в автопилоте которого запрограммирован только прототип.
PM: Да, это ещё одно ограничение применения методологии Agile. В твоём примере прототип может работать только в авиасимуляторе (тестовой среде), который также необходимо будет создать.
Вернёмся, однако, к ситуации, в которой Agile эффективно применим. Представленный конечному пользователю прототип провоцирует последнего на максимально оперативное формулирование истинных потребностей относительно реальной практики каждодневной работы. Тем самым, ресурсы, потраченные на создание прототипа, является страховкой от необходимости глобальной переделки. Ведь обычно такая необходимость возникает в тот момент, когда уже потрачена часть бюджета и упущено время. Упущенное время и бюджетные ограничения не сразу приводят к провалу проекта, но неизбежно отражаются на качестве конечного результата. Кстати, моё личное мнение, что готовность поступиться качеством — признак корпоративного бескультурья, т. к. по сути очень близко к банальному обману акционеров. И все, кто съезжал с федеральных трасс в глубинке России, меня поддержат.
ALM: Я понимаю, о чём ты говоришь. Когда мы только начали разрабатывать систему управления эффективностью розничных кредитных портфелей, мы её изначально сделали средствами MS Access и MS Excel. При этом основная операционная работа выполнялась «руками»: вручную вычищались ошибки из данных, вручную оценивались матрицы миграции кредитов по состояниям просрочки, вручную они перемножались и т. д. Простейший отчёт о кредитном портфеле формировался дня три, а то и неделю. Подтверждение качества моделей (back testing или validation) было в реальности невозможно (хотя мы об этом никому не говорили, прикрываясь некогда подготовленным отчётом, который мы, впрочем, никому дальше титульного листа не показывали). Наши электронные таблицы не работали универсально на всех типах портфелей и не позволяли рассчитать все показатели эффективности, выявить все факторы, обуславливающие поведение портфеля (в частности, большие проблемы были с оценкой влияния макроэкономической конъюнктуры). Но мы были горды, что можем содержательно прикинуть резервы в соответствии с МСФО (IAS) 39.
В итоге всё это рухнуло. Когда ключевой сотрудник женился и взял впервые за 3 года отпуск, а в банке начался кризис 2008 года, и потребовалось очень быстро оценивать последствия реструктуризации кредитных портфелей, электронная таблица стала слишком «тяжёлой» и просто зависла.
PM: Типичная история всех подобных технологий. Вашего сотрудника можно поздравить, а всем остальным посочувствовать. Именно для этого и нужны поставленные и регламентированные бизнес-процессы и промышленная автоматизация, то есть реализованная с соблюдением ряда принципов, касающихся качества и поддержки.
ALM: В начале истории мы не были к этому готовы. Мы были первопроходцами и лишь позднее узнали, что разработкой похожих технологий занимается ещё одна команда в США. А больше никого и не было! И это решение позволило нам:
• поверить в свои силы,
• определить нашу роль в процессах финансового планирования, расчёта резервов на возможные потери (нам регулярно удавалось отстаивать низкий объём резервов перед аудитором),
• оптимизировать фондирование за счёт более точного учёта досрочного погашения,
• оптимизировать ценообразование,
• осуществить необходимую реструктуризацию в ходе кризиса (нам повезло, основную часть портфелей мы обсчитать успели),
• понять, что необходимо нам сделать, чтобы эта технология работала лучше,
• подготовить данные для такого анализа,
• понять, как мы эту технологию будем использовать, и что в ней надо доработать, чтобы «закрыть» ею ещё бóльшее множество задач, стоящих перед нами.
Потом мы переработали эту систему, реализовав ряд расчётов кодом на Visual Basic for Applications. Однако развитие системы «упёрлось» в ограничения Visual Basic for Applications. Этот язык не позволяет разрабатывать по-настоящему быстрые приложения, а наши потребности (как и перечень решаемых задач и обеспечиваемых бизнес-процессов) росли. Понадобилось анализировать розничные депозитные портфели и управлять ими. В область интереса попала ипотека, где статистика поведения кредитов возраста 10 лет попросту в России отсутствовала, а обеспечение по кредитам (недвижимость) играет ключевую роль. Да и вообще макросы на Visual Basic for Applications крайне редко можно назвать промышленным решением, о важности которого говорил ты. Поэтому возникла третья версия системы, которую мы назвали Roll Rate Analytic System. Она стала полноценной промышленной системой управления эффективностью розничных кредитных и депозитных портфелей, реализованная в клиент-серверной архитектуре, интегрируемой с хранилищами данных. Но и на этом развитие не остановилось. Понадобилось реализовать стресс-тесты ФРС США (в ответ на интерес одного регулируемого ФРС банка), прогнозировать процентные платежи (помимо платежей по основным суммам кредитов) и пени за просрочку. Появилось МСФО 9 (тут нам пригодилось, что мы в рамках стресс-тестирования научились устойчиво выявлять макроэкономические связи). И… «эту песню не задушишь, не убьёшь».
PM: Это позитивный пример Agile! Не то, что про ремонт квартиры (хотя вопрос, кому больше повезло в части ухода жены!). Это потому, что вы применяли Agile в правильном контексте. Формулировки принципов этого подхода только устанавливают, что важнее люди, продукт, сотрудничество и готовность к изменениям, но ни в коем случае не исключают процессы/инструменты, документирование, условия контрактации и наличие первоначального плана.
Твоя история хорошо иллюстрирует проектную работу в стиле Agile, но не более чем схематично. С момента первой презентации первого рабочего прототипа (даже в режиме «кинотеатра», т. е. без активного участия конечных пользователей) задача проектной команды — стимулировать проактивную позицию конечного пользователя, то есть заставить его начать формулировать тезисы в трёх жанрах:
• явные ошибки функциональности;
• детализация или коррекция ранее сформулированных требований;
• формирование новых функциональных требований или отказ от ранее сформулированных.
Вы явно прошли все три этапа. Ваша технология совершенствовалась (устойчивость результатов повышалась, вы расширяли её применение к разным портфелям), у вас появлялась новая функциональность (подтверждение качества моделей, прогнозирование процентных и комиссионных платежей, пеней, МСФО 9).
Продолжение следует...
Начало диалога: часть 1, часть 2, часть 3, часть 4.
© С. А. Копылов, CFA, FRM
