Несмотря на немного биологический заголовок, в этом посте мы обсудим старые добрые продуктовые проблемы. Меня зовут Александр Федюнин, я пришел в Спортмастер в 2019 системным аналитиком, а сейчас — PL продукта «SM 3.0», о котором вы могли читать в предыдущих постах нашего блога. Я расскажу вам, как мы пытались придумать что‑то новое, чтобы быстро решить проблему с ресурсами и не потерять в скорости и качестве разработки.

Исторический экскурс

Начнем с того, что продуктовый подход как сущность был придуман маркетологами. В 1932 году Нил Макелрой, который работал в Procter & Gamble, решил, что стандартных маркетинговых инструментов ему уже не хватает, а более плотно развивать пользовательский опыт хочется. Он в то время как раз отвечал за продвижение мыла марки Camay. Как вы понимаете, продвигалось оно неплохо.

Другой важный этап в развитии продуктового подхода — опыт Hewlett‑Packard. Эти ребята в свое время решили, что чем ближе клиент (или конечный пользователь продукта) к точке принятия решения по этому продукту, тем успешнее будет сам продукт. И стали создавать команды, такие мини‑организации, которые полностью отвечали за весь цикл выпуска продукта, от идеи до выхода на рынок. А если численность такой организации начинала подкрадываться к 500 человек, ее делили на более мелкие части.

А ещё был послевоенный опыт Toyota, когда в ресурсах был жуткий дефицит, и компания приняла решение выпускать машины непосредственно под заказчика — just in time. Производственная система Toyota TPS — всем известна её основа, kaizen, которые стал отправной точкой для множества других полезных фреймворков.

Первый же продуктовый подход именно в разработке ПО — это компания Intuit (1983) и ее продукт Quicken. Бухгалтерский софт для ведения домашней бухгалтерии, был выполнен в формате стандартной чековой книжки и ориентирован на обычных домохозяек, а не матерых бухгалтеров. Ребята из Intuit придумали свою программу, в рамках которой специалисты компании ходили по домам пользователей и смотрели, как они устанавливают этот софт, работают с ним. А затем на основе этого вырабатывали решения по продвижению продукта.

В 1990-х Microsoft и другие крупные компании осознали, что тимлидам дико сложно согласовывать технические детали с заказчиками и конечными пользователями, нужен был какой‑то вменяемый переводчик. Так родилась новая роль — program manager.

В 2001 был подписан Agile‑манифест, предрекший сокращение водопада и развитие гибких методологий. Так что в нулевых развитие продуктового подхода в разработке ПО определяли такие гиганты, как Google, Amazon, Apple. Требования к PM у них были разные, но главный вектор был довольно четко определен.

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

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

Самый просто пример — строительство. Если бетон должен застывать, например, неделю, то тут как ни спеши — раньше он не застынет.

А что если...

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

Год назад мы с командой внедряли интернет‑магазин Funday. Все шло хорошо, мы стали настоящей командой, разогнались, дела пошли в гору и вообще.

Но тут кое‑что пошло не так.

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

А затем я внезапно вспомнил, что после майских праздников наш второй фронтенд‑разработчик должен был улетать в отпуск, уже и билеты давно купил, путевки. Ну что ж, минус два разраба, становится немножко напряженнее. Мы сели, подумали, решили немного снизить вип‑лимиты. Я включил глаза кота из Шрека и снова пошел к бизнес‑заказчику, мол, помните, я говорил, что может случиться подобное? А вот и оно! Но не переживайте, все ОК, HR в курсе, уже ищут замену, да и вообще у нас третий разраб есть, отличный фронт.

У которого в середине мая рождается первенец, и парня тоже приходится отпустить с работы. И вот уже на этот случай у меня плана не было. Конечно, у нас был один фуллстек‑разработчик, но он был на все 100 занят другой задачей.

В общем, пришлось погружаться в полный t‑shape.

У нас был разработчик, который настраивал нам конвейер и занимался инфраструктурой. В текущей ситуации пришлось на время забыть о конвейере и вспомнить основы Vue. Системный аналитик начал программировать, а я вспомнил молодость и стал системно анализировано. Бизнес, конечно, был опечален, но не сломлен.

 — Саша, где девять женщин-то?

Почти‑почти подобрались к сути. Работая в таких условиях, я заметил одну особенность — у нас кратно возрос lead time по задачам. Мы же снизили лимиты, задач стало меньше, но они же не должны были стать больше. Мы очень активно обсудили это на ретро. Обошлось без рукоприкладства, спасибо удалёнке. И решили, что в поток начинают заходить очень большие задачи. Видимо, у нас что‑то не так с декомпозицией.

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

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

Но это все сломалось бы на втором шаге.

Поэтому процесс разработки у нас выглядел так.

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

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

Меня смущали вот эти три квадрата.

И я начал думать, что с ними сделать. Как раз в то время наша команда внедрила механизм фиче‑тогглинга и A/B‑тестирования на продукте. Продукт созрел, а бизнес жаждал.

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

Вообще, я такого не делал никогда и даже слышал не так много о подобном подходе. Но выбор был довольной простой — спокойной объявить дефолт или рискнуть и попробовать. И мы решили рискнуть.

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

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

В этом смысле разработка у нас должна была начать выглядеть так.

Мы заводим фиче‑тогглы на это, три разработчика берут каждый по своему куску и делают их (делают быстрее, ведь куски меньше), плюс разработчики погружены в контекст, ревью проходит быстрее. А тестировщики могут шарить куски кода между собой, так тестирование проходит быстрее. Потом по фиче‑тогглам мы все это собираем и релизим. Судя по графику, все это должно занимать меньше времени.

Результаты

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

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

Но у этого метода, как выяснилось, были ограничения.

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

Так что в такой большой команде, как SM 3.0, это просто не взлетело — много участников, много стейкхолдеров, много заказчиков. Может быть, просто не пришло время. Может быть, надо было где‑то что‑то подправить, и все бы получилось.

Получилось или нет у меня оправдать заголовок — решать вам. В любом случае, я убедился, что в командах, подобных Funday, такое возможно. Это, конечно, не выглядит массовым рецептом или панацеей, но мне не хочется забегать вперед и давать окончательный вердикт насчет этого. Ведь если мы знаем ограничения, то мы можем подстроить под них наш процесс. Вспомним Тойоту и HP. В конце концов, можно формировать команды, подходящие под эту концепцию, и успешно развивать продукт. А может, можно выйти за рамки привычного, хорошо поразмыслив, и, подобно Нилу Макелрою и ребятам из Intuit, совершить революцию? Кто знает…