Управление проектами SI

“Почему SI проекты всегда проваливаются в последний момент?”

5 основных рисков SI проекта и реалистичные стратегии реагирования, с которыми столкнулся PM

SI проекты, как правило, начинаются похоже.

На этапе предложения график кажется осуществимым, и кадров достаточно. Архитектура выглядит многообещающе, и клиент говорит «пожалуйста, позаботьтесь об этом».

Но как только разработка преодолевает 50%, атмосфера начинает меняться.

• Требования продолжают добавляться,

• график интерфейса откладывается,

• разные отделы клиента говорят по-разному,

• ключевые разработчики испытывают выгорание,

• график тестирования начинает сжиматься.

И за месяц до открытия проект фактически оказывается на поле боя.

Люди на месте знают. SI проект — это борьба по управлению рисками, а не по технологиям.

Шаблоны разрушения реальных проектов в основном известны. В этой статье мы рассмотрим 5 наиболее распространенных рисков SI проектов и методы реагирования, которые действительно были эффективны с точки зрения PM.

1. Риск требований (Scope)

Причина, из-за которой проекты чаще всего проваливаются.

В проекте SI самым опасным является не технология. Большинство проблем вызывают требования, которые разрушают проект.

Первоначальное RFP обычно абстрактно. Проблема в том, что проект начинается с того, что каждый понимает это по-своему.

Клиенты думают: «Ну, это должно было сработать», а команда разработки говорит: «Этого не было в спецификации».

Этот разрыв взрывается на позднем этапе.

① Разрастание объема — постепенно добавляются элементы, и проект рушится.

В реальной жизни такое действительно часто упоминается.

«Это всего лишь простая функция, не могли бы вы добавить ее?»

Проблема в том, что чаще всего это не так просто.

Добавили один экран:

• изменяется структура прав,

• вводятся изменения в пакет,

• влияет на API,

• необходимо снова настроить логику статистики,

• часто требуется полная корректировка тестовых случаев.

Если в начале PM начинает принимать это устно, чтобы поддерживать отношения, то в дальнейшем это становится непосильной ношей.

На месте это выражается как «катится снежный ком».

② Если спецификация неясна, в конечном итоге всё перевернётся в последнюю минуту.

Определение требований, сосредоточенное на тексте, рискованно.

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

В итоге на этапе UAT неизбежно прозвучит фраза.

«Я хотел не это ощущение?»

Если на этом этапе направление UI/UX пойдёт не так, проект практически достигает уровня полной переработки.

Точки реагирования PM

На практике предотвратить изменения требований фактически невозможно. Главное — предотвратить «неконтролируемые изменения».

На практике обязательно нужно контролировать три момента.

• Все запросы на изменения должны быть документированы.

• Анализ последствий и одобрение после этого.

• Формализация Trade-off по срокам/стоимости.

Особенно важно это.

«Дополнительные функции возможны, но нужно корректировать сроки или объем».

Если не оставить это замечание официально, позже все вернется на исполнение ответственности.

2. Риски технологий и инфраструктуры

Экран появляется, но система не работает.

Архитектура на этапе предложения всегда выглядит идеально.

• MSA

• Облачно-нэйтив

• Синхронизация в реальном времени

• Обработка больших объемов данных

• Интеграция ИИ

Но реальная операционная среда отличается.

Во второй половине разработки технический долг накапливается одновременно.

① Если вставить новые технологии без проверки их работоспособности, это обязательно приведет к проблемам.

Это часто встречающаяся ситуация на местах.

• Введение в использование фреймворка, который никто не использовал.

• Применение структуры без ссылок.

• Отсутствие опыта работы с открытым ПО

На начальном этапе все выглядит хорошо.

Проблема начинается с интеграционного тестирования.

• Производительность не удовлетворительная

• Переполнение памяти

• Проблемы с транзакциями

• Невозможно воспроизвести сбои.

Когда это происходит, проект превращается не в "разработку", а в "дебаг-организацию".

② График интерфейсов почти всегда срывается

SI-проекты, в конечном итоге, являются связанными проектами.

Интеграция с ERP, группами, внешними учреждениями, PG, устаревшими системами встречается гораздо реже.

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

Ситуация, часто встречающаяся на местах:

