ݺߣ

ݺߣShare a Scribd company logo
Coub 2014: Управление быстрорастущим проектом
Управление
быстрорастущим проектом
на примере Coub
Михаил Табунов, CTO
Что такое Coub
- Сайт про короткие зацикленные
видеоролики
- За 2013 год – 120 кратный рост
Начало 2013:
- 1mln MAU
- 2.4mln pageviews
Начало 2014:
- 48mln MAU
- 475mln pageviews
Мы – стартап
- Сделать минимальный продукт
который будет нужен людям
(Minimal Valuable Product)
- Дальше - успешно его
масштабировать и развивать
Процессы в компании
Требования
Реализация
Тестирование
Эксплуатация
Управление продуктом
Управление проектом
Управление качеством
Управление
инфраструктурой
Управление
продуктом
- MVP — это стартовая точка
- Появляется понимание, что как и
для кого мы делаем
- Начинают появляться Performance
Indicators, развиваются метрики
- Мы год искали тот самый MVP
- За этот год перепробовали кучу
нужного и ненужного: три раза
меняли целиком концепцию
- Стало ясно, что мы знаем очень
мало о наших пользователях
Мы не знаем что происходит
- Data-Driven и Data-Informed подходы
- A/B тестирование
- Поиск реально важных метрик,
целенаправленная работа над их увеличением
- Engagement
Наш опыт
- Внутренняя система A/B тестирования
на базе готового решения
- Mixpanel + Google Analytics
- Собственная система записи и
анализа событий
- Движение к плотной интеграции
аналитики в продукт
- Стараемся выкатывать весь новый
функционал через A/B тесты
- Собираем статистику, пусть она
кажется ненужной
- Не боимся убирать редко
используемые фичи
Мы не знаем куда двигаться
- Появилось несколько планов
(Roadmap, месячный план разработки)
- Нужно учится расставлять
правильные приоритеты
- Даже бредовые идеи надо записывать
Наш опыт
Roadmap — всё, что когда либо хотелось бы сделать
План разработки - всё, что мы делаем в
ближайшие несколько спринтов
План спринта
Управление
проектом
Кризис роста
- Теперь появились пользователи, вместе с
ними появился запрос на качество
- Помимо этого теперь надо работать над
масштабируемостью
- Новых фич теперь нужно больше, они
нужны быстро чтобы зафиксировать
успех
- Месяц - очень длительный срок
Наш опыт
- Без четкой и понятной системы
управления много времени уходит
на решение простых задач
- Требования очень быстро
меняются
- Всем нужна прозрачность того,
что происходит
- Scrum-подобный процесс (но не
Scrum)
- Недельный спринт
- Оценка в пойнтах
- Очень удобный инструмент для
руководителя
- Спринты вносят больше ясности в
процесс как для разработчиков,
так и для руководства
- Новые сотрудники говорят что им
проще влится
- Можно делать приблизительные
прогнозы
- Github workflow (Feature branch &
Pull Request)
- Jira integration
- Production и Staging среды
- За год команда увеличилась в три
раза - процесс менять не пришлось
Команда
- Чем сложней предметная область -
тем дольше время адаптации
- Не получится нанять много и сразу
- Формируйте корпоративную
культуру, она сильно экономит время
- Быть маленькой командой - круто
Наш опыт
- Не делайте лишней работы,
используйте готовое
- Всё, что вы делаете, будет
меняться, надо помнить про это
- Работайте над командной
продуктивностью
Управление
качеством
Качество
- Очень много багов в самом
начале, из за сырости технологии
- На разных этапах – разные
требования по качеству продукта
- Ресурсы по остаточному принципу
Тестирование
- Автоматичекое API тестирование –
спасение в условиях нехватки рук
- Пишем тесты с первого дня
- Тесты без Continous Integration не
имеют смысла
Тест-план
- Автоматические интерфейсные
тесты (Selenium) дорого содержать
- Пишем тест-план, все серьезные
релизы кликаем руками
- Если нет тестировщика - дружно
кликаем все вместе
Continuous Integration
- Environment, близкий к production
- Следим за code coverage
- Важно держать тесткейс рабочим: билд
должен собираться быстро, тесты должны
быть актуальными
Continuous Delivery
- На стейджинг можно задеплоить
только через CI
- Тесты всегда в актуальном
состоянии, иначе работа встанет
- Весьма рискованно так
выкатывать production
Практика
- Очень мало проблем с поломкой
уже работающего функционала
- Реально критичные баги
встречаются редко (раз в месяц)
- Баги есть, но все терпимые
- Есть что улучшать
Эксплуатация
Эксплуатация
- Всё растет в N раз в месяц
- Надо чтобы всё работало, причем
хорошо
- Нет возможности нанять толпу
специалистов
- Инцидентов много, надо реагировать
быстро
Инфраструктура
- Используем самые простые в
поддержке и надежные
компоненты системы
- Мониторим не только сервера, но
и приложения
- Автоматизируем с первого дня
SAAS, PAAS
- Используйте по максимуму, они
экономят время
- В любом таком решении всё не
идеально
- Ищите баланс, не бойтесь делать
своё, зачастую это имеет смысл
Что мы используем
- Статика: CDN, Amazon S3
- Отсылка почты: Amazon SES,
Mandrilapp
- DNS: Amazon Route 53
- Мониторинг: NewRelic, Scoutapp,
HoneyBadger
Релизы
- Выкатка должна быть идеальной
- Нужно учится правильно выкатывать,
сразу не получится
- Быстро растем, быстро меняемся,
часто релизим
- Zero-Downtime - сильно влияет на
ваш рост, если вы релизите часто
Мобильные приложения
- Релиз может занимать от нескольких
часов, до нескольких недель
- Помним про обратную
совместимость и зоопарк устройств
- Очень важен хорошо
спроектированный API, это снимет
много проблем
coub.com

More Related Content

Coub 2014: Управление быстрорастущим проектом

  • 3. Что такое Coub - Сайт про короткие зацикленные видеоролики - За 2013 год – 120 кратный рост Начало 2013: - 1mln MAU - 2.4mln pageviews Начало 2014: - 48mln MAU - 475mln pageviews
  • 4. Мы – стартап - Сделать минимальный продукт который будет нужен людям (Minimal Valuable Product) - Дальше - успешно его масштабировать и развивать
  • 5. Процессы в компании Требования Реализация Тестирование Эксплуатация Управление продуктом Управление проектом Управление качеством Управление инфраструктурой
  • 7. - MVP — это стартовая точка - Появляется понимание, что как и для кого мы делаем - Начинают появляться Performance Indicators, развиваются метрики
  • 8. - Мы год искали тот самый MVP - За этот год перепробовали кучу нужного и ненужного: три раза меняли целиком концепцию - Стало ясно, что мы знаем очень мало о наших пользователях
  • 9. Мы не знаем что происходит - Data-Driven и Data-Informed подходы - A/B тестирование - Поиск реально важных метрик, целенаправленная работа над их увеличением - Engagement
  • 10. Наш опыт - Внутренняя система A/B тестирования на базе готового решения - Mixpanel + Google Analytics - Собственная система записи и анализа событий - Движение к плотной интеграции аналитики в продукт
  • 11. - Стараемся выкатывать весь новый функционал через A/B тесты - Собираем статистику, пусть она кажется ненужной - Не боимся убирать редко используемые фичи
  • 12. Мы не знаем куда двигаться - Появилось несколько планов (Roadmap, месячный план разработки) - Нужно учится расставлять правильные приоритеты - Даже бредовые идеи надо записывать
  • 13. Наш опыт Roadmap — всё, что когда либо хотелось бы сделать План разработки - всё, что мы делаем в ближайшие несколько спринтов План спринта
  • 15. Кризис роста - Теперь появились пользователи, вместе с ними появился запрос на качество - Помимо этого теперь надо работать над масштабируемостью - Новых фич теперь нужно больше, они нужны быстро чтобы зафиксировать успех - Месяц - очень длительный срок
  • 16. Наш опыт - Без четкой и понятной системы управления много времени уходит на решение простых задач - Требования очень быстро меняются - Всем нужна прозрачность того, что происходит
  • 17. - Scrum-подобный процесс (но не Scrum) - Недельный спринт - Оценка в пойнтах - Очень удобный инструмент для руководителя
  • 18. - Спринты вносят больше ясности в процесс как для разработчиков, так и для руководства - Новые сотрудники говорят что им проще влится - Можно делать приблизительные прогнозы
  • 19. - Github workflow (Feature branch & Pull Request) - Jira integration - Production и Staging среды - За год команда увеличилась в три раза - процесс менять не пришлось
  • 20. Команда - Чем сложней предметная область - тем дольше время адаптации - Не получится нанять много и сразу - Формируйте корпоративную культуру, она сильно экономит время - Быть маленькой командой - круто
  • 21. Наш опыт - Не делайте лишней работы, используйте готовое - Всё, что вы делаете, будет меняться, надо помнить про это - Работайте над командной продуктивностью
  • 23. Качество - Очень много багов в самом начале, из за сырости технологии - На разных этапах – разные требования по качеству продукта - Ресурсы по остаточному принципу
  • 24. Тестирование - Автоматичекое API тестирование – спасение в условиях нехватки рук - Пишем тесты с первого дня - Тесты без Continous Integration не имеют смысла
  • 25. Тест-план - Автоматические интерфейсные тесты (Selenium) дорого содержать - Пишем тест-план, все серьезные релизы кликаем руками - Если нет тестировщика - дружно кликаем все вместе
  • 26. Continuous Integration - Environment, близкий к production - Следим за code coverage - Важно держать тесткейс рабочим: билд должен собираться быстро, тесты должны быть актуальными
  • 27. Continuous Delivery - На стейджинг можно задеплоить только через CI - Тесты всегда в актуальном состоянии, иначе работа встанет - Весьма рискованно так выкатывать production
  • 28. Практика - Очень мало проблем с поломкой уже работающего функционала - Реально критичные баги встречаются редко (раз в месяц) - Баги есть, но все терпимые - Есть что улучшать
  • 30. Эксплуатация - Всё растет в N раз в месяц - Надо чтобы всё работало, причем хорошо - Нет возможности нанять толпу специалистов - Инцидентов много, надо реагировать быстро
  • 31. Инфраструктура - Используем самые простые в поддержке и надежные компоненты системы - Мониторим не только сервера, но и приложения - Автоматизируем с первого дня
  • 32. SAAS, PAAS - Используйте по максимуму, они экономят время - В любом таком решении всё не идеально - Ищите баланс, не бойтесь делать своё, зачастую это имеет смысл
  • 33. Что мы используем - Статика: CDN, Amazon S3 - Отсылка почты: Amazon SES, Mandrilapp - DNS: Amazon Route 53 - Мониторинг: NewRelic, Scoutapp, HoneyBadger
  • 34. Релизы - Выкатка должна быть идеальной - Нужно учится правильно выкатывать, сразу не получится - Быстро растем, быстро меняемся, часто релизим - Zero-Downtime - сильно влияет на ваш рост, если вы релизите часто
  • 35. Мобильные приложения - Релиз может занимать от нескольких часов, до нескольких недель - Помним про обратную совместимость и зоопарк устройств - Очень важен хорошо спроектированный API, это снимет много проблем