Всем привет, на связи Катя Гришина — C#-разработчик Mindbox.

Бывает, разработчик завершил задачу, выполнил все по ТЗ. Но заказчик просит все переделать. Можно сколько угодно ворчать или брать плату за работу, которая не попала в прод. Но ситуацию это не меняет: сырые задачи будут приходить, результат будет уходить в стол. 

Решение — включить продуктовое мышление: задавать неудобные вопросы и не бояться менять ТЗ. В этой статье я на примере Mindbox расскажу, как разработчик может проявлять продуктовое мышление и зачем это нужно. 

Зачем разработчику развивать продуктовое мышление

Джуны и мидлы могут фокусироваться на технической стороне задачи: как написать понятный и рабочий код. Но чтобы расти дальше, полезно смотреть выше: разбираться, зачем нужна новая фича и как она впишется в продукт. Такой подход помогает:

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

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

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

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

Например, наш продукт — платформа автоматизации маркетинга. Один из сценариев ее использования — запуск email-рассылок.

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

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

Что сделали. Мы предложили продакту упростить первую итерацию. Вместо нового раздела в UI решили использовать скрипт, чтобы создавать поля для вычисления данных о покупателях. Его бы запускали разработчики Mindbox для клиентов, которые согласились протестировать обновление. Так мы хотели замерить эффект от нововведения и понять, нужно ли оно пользователям.

Также решили не разворачивать микросервис, а расширить существующую логику. Чтобы вычисления не нагружали систему и не мешали работать другим фичам, добавили ограничение: анализировать данные можно максимум по двум формулам для каждого клиента.

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

Что получилось в итоге. Мы автоматизировали создание вычисляемых полей: добавили раздел, где пользователь может сам настроить нужные критерии и формулу пересчета. Вычисления вынесли на отдельный сервис и расширили лимит — теперь можно анализировать данные по 10 формулам. Сейчас обновление работает для всех и им уже пользуется 150 клиентов. Планируем, что до конца года фичу будут использовать 250 компаний.

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

Что бывает, если не разобраться в задаче перед тем, как писать код

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

Какую задачу решали. Есть компании, у которых главный канал продаж — мобильное приложение. Им важно, чтобы покупатель из email-рассылки сразу попадал в него. Раньше по ссылке из письма сначала открывался сайт компании, поэтому клик не связывался с переходом в приложение. Из-за этого маркетолог не понимал, оформили заказ после рассылки или, например из рекламы.

Что сделали. Мы решили добавить универсальные ссылки, которые ведут покупателя сразу на нужную страницу в приложении, без перехода на сайт. Такую возможность просили 10 клиентов, один даже грозился уйти от нас, если ее не будет. Предполагали, что это нужная фича, и через полгода ей будет пользоваться половина клиентов.

Взялись за разработку: описали архитектурные решения в ADR, реализовали и выкатили в релиз. В итоге потратили два месяца.

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

Какие последствия. Сейчас фича не развивается и превращается в легаси: знания о том, как она работает, больше не поддерживаются в команде. Поэтому, если требуется доработка, приходится много времени тратить на изучение кода, прежде чем что-то в нем менять. При этом отключить обновление нельзя. Несколько клиентов продолжают им пользоваться, и придется тратить время на разработку альтернативного решения.

Если бы мы изначально понимали масштаб задачи, выбрали более простое техническое решение: помогли клиентам и при этом сэкономили два месяца работы. Заодно показали бы нашу ценность как разработчиков, которые думают не только о коде, но и о пользе для бизнеса.

Как мы применяем продуктовое мышление на практике

Чтобы развивать продуктовое мышление и быстрее приходить к правильному решению, полезно задавать вопросы продакту и заказчику. Как мы это делаем в Mindbox, расскажу на примере одной из задач.

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

К нам пришел продакт с задачей: «Добавить прогнозное время, когда закончится пересчет. При расчете нужно учитывать, сколько времени займет обработка других сегментов в очереди». 

Шаг 1. Изучаем проблему клиента и уточняем детали

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

В нашем случае маркетологу нужно было знать, когда закончится пересчет сегментов, чтобы планировать кампании. Например, если рассылка должна отправиться в 12:00, в какое время запускать пересчет — в 10:00 или 11:30? Раньше маркетологу приходилось выписывать, сколько времени уходит на обработку нужного сегмента, и ориентироваться на эти данные — это было неудобно.

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

Чтобы понять, что в итоге хочет получить заказчик, полезно уточнить все неясные моменты. Например, какую проблему должна решить фича, что будет считаться результатом и какие данные важно учитывать. Иногда кажется, что вопрос может быть глупым и только тормозит работу. Но лучше задать его сразу: для команды это дешевле, чем потом переделывать код из-за неверно понятой задачи.

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

Шаг 2. Проектируем решение

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

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

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

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

Шаг 3. Проверяем гипотезу

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

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

Какие выводы мы сделали из истории с пересчетом сегментов: 

1. Идеальное решение может оказаться слишком сложным и не принести пользы.

2. Первую итерацию лучше делать простой, чтобы быстро проверить гипотезу в проде.

3. Если упрощенное решение закрывает 80% кейсов — это уже успех. Остальные 20% стоит проанализировать: понять, насколько они критичны для клиентов, как часто встречаются и какую пользу даст решение проблемы. Если доработка окажется слишком затратной, можно предложить альтернативу, например передавать такие кейсы в поддержку.

«Продуктовые» вопросы, которые стоит задать перед началом работы

Чтобы правильно определить проблему клиента и найти для нее решение, перед началом работы полезно ответить себе на вопросы:

• Какую проблему мы хотим решить?

• Кто и как будет пользоваться новой фичей?

• Какие вопросы по задаче остаются?

• Как должен выглядеть результат?

• Сколько времени займет разработка фичи? Устраивает ли этот срок заказчика? Можно ли предложить альтернативное решение, которое получится сделать быстрее?

• Как можно упростить решение?

• Как решение будет поддерживаться и изменяться в будущем?