ИдаПроджект 
Тендеры и лиды
Информация
Меня зовут Иван Ромашов, я руководитель отдела продаж в ИдаПроджект. За четыре года в компании прошёл путь от проектного менеджера до человека, который выстраивает продуктовые процессы для крупнейших девелоперов страны. ИдаПроджект — цифровой партнёр девелоперов, больше 12 лет разрабатывает цифровые продукты для компаний из топ-100 ЕРЗ.
Об этом мы недавно сняли 16-й выпуск «Ида.Инсайт» — серии видео про технологии, маркетинг и изменения в девелопменте. Здесь расскажу, чем цифровой продукт в недвижимости отличается от обычного e-com, что такое продуктовый подход, как понять, что команда превратилась в «фабрику фич», и как на практике выглядит переход к работе на результат — на примере одного из наших клиентов, компании А101, которая прошла путь от спонтанной реализации задач до продуктового подхода, приносящего результат в зелёных цифрах.
Начнём с определений. В девелопменте цифровой продукт — это надстройка над квартирой за 15–20–30–40 миллионов рублей. Если личный кабинет или витрина работают плохо — это не просто баг, это удар по доверию к бренду. Поэтому просто делать фичи здесь не сработает.
К тому же у девелоперов цифра стоит на стыке сразу нескольких департаментов: маркетинг, сервис, продажи — и у каждого свои цели и задачи. Всё это рвёт цифровой продукт на части.
Путь клиента разрезан на куски: онлайн-заявка живёт отдельно от визита в офис. Из-за отсутствия единой концепции пользователь спотыкается, а продукт выглядит как набор разрозненных сервисов, а не единый организм.
Мы видим действия пользователя, но не видим его путь целиком. Без сквозной аналитики невозможно понять, где именно «отваливается» сделка в длинном цикле — управление продуктом становится интуитивным, а не основанным на данных.
И третье: в девелопменте цена ошибки в проектировании умножается на длительность цикла. Чем позже находим ошибку в логике процесса, тем дороже она обходится бизнесу в реальных деньгах.
Так какие задачи приоритетнее? И если спринты закрываются, а релизы выходят — значит ли это, что продукт становится лучше?
Продукт девелопера начинается не с дизайна и не с разработки. Он начинается с вопросов: что именно мы улучшаем? Как поймём, что стало лучше? И что будет, если мы этого не сделаем? А ответить на эти вопросы может только конечный покупатель.
Продуктовый подход — это подход к развитию и внедрению решений, в котором главное — ценность для пользователя и результат для бизнеса. Оценивать в нём нужно метрики, а не бюджеты и сроки, и всегда работать над улучшениями на основе аналитических данных и обратной связи.
В современных методологиях, которые базируются на исследованиях и практическом опыте, принято выделять два параллельных процесса — Discovery и Delivery, или же Upstream и Downstream Kanban.
Цель Discovery — анализ конкурентов, сбор информации о пользователях, генерация и проверка гипотез, чтобы обеспечить связь между бизнес-целями, выраженными в цифрах, и технической реализацией. Discovery фокусируется на проблеме и её решении, а Delivery — на надёжной реализации. Благодаря этой синергии команда чаще делает то, что даёт экономический эффект.
Простой пример: вместо 10 фич без валидации команда разработки делает 4–5, но прошедших Discovery, и каждая из них заметно влияет на метрики. Это увеличивает «time to money», даже если «количество релизов» внешне не выглядит огромным — эффект отражается на time to market, то есть на скорости разработки.
Разделение процессов в первую очередь связано с уменьшением количества «лишних» фич: за счёт этого ускоряется вывод более ценных фич на рынок и улучшаются продуктовые метрики.
Ещё в 2016 году Джон Катлер, один из ведущих экспертов в продуктовом менеджменте, ввёл понятие «фабрика фич» — конвейер, который штампует улучшения без реальной ценности для бизнеса. Вот пять признаков, по которым можно проверить, не является ли ваш продукт такой фабрикой:
• Отсутствие связи с метриками. Фичи выпускаются, но никто не измеряет, как они повлияли на удержание, доход или удовлетворённость пользователей.
• Бэклог как список покупок. Планы на год вперёд забиты конкретными решениями, а не проблемами, которые нужно решить.
• Культ «скорости». Главное — успеть к дедлайну, качество и пользовательский опыт часто приносятся в жертву.
• Отсутствие итераций. После релиза команда сразу переходит к следующей задаче, никогда не возвращаясь к предыдущей фиче, чтобы доработать её на основе фидбека.
• Дистанция между разработкой и клиентом. Разработчики не понимают, зачем они это делают, и никогда не общаются с реальными пользователями.
Важно понимать: это не две разные команды, а одна и та же группа людей, которая работает в двух направлениях.
В Discovery входят продакт-менеджер, который отвечает за ценность и жизнеспособность бизнеса и решает, какую проблему мы лечим; дизайнер, который отвечает за юзабилити, рисует прототипы, готовит макеты к исследованию и проверяет, поймёт ли пользователь интерфейс; тех-лид, чья задача на этом этапе — не писать код, а сказать «это мы сделаем за день, а это потребует переписки всей архитектуры, давайте поищем другой путь»; проджект-менеджер, который следит, чтобы Discovery-цикл не затягивался, и соединяет процессы; и аналитик, который ищет аномалии в данных, строит продуктовые дашборды и помогает запускать и проверять гипотезы.
В Delivery остаются продакт, проджект, тех-лид и дизайнер, к ним подключается команда разработки — дизайнеры, разработчики и тестировщики.
По данным McKinsey, генеративный ИИ уже сейчас удваивает скорость написания кода. Это означает, что мы можем вдвое быстрее создавать продукты, которые никому не нужны, если не сменим парадигму мышления. Разработка перестаёт быть тормозом — именно Discovery становится главным узким горлышком. Но как бы быстро мы теперь ни писали код, сам принцип работы с продуктом — разделение на «найти решение» и «исполнить его» — остаётся незыблемой базой. В дорогом девелопменте это единственный способ гарантировать, что мы создаём ценность, а не просто сжигаем бюджет на высокой скорости.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13752 тендера
проведено за восемь лет работы нашего сайта.
По нашему опыту, при появлении этапа Discovery time-to-market крупных фич сокращается на 35–40%, резко падает количество правок, уменьшается количество багов на продакшене, а разработка в итоге становится дешевле при большем объёме фич.
А главное — до разработки вообще не доходят десятки процентов идей. В этом и заключена суть подхода: нарисовать концепт — это дёшево, например, десятки тысяч рублей, и не страшно положить его в стол. А реализовать нерабочую фичу — это уже сотни тысяч, а иногда и миллионы рублей, причём порой без окупаемости затрат.
Разберём это не в теории, а на практике — на примере компании А101, одного из крупнейших застройщиков страны, который прошёл путь от спонтанной реализации задач до продуктового подхода.
Первое, что изменилось — принятие решений. Появился тот самый ныне популярный вопрос «а зачем?». В этом кейсе он помог глубже разбираться в целеполагании задачи и «хотелках», что повлекло за собой корректировку ТЗ и более точную постановку задачи.
Хаоса стало меньше практически на всех этапах — но уже после того, как появилось корректное ТЗ с пониманием конечного результата. Да, это добавило работы продактам, зато отсеяло много задач ради задач, и появилось понимание, что всё нужно проверять, изучать и анализировать.
Изменилась и срочность выполнения задач: команда перестроилась в сторону качественной оценки и проверки результата, и дедлайны «вчера» стали редкостью, потому что появилось понимание — лучше проанализировать, прежде чем брать в работу.
Команде стало понятно, в каком направлении она движется, — а значит, стало проще масштабировать и улучшать функционал, процессы и структуру. Бизнес, в свою очередь, стал больше доверять продукту, потому что на выходе транслируется не то, как работает функционал, а то, какую именно проблему решили и на что это повлияло в сравнении с предыдущим результатом.
Специфика девелопмента. В девелопменте продукт — это не только сайт или приложение. Это всё, что стоит за этим: маркетинг, продажи, сервисная компания, колл-центр, регионы, ипотека, брокеры. И всё это должно работать как единая экосистема. Ключевые сложности здесь такие:
• длинный цикл сделки — нужно уметь отслеживать путь клиента на каждом этапе, ведь между ключевыми конверсиями большой лаг, и важно понимать, на каком этапе клиент отваливается и что стало триггером покупки;
• онлайн и офлайн процессы обязательно должны полностью коррелировать внутри компании, и при переходе от одного к другому должна сохраняться вся история;
• много стейкхолдеров, и у каждого свой KPI, но важно, чтобы все они были направлены на общую единую цель бизнеса;
• регионы часто живут своей жизнью — с установкой «у нас это не работает», при этом ничего не проверяя, — устоявшиеся понятия и стереотипы тормозят изменения;
• без сквозной аналитики все смотрят на разные цифры;
• нет ощущения, что всё должно работать как единый организм, — а любой пользовательский путь должен бесшовно переходить от одного этапа к другому, и везде должна отслеживаться единая концепция.
Вне зависимости от масштаба компании многие наши клиенты становятся заложниками внутренней политики. Когда маркетинг, продажи и IT действуют как независимые государства со своими целями, а клиентский путь рвётся на стыках департаментов, без единого центра принятия решений вместо синергии мы получаем постоянную конкуренцию отделов внутри одного проекта. Без общей системы целеполагания здесь вообще невозможно двигаться.
Решение — двигаться итерационно, обязательно привязывая результат к общей цели компании. В случае А101 команда выстроила методологии и процессы принятия задач, установила общее дерево целей, ключевых результатов и метрик на все департаменты — в частности, реализовала с кросс-функциональной командой из разных подразделений корпоративную часть сайта по методологии OKR, а затем внедрила эту методологию и в отдел веб-ресурсов. Общие цели компании транслируются на весь организм — продукт не живёт сам по себе, а привязан к бизнес-результатам.
Иными словами, цифровой продукт перестаёт быть «игрушкой» со своей вкусовщиной и становится частью бизнес-модели.
Но даже когда цели есть, часто возникает другая ловушка — «сделайте как у конкурента» или, наоборот, «точно, чтобы не было похоже на конкурента». Это опасный подход: за каждой фичей стоит не интерфейс, а бизнес-процесс, и обязательно нужно учитывать целеполагание и то, как решение может повлиять на сам продукт. Слишком много нюансов — и часто непонятно, как было принято решение о реализации функционала у конкурентов и отрабатывает ли он должным образом. Поэтому важность определения целей и проверки гипотез стоит особенно остро — иначе на выходе получается одинаковый функционал, который никому не приносит нужного результата. А порой мы даже не знаем, дал ли результат тот функционал, который скопировали, — и рискуем повторить чужую ошибку.
Как организовали Discovery. На практике изменения выглядели так: разделили процессы Discovery и Delivery, начали собирать бэклог на 2–3 спринта вперёд, стали глубже работать с данными, усилили growth hacking — то есть работу с гипотезами, ввели wip-лимиты, чтобы не утопать в идеях, и, самое важное, привязали ключевые результаты к каждой задаче.
При этом изменения не оказались дорогими — команда, наоборот, много сэкономила. Показательные примеры — «карта коммерции» и переименование классов жилья: точечные, недорогие решения, которые дали заметный эффект в деньгах.
Если собрать всё вместе, продуктовый подход даёт три вещи: экономию бюджета, фокус команды и предсказуемость результата.
С чего начать девелоперу, если он хочет идти в эту сторону:
• научиться на начальном этапе отсеивать задачи и брать в работу только те, чьё влияние уже проанализировано;
• принять как неотъемлемую часть процесса, что все задачи должны заканчиваться конечным результатом и влиять на бизнес;
• убедиться, что весь бизнес-процесс — единый организм: от первого касания бренда до итоговой конверсии в передачу ключей, и все работают на единые цели;
• внедрить стратегическое и тактическое планирование;
• регулярно работать с метриками — через воронку метрик или продуктовую воронку;
• общаться с бизнесом и клиентами через маленькие эксперименты и исследования, чтобы получать обратную связь и работать с ней дальше;
• не бояться говорить «не знаем, надо проверить» — или отказывать в реализации, если гипотеза не подтвердилась.
Если формулировать коротко, продуктовый подход — это когда вместо того, чтобы измерять успех количеством закрытых задач, вы измеряете его изменением бизнес-показателей. Вместо того чтобы принимать требования от стейкхолдеров «как есть», вы изучаете «боли» пользователей и проверяете гипотезы. Вместо жёсткого roadmap на год вы используете гибкие дорожные карты, ориентированные на результат (outcome-based roadmap). И вместо того чтобы считать разработку только инструментом реализации, вы вовлекаете команду разработки в обсуждение проблем и проектирование решений.
Discovery и Delivery, OKR, wip-лимиты, growth hacking — это всё инструменты. Сами по себе они не спасают продукт. Спасает привычка на каждом шаге спрашивать «а зачем мы это делаем» и быть готовым отказаться от красивой, но непроверенной идеи, потому что в девелопменте цена такой ошибки исчисляется не потерянным спринтом, а вполне реальными миллионами.
ИИ ускоряет написание кода и уже в ближайшие годы будет ускорять его ещё сильнее. Но это делает вопрос выбора — что вообще стоит делать — только острее. Если раньше узким местом была разработка, то теперь им становится способность команды находить и проверять правильные гипотезы до того, как в них вложены деньги.
Полную версию разговора с разбором кейса А101 — с цифрами, паузами и живыми примерами, которые не влезли в статью, — можно посмотреть в 16-м выпуске «Ида.Инсайт». Гостем эпизода стал Александр Онин, CPO ГК А101, от первого лица рассказавший о внедрении продуктового подхода в компании.
Возможно, вас зацепит один из других выпусков «Ида.Инсайт» — наша команда регулярно рассказывает в них о технологиях, маркетинге, продажах и управлении в девелопменте.
