Начало диалога: часть 1, часть 2, часть 3.
Важное предупреждение. Все примеры, приведённые в статье, не отражают реальные ситуации, относящиеся к конкретным лицам, и являются плодом художественного вымысла. Все возможные совпадения случайны, но лишь подтверждают актуальность этих примеров.
Информационно-технологические решения и проекты по их внедрению
ALM: Практически нет. Информационные технологии — очень важная тема. Я лишь повторюсь, сказав, что банковский бизнес — это всего лишь биты и байты (Banking is about bits and bytes — John Reed, CEO of Citi Bank). Но я всё-таки считаю, что в обывательском восприятии их значимость гипертрофирована. Хорошие методики и порядки взаимодействия подразделений первичнее (Копылов С. А. Новая стратегия для получения новой прибыли в новом мире // https://www.bsc-consult.com/bscnews.php?id=69). Информационно-технологическая разработка появляется потóм и в этом проекте мы до неё закономерно не дошли.
PM: Ты прав. Серьёзный проект не может сводиться только к разработке или настройке программного обеспечения, необходимо осуществить работы, определяющие что и как разрабатывать и настраивать:
• разработка методологии продукта, услуги, принципиальных подходов к управлению и/или обеспечению профильного бизнеса;
• инжиниринг или реинжиниринг бизнес-процессов, порождающие базовый набор функциональных и эксплуатационных требований.
• разработка функциональных требований, целевой архитектуры, требований по интеграции с другими ит-системами, требований безопасности и т. д., в которые выливается сочетание первых двух пунктов — методологии и порождаемых или изменяемых бизнес-процессов.
Более того, разработкой или настройкой программного обеспечения ни один проект не исчерпывается. Необходимо в дальнейшем обеспечить:
• миграцию и чистку данных из выводимых из эксплуатации систем;
• опытную или опытно-промышленную эксплуатацию, обеспечивающую стабилизацию функциональности и эксплуатационных требований;
• нагрузочное тестирование;
• финализацию технической документации;
• разработку руководств пользователя и обучение функциональных пользователей (иногда необходима даже сертификация);
• изменения организационно-штатной структуры банка (например, как следствие перераспределения существующих бизнес-функций или появления новых);
• формирование собственной технической компетенции по поддержке и доработке данного программного обеспечения;
• организацию поддержки в гарантийном и пост-гарантийном периодах;
• приведение в соответствие технических или операционных регламентов и должностных инструкций.
ALM: Ты формулируешь то, что я всегда ощущал, работая в проектах.
PM: Настройка готовой платформы или разработка программного обеспечения — при бизнес-ориентированном подходе не более чем одна из составляющих проекта внедрения крупных промышленных информационно-технологических решений. Особенно это важно, если одним из результатов проекта является промышленная core system компании, автоматизирующая и координирующая исполнение производственных, управляющих и обеспечивающих процессов, нацеленных на обеспечение основных целей в виде предложения на рынке продуктов или услуг (в т. ч. поддержку решения задач на этапе предпродаж, собственно продажу, гарантийное и постгарантийное или попросту последующее обслуживание клиентов).
ALM: Да, сколько всего нужно учитывать до начала проекта. Но ведь проект требует времени, в течение которого меняется внешняя среда, условия, тренды, настроения акционеров банка и регуляторов, потребности заказчиков, словом, всё! Как это обеспечить? Есть сейчас модный подход к управлению проектами — agile (гибкое управление проектами)…
Agile
PM: А вот это грубая ошибка. Agile — это подход к управлению разработкой программного обеспечения, которая осуществляется как часть проекта и, в зависимости от ситуации, в разных вариантах — SCRUM, Kanban и т. д. Я не случайно перечислил то, что лежит за рамками разработки и, следовательно, не может эффективно управляться на основе agile-подходов. Более того, не всякое программное обеспечение целесообразно разрабатывать с помощью подходов agile. Если заказчик чётко знает, что ему надо (см. выше про методологию + бизнес-процессы), вероятность волатильности требований к результатам снижается. Кстати, ратуя за agile-подход, заказчик получает возможность замаскировать свою не самую высокую компетентность в предметной области: «гибко» начнём и «по ходу» разберёмся, и, главное, что все заняты! Возможность оценки потенциальной волатильности вследствие внешних факторов тоже можно отнести к высокому уровню профессионализма.
ALM: Интересно! А ведь почитаешь, что люди говорят, так agile — это панацея (Панацея (от др.-греч. Πανάκεια) — всеисцеляющее лекарство) в нашем изменчивом мире!
PM: Лекарств универсальных не бывает. Универсальным бывает только яд. Любой разумный проектный менеджер, даже скрупулёзно придерживающийся стандартов PMBOK, применяет элементы agile в своей работе. Нужно только делать это в надлежащей ситуации и главное без потери инструмента управления. Как уже сказано выше, во главе угла должен быть здравый смысл!
ALM: Какой?
PM: Начну с того, что ещё раз подчеркну: Agile — это изначально придуманный подход к управлению именно разработкой программного обеспечения в условиях неопределённости. Это значит, что:
1) область применения ограничена лишь частью проекта, например, при проектировании интерфейса пользователя с учётом его «вкусовщины». То есть уже должны быть закрыты вопросы что (целеполагание, политика), зачем (методология), как (методика), кем и когда (целевой бизнес-процесс, описываемый порядками), в какие сроки (порядки или регламенты);
2) сам проект должен иметь дело с программным обеспечением, при этом все результаты разработки должны в последующем состыковаться между собой (например, когда в основу заложена микро-сервисная архитектура);
3) речь идёт именно о разработке: внедрение готового «коробочного» решения не может управляться так.
ALM: Да, по второму пункту могу добавить. Один мой знакомый делал ремонт в квартире на основе принципов Agile. Сначала от него ушла жена, якобы временно пожить к маме, потом рабочие (и они уже не хотели даже денег за свою работу), потом кончились деньги. А серьёзно, надо пояснить первый пункт: что значит «вопросы закрыты».
PM: Это значит, что у всех лиц, задействованных в проекте, и исполнителей, и заказчиков нет видимых разногласий, и все готовы принять на себя осознанную ответственность: заказчик отвечает за осознание того, что, когда и за какие деньги ему надо, а исполнитель за осознание готовности и способности обеспечить результат на этих условиях.
ALM: Когда нет разногласий, это означает, что проект в некотором смысле закончился. Ведь проект — это перевод системы из одного стационарного состояния в другое, а когда нет разногласий — это стационарное состояние. В общем, так на этом этапе (то есть ещё до разработки программного обеспечения) не бывает!
PM: Не совсем! На этом этапе есть только общее ви´дение результата, только вектор, указывающий на принципиальные условия и направление дальнейшего движения. И эта ситуация не стационарна, в ней высоки риски. Главный риск — это риск промахнуться мимо реальных ожиданий заказчика, которые будут меняться (и хорошо, если это изменение обусловлено не недостатками ви´дения, а внешней конъюнктурой. Цена вопроса — потерянное время и неэффективное использование бюджета, т. е. трудозатраты команды исполнителя, потраченные впустую, выброшенные в урну.
Продолжение часть 5.
Начало диалога: часть 1, часть 2, часть 3.
© С. А. Копылов, CFA, FRM