Спрос на электромобили будет увеличиваться в среднем на 38% ежегодно, согласно прогнозу по развитию рынка электромобилей в России. Соответствующие данные предоставили аналитики из консалтинговой компании Strategy Partners.
26–27 марта 2024 года в конференц-зале ЦВК «Экспоцентр» (Москва) прошла ежегодная научно-практическая конференция «Российский рынок систем электрохимического накопления электрической энергии и батарейных систем электротранспорта. Проблемы и перспективы». Эксперт «РТСофт-СГ» выступил с докладом о комплексном подходе к проектированию развития инфраструктуры заряда электротранспорта.
В своей предыдущей статье по бюджетированию я рассуждал, как сложно бывает заранее оценить бюджет проекта по разработке ПО. Часто здесь возникает серьезный конфликт между инжинирингом и финансами. Дело в том, что проектные менеджеры и финансовые директора по-разному смотрят на бюджетирование: если первые осознают риски и умеют с ними работать, то вторые просто хотят фиксированный бюджет. Однако все бюджеты строятся на прогнозах, что подразумевает некий уровень неопределенности. Ни один подход не гарантирует вам 100% предсказуемости при разработке инновационного продукта. В подвижном мире технологий постоянно что-то меняется: эволюционируют рынки, возникают новые тренды, смещаются потребительские предпочтения. Значит, и цели проектов могут трансформироваться, требования могут (и будут) меняться, могут возникнуть непредвиденные задержки, а ведь все это риски, которыми надо уметь управлять.
Требования будут меняться – примите это как факт. Изменение требований естественно для проектов по разработке ПО. Однако практика показывает, что 95% заказчиков не понимают этого: сталкиваясь с необходимостью расширить бюджет из-за новых требований, они не могут этого сделать. Тем временем даже в системных разработках этот риск составляет около 20%, в корпоративных – минимум 100%, а если в проекте есть разработка UI/UX, то и трех итераций может быть недостаточно. Да-да, 300% и более, чтобы прийти к варианту, который устраивает заказчика.
Говоря об изменениях, нельзя не упомянуть Agile. Согласно модной методологии, изменения – это возможность выявить и исправить ошибки на ранней стадии проекта и быстрее поставить качественное решение заказчику. Сегодня многие тяготеют к «гибкому» подходу c его быстрой реакцией на перемены, однако некоторые организации оказываются не готовы к работе по Agile. Во-первых, «гибкий» проект требует большой вовлеченности владельца продукта и готовности работать с инженерами 24/7, что часто не учитывается. Во-вторых, «гибкий» подход означает постоянные изменения и грамотное управление ими. Более того, Agile подразумевает регулярные демо (обычно раз в две недели), задача которых – не только показать, что Аурига разработала какой-то новый функционал, но и получить обратную связь от клиента. Что сделано хорошо? Что можно улучшить? Каковы наши краткосрочные цели? В противном случае возникает весьма неприятная ситуация: разработанное решение функционирует и соответствует требованиям, и все же клиент не удовлетворен результатом.
Как опытные и ответственные партнеры, мы всегда предупреждаем об этом своих заказчиков. На этапе бюджетирования проекта мы стараемся убедиться, что клиент осознает риск изменения требований и закладывает достаточный бюджет на управление им. Делая это, мы сами себя подвергаем большому риску, ведь клиент может уйти за более дешевой альтернативой. (Такое в самом деле случалось, но не раз такие заказчики возвращались к нам через полгода, исполненные неоправданных ожиданий). Тем не менее, если риск изменения требований не будет учтен изначально, конфликт непременно назреет позже и разрастется как снежный ком.
Очевидно, инженерная команда работает не в вакууме: разработчики сотрудничают с командой заказчика и различными отделами, вендорами, поставщиками, партнерами и т.п. Крайне важно, чтобы все звенья этой сложной цепочки взаимозависимостей работали слаженно. К примеру, если мы интегрируем одну систему с другой, эта система должна быть готова на стороне заказчика. IT-отдел должен предоставить нам логины, развернуть необходимые системы, проапдейтить сервера до нужных версий, наладить работу соответствующих библиотек… Но мы работаем с людьми, а люди могут забыть, не успеть или просто уйти в отпуск.
Риск срыва зависимостей неизбежен, кто бы что ни обещал. Как правило, этот риск увеличивает стоимость проекта на 20-30%. Вот почему мы всегда просим заказчика подготовиться к проекту за 1-2 месяца до старта. Если риск все же наступает в процессе, мы пытаемся смягчить его, выполняя другую часть проекта, хотя начинать строить дом с крыши – не очень мудрое решение.
Многие утверждают, что проектные менеджеры бесполезны в Agile. Методология SCRUM, заявляют они, подразумевает наличие SCRUM-мастера и владельца продукта, а для проектного менеджера здесь места нет. И все же давайте подумаем. Мы разрабатываем нечто «законченное» и измеримое в рамках времени, бюджета и качества. Значит, мы имеем некие сроки и ограничения. Кто будет ответственным за их выполнение? Видимо, владелец продукта.
И вот здесь возникает огромный риск: владельцы продукта отлично знают свою бизнес-сферу, но обычно у них мало опыта в разработке ПО. Большинство из них искренне верят, что внедрение функций «минимально жизнеспособного продукта» (MVP) уже позволяет загрузить решение в Google Market. А что насчет регрессионных тестов и тестирования безопасности? Сколько времени это займет? Пару недель? А сколько раундов? И как быть с багфиксингом? Возникает слишком много вопросов.
В лучшем случае вы превысите сроки на несколько месяцев, хотя обычно бывает хуже: программный продукт не создает синергии в наборе безупречно внедренных пользовательских историй, то есть он почти бесполезен. Почему так происходит? Потому что никто не заботится об этом, ведь Agile этого не предусматривает! Однако в любом проекте на свете должны быть тактика и стратегия. Можно выиграть битву, но проиграть войну. Кто-то (а именно опытный проектный менеджер) должен быть ответственным за стратегию, иначе отсутствие стратегического видения может стоить вам проекта.
Разработка инновационных программных решений полна рисков, нравится нам это или нет. В этой короткой статье я упоминаю только некоторые из них: несмотря на то, что их часто недооценивают, они могут существенно влиять на бюджеты и результаты проектов. Конечно, есть и много других рисков: стратегических, операционных, технических и прочих. Не надейтесь избежать их по счастливой случайности и не игнорируйте их на свой страх и риск. Позаботьтесь о них заранее! Выделяйте соответствующий бюджет, время и ресурсы на управление рисками и сотрудничайте с надежными поставщиками, чтобы смягчить и минимизировать риски.
— Вячеслав Ванюлин, Генеральный директор ООО «Аурига»
