Делать много А/Б тестов это круто и весело. Еще веселее – заявлять что вы делаете тысячи А/Б тестов в год. Но правда в том, что суета с А/Б тестами нужна если непонятно как сделать рост продукта. То есть – нет экспертизы.

Если экспертиза есть, то вы четко понимаете что надо делать. Смысл тогда делать тесты?

Итоги года по нашим продуктам в FunCorp – двойной рост выручки, и рост аудитории в США. Драйверы роста – наш новый продукт ABPV, улучшения пушей и ленты в iFunny, которые дали рост ретеншена и буст в бизнес-модели. Команда выросла, теперь занимаем целый этаж в Белых Садах.

Точки роста на 2022:
- ML и рекомендации
- ML в пушах
- Работа с контентом (авто-категоризация, распознавание)
- Поиск по мемам

🤟🤟

Все знают про правило Парето, где 20% действий дают 80% результата. Срабатывает один тест из пяти. Отсюда вытекает что если делать только нужное, то освободится куча времени, а результаты будут такие же. Но статистика штука жестокая. Если не делать 80% лишних действий, то нужные 20% тупо не найдутся.

Например, MVP. Сначала пишем какой продукт мы хотим сделать, потом отрезаем всё лишнее, и делаем эти 20%. Запускаем, смотрим фидбек, и решаем – работать с этим или нет. Но обычно отрезают всё мясо, и остаются одни кости. Которые, естественно, никому не продашь, ведь пользователи хотят полноценный продукт.

С А/Б тестами то же самое. Мы провели 10 тестов на улучшение CTR, один из них сработал. Встает вопрос как трактовать этот результат. Если забить на пуши и не заниматься этим – то кардинально новых идей и не появится. Если разбираться глубоко в вопросе, то за 3-6 месяцев до чего-то докопаетесь.

Есть продакты, которые без аналитиков не могут ничего. Примеры задач в аналитику от них:

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

Список бесконечный. Такие продакты обычно очень мало делают, потому что все время что-то ждут от аналитиков. Потом с них хрен что спросишь, потому что всем мясом занимались не они.

Аналитикам рекомендую не вестись на продуктовую импотенцию, и таких продактов слать нахер. Пусть сами принимают решения и отвечают за них.

Три правила антикризисного продакт менеджмента:

1. Делаем только то, что 100% даёт рост (давало раньше)
2. Катим сразу на сотку – зачем тесты если 100% работает?
3. Даем личный телефон и телеграм самым заебчивым пользователям

Profit

Есть такие друзья, которые знают тебя как облупленного. С Игорем мы познакомились на работе: шесть лет подряд были соседями по офису, сидели в соседних комнатах и по вечерам играли в Стар. Сейчас Игорь работает Head of Product в Vivid money - необанке на европу.

Мы записали с ним подкаст https://youtu.be/LutrUa-KHMk про работу и не только

На фото я показываю член менеджера-чеда, который катит в прод на 100 без АБ тестов

Великое перераспределение

42% разработчиков планируют уволиться в этом году, по недавнему отчёту Digital Ocean. Основные мотивы — поиск места с более высокой зарплатой и возможностью удалённой работы. 8% планируют работать на себя или запускать компании.

В Digital Ocean это назвали «великим перераспределением» — пока Big Tech пытаются вернуть сотрудников в офис, сами они подыскивают возможности получше. Как правило, это удалёнка, гибкая занятость и работа над своими проектами.

И этот тренд относится не только к айтишникам. Молодые специалисты в целом больше не стремятся строить карьеру в одной компании. По опросу Bankrate, 55% трудоустроенных американцев планируют уйти из компаний в ближайший год: из-за низких зарплат, переработок и несправедливого начальства.

Поэтому миллениалов прозвали «job-hopping generation»: 21% из них поменяли работу за последний год, что в 3 раза больше старших поколений. Ещё 60% готовы уволиться хоть сейчас, если подвернётся местечко получше.

Саббатикалы и долгие перерывы в работе тоже теряют своё клеймо — число таких долгих отпусков посреди карьеры выросло в 3 раза за последние 4 года.

Какие возможности для стартеров открывает этот тренд? Давайте побрейнстормим в комментариях.

Краткое резюме отчета: всё больше чуваков хотят на удаленку, на которой они деградируют как специалист и получат букет психических проблем. Остальные просто хотят рейз ничего не делая, потому что #inflation. На свой бизнес вдохновились 8%. Что-то мне подсказывает что это пиздежь, и на самом деле просто хотят рейз

Все вокруг выгорают. Тестировщики, разработчики и менеджеры вот уже лет пять-семь выгорают по кругу во всех успешных IT компаниях. У кого-то трудная ситуация дома, кому-то надоели задачи, а кому-то надо в отпуск. Ну или просто на удаленку.

Остаются только Хеви профи. Люди, на которых молятся акционеры, топ-менеджмент, контрагенты, да и вообще все. Хорошие специалисты, которые стабильны, предсказуемы, и всегда дают отличный результат. Атланты, мастера своего дела.

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

Получается что профи смотрят наружу: на рынок, на конкуренцию и бизнес в целом. Там постоянно что-то меняется, выходят новости о инвестициях, новые фичи, итп. Отсюда вовлеченность в продукт и интерес к работе.

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

Интересный момент в пушах на андройде: система считает средний CTR пушей, и пессимизирует те приложения, у которых плохой CTR. Например, мы в тестовой группе начали отправлять в три раза больше пушей, а потом откатили тест. В этой группе CTR в дальнейшем будет ниже, потому что система пессимизировала приложение. Что делать? Менять айди канала пушей. Вроде помогает, а вроде и нет.

Прикладываю перечень лишней шелухи, которая тормозит разработку и развитие ваших продуктов:

1. Оценка сроков
2. Оценка рисков
3. Установочные встречи
4. Ретроспективы
5. Разрабы не тестируя передают в QA
6. Спринты, юзер стори и стори поинты
7. UX резерчи и коридорные тесты
8. Исследование оттока

Ошибка найма – это когда на собеседовании чувак мастерски отвечает на все вопросы, делает тестовые задания, а на испытательном (или после него) начинается какая-то хуйня. То есть, это мастер проходить собеседования. Теоретические знания есть, но реальной практики не хватает. Часто это встречается у ребят из корпораций, которые красили год подряд кнопку в админке, но в резюме написали что "увеличили конверсию в выполненный заказ за счет улучшения бек-офиса".

Как это выявить? Очень просто. Садимся с кандидатом за стол (или в режиме скриншера) и начинаем решать ваши задачи, по пути обсуждая что и почему он делает. С разработчиками пишем код, с дизайнерами рисуем макет, с менеджерами пишем спеки и двигаем таски.

Тут сразу будет всё понятно: как кандидат соображает, как обрабатывает информацию, думает, общается, пишет код, обращается с компьютером. Это круто работает даже если вы не глубоко разбираетесь в вопросе.

Я знаю что многие компании с сильной инженерной культурой первоначальный скрининг делают через написание кода, и это экономит кучу времени

У нас плохие метрики потому что в продукте баги. Давайте сначала починим баги, а потом будем решать нормальный ретеншен или нет. Crash Free только 90%, о какой конверсии может идти речь?

Так продакты переводят стрелки на разработчиков и тестировщиков. Хотя, казалось бы, всё верно.

Прикол в том, что продуктом пользуются не потому, что он работает без багов, а потому что он нужен. Возьмем iPhone в 2012 году и HTC на Android 4. По сравнению с iPhone андройды были просто кладбищем багов, но их покупали, потому что против УТП не попрешь. Все хотели айфон но дешевле, а то что он глючит – ну что вы хотели, не надо было экономить)

Никто не любит таких вопросов от начальника: какого хуя, почему только сейчас, что за пиздец, чем мы думали, почему они а не мы, че за хуйня у нас в проде. Всё это токсично, а значит можно и выгореть.

Однако только такие вопросы и приводят к росту. В здоровой рабочей атмосфере результат преобладает над отношениями. Проблемы не замалчиваются, а открыто обсуждаются и поэтому решаются. Вне зависимости от степени тяжести этих проблем.

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

Так что лайк если это про тебя

За прошлый год у меня было два крутых тренера: по электрогитаре и по мотоциклу.

Тренер по гитаре - просто деспот. Он не идет ни на какие уступки, все должно быть строго так как он говорит. Придирается к малейшим оплошностям, и всегда доводит начатое до конца.

Тренер по мотоциклу сходу сказал: если ты не будешь внимательно слушать и делать что я тебе говорю - я не буду тебя тренировать. И он реально отказывает некоторым ученикам, которые приходят на тренировки чтобы делать как они привыкли, а не так как надо.

Оба эти тренера - крутые ребята и мастера своего дела. Они знают как сделать результат.

Когда вы приходите на работу, у вас есть начальник. У него есть видение, требования, критерии оценки, итп. Крутой начальник имеет планку, и нормально требует.

Если вам кажется что начальник требует хуйню - не надо доказывать что он не прав, сам не знает чего хочет, или слишком лезет в детали. Надо понять логику его мышления, и сделать как просит. Только так рождается готовый продукт, даже если это MVP.

«Простота — это великая добродетель, но она требует напряженной работы, чтобы её достичь и образование, чтобы оценить. И к сожалению, сложность продается легче.» — Дейкстра.

—

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

Кажется, что раз решение сложное — то в него вложено больше труда и значит оно должно быть лучше.

Это, конечно, не так. Процитирую Паскаля: «если бы у меня было больше времени, я бы написал письмо покороче».

В программировании ровно то же самое: простые решения требуют гораздо больше интеллектуальных усилий, приходят с опытом.

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

—

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

Херовые программисты пишут много кода, много сервисов, придумывают архитектуру, потом геройски это все тестируют и катают в прод. Хорошие программисты придумывают как сделать так чтобы этого не надо было делать.

Пока не видел ни одних курсов по программированию где учат упрощать)

Кстати, есть такая советская книжка – ТРИЗ – Теория решения изобретательских задач. Единственная на моей памяти книжка по инжинирингу, которая учит упрощать. Пример из книги такой:

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

Есть два решения:
1) в лоб – вы делаете электрические-гидравлические привода, блок управления, ножи которые чистят решетку. подводите электричество и придумываете систему мониторинга работоспособности
2) красивое – вы делаете поплавок, который приводит ножи в движение от волн на реке. не надо электричества, сложных инженерных систем, мониторинга

Пример абстрактный, но тем не менее показательный. Речь про то, что задачу в лоб может решить любой дурак. А вот найти красивое решение – это мастерство.