От Agile к гибкости: как в Magora Systems помогают российскому бизнесу расти

𝓲

Фото: Личный архив Алексея Чернеги

Agile в консервативной среде: как убедить заказчика

— Российские заказчики часто скептичны к Agile. Как вы «продаете» гибкие методологии? Приведите пример успешного гибридного подхода.

— Российские заказчики, особенно из традиционных отраслей или государственного сектора, действительно с настороженностью относятся к Agile. Часто Agile воспринимается как хаос или «отсутствие четкого плана». Поэтому моя задача — не навязывать терминологию, а показывать ценность подхода на конкретных результатах. Я не предлагаю внедрить Scrum, а предлагаю составить план с короткими циклами, чтобы быстрее получать обратную связь и снизить риск ошибок.

В таких случаях я использую гибридный подход, при котором сохраняются элементы классического управления (документация, этапы, согласования), но внутренняя работа команды строится по принципам Agile: короткие итерации, регулярные демонстрации, приоритизация задач и быстрая адаптация к изменениям.

Один из ярких примеров — проект для крупной российской логистической компании. Клиент настаивал на фиксированных сроках и жестких контрольных точках. Мы согласовали каскадную модель по этапам (исследование, проектирование, интеграция, запуск), но внутри каждого этапа использовали спринты по 2 недели, ежедневные синки и демоверсии по каждой функциональной группе. Ключевым моментом стало то, что в каждом демо участвовал заказчик, который видел прогресс и сам инициировал изменения по ходу проекта, хотя изначально требовал строгого следования техническому заданию.

В результате сроки были соблюдены, но самое главное — конечный продукт оказался более адаптированным к бизнесу клиента, чем если бы мы следовали только исходному техническому заданию. Такой опыт — лучшее доказательство эффективности гибких подходов даже в консервативной среде.Международный конгресс по anti-age и эстетической медицине — ENTERESTET 2026

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

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

На уровне бизнеса ключевыми показателями становятся уровень использования продукта, скорость выхода на рынок (Time-to-Market), окупаемость инвестиций (ROI) и показатели активности пользователей — удержание, внедрение функций, коэффициент оттока. Если проект влияет на внутренние процессы заказчика, мы оцениваем, насколько повысилась эффективность: сократилось ли время выполнения операций, уменьшилось ли количество ошибок, повысилась ли прозрачность данных. Все это заранее обсуждается с клиентом и формализуется в виде KPI.

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

Для оценки долгосрочной ценности продукта я использую метрики после запуска: количество инцидентов, стабильность архитектуры, масштабируемость, технический долг. Если спустя 3–6 месяцев продукт активно развивается, получает обновления, адаптируется к новым условиям, значит, мы создали не просто MVP, а жизнеспособную платформу. Важно также учитывать количество повторных заказов или продолжение сотрудничества с клиентом — это один из лучших показателей реальной ценности работы.

Основные навыки PM: от SDLC до эмоционального интеллекта

— Какие hard и soft skills вы прокачиваете в первую очередь?

— Я рассматриваю развитие Project Manager как системную работу в двух направлениях: технологическая грамотность и управленческая зрелость. Поэтому в первую очередь я прокачиваю те hard- и soft-навыки, которые помогают быть не просто координатором, а полноценным лидером продукта и команды.

Из hard-скиллов — глубокое понимание жизненного цикла разработки программного обеспечения, владение инструментами управления (Jira, Confluence, Notion, Miro), знание гибких и гибридных методологий (Scrum, Kanban, SAFe, Waterfall). Также важно уметь читать и интерпретировать метрики — Time-to-Market, Velocity, Cycle Time, Retention, Churn. Я регулярно прокачиваю навыки в области системной аналитики, чтобы понимать, как требования превращаются в архитектурные решения и как это влияет на сроки и риски.

Из «мягких» навыков на первом месте — коммуникативная гибкость. Умение донести смысл до разработчика, клиента, дизайнера, юриста — разными словами, но с единым смыслом. Важно уметь слушать не для того, чтобы ответить, а чтобы услышать. Далее — управление неопределенностью: готовность работать в условиях неполных данных, конфликта интересов и меняющихся вводных. Навык фасилитации — тоже один из базовых: если менеджер проекта умеет вести диалог, управлять совещаниями и принимать решения в группе, проект движется.

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

Гибкость в действии: как выжить в Web3-проекте

— Как вы работаете со стартапами, где требования меняются ежедневно? Какие framework’и лучше всего подходят?

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

В таких проектах я использую сочетание методов бережливого стартапа, Agile (Scrum или Kanban) и Product Discovery. На начальном этапе основное внимание уделяется Discovery — формулируются гипотезы, проводятся кастдевы, собираются рыночные данные. Далее следуют короткие спринты (часто по 1 неделе) и приоритизация с помощью фреймворков типа RICE или ICE. При этом дорожная карта строится как набор версий гипотез, а не как фиксированная линейная шкала.

Управление задачами и коммуникацией осуществляется через Notion и Jira с минимальным формализмом, но высокой прозрачностью. Ежедневные сводки, еженедельные демонстрации и, самое главное, обязательный обзор с заказчиком, чтобы убедиться, что мы решаем ту же проблему или она изменилась.