• Спецификации API продолжают меняться

• Тестовый сервер не открыт

• Отпуск ответственного

• Ожидание одобрения безопасности

• Фаервол не открыт

В конце концов, команда разработки будет работать только с моковыми (Mock) данными.

И в итоге на реальной интеграции ошибки всплывают.

Точка реагирования PM

Настоящие PM управляют интерфейсом как «отдельным проектом».

На самом деле важно:

• Раннее утверждение определения интерфейса

• Обеспечение контактной сети ответственных за интеграцию

• Проведение еженедельных совещаний по интеграции

• Принудительное соблюдение графика Sandbox

• Предварительное отражение времени фаервола

Это так.

Особенно интерфейсы труднее восстановить, если их закрепляют позже.

3. Риски графика и персонала

В конце концов, проект выполняет человек.

SI — это в конечном счете бизнес для людей.

Какой бы хорошей ни была процесс, если ключевой персонал начинает ломаться, проект тоже пойдет под откос.

① Выход ключевого человека оказывается более критичным, чем ожидалось.

Такой человек есть в проекте.

• PL, который знает всю структуру.

• Разработчик, создавший развертывание в одиночку.

• Ключевой ответственный за интерфейс.

В момент, когда этот человек уходит, проект останавливается.

Проблема в том, что даже если замещающий персонал введен, восстановление не происходит сразу.

Обычно:

• Понимание задач

• Анализ исходного кода

• Понимание домена

это занимает минимум несколько недель.

В проектной практике этот этап принято называть «периодом простоя» (gap period).

② график, как правило, с самого начала является неосуществимым.

честно говоря, в графике SI большинство это графики продаж.

график открытия клиентов считается по обратной хронологии.

поэтому:

• сжатие тестов

• пропуск проектирования

• задержка документации

• повторяющиеся переработки

и продолжаются.

и часто, если график сдвигается, принимаются стандартные меры.

«мы добавим больше сотрудников.»

но на самом деле это замедляет процесс.

потому что существующие сотрудники теряют продуктивность из-за обучения новых сотрудников.

Причина, по которой закон Брукса продолжает повторяться на практике.

Точки реагирования PM

На практике необходимо обязательно управлять следующими аспектами.

• Исключение зависимости от конкретных специалистов

• Принуждение к рецензированию кода

• Поддержание минимальных стандартов документации

• Регулярный обмен проектированием

• Обеспечение резервирования работ

Особенно состояние «без него не обойтись» уже следует рассматривать как возникший риск.

4. Риск коммуникации

Сложнее, чем технологии, это согласование людей

Проект может быть технически успешным, но если не достигнуто удовлетворение заказчика, это провал.

Особенно в крупных SI слишком много заинтересованных сторон.

• Отделы бизнеса

• IT-отдел

• Команда безопасности

• Инфраструктурная команда

• Операционная команда

• Руководство

У каждого свои желания.

① Конфликты внутреннего мнения клиентов неизбежны

Это довольно часто встречается на практике.

Требования отдела продаж и требования управленческой команды различаются, требования от бизнес-подразделений и IT разные, а также различия между требованиями головного офиса и филиалов.

Проблема заключается в внутренних вопросах клиента, но в конечном итоге давление сроков несет подрядчик.

② В системе субподряда границы ответственности размыты.

Чем больше проект, тем более наглядно это видно:

• Публикация

• Фронт

• Бэкэнд

• Интерфейс

• Инфраструктура

Компании действуют независимо друг от друга.

Если здесь неясные R&R, проект быстро превратится в борьбу за ответственность.

На площадке есть самая опасная фраза.

“Это не в нашей области?”

Когда эта фраза начинает звучать, сроки резко сдвигаются.

③ На самом деле самое страшное — это риск CEO.

На площадке PM больше всего боятся не технических проблем.

Это переменные руководства.

Характерный случай:

Мы проектировали и разрабатывали в течение 6 месяцев, но на совещании с директорами вдруг:

“Разве сейчас не нужно использовать AI?”

Одно слово, и направление меняется.

Исполнительный персонал уже понимает, что поздно.

Но проект снова начинает шататься.

В то же время есть риски управления проектом.

• Необоснованный заказ

• Нереалистичный график

• Дешевый контракт

• Обещание бесплатных функций

С площадки проект начинается с убыточной структуры.

Точки реакции PM

Управленческие риски не имеют ответа, кроме «раннего обнаружения».

Поэтому важно:

• Комитет по управлению (Steering Committee)

• Регулярные отчёты для руководства

• Ранний показ прототипа

• Промежуточный обзор демонстрации

Это.

Руководство почти всегда меняет курс на финальном этапе.

5. Тестирование и риск переноса данных

Проект становится действительно рискованным непосредственно перед открытием

Когда начинают появляться экраны второй половины, проект выглядит почти завершённым.

Но на самом деле самый рискованный момент начинается с этого момента.

① Если вы начинаете сокращать тестирование, это уже сигнал тревоги

Если график сдвигается, первое, что сокращается — это тестирование.

Ситуации, часто возникающие на месте:

• Пропуск юнит-тестов

• Сжатие интеграционных тестов

• Проверка только Happy Path

• Не проверенные сценарии сбоев

Если открыть в этом состоянии, в первый день эксплуатации произойдёт авария.

Особенно:

• Одновременные подключения

• Конфликты партии

• Согласованность данных

• Ошибка доступа

чаще всего возникает в операционной среде.

② Перенос данных почти всегда сложнее, чем ожидалось

Унаследованные данные чаще всего повреждены.

• NULL данные

• Несоответствие кодов

• Дублирующие данные

• Ошибка формата даты

• Разрушение согласованности

В день фактической передачи возникают неожиданные ошибки.

Поэтому проектные менеджеры на местах проводят несколько репетиций миграции данных.

Фактический Cut-Over должен быть не «реальной практикой», а «результатом повторных репетиций».

Вывод

SI проект в конечном итоге является проектом управления рисками.

На практике опытные PM часто говорят одно и то же.

Важно не то, что у проекта нет проблем, а то, чтобы он не рушился даже в случае их возникновения.

В проекте SI важным является не совершенство.

• Быстро обнаружить риски

• Делиться, не скрывая

• Ранняя коррекция направления

• выявление решений

Это жизнеспособность проекта.

Действительно опасные проекты в реальной работе — это не проекты с проблемами, а проекты, о которых никто не говорит.

И большинство проектов не ломаются внезапно, когда они ломаются.

С самого начала я продолжал посылать сигналы.

Заключение: 'Три основных принципа управления рисками PM' для успешных проектов SI

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

[Ключевой цикл управления рисками]

정기적인 위험 식별(WBS 기반)

  ▼

  투명한 시각화(Red / Yellow / Green)

  ▼

  신속한 에스컬레이션(공식 채널 활용)

Во-первых, визуализируйте и делитесь открыто (конец показной Green отчетности)

Во многих проектах риски скрываются до отчетного периода, и лишь в критический момент ситуация оказывается в состоянии 'красный'. Если возникают признаки риска, их следует немедленно отразить в еженедельном отчете и на дашборде. Проблема должна быть доведена до сведения как можно раньше, чтобы получить техническую поддержку на уровне головного офиса или иметь возможность переговоров с клиентом по уточнению объема работ.

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

Хорошие отношения с клиентами не поддерживаются только удовлетворением всех требований. Наоборот, при открытии с некачественным продуктом отношения полностью разрушаются. Все изменения требований должны фиксироваться в письменном виде, и необходимо четко рассчитывать дополнительные затраты и влияние на график, чтобы утвердить культуру получения одобрения через систему (CCB).

В-третьих, стоит рассмотреть 'безопасный поэтапный запуск (Phased Rollout)', а не стремиться к идеальному открытию.

Запуск всей системы по методу 'биг-банг' подразумевает слишком большие риски. Рассмотрим возможность сначала открыть систему (Pilot Open) по ключевым модулям, определенным точкам или конкретным группам пользователей для проверки стабильности, а затем постепенно расширять применение, выстраивая архитектуру и стратегию графика.

Проект SI похож на плавание по бурному морю. Когда неизвестно, когда начнется буря, наличие надежной карты (контрольного списка) и прочной устойчивости (процесса управления рисками) позволит каждому проекту успешно достичь цели — доставить продукт в срок. Насколько безопасен ваш текущий проект?

Daniel(L)