How we killed 80% of features and increased outcomes of a/b testing by 100% [eng]

Презентація доповіді

Іноді менше - це більше.

Ми часто говоримо про те, як спроєктувати систему таким чином, щоб вона була пристосованою до змін, як швидко додати новий функціонал до продукту. Однак все менше людей задають питання: «Чи потрібна нам ця функціональність? Які фічі дійсно цінні для нашого кінцевого користувача?»

У цій доповіді я поділюся нашим досвідом у Preply про те, як ми підходимо до челенджу "Витягнути максимальну цінність бізнесу, зберігаючи продукт максимально простим".

Ми проводимо більше A/B 100 тестів одночасно, а це означає, що у всьому Інтернеті немає 2 користувачів, які побачили б однакову версію Preply. Я поділюся нашим баченням розвитку продукту, а також технічними деталями та проблемами, з якими ми зіткнулися під час впровадження та прийняття культури A/B тестування у Preply. Серед інших тем, які я висвітлю:

• Як побудувати систему A/B тестування та продукт, який буде обробляти більше 100 A/B тестів одночасно?
• Чи може A/B тестування завдати шкоди бізнесу?
• Приховані витрати на проведення A/B тестів;
• Чи є сенс у технічних змінах та рефакторингу A/B тестування?
• Як A/B тестування може захистити вас від втрати кількох мільйонів доларів за просте оновлення бібліотеки?