2. Как все построено в DropBox
Испытания, с которыми мы
столкнулись при
масштабировании
Как мы решаем что создавать
3. Dropbox в цифрах
• Всего год назад:
– 20 человек в команде
– 5 млн пользователей
• Сегодня:
– 55 людей в команде
– >25 млн пользователей
– 100+ млрд файлов
– 300млн файлов ежедневно (1млн
каждые 5 минут, больше чем твитов в
Twitter)
– Платные пользователи в 175 странах
4. Люди > процесс
• Отличные инженеры значительно более продуктивны чем
средние
• Нанимайте меньше, но лучших людей. Они снижают вашу
необходимость быть отличным координатором, планировщиком
и т.д.
• Планируйте/работайте в Google Docs, отслеживайте баги с Trac
• Инженерная команда из ~25 человек разделена на более
мелкие команды, слабо связанные подгруппы
– Клиент, сервер, web, мобильные прил., аналитика/рост, API, и т.д.
– Каждая с собственным роадмэпом, циклом релизов, процессами,
встречами, Google Docs, тестами и т.д.
– Основные протоколы и API резонно заморожены, обеспечивая
слабую связь (a ля Amazon)
5. Найдите великолепных людей…
• …и не мешайтесь под ногами
– Обычно мы не говорим людям как работать – нет
обязательных часов, и т.д.
– Сделайте офис местом, где приятно находиться
– Возьмите любые раб. Станции, инструменты (без
бюджета)
• Минимизируйте накладные расходы и
децентрализируйте ежедневные решения
через культуру/ценности
6. Большие результаты меньшим #
людей
• Один дизайнер интерфейсов (бывший менеджер
сообщества!)
• Серверная команда из 3-х человек управляет
100+ млрд файлов, 10+ петабайтами данных, и
т.д.
• Стратегия: разделяй и властвуй, сохраняй
маленькую команду (не навсегда, но сейчас)
• В процессе роста команды,
ценности/культура/миссия делает более четким
и целенаправленным обучение новых людей
7. Планирование
• Мы не занимаемся много планированием
• Но нам нужно больше когда
– Происходит больше событий
– Круг обязанностей вне разработки
– Люди не знают, что делают другие
– Меньше информации распространяется под давлением
– Когда мы выращиваем внутри себя лидеров, им нужно
остановиться и заняться планированием для их команд
• Некоторое время мы делали слишком
много вещей, и ничего не выводили на
рынок месяцами
8. Цели компании Dropbox
• Смоделированы после Google OСR системы
• Ежегодные и ежеквартальные цели
• Формы иерархии в открытом доступе
– Стратегические цели компании
– Общие цели продукта
– Цели команды (напр, клиентской команды)
– Личные цели каждого
• Лучшее враг хорошего – вашему процессу
планирования тоже нужна итерация
9. Как росла наша компания
• Испытание с масштабированием в том, что
вещи, которые обычно работали начинают
спокойно проваливаться
– “Что мы делаем? Для чего?”
– “Почему то, что я делаю важно?”
– “Что важнее всего?”
• Мы пытались учиться у других компаний
болезням роста; не изобретайте колеса
• Утешьтесь тем, что другие быстрорастущие
компании тоже были в чем-то бестолковыми
11. Запускайте быстро и быстро
проводите итерации…
• …только если вы не делаете
кардиостимуляторов
• Разным группам нужны разные техники
• Наш самый ценный актив: доверие людей. Годы
на создание, секунды на потерю, если данные
когда-либо будут потеряны
• Нужны большие инвестиции на клиентскую
команду, чтобы сохранять быстрый цикл
– Google Chrome, множество других хороших примеров
– Но, чтобы туда попасть нужно много работать! (тесты,
непрерывное развертывание, автоматич. Обновления и
т.д.)
12. Мир более сложен…
• …когда у вас много пользователей
– Больше на карте: платежеспособные клиенты и
общественный контроль
– На раб. столе взрыв окружающей обстановки; невозможно
протестировать все
– Проблема, затрагивающая всего лишь 0.1% пользователей все
еще 25,000 человек когда у вас 25 миллионов пользователей
• …когда в коде много подвижных частей
– Оптимизация производительности и памяти добавляет
сложностей коду
– Сложнее добавлять в команду новых людей, сложнее
добавлять новые функции
13. Не просто быть бережливыми
• Сплит тесты и оптимизация великолепны, но вы
быстро закончите гонку за низко висящими плодами
– Быстрые победы
– …помните, что A/B тесты не сделают вас iPhone
• Аналитика необходима, но ее трудно использовать
– Наша база данных увеличивается в 10 раз за год
• Большинство нервных проектов не имеют MVP
(минимально жизнеспособный продукт), который
легко сделать
– Необходим более высокий уровень координации, усилий
для тестирования идей
– Особенно тестов, требующих польз. интерфейса
14. Создавайте правильные вещи и
создавайте вещи правильно
• Но если вам нужно выбрать что-то
одно, создавайте правильные вещи
– Нет ничего хорошего, чтобы бежать быстро в
неправильном направлении
– Никаких серебряных пуль в софтверной методоголии;
контекст имеет значение
• Мы становимся лучше
– Наш хронический оптимизм медленно вылечивается
– Постановка целей помогает предсказуемости
– Продолжаем инвестировать в основную
инфраструктуру и сокращение циклов
16. Некоторые принципы дизайна
• Все должно “просто работать”
– Не заставляйте пользователей думать
– «Это не только то, на что это похоже и склонно. Дизайн –
то, как это работает." – Стив Джобс
– Юзабилити, скорость, надежность требует постоянного
совершенствования
• Не запускайте ничего, сделанного
наполовину
– Мы обычно запускаем “когда оно готово”, но пытаемся
получить более предсказуемый результат
– “Делать меньше” нормально; Уродливое/запутанное - нет
20. Большие проблемы скрыты на виду
• Для большинства людей, технология не
выдерживание теста “Особого мнения”
– Т.е в “будущем”, Тому Крузу не надо было бы заходить
в свой Gmail или беспокоиться о USB драйверах
• Нерешенные проблемы вокруг нас
– Просмотр фото на вашем телевизоре, прослушивание
музыки в машине, обмен свадебными фото с семьей
• В будущем, все будет “просто работать”,
но совершенно точно не сейчас
21. Подведение итогов
• Это стоит того, тем не менее
• Невероятная награда делать
вещи, которые действительно
используют люди
• Большая аудитория означает, что
мы можем решить большие
проблемы для десятка и скоро
для сотен миллионов людей
• Мы все еще вписываемся в 1
комнату
(пока!)
