5 шагов: что делать, если разработка не поспевает за развитием продукта

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

Что случилось?

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

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

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

Мы стали ошибаться в прогнозировании сроков разработки. Раньше на глазок определяли, что новую фичу выпустим недели за две – и если получалось три, то это все равно более-менее всех устраивало. Сейчас гораздо больше времени стал отнимать CustDev, проверка гипотез, а на рынке появилось много конкурентов – чтобы сохранять лидерство, приходится действовать еще быстрее.

Шаг первый: перестроили процессы в команде

Начали изменения с того, что структурировали работу, опираясь на Scrum. Процесс оброс «ритуалами»: подключили все отделы к планированию и обсуждению релиза. Разработчики начали проводить демо-релиз и применять codefreeze. Ежедневные стендапы стали не формальностью, а инструментом реального отслеживания прогресса и принятия экстренных мер при необходимости.

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

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

Шаг второй: приоритет новым технологиям

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

Мы всегда придерживаемся точки зрения, что новое лучше, чем старое. Во-первых, чтобы быть в тренде всех инноваций, которые появляются в нашей сфере. Во-вторых, если успокоиться, то конкуренты рано или поздно обойдут нас с более совершенными технологиями. В-третьих, лучшие разработчики приходят на более современный стек – это важный фактор, если команда постоянно растет и нужны новые люди. Допустим, мы переходим на Spring Framework не только потому, что с ним проще балансировать нагрузку на разные модули, но и потому, что всё больше перспективных разработчиков предпочитают его.

При этом мы за плавный переход – новые фичи строим уже на новых технологиях, а «ядро» переписываем постепенно.

Шаг третий: автоматическое тестирование

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

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

Шаг четвертый: как настроить обратную связь

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

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

И все-таки любая индивидуальная настройка – то, что в перспективе может понадобиться другим, поэтому хорошо бы ввести ее в платформу. Например, у вас один клиент, которому нужна опция, чтобы в личном кабинете можно было работать от нескольких юрлиц, но ведь завтра могут появиться и другие такие клиенты. Мы в этом убеждались неоднократно: сегодня с нашей платформой работают более 30 банков из топ-50, более 200 застройщиков, ключевые российские маркетплейсы. Когда идет активный приток клиентов, довольно часто возникают похожие пожелания по дополнительным опциям.

Шаг пятый: перехватить инициативу

Нельзя рассчитывать только на то, что клиенты уже готовы высказать. Нужно идти и проводить с ними интервью, чтобы выявить, что еще было бы интересно – не только выслушиваем их, но и обсуждаем свои идеи. Такой подход перспективен и для действующих, и для потенциальных клиентов: первые заинтересованы в том, чтобы продукт развивался, вторые могут говорить с позиции «Мы будем с вами работать, если вы реализуете у себя то-то и то-то».

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

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

Как изменения влияют на саму команду?

Надо трезво осознавать, что любые изменения в разработке – это стресс, потому что каждый должен перестраиваться. От кого-то требуют того, чего раньше не требовали, кто-то не привык к дискуссиям. По нашим наблюдениям, легче въезжают новые сотрудники. Но и среди тех, кто давно в команде, не преобладают консервативные настроения, многие рады, что меняются их компетенции: «Раньше я только программировал по поставленным задачам, теперь начинаю заниматься архитектурным проектированием, классно».

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

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

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