Рубрика «процессы»

Как Unsplash масштабируется силами небольшой команды - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

В то же время наша команда сравнительно мала: два дизайнера, три человека, работающих с фронтендом, два — с бекендом и один дата-инженер. У нас нет отдельного DevOps-инженера, и каждый член команды тратит бОльшую часть своего времени на эксперименты и разработку новых фич для обеспечения дальнейшего развития продукта.
Читать полностью »

Масштабирование Unsplash маленькой командой: 8 человек и 10 миллионов запросов в сутки - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

В то же время наша команда сравнительно мала: два дизайнера, три человека, работающих с фронтендом, два — с бекендом и один дата-инженер. У нас нет отдельного DevOps-инженера, и каждый член команды тратит бОльшую часть своего времени на эксперименты и разработку новых фич для обеспечения дальнейшего развития продукта.
Читать полностью »

Как восемь человек масштабируют highload-проект. Опыт Unsplash - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

В то же время наша команда сравнительно мала: два дизайнера, три человека, работающих с фронтендом, два — с бекендом и один дата-инженер. У нас нет отдельного DevOps-инженера, и каждый член команды тратит бОльшую часть своего времени на эксперименты и разработку новых фич для обеспечения дальнейшего развития продукта.
Читать полностью »

Выстраиваем эффективное взаимодействие инженерной и продуктовой команд - 1
@innubis

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

Мы в Badoo относительно небольшими силами (в моей команде 30 человек) ежемесячно деплоим порядка сотни новых востребованных фич, при этом не теряя в качестве кода, планирования и поддержки. Каким образом нам удаётся оставаться «на коне» и как у нас построено взаимодействие инженерной команды с продуктовой, я расскажу в этой статье.

Уверен, что наш опыт будет интересен и другим компаниям. И надеюсь, что подход, который мы выработали путём проб и постоянных улучшений, кому-то реально поможет (а в идеале — сэкономит время и силы при выстраивании процессов и даст нужный результат).

Читать полностью »

Привет!

Сегодня я расскажу о создании отдела тестирования на примере небольшой компании, которая уже 3 года выпускает мобильные игры. Особенность в том, что компания не зависит от спонсоров и живёт за счёт денег, которые зарабатывает. И нам, как сотрудникам, важно делать то, что, на наш взгляд, будет нравиться пользователям. Есть возможность экспериментировать и работать на аудиторию, но, при этом, куда меньше времени на разработку продукта.

Необходимость в QA отделе появилась год назад и процесс тестирования мне необходимо было выстроить, не ломая при этом график релизов.

Тестирование в мобильном геймдеве: что такое и в чём проблема

QA в мобильной разработке выступает чем-то вроде секретной службы. Пока работает хорошо, никто не замечает, что тестирование проводится. Но стоит Акелле хотя бы раз промахнуться и комментарии к игре пестрят сообщениями разной степени разгневанности. В сущности, задача мобильного тестировщика — проследить за тем, чтобы в приложении был минимум заметных багов, а команды разработки чётко представляли себе смысл каждого релиза и работали на достижение результата.

Тестирование — фактор, который помогает улучшать продукт, но, при неграмотном использовании он будет ещё и нагрузочным элементом в системе, сильно задерживающим релиз. В нашей компании, на тестирование игры закладываются 2 рабочих дня: первый день — продукт тестируется и дорабатывается; второй день — игра проходит последние проверки и отправляется на маркет.

Процесс тестирования сталкивается со следующими проблемами:

  • Нет автоматизации тестирования
  • Разный подход к полному тестированию и тестирование фичи
  • Зависимость от других отделов. Провал сроков от других сотрудников сказывается на загруженности. Недели перегруженные релизами чередуются с неделями, когда релизов нет вовсе
  • Необходимость научиться находить недоработки геймдизайна или UI. Существуют ситуации, когда этап тестирования помогает отказаться от бесперспективной игры.

Читать полностью »

Это последняя статья из моего цикла. В ней будет много о менеджерской и организационной сторонах разработки.

Особенности разработки мобильной MMO RTS. Часть 6 - 1
Читать полностью »

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

Моделирование активности и мифологическое сознание - 1

Итак, есть некая активность. В мифологическом сознании первобытного человека за каждым действием стоит сознательное существо. Например, если течет, то делает это живое существо — река, если светит, то делает это живое существо Солнце. Поэтому в мифологическом сознании у каждого действия есть сознающий себя актор, который это действие выполняет. И мы можем сказать, что назначение (функция) этого актора — делать это действие. Я специально говорю о том, что все это происходит только в рамках мифологического сознания. Например, машина едет по дороге только в рамках мифологического сознания, потому что на самом деле машина не обладает волей и не может куда-то ехать. Наш язык настроен на отражение мифологического сознания, поэтому нам так сложно мыслить иначе. Например, можно было бы сказать, что участником активности является машина и дорога, в результате этой активности машина постоянно перемещается по дороге, но мы, одушевляя машину, говорим о том, что это делает именно машина. Таким образом, назначение машины в рамках мифологического сознания — ехать, или в рамках мифологического мышления функция машины — ехать. (хотя мы могли бы с тем же успехом одушевить колесную пару и сказать, что ехать — это функция колесной пары, а не машины). Замечу, что назначение как и функция — не имеет начала и конца в рамках существующего контекста.
Читать полностью »

Frontend: Разработка и поддержка - 1

Давайте представим, что вас перевели на новый проект. Или вы сменили работу и о проекте максимум только слышали. Вот вы садитесь за рабочее место, к вам приходит менеджер, жмёт руку и… прямо сходу открывает страницу проекта, тыкает пальцем в монитор и просит вставить «информер о предстоящем событии Х». На этом вы расстаётесь… Что делать? С чего начать? Как создать «информер»? Где найти нужный шаблон? И море других вопросов.

Под катом будет рассказ, как мы стараемся организовать эти процессы, какие инструменты создаём для препарирования SPA. Кроме этого, мы поговорим о технических подробностях реализации Live Coding / Hot Reload и чуток о VirtualDom и React с Angular.
Читать полностью »

Вступление

Эта статья ориентирована на тех, у кого есть SharePoint и кто не знает, что с ним делать. :)

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

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

Встречи руководства и сотрудников в ICL Services называются Strategy Update. Проводятся они с 2011 года, когда нас еще было около 350 человек. К слову, сейчас почти 1000. На встречах, как следует из названия, обсуждаются всевозможные стратегические вопросы. В конце прошлого года мы “подбили” статистику “посещаемости” встреч и решили обновить формат. Добавили диалог, запланировали фокус-группу, а заодно и сформулировали, зачем вообще нужны такие встречи.

Немного теории

Очевидно: встречи руководства с сотрудниками полезны и интересны. И совершенно точно нужны. Причём независимо от размеров компании.

imageЧитать полностью »