Пример — один из Web3-проектов, в котором команда меняла концепцию токеномики 4 раза за 6 недель. Вместо того чтобы пытаться «дисциплинировать хаос», мы внедрили модель гипотез с показателями успеха, быстро отсеивали нерабочие идеи и фокусировались только на том, что пользовалось спросом у аудитории. Это позволило не просто «дожить до релиза», а выпустить продукт, который действительно решал проблемы пользователей.

В инновационных проектах успех определяется не стабильностью требований, а скоростью адаптации. Менеджер проекта здесь — не администратор, а навигатор в условиях высокой неопределённости.

Специфика FinTech и HealthTech: где скорость, а где – точность

— Чем управление проектами в этих domain’ах отличается? Где больше бюрократии и рисков?

— FinTech и HealthTech — два совершенно разных направления с точки зрения управления проектами, хотя оба требуют высокой точности, надежности и соответствия нормативным требованиям. Но природа рисков, темпы изменений и стиль взаимодействия с заказчиком в них принципиально различаются.

В сфере финансовых технологий основное внимание уделяется финансовой безопасности, устойчивости к нагрузкам и соответствию нормативным требованиям (KYC, AML, PCI DSS, ISO 27001, SOC 2). Здесь больше технологических и юридических рисков: малейшая уязвимость в логике транзакций или доступах может привести к серьезным потерям. Но в сфере финансовых технологий часто больше свободы в плане UX/UI и экспериментов с выходом на рынок. Продукты должны быть быстрыми, гибкими и конкурентоспособными, особенно если речь идет о сегменте B2C. Регуляторная политика строгая, но предсказуемая — её можно заранее встроить в процессы.

В сфере HealthTech основные риски связаны с жизнью и здоровьем людей, поэтому здесь ключевое внимание уделяется точности обработки данных, этике и соответствию отраслевым стандартам: GDPR, HIPAA, MDR, ISO 13485. Любая ошибка в отображении информации, расчете дозировки или интерпретации результатов может привести к критическим последствиям. Поэтому здесь больше бюрократии, особенно если продукт выходит на европейский рынок. Отчетность, аудит, многократные согласования — часть каждого этапа. Работа с врачами, пациентами, исследовательскими институтами требует высокой эмпатии и тщательной проработки требований.

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

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

Управление знаниями: как превратить опыт в актив

— Как вы организуете обмен опытом между проектами? Какие инструменты используете?

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

В первую очередь, я внедряю единый репозиторий знаний — чаще всего это Notion или Confluence. В нем создаются шаблоны для проектной документации, глоссария, базы типовых решений, ретроспектив, багов и архитектурных находок. Каждая команда заполняет их по итогам ключевых этапов: Discovery, MVP, релиз, анализ после запуска. Важно, чтобы эта информация была структурирована и легко находилась — без «захоронений» в архивах.

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

Кроме того, я внедрил в компании формат PM-клубов, где руководители проектов делятся кейсами: что сработало, какие фреймворки применялись, как решались кризисные ситуации. Это помогает синхронизировать подходы и избегать повторения ошибок.

Также важна поддержка новых участников: у нас настроен onboarding-путь, в который включен доступ к базе знаний, гайды по процессам, рекомендации по инструментам и менторство со стороны опытных PM. Это особенно важно в распределенных командах, где не хватает неформального обмена опытом.

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

Как стать Senior PM: советы и рекомендации эксперта

— Что бы вы посоветовали тем, кто хочет вырасти до Senior PM в международной компании?

— Первое, что нужно понять — Senior PM в международной среде это не просто опыт + английский. Это управленец, который умеет работать с неопределенностью, коммуницировать на уровне ценностей и брать ответственность за результат вне своей зоны комфорта. Поэтому путь к Senior начинается не с сертификатов, а с внутренних принципов.

Мой первый совет — учитесь управлять не задачами, а контекстом. Senior-менеджер не ждет постановки — он умеет разобраться в бизнес-цели, выстроить процесс с нуля, синхронизировать интересы команд, клиента и пользователей. Это требует системного мышления и навыка договариваться на уровне «почему?», а не «что делать?».

Второе — инвестируйте в развитие soft-skills: навык слышать, договариваться, убеждать и конфликтовать конструктивно. Чем выше уровень, тем больше ваша работа — это фасилитация, принятие решений, коммуникация в условиях стресса. Эти навыки невозможно прокачать за один курс — только через практику, фидбэк и работу с ментором.

Третье — расширяйте горизонты: работайте в разных доменах, пробуйте международные проекты, выходите за пределы роли. Знание индустрий, понимание технической архитектуры, владение несколькими фреймворками управления — это отличает Senior от просто опытного PM. Важно уметь адаптироваться под разные контексты — от стартапа до enterprise.

Четвертое — берите на себя ответственность раньше, чем «положено». Ищите зоны, где вы можете усилить процесс, взять инициативу, закрыть «белое пятно». Senior — это не должность, это поведение. Если вы так себя ведете — вы уже на этом уровне.

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

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

Автор: Николай Бородин