Чему техлиду научиться у Tinder

На днях стало интересно, как запускаются сервисы с "сетевым" эффектом. И это навеяло интересные аналогии с работы...

Представьте запуск нового дейтинг-приложения: приложение готово, можно создать профиль, можно свайпать людей

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

Это и есть Cold start problem — проблема запуска продукта, ценность которого зависит от других участников. Через этот этап проходили все сервисы, которые держатся на участниках, типа аирбнб, тиндера, фейсбука и тд

——

В книжке The cold start problem разбирается такой запуск через 5 фаз, из которых нам интересны первые 3:

Фаза 1: Cold start

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

• Hard side — кто является дефицитным участником, создающим ценность для остальных?

• Hard problem — какую проблему надо решить, чтобы hard-side остались?

• Zeroes — как выглядит ситуация, когда обещанная ценность у пользователей не возникает?

• Magic moments — как выглядит ситуация, когда система реально работает и дает "вау эффект"?

У тиндера первым маленьким сообществом стал кампус University of Southern California. Hard side — привлекательные люди. Их hard problem состоял в том, что старый онлайн-дейтинг создавал слишком много нежелательного внимания. Тиндер это решает свайпами и метчами

Фаза 2: Tipping Point

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

Фаза 3: Escape Velocity

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

——

Поворот сюжета: представь, что ты техлид, который хочет внедрить clean architecture в подразделение разработки

Провел презентацию, всем рассказал какую это даст пользу и... ничего не поменялось. На самом деле, это и есть нечто похожее cold start problem

Люди не будут применять практику, пока вокруг неё нет примеров, инструментов и общего понимания. Но всё это не появится, пока люди не начнут её применять

И если попробовать это переложить на фазы выше:

Фаза 1: Cold start

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

• Hard side — активные разработчики, которые начнут применять практику и распространять ее другим

• Hard problem — конкретная боль, ради которой надо менять привычный способ работы. Например, что изменение бизнес-правила затрагивает кучу модулей

• Zeroes — разраб пытается применить подход, но не находит рабочих примеров

• Magic moment — "вау" эффект, когда практика облегчает работу. Фичу получается сделать быстро, изолированно и легко протестировать

Для техлида cold start пройден, когда любой разработчик внутри пилотной команды может применять и сопровождать практику без постоянной помощи от автора

Фаза 2: Tipping point

После того как получен опыт с пилотной командой нужно научиться распространять практику на следующую команду

Для техлида tipping point пройден, когда следующая команда внедряет практику быстрее первой и без полного повторения ручной работы

Фаза 3: Escape velocity

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

Больше участников → больше примеров, инструментов и экспертизы → дешевле следовать практике → проще подключать следующих участников

Для техлида escape velocity достигнута, когда новый разработчик осваивает практику через окружение: код вокруг, ревью, инструменты. Без отдельной помощи инициатора

——

И на самом деле, прогнав в голове опыт различных внедрений изменений, в основном они так и выглядели: перевезти узкий контур → научиться распространять на другие контуры → распространяется само

Пользуйтесь!