Русский
Русский
English
Статистика
Реклама

Управление продуктом

Pet-проект для джуна. Или зачем и как выбрать pet project. (личный опыт)

23.02.2021 14:15:47 | Автор: admin

Предисловие

Привет Хабр! Эта публикация написана джуном для джунов (но возможно и специалисты более высокого уровня что-то найдут для себя / своих падаванов).

Зачем нужны pet проекты?

Для саморазвития как разработчика и закрепления изученного материала.

Если Вы днями на пролёт "штурмуете" теорию: читаете посты, смотрите туториалы, но при этом не применяете изученное на практике, то времени на освоение выбранной Вами темы понадобится в разы больше.

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

Для джуна без постоянного места работы, pet проект заменяет тут самую работу (со стороны разработки). Вы ставите себе задачу/цель и делаете всё возможное что бы её выполнить. При разработке Вы ещё глубже погружаетесь в тему, а иногда находите новые объекты для изучения.

Суммируя pet проекты нам нужны для:

  • изучения / закрепления нового материала;

  • получения удовольствия от разработки чего-то интересного лично Вам;

  • пополнения своего портфолио;

  • (bonus) есть шанс что Ваш pet проект может кому-то приглянуться и тогда из этого можно получить финансовую выгоду.

Как выбрать и на что обратить внимание?

Я рассматривал этот вопрос со стороны фронтенд разработчика и возможно для других отраслей приведенные ниже тезисы будут не валидны.

Самое главное разработка должна приносить удовольствие. Технологии, дизайн или что-то ещё не должны вызывать у Вас отвращение, иначе такой pet проект может остановиться на этапе первого коммита.

Технологии

Раз Вы выбрали определенные технологии для своего домашнего проекта, то скорее всего они Вас интересуют и проблема приведенная выше Вас не касается. (Или же Вас заставляют писать на том что Вам отвратно?)

Дизайн

Тут все зависит от человека и ситуации. Есть два варианта:

  1. Запариться и сделать крутейший дизайн.

    Плюсы:

    • lvl up как дизайнера;

    • обычно свой дизайн очень приятен;

    • так как это собственный макет Вы в нём хорошо ориентируетесь и ещё на этапе дизайна продумываете некоторые фичи.

    Минусы:

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

  2. Найти готовый дизайн и работать с ним.

    Плюсы:

    • быстро (хотя поиск может затянуться, об этом ниже);

    • не нужно отвлекаться на дизайн.

    Минусы:

    • не всегда можно найти дизайн для Вашей задумки, особенно если она не типичная;

    • готовые бесплатные макеты не всегда красивые.

Идея

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

Вот пару вечно актуальных примеров:

  • список задач;

  • список задач;

  • менеджер покупок;

  • сайт портфолио;

  • кино сайт;

  • калькулятор;

  • блог;

  • магазин чего-либо.

Личный опыт

В этом блоке я раcскажу как придумывались / создавались мои pet проекты.

Начало (AniList)

Шёл июль 2020 года. Спустя семестр изучения JavaScript'а в колледже я решил изучить какой-то фреймворк. Выбор пал на React. Через пару дней ознакомления с фреймворком я наткнулся на серию видеороликов по разработке веб-приложения пиццерии на ютуб канале Archakov Blog. И решил сразу же применять изученное в видео на реальном проекте, но просто переписывать код из видео в IDE было не интересно. По этому я решил делать аниме список.

Выше я писал про два варианта получения дизайна для проекта. Какой же из вариантов выбрал я при создании макета? Оба. Для начала я зашёл на уже существующие сайты с такой-же тематикой потом пролистал Behance и собрал своего "франкенштейна" из собственных идей и кусков уже готовых дизайнов.

Скриншот проекта из FigmaСкриншот проекта из Figma

По готовому макету я понял что мне нужно будет где-то брать информацию об аниме (API, AJAX), где-то хранить её (Redux), а также как-то организовать авторизацию и хранение информации о пользователях (Firebase) + работа с версиями файлов(GIT, GitHub). В итоге мне предстояло ознакомиться как минимум с 5 новыми технологиями помимо React.

И в этом я считаю один из плюсов pet проектов. Начиная учить что-то одно, а в конце осваиваешь намного больше чем ожидал.

ToDo list

Дизайн ToDo appДизайн ToDo app

Следующим проектом должен был стать todo list. Мой одногруппник (тоже начинающий фронтендер) должен был делать frontend на Angular, а я (неожиданно) backend. Тут мне пристояло погрузиться в мир backend'а и может не изучить, но хорошо так ознакомиться с NodeJS, Express, MongoDB, mongoose, cors, dotenv, способами авторизации, деплоем на Heroku и ещё глубже понять работу API.

По итогу вышло так что и я и мой товарищ каждый для себя писали back и front end.

Остальное

Потом было ещё пару проектов. Вкратце напишу что для себя я вынес из них.

Приложение погоды:

  • рисование на canvas'е;

  • работа с геолокацией;

  • анимация React компонентов.

Shedaily (front & back end) - приложение которое парсило расписание из сайта колледжа где я учусь и приводило его в приятный вид:

  • парсинг информации из сайта;

  • работа с Excel таблицами в NodeJS.

Terminal website - вдохновившись сайтом dodo.dev создал сайт с контактами:

  • SCSS;

  • Gulp.

Менеджер подписок:

  • MobX;

  • переключение темы.

Магазин аксесcуаров (backend) (в разработке):

  • более глубоко познал MongoDB + mongoose;

  • GraphQL.

Портфолио (на стадии дизайна):

  • JAM stack;

  • Gatsby;

  • создание кастомного курсора.

Заключение

Недавно меня постигла идея переписать свой первый pet project (Аниме список), но теперь с новыми навыками: backend на NodeJS, Express, GraphQl вместо Firebase, и frontend React + Apollo Client, ну и дизайн по красивше сделать. Эта мысль является результатом моего прогресcа который я постиг благодаря pet проектам.

Всякое дело совершенствуется овладением техники. Всякий навык достигается упражнением. - Гиппократ

Подробнее..

Как мы боролись с фейковыми аккаунтами на сайте знакомств

18.02.2021 22:12:39 | Автор: admin

С ростом популярности сервиса мы столкнулись с нереально большим количеством мошенников, которые регистрировали фейковые аккаунты и спамили других пользователей (порно, наркотики и вся остальная запрещёнка). Дошло до того, что таких регистраций стало в несколько раз больше, чем настоящих пользователей. Жалобы и отток нормальных посетителей положили начало нашей борьбе.

Изначально подтверждение регистрации было через email (сервис существует с 2007 года), но с ростом посещаемости мы заметили аномально резкий всплеск подозрительных регистраций. Решили внедрить подтверждение ключевых действий с аккаунтом, привязав их к мобильному телефону.

Отправка SMS на короткий номер

Первый вариант верификации был через отправку пользователем исходящего sms на короткий номер. Люди отправляли сообщение на самый дешевый короткий номер, тем самым подтверждали свой. В 2010 году это казалось решением проблемы, не требующим существенных затрат. Мы были одни из первых, кто это внедрил, а тогда больше половины пользователей принципиально не хотели светить свой номер мобильного телефона. Мало того, отправка на номер для пользователя была платной, хоть и минимальной стоимости около 2 (сумму забирал себе оператор), и требовала дополнительного действия. Вдобавок: поддерживались не все операторы, а сами короткие номера тогда часто ассоциировались с мошенниками. Хлынули жалобы, конверсия регистраций упала. Стало понятно, что решение выбрано неудачно.

Подтверждение SMS с кодом

Решили внедрить отправку клиенту sms с кодом. Несмотря на существенные расходы в пределах 50000 (около 1,500$ по тому курсу) на подтверждения и восстановления паролей, команда вздохнула с облегчением и о проблеме надолго забыли. Время и трудозатраты на борьбу со спамерами изматывали сильнее, чем дополнительные расходы.

Всё изменилось ближе к 2015 году, когда сотовые операторы ввели интерконнект. До этого исходящие сообщения стоили очень дешево (от 10 копеек) из-за возможности отправлять смски через региональных операторов в обход прямых подключений, не теряя в качестве доставки. После интерконнекта операторы стали блокировать отправку sms из других сетей своим абонентам, если она происходила от незарегистрированного имени отправителя. У заказчиков и агрегаторов не было выхода, кроме как подключаться напрямую и отправлять через прямые официальные каналы, которые в целом были всегда, но стоили до 10 раз дороже. Для усиления эффекта основные операторы выкупили почти всех тех мелких, через которых можно было отправлять сообщения дешево. Когда рынок стал монополизирован, операторы еще сильнее подняли цены на смски и продолжают это делать каждый год.

После повышения цен затраты увеличились на порядок: до 300000-400000 в месяц. Рост количества пользователей и платные плюшки ещё позволяли нести такие издержки, но шутки про то, что затраты на sms превышают затраты на несколько десятков серверов уже перестали быть смешными. Но других вариантов не было: безопасность аккаунта и блокировка спамеров важнее, приходилось платить.

Тем временем география пользователей расширилась за пределы России, в первую очередь за счет СНГ. А это, в свою очередь, совпало с желанием заработать и у операторов соседних стран: Украина, Беларусь, Казахстан, Киргизия и других. Они решили, что 1-2 за sms это не предел, давайте повысим до 7-13! Так было введено разделение трафика на национальный и международный с разницей в несколько раз.

Примеры:

Страна\Стоимость SMS

Национальные

Международные

Казахстан

1,5

7

Беларусь

0,75

11

Украина

1

5

Под международный трафик автоматически попадают все известные международные бренды, все проекты, которые не имеют в данной стране юр.лица и национального домена. Некоторые страны (особенно Казахстан) еще изобретательнее подошли к вопросу: если у проекта есть сайт в другой доменной зоне (например, не только site.kz, но еще и .ru), проект не может быть согласован по национальному тарифу, несмотря на то, что sms отправляются от имени местного проекта и только по Казахстану местным жителям. Попробуешь обойти огромный штраф и блокировка имени.

Звонок с кодом голосом

Расходы на sms перевалили за психологический барьер 1 млн в месяц, что само по себе всерьез заставляло задуматься над альтернативами. Но вместе с ростом расходов вернулась и старая проблема в новом обличии. Теперь благодаря куче ?сервисов по приему sms в выдаче Яндекса на виртуальные номера стало легко зарегистрировать аккаунт для любой социальной сети, включая VK и Facebook.

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

Как это выглядело на сайтеКак это выглядело на сайте

Но и тут есть подводные камни: по России и некоторым странам звонки работают хорошо, но из-за международной тарификации стоимость минуты по некоторым направлениям превышает 20-30 (например: Беларусь, Украина и др). Вторая проблема качество доставки: операторы могут фильтровать трафик по длительности соединения. Звонки определяются операторами, как спам и фильтруются, а значит пользователь не получает свой код подтверждения.

Еще был Viber :)

И предупреждение с угрозой штрафа в 5000 евро за отправку запрещенного контента. Пока мы тестировали новый способ и часть пользователей получали приветственное сообщение при регистрации вида Здравствуйте, %username%!, пранкеры подсуетились и начали оформлять левые регистрации на чужие номера. Людям пришли сообщения вида Здравствуйте, Жопа:

Детализация из кабинета оператораДетализация из кабинета оператора

Заметили быстро и лавочку прикрыли, но собрали негатив. Сам же Viber показал низкое проникновение (порядка 15-25%) и экономическую нецелесообразность из-за минимального платежа в ~30000, который сгорает в конце месяца, если пакет услуг на эту сумму, при цене сервисного сообщения в ~50 копеек, не был использован.

Звонок с кодом в номере

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

Как выглядит форма в мобильном приложенииКак выглядит форма в мобильном приложении

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

Стало понятно, что гарантия доставки может быть лишь при наличии своих пулов номеров и белых каналов, а значит и экономии в 20 раз не получится. В партнерстве с greensms.ru под нас запустили сервис со своими номерами и резервными каналами, а позже добавили в API и выложили SDK к нему на разных языках на GitHub. В процессе оказалось, что даже при нулевой продолжительности соединения с абонентом, вышестоящие операторы связи произвольно тарифицируют количество секунд разговора (кстати, кто сталкивался с подобным и смог решить это с оператором или на стороне Asterisk напишите, пожалуйста, в комментариях).В итоге удалось добиться стабильных результатов при стоимости в 40-60 копеек.

Сначала пользователи встретили нововведения замешательством. Конверсия при использовании sms >95%, звонки сейчас показывают ~85%. Еще год назад конверсия была, примерно на 10% хуже, но стала расти по мере распространенности метода и с изменениями в интерфейсе.

Статистика конверсии по странам в админкеСтатистика конверсии по странам в админке

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

Сейчас проще: всё больше проектов используют этот способ, люди привыкли и не так удивляются. Кстати, теперь еще и Яндекс их внедрил для подтверждения номера при входе на новом устройстве в свой аккаунт.

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

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

Финальная битва между добром и интернетом

А не будет её финальной. Чем популярнее становится сервис, тем больше желающих использовать его в плохих целях. И на новые методы защиты находятся новые методы нападения. Так что ждем новых ухищрений, может с помощью eSIM?

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

Подробнее..

Почему проекты переписываются и почему это не удается

23.02.2021 04:22:12 | Автор: admin
Извечная тема можно или нельзя переписать большой, работающий продукт с активной пользовательской базой? Ответ, в целом, будет да, можно. Вопрос только как? Наблюдая в прошлом несколько таких попыток (как удачных, так и не очень), данная статья является авторским взглядом на эту проблему.

Плохой код, слишком сложный процесс сборки, устаревшие технологии, ужасный язык программирования все эти проблемы, да и многие другие, сопровождают каждый достаточно успешный крупный проект, любой процесс разработки программного обеспечения в любой организации. Как показывает практика, в большинстве случаев со временем ситуация лишь усугубляется мелкие неудобства перерастают в неприятные особенности нашей работы, постоянно увеличиваются оценки при планировании задач, начинает страдать качество готового продукта. Последним штрихом к этой картине становится срыв сроков и планов из-за невозможности или отладить функциональность, или же вообще доставить её до рабочего окружения. Зачастую, в таких ситуациях мы говорим, что накопился технический долг.


Этот долг возникает вполне естественным образом и преследует все сколь бы то ни было успешные системы когда есть сам продукт, его пользователи, каналы коммуникации с ними. Не важно, продается ли продукт непосредственно, либо же он является вспомогательной частью бизнеса компании, важно то, что он находится в эксплуатации достаточно длительное время. Пользователи хотят получить новую функциональность (возможно, они даже заплатят за это), менеджмент хочет поскорее это пользователям предоставить, потому отдел разработки, находясь под прессингом сроков, реализует необходимые изменения. Процесс повторяется многократно, и рано или поздно кто-то громко скажет кажется, у нас долг, возможно технический!


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


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


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


Кризис


Информация о критическом положении вещей медленно, но со все увеличивающейся частотой начинает поступать от разработчиков к менеджменту. Опять задержки, опять ошибки у клиентов и сломанная функциональность. И вот, на очередном митинге, посвященном очередной проблеме, кто-то решается поставить вопрос ребром что нам нужно сделать, чтобы вернуть наш процесс разработки в нормальное русло? Что нужно сделать, чтобы вернуть ему предсказуемость? Что требуется сделать для снижения количества дефектов и возвратов? Что нужно, чтобы вернуть нам доверие со стороны бизнеса и клиентов? Повисает тишина. Если внимательно прислушаться и приглядеться к лицам некоторых людей, то можно услышать, как их пульс, подгоняемый адреналином, учащается они готовились, и теперь время настало. Эти тщательно скрывающие свою радость люди инженеры.


Подготовка к этому решающему моменту шла долго дни, недели и месяцы обсуждений на офисной кухне и за пивом после работы, переписок в чате после прочтения статьи о том, что серебряной пули вроде нет, но на самом деле есть. Как бы мы сделали вот этот сервис, что выбрали бы вместо этого протокола, как построили бы архитектуру. И самый главный вопрос какой язык программирования и базу данных надо бы выбрать. Хеловорды написаны, плагины к IDE поставлены, в топку котла аргументации заброшены лучшие найденные статьи и презентации с последних конференций, так что избыток давления нужно постоянно спускать в свисток. И вот время настало.


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


  • Помните вот ту функциональность, которую просил клиент? Мы отказали из-за нашей текущей базы данных, которая так не умеет.
  • А вот из-за этой, когда-то принятой архитектуры, мы не в состоянии быстро написать реализацию этой задачи.
  • Код старый, там никогда не было тестов, потому их и теперь нет.
  • Фреймворк старый, таких теперь не делают.
  • Язык программирования старый, такие еще делают, но вообще это уже опасно для жизни на таком писать, и новички к нам не идут поэтому, ага.
  • Тут вообще какие-то скрипты для развертывания окружения, которые никто не понимает, а автор давно уволился.
  • Нам просто больно каждый день трогать такой код руками, а вы нам еще никогда не давали времени что-то с ним сделать хорошее, и вот сейчас уже совсем поздно.

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


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


Звук победных фанфар раздается в сознании инженера ровно в момент произнесения фразы сколько времени вам потребуется на переписывание?. Победа! Конечно, 100% времени никто не сможет выделить нужно поддерживать старое, может сделать какие-то небольшие изменения, и все же доделать вот то, что начато. Но это уже не имеет значения, как и общая оценка необходимых ресурсов, как и то, в каких пропорциях будет разделена работа между старым и новым 50/50, 60/40, треть и две трети. В этот момент случается один из важных и опасных фазовых переходов в сознании существующая система начинает считаться временной, соответственно, временными выглядят и неудобства по работе над ней.


Благая весть


Новости распространяются быстро, слишком быстро, да еще и с присущей слухам гиперболизацией благая весть летит по кубиклам, заглядывает в каждую переговорку, влетает на кухню и придает вашему кофе особый аромат. Переписываем! Мы договорились! Всё как мы и обсуждали! Радостный момент джентльмены уже заводят моторы и готовятся отправиться в новое прекрасное приключение. Настоящее приключение.


Если вы это слышите, либо же это вы произносите, то знайте ваш проект, ваша работа в большой опасности.


Дело в том, что согласие на переписывание крайняя мера, когда другие, вроде бы, уже невозможны так считают и такую версию принимают участники процесса. Никто и никогда не будет переписывать заново хорошо работающий, поддерживаемый продукт или систему зачем? Конечное же, мы не берем в рассмотрение крайние случаи, когда внешние обстоятельства вынуждают это делать. Например, как это было с приложениями на Flash когда технология, лежащая в основе продукта, рискует исчезнуть по не зависящим от вас обстоятельствам. Причем, технология эта может быть и не программной, а аппаратной такое тоже бывает. Я отталкиваюсь от того, что такое все же случается гораздо реже, чем кризис, вызванный преимущественно внутренними факторами.


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


Пока же я предлагаю обратится к собственному жизненному опыту, особенно детскому. Наверняка, у каждого были моменты, когда хотелось разбить, разломать наполовину собранную игрушку из конструктора, скомкать и выбросить наполовину исписанный лист сочинения, бросить играть в игру с друзьями после пятого проигрыша подряд. Моменты гнева, бессилия и отчаяния, когда что-то не получается. Когда мы старались следовать инструкции, правилам, советам, но ничего не выходит детали игрушечного автомобиля не встают на свои места, слова не складываются в предложения, а предложения в повествование, вы не подсчитываете свои очки после партии, потому что и так все ясно, но ожидаете следующей в надежде отыграться. Знакомо? Внезапно, это все продолжает случаться с нами и во взрослой жизни, тем более в профессиональной ее части. Желание переписать систему, в которой настолько все плохо, как это пытаются показать разработчики, возникает ровно по одной причине не получилось.


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


Сложности


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


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


Одну из частей этой сложности, зачастую неосознанную и незримую, представляет собой контекст взаимодействия людей с системой. Скажу проще в подавляющем большинстве случаев, в компании нет ни одного сотрудника, который знает, как работает их программный продукт. Эти знания либо слишком общие и высокоуровневые, либо слишком локальные и частные. Кое-где вообще Terra incognita, потому что написавший ее человек уже уволился. Кто-то просто что-то забыл, например, что именно это место в коде было сделано потому, что какой-то конкретный клиент (с которым уже не работают) просил о подобных изменениях. Кто-то из отдела поддержки использует старую, не документированную возможность какой-то части системы, чтобы добыть отсутствующие данные для отчета. Но это еще цветочки, по сравнению с тем, что творится у пользователей.


Вы не знаете, не можете знать того, как пользователи взаимодействуют с продуктом. Как они обходят ограничения. Какая функциональность используется, а какая нет. Куда они нажимают, с помощью чего они работают с вашим публичным API. Изобретательность людей по ту сторону http-соединения поистине безгранична. Мой любимый пример клиент нашей платформы, по каким-то причинам не дождавшись того, чтобы определенные данные появились в offline-отчетах, с помощью кого-то написал Selenium-скрипты, которые вытаскивали нужные данные с UI, чтобы потом присовокупить их к отчетным. С этого момента разметка страницы стала не документированным, но публичным API.


Это и есть тот самый контекст, который разделяют все люди, прикладывающие свои руки к программному продукту. И что самое главное часть его всегда скрыта от той или иной подгруппы этого сообщества. Именно это приводит к весьма болезненным последствиям внесения изменений, если они ломают устоявшиеся модели взаимодействия. Если вы поменяли ваш публичный API так, что он перестал быть обратно совместимым, то будет ли на стороне вашего клиента кто-то, кто может произвести зеркальные изменения? Как это повлияет на их бизнес, а потом и на стоимость вашего продукта? Конечно же, я не говорю о том, что изменения не нужны без них никуда, но управление их внесением это тоже часть контролирования той самой сложности.


Падение


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


  1. не справились со сложностью ведения точно такого же проекта, и не осознали этого
  2. не обладают всеобъемлющим знанием контекста

Может ли у них что-то получиться? В каких-то случаях да на короткой дистанции в пару месяцев это может и будет возможно. Другой вопрос как быстро технический долг накопится вновь, ведь люди вокруг все те же. Как об этом писал Джоель Спольски в своей статье Вещи, которые вы никогда не должны делать: Важно помнить, что если вы начинаете все с начала, то нет ни единого основания предполагать, что у вас получится сделать свою работу лучше, чем вы сделали ее в первый раз. А уж если мы говорим о длинных марафонских дистанциях, то тут вступают в игру осложняющие факторы, начиная от Эффекта второй системы Брукса, заканчивая простым фактом того, что переписывающим нужно бежать очень быстро, чтобы догонять постоянно удаляющуюся цель зачастую, в старую систему продолжают вносить изменения в то время, как пишется новая. Хватит ли ресурсов команды, чтобы вести разработку двух продуктов сразу?


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


Дальше случается то, что должно случиться. Состояние старой системы резко ухудшается от работы над ней забрали часть команды, а оставшиеся, рассматривая ситуацию как временную, не особо утруждают себя соблюдением рабочих практик и дисциплины. С другой стороны, начинается работа над системой, у которой нет клиентов, нет работающего для них окружения, нет ни реальной нагрузки, ни обратной связи, а значит, часть того самого общего контекста останется неизвестной до самого последнего момента и не будет браться в расчет, хотя там наверняка скрыты критически важные сведения. Делаются квартальные презентации, пишутся отчеты так проходит полгода, потом год. При демонстрационном показе новой платформы клиенту, внезапно оказывается, что ему не хватает какой-то имевшейся ранее функциональности, что, помноженное на количество этих самых клиентов, приводит к взрывному росту объема работы, необходимой для успешной миграции. Соответственно, бежать надо быстрее, меняя архитектуру и технические решения, принятые без полного обладания информацией, срезая углы, накапливая технический долг, только теперь уже в двукратном размере на руках у разработчиков две системы, старая и новая. Круг замкнулся.


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


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


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


Поток


Крупные, большие системы, обладающие активной пользовательской базой не переписываются целиком, даже если есть возможность разделить изменения по версиям. Если оглянуться на успешные компании, выпускающие программные продукты, особенно это касается web-сервисов, то их подход в большинстве случаев сводится к тому, что называют инкрементальными изменениями непрерывный поток трансформаций, которые не нарушают общего равновесия. Вспомните, когда вы в последний раз получали сообщение от владельца социальной сети о том, что у них выходит новая версия их продукта и там уже есть ваш аккаунт, но все сообщения и записи остались в старой версии и миграции этих данных не будет заново напишите и подружитесь? Никогда? А что бы вы подумали, все же получив такое письмо? Наверняка, реакция была бы очень негативной. Так почему же у нас возникает желание проделать ровно то же самое, но уже с клиентами нашего приложения, нашей компании?


Позитивный опыт, накопленный индустрией, говорит нам о том, что код довольно податливый материал. Тут показательна история Twitter, который был плавно, в несколько этапов, перенесен между технологиями, без простоев и вместе со всеми своими пользователями и их данными, причем незаметно для последних. Были заменены подсистемы поиска, рендеринг страниц, хранилище данных и другие компоненты. И вот платформа, начавшаяся как приложение Ruby on Rails, теперь работает в основном на JVM, по пути полностью сменив архитектуру. Пример более чем впечатляющий.


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


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


P.S.


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

Подробнее..

Бережливый стартап или как мы используем концепцию Lean Startup в своих проектах

02.03.2021 08:14:22 | Автор: admin
Создание чего-то нового дело всегда рискованное. Как и многие люди до вас, вы пишете бизнес-план, предлагаете его инвесторам (либо роетесь в собственном кошельке), набираете людей, начинаете разрабатывать продукт, тратите тысячи человеко-часов. А потом, спустя месяцы разработки (а иногда и годы) получается, что вы всё это время усиленно делали продукт, который никому не нужен. Вот вообще. А деньги и время уже потратили.

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

В этом посте расскажем, как мы в компании Автомакон применяем успешные практики из Lean Startup (несмотря на то, что многие наши проекты вполне сформировались и устоялись), с какими проблемами сталкиваемся и как с ними справляемся.

У ВкусВилл есть книжный клуб для сотрудников, в рамках которого часто обсуждаются те или иные книги. И нас часто приглашают поучаствовать в нем. На одном из таких собраний обсуждалась книга Эрика Риса Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.

image

Как раз в то время мы строили совместно с ВкусВилл новую продуктовую платформу: Тилси, она должна была соединить магазины и поставщиков продуктов с коротким сроком годности, объединить функционал для конечного потребителя, логистов, дистрибьютора, производителей, склада в одном месте.

Работа по классике


С самого начала проекта Тилси началось выстраивание платформы с космическими требованиями:
  • Высоконагруженная система;
  • Всё пишем на Golang;
  • Создание теоретических бизнес-процессов.

За восемь месяцев работы над проектом мы сделали только основу для бэка. Никаких процессов, никаких сущностей в системе не было, только некий фундамент, который когда-то потом позволил бы построить самую крутую платформу во вселенной. К тому времени мы уже потратили около 10 млн. рублей.

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

Работа по линам


Вот что сделали:

  • Отказались от всего, что сделали ранее. На коленке сделали в CMS самые примитивные, но работающие процессы. За месяц сделали MVP и запустили для проверки гипотез и начали получать первых пользователей: магазины, поставщики, конечные покупатели.
  • Затем пытались тестировать разные гипотезы. Протестировали много чего, но гипотезу ценности не подтвердили. Пытались сделать вираж, но все же в определенный момент приняли решение закрыть проект в текущем виде.
  • Итого нам удалось потратить не так много денег и времени (порядка 1 млн. и 2 месяца), а главное вовремя понять, что проект не взлетит, и сфокусироваться на другом.

Кроме этого мы использовали подход Lean Startup в Зеленой линии, совместном проекте ВкусВилла и Перекрестка по запуску новой линейки натуральных молочных продуктов с ультракоротким сроком годности. Он так и назывался, Маркет. Зеленая Линия В рамках проекта мы протестировали много гипотез. Подтвержденные гипотезы ценности позволили сэкономить кучу денег и времени, а неподтвержденные не тратить ресурсы на тупиковые направления.

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

С экономией по времени и ресурсам подходим теперь и к вопросу автоматизации. Какие-то вещи не автоматизируем совсем, собираемся и думаем, как в короткий срок (скажем, за день) сделать новый сервис. Например, раньше многие возвраты в системе оформлялись вручную, и подобные функции перекладывались на поддержку. Если таких обращений у вас в компании мало, раз-два и обчелся, тратить силы на их автоматизацию не стоит, проще руками. А вот если статистика говорит, что обращений по конкретной проблеме уже много, тогда ту или иную функцию есть смысл автоматизировать.

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

На чём стоит Lean Startup


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

Поэтому Дешево, быстро, хорошо оказывается штукой, которую можно написать в тексте, но нельзя увидеть в работе. Если у вас большая компания, у которой более чем достаточно ресурсов, причем как материальных, так и временных, то для вас отлично подойдет триада Тёмы Лебедева, которую мы бы процитировали, но нас за нее забанят.
А если у вас стартап в принципе, или же стартапная разработка продуктов внутри большой компании, то бюджет и время надо считать.

Не дешево, а экономно


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

Каждый рубль, каждый час сотрудника должны тратиться с умом. Здесь не получится взять и бросить команду на создание какой-то части продукта, сжечь пару КАМАЗов денег в процессе, а через полгода понять, что не взлетело. И пойти делать новый продукт.

Суть подхода


Компания тщательно изучает нужды потребителей, разрабатывает MVP и проводит эксперимент, дабы узнать, подходит этот продукт потребителям, или стоит еще что-то допилить. Или вообще отказаться от него.

Это важно, ведь это касается интереса людей к продукту, его нужности, как следствие спроса. Вы можете сделать великолепный по своим ТТХ смартфон. Открыть кофейню с лучшим кофе в мире.

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

В общем, примеров много, вы наверняка вспомните, как какая-то компания пыталась что-то выводить на рынок. Вроде и неплохое, но просто не нужно. Вот это не нужно и должно отлавливаться на самом старте.

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

Соответствует ли продукт нуждам потребителей?

На самом деле он нужен, или команда убеждает себя в этом и делает неправильные выводы? Тут нужно подходить к делу максимально объективно, абстрагируясь от своего отношения к продукту.

Как потребители решали подобную проблему раньше?

Раз у потребителей есть какая-то нужда, то они уже как-то её удовлетворяют, не будут же они просто терпеть и ждать, пока кто-то что-то предложит. Поэтому изучите текущие решения, как самые удачные, так и не совсем. Сравните свой продукт с аналогами, посмотрите, есть ли что-то в аналогах, что раздражает пользователей. Подумайте, что можно сделать лучше. Не получится ли, что какая-то часть вашего продукта будет их так же разочаровывать?

Какие издержки потребители сегодня несут из-за этой проблемы?

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

Нужно ли адаптировать или изменить ваш продукт?

Отдельным пунктом небольшое следствие из ответов на все предыдущие пункты. Вот вы оценили соответствие продукта потребностям. Присмотрелись к аналогам. Разобрались в том, как люди жили до появления вашего продукта. Теперь вопрос учитывая все это, вы оставите свой продукт в первоначальном виде или, возможно, стоит внести пару правок?

Если точно всё ОК, то переходим к пятому вопросу.

Готовы ли вы масштабировать его?

Допустим, все здорово, и у вас или сразу получилось что-то отличное, или вы вовремя допили продукт до такого состояния. Надо быть готовым к масштабированию продукт-то успешный (если вы честно ответили на вопросы выше). Значит, спрос будет. И он будет увеличиваться.

Осилит ли компания масштабирование? Хватит ли времени и денег, рук разработчиков, потянет ли инфраструктура возросшую нагрузку?

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

Непрерывность развития


Один из важных принципов Lean. Вы же не думали, что можно просто запустить какой-то отличный продукт, выдать всем премии и пойти смотреть, как оно все само по себе работает, оставаясь таким же отличным?

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

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

Гибкость


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

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

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

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

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

А руль дает вам возможность подстроиться под то, что уже точно случилось

Погодите, это же постоянный MVP


Это постоянно развивающийся MVP. Вы сделали первую версию MVP, она сработала, приносит людям пользу, бизнесу деньги, а вам обратную связь от пользователей. И благодаря обратной связи (а ее получение это постоянный процесс) вы все время фиксируете соответствие вашего продукта ожиданиям. Если какие-то добавочные гипотезы не подтверждаются в процессе использования продукта отказывайтесь от них. Не тратьте деньги компании и время сотрудников на то, чтобы поддерживать фичу, которая не нужна.

Это и есть бережливость.

Что еще важно


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

Работайте с обратной связью. Это постоянный статус вашего проекта.

Эксперименты. Не бойтесь проводить их снова и снова. Посмотрите, сколько больших компаний вокруг используют A\B-тестирование. Вспомните, сколько разных версий интерфейса Facebook прямо сейчас показывается различным сегментам пользователей. Это все эксперименты, это все проверки тех или иных гипотез.

Это постоянные инновации, которые обеспечивают постоянный прогресс.

Итого


Настоятельно рекомендуем обратить внимание на концепцию Lean Startup. Из IT вы или нет, большие у вас бюджеты или собственные сбережения на продукт, методология пригодится.

Вот наши выводы от использования подхода на практике:

  • Лины работают. И работают хорошо.
  • Но лины не панацея, подход не поможет поднять любой проект. Скорее, наоборот концепция поможет быстрее закрыть тупиковый проект, а не жить в иллюзии, что он клёвый. Что тоже очень полезно.
  • Ограниченное трактование линов может завести в другую крайность все процессы будут строиться на MVP. Зачем рефакторить, ведь все и так работает. Но есть большой риск, что в определенный момент это все может рухнуть. Поэтому использовать лины надо грамотно. Запустили MVP, подтвердили гипотезу ценности, дальше проанализировали надо ли делать нормальный продукт.


Кстати, мы сейчас активно расширяем команду, которая активно применяет Lean-подход. Вот тут можно посмотреть полный перечень вакансий hh.ru / наш карьерный сайт

Будем рады ответить на ваши вопросы.
Подробнее..

Recovery mode ИТ-аутстаффинг глазами клиента обсуждаем с руководителем разработки Mail.ru Cloud Solutions

03.03.2021 14:04:54 | Автор: admin

В 2021 году половина российских компаний планирует нанимать временный персонал для привлечения к проектной деятельности. Это показал опрос Hays, в ходе которого высказались почти 5 тысяч респондентов. 15% из них планирует за счет аутстаффинга оптимизировать свои расходы. 7% опрошенных испытывают сложности с поиском подходящих сотрудников в штат.

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

Глеб Корсунов, CBDO Holyweb, обсудил с Михаилом Кебичем, руководителем разработки публичного облака Mail.ru Cloud Solutions, какие существуют опасения относительно аутстафф-подрядчиков, как безболезненно подключить внешних специалистов к инхаус-команде и как влиять на их мотивацию.

Приятного чтения!

Стоит ли бояться, что подрядчик выйдет из проекта или заберет половину команды?

Функция аутстаффинга дополнять, усиливать или заменять команду заказчика. Это рабочий инструмент, у которого есть свои плюсы и минусы. Мы в Mail.ru Cloud Solutions им пользуемся и нам он помогает.

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

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

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

С помощью аутстаффинга мы решаем задачи управления ресурсами быстро привлечь под задачу дополнительные руки и так же быстро сократить этот ресурс, если он не нужен здесь и сейчас. Если кто-то из аутстафферов уйдет, на наш бизнес это никак не повлияет. У нас своя разработка: все, кто отвечает за предоставление сервиса в режиме 24/7, работают во внутренних командах Mail.ru Cloud Solutions. На аутстафф мы стараемся отдавать полностью отчуждаемые задачи, чтобы они находились в зоне ответственности одной команды разработки от и до. Это могут быть сложные и объемные проекты на нескольких месяцев. Впрочем, мы всегда стремимся уменьшать циклы разработки стандартный спринт для инхаус-команды составляет две недели, и аутстафф двигается в том же ритме.

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

Как отношение инхаус команды к аутстафферам влияет на качество сотрудничества?

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

Например, саботаж со стороны внутренних разработчиков, причиной которому может стать банальная ревность. Представьте: команда месяцами или годами пилит продукт, и вдруг приходят разработчики со стороны и начинают предлагать новые идеи, добавляют свой код (и критикуют существующий), требуют к себе внимания. Главное здесь заранее донести до команд всю ценность их взаимодействия и убедиться, что все одинаково понимают общие цели. И, конечно, не пускать взаимоотношения на самотек, а держать их под контролем и вовремя реагировать на тревожные звоночки.

Еще противоречие, которое может привести к конфликту, команда внутренних разработчиков ориентирована на стабильность и долгосрочное развитие сервиса, а аутстафф-команда, наоборот, заточена на скорость доставки новых фичей здесь и сейчас. Разрешить его можно правильной постановкой задач и едиными требованиями к разработке.

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

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

Как доверять, но проверять?

Универсальный совет выделите сотрудника, который следит за загрузкой специалистов и администрирует всю работу аутстафф-команды.

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

Если для эффективной работы программисту нужно играть на балалайке или в Dota пожалуйста. Оценивать мы будем результат.

Эта позиция в той же степени распространяется и на внутренних сотрудников Mail.ru Cloud Solutions.

Аутстафф-сотрудники не такие мотивированные, как штатные? Так ли это и как можно на это влиять?

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

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

Если проблемы с мотивацией внешней команды все-таки возникают, нужно незамедлительно общаться с руководителем команды со стороны поставщика.

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

Когда можно делать первые выводы об эффективности аутстафферов? Первый месяц работы самый важный?

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

Если аутстаффер работает внутри команды, то мы в Mail.ru Cloud Solutions оцениваем его точно так же, как и штатных сотрудников. Онбординг новых специалистов занимает столько же времени, они полностью интегрируются в команду и работают по той же системе и с теми же KPI, что и инхаус-разработчики. КПД каждого отдельного разработчика измеряется в зависимости от сложности сервисов и задач, с которыми работает его команда. Быть эффективным и попадать в сроки команды невозможно без качественной коммуникации.

Как правило, первый месяц работы не всегда дает объективную картину по эффективности. Разработчик на аутстаффе должен полностью погрузиться в предметную область, внутренние рабочие процессы спринты, планирование, груминг бэклога, созвоны и обсуждения корпоративную культуру и атмосферу заказчика.

При оценке внешней команды мы смотрим на ее результативность. Качество коммуникации можно оценить уже в начале работы. Через 2-3 недели становится понятно, насколько аутстафферы проактивны, самостоятельно инициируют обратную связь или нет, сразу ли сообщают о возникшей проблеме, предлагая собственные пути решения.

Как найти баланс при подборе разработчиков не перегнуть палку и не проглядеть подходящих кандидатов?

Мы проводим полноценное техническое интервью такое же, как для сотрудников Mail.ru Cloud Solutions, которых берем в штат. Обязательно уделяем внимание софт-скилам разработчика и его кругозору. Кроме того, устраиваем собеседование с руководителем команды и продуктовым менеджером.

Этапы отбора не отличаются для аустафферов и членов инхаус-команды, ведь требования и для тех, и для других у нас одинаковые.

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


Аутстаффинг относительно новая форма взаимоотношений между клиентом и поставщиком, и правила игры только формируются. Если тема вас заинтересовала, рекомендуем почитать другие статьи Holyweb об аутстаффинге: почему это выгодно и как успешно обходить подводные камни.

Остались вопросы? Пишите в комментарии или Глебу в Facebook ответим всем.

Если вы хотите присоединиться к команде Mail.ru Cloud Solutions: прямо сейчас открыты вакансии Python/Go-разработчика в команду PaaS и Go-разработчиков в команды объектного хранилища и IAM.

Полный и актуальный список вакансий MCS.

Подробнее..

Самые популярные языки для локализации в 2021 году обзор от Alconost

24.02.2021 16:18:54 | Автор: admin
Какие языки выбрать для локализации сервиса, приложения или игры?Какие языки выбрать для локализации сервиса, приложения или игры?

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

Несколько слов о том, кто мы и почему из нашей статистики можно делать выводы. Мы в Alconost локализуем приложения, игры и веб-сервисы. Наши клиенты и крупные игроки IT-рынка, и небольшие команды, и инди-разработчики. С 2004 года мы помогли 2000 IT-компаний со всего мира вывести их продукты на новые рынки.

Клиенты регулярно спрашивают у нас: На какие языки посоветуете переводить? Ответим с опорой на факты. Мы проанализировали заказы за 2020 год и подготовили для вас статистику, инфографику и аналитику по языкам, которые выбирают наши клиенты.

Для этого обзора рассматривались заказы на перевод с английского языка, выполненные в отделе локализации Alconost.

Топ-12 языков для локализации с английского

В 2020-м клиенты переводили у нас с английского на 89 языков. Подчеркнём, что абсолютное большинство клиентов переводят у нас именно с английского, в то время как локализацию с других языков заказывают менее чем в 3% случаев.

Итак, давайте посмотрим, какие языки самые популярные при переводе сервисов, приложений и игр с английского.

Диаграмма 1. Самые популярные языки для локализации с английскогоДиаграмма 1. Самые популярные языки для локализации с английского

Диаграмма 1. Доля переводов на языки из топ-12 языков составляет 62,3% от общего объёма заказов на локализацию с английского.

Удивлены? Да, локализация даже на все 12 самых популярных языков будет отвечать потребностям лишь 2/3 потенциальной аудитории. Для охвата оставшейся трети понадобится локализация ещё на 70+ языков.

Давайте подробнее рассмотрим топ, а затем сделаем небольшой экскурс в статистику по переводам на менее популярные языки.

Лидеры рейтинга: классика FIGS и не только

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

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

Посмотрите, как распределились доли по переводам с английского в лидирующей пятёрке: локализация на французский более 25%, а на три других классических языка в среднем по 19% на каждый.

Диаграмма 2. Пять самых популярных языков для локализации с английского: распределение долейДиаграмма 2. Пять самых популярных языков для локализации с английского: распределение долей

Диаграмма 2. Самые популярные языки для перевода с английского среди клиентов Alconost французский, итальянский, испанский и немецкий.

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

Выбор языка или выбор страны?

Интересный факт: бразильский португальский единственный язык в нашем топ-5, не совпадающий со страной происхождения. Так, французский может быть ещё и канадским; к слову, если вас интересует это направление вот наш обзор рынка и советы по локализации для Канады. У испанского несколько разновидностей: взять хотя бы аргентинский, колумбийский и мексиканский. И хотя мы переводим на все эти диалекты (а переводы на мексиканский испанский даже входят в наш топ-20), французский и испанский наши клиенты чаще всего заказывают именно для Европы, а португальский именно для Латинской Америки (Бразилия).

На наш взгляд, вот почему бразильский португальский популярен для локализации. Бразилия входит в топ-10 стран по величине экономики, в топ-3 по показателям загрузок в Google Play и App Store, а ещё в стране высокий уровень покупательной способности. Кстати, мы внимательно изучали рынок мобильных игр и приложений Бразилии; почитайте наш обзор.

Смотрим на Восток

С ощутимым отставанием от бразильского португальского, шестое место в топе занимает японский. Да, локализация на этот язык опережает в нашем рейтинге локализацию на упрощённый китайский! Мы видим причину в том, что Япония третий игровой рынок в мире, а локализация игр одна из наших ключевых компетенций.

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

Что до китайского, то локализация на его упрощённый вариант занимает в нашем рейтинге 8-е место, а переводы на традиционный китайский 13-е.

Диаграмма 3. Локализация с английского на китайский: нюансы Диаграмма 3. Локализация с английского на китайский: нюансы

Диаграмма 3. С английского на упрощённый китайский мы перевели почти в 2 раза больше заказов, чем на традиционный китайский.

Различия между разновидностями китайского разработчики учитывают при выборе региона, в котором планируется продвигать продукт. Так, на упрощённый китайский его ещё называют мандарин переводят для пользователей из материковой части Китая. А на традиционный китайский и его другие диалекты заказывают локализацию для пользователей с Тайваня или из Гонконга.

Обратно на Восток через Нидерланды

Интересно, что между двумя популярными языками азиатского региона японским на 6-м месте и упрощённым китайским на 8-м неожиданно оказался нидерландский. На наш взгляд, есть несколько причин его популярности для локализации. Среди них платежеспособность и развитая Интернет-инфраструктура, а ещё высокая лояльность голландских пользователей к контенту на родном языке.

К слову, любопытный факт о геймдев-индустрия Нидерландов: именно эта страна стала первой в Европе, сделавшей гейм-дизайн учебной дисциплиной.

Замыкают десятку турецкий и корейский языки. Эти страны в последние годы особенно интересуют разработчиков игр. Ведь среди стран Среднего Востока и Северной Африки именно Турция приносит гейм-девелоперам наибольший доход, а корейский игровой рынок четвёртый по доходности в мире.

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

А что за пределами топ-10?

Вторую десятку рейтинга открывают переводы с английского на польский язык. Количество заказов по этому языковому направлению совсем немного отстаёт от пары английский корейский.

Интересно, что переводы с английского на русский, на котором говорят около 260 млн человек в мире, популярны меньше переводов на польский, общее число говорящих на котором около 40 млн. И это далеко не единичный случай, когда количество говорящих и популярность языка для перевода не коррелируют друг с другом. Рассмотрим эту особенность подробнее.

Влияет ли общая численность говорящих на популярность языка для локализации?

По нашим наблюдениям скорее нет, чем да. Выше мы уже привели пример с польским и русским. Ещё пример: общее число говорящих на японском около 140 млн (сравните с 260 млн русскоговорящих). Но переводы с английского на русский занимают в нашем рейтинге лишь 12-е место, а на японский 6-е.

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

Такую же тенденцию мы заметили и за пределами топа. Например, общее число говорящих на вьетнамском около 90 млн человек; индонезийский язык распространён в 2,2 раза больше, а хинди почти в 7 раз. Тем не менее, количество заказов по переводу с английского на каждый из этих языков было у нас в 2020-м почти одинаковым.

Продолжая анализировать азиатские страны, похожую картину увидим и с языками Малайзии и Таиланда. Локализация на тайский интересует наших клиентов почти вдвое чаще переводов на малайский и это несмотря на то, что на тайском говорит в 4 раза меньше людей на Земле, чем на малайском.

Что принимать во внимание при выборе языка для локализации?

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

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

С чего начать локализацию игры или приложения? Конечно, это зависит от бюджета. Наши клиенты, как правило, начинают с локализации интерфейса продукта, параллельно с этим переводя справочную документацию и сайт. Для мобильных приложений вместе с UI локализуют описания и скриншоты для сторов. А если проводятся локальные маркетинговые кампании, переводится и рекламный контент: текстовые объявления, баннеры, видеоролики.

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

На какой бы стадии выпуска продукта на новый рынок вы ни находились, обращайтесь за локализацией к нам в Alconost. Мы переводим сервисы, сайты, игры и приложения на 70+ языков.

Больше статистики по локальным рынкам

Как мы упоминали в начале, языки из топ-12 это только 2/3 локализаций. О менее популярных, но не менее интересных направлениях для локализации с английского мы решили рассказать в дополнительной подборке. Из неё можно можно узнать:

  • какой из языков Северной Европы был самым популярным среди наших клиентов в 2020-м, а какой заметно отставал от тройки лидеров;

  • какие языки Центральной Европы, помимо входящего в топ польского, были востребованы для локализации приложений, игр и сервисов с английского;

  • на какие языки Южной Европы стоит обратить внимание помимо испанского, итальянского и турецкого, входящих в топ-10;

  • как обстоят дела с локализацией на языки стран Ближнего Востока.

Посмотреть эту подборку можно в нашем блоге.

Обзоры рынков конкретных стран и рекомендации по локализации для них от Alconost

  1. Чехия и Словакия

  2. Финляндия

  3. Япония

  4. Арабский рынок

  5. Бразилия

  6. Япония, Корея, Китай

  7. Канада

Подробнее..

Перевод Кратко о продуктовых метриках

18.02.2021 10:20:32 | Автор: admin

Продуктовые команды часто применяют такие термины, как инструментарий и телеметрия, и не только потому, что это звучит солидно. Представьте, что вы летите на самолете ночью. Как пилот узнает, в каком направлении движется самолет, достаточно ли топлива, нет ли горы прямо по курсу? С помощью телеметрии.

А теперь представьте, что вы отвечаете за рост вовлеченности на Ютубе. У вас миллиарды пользователей, сложная экосистема. Как узнать, повышается ли вовлеченность пользователей? Почему кто-то использует ваш продукт больше, а кто-то меньше? И что вообще такое эта вовлеченность?

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

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

  • Анализировать выход: получать ответ на вопрос, почему мы видим тот или иной выход.

  • Принимать решения: проводить эксперименты и решать, как должен развиваться продукт.

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

  • Концентрировать усилия: направлять работу команды в одном направлении.

Типы метрик для продуктовых команд

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

Успех, эмпатия и работоспособность

  • Успех (измерение выхода). В правильном ли направлении движется продукт? В чем причины?

  • Эмпатия. Можем ли мы определить смысл метрик? Знаем ли мы, что пользователи думают о продукте?

  • Работоспособность. Контролируем ли мы состояние продукта? У какого процента пользователей он работает надежно?

Истинный север, указатели и контрольные метрики

Истинный север: должен остаться только один.Истинный север: должен остаться только один.

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

  • Spotify общее время прослушивания.

  • Facebook количество активных пользователей в месяц (MAU).

  • Slack количество активных пользователей в день (DAU).

Указатели это метрики, которые не определяют успех продукта, однако (вспомним аналогию с черным ящиком) помогают понять, почему истинный север или иные важные части продукта, которые нужно отслеживать, движутся в определенном направлении. Например, если истинный север для Spotify общее время прослушивания, то указателями могут быть (1) количество уникальных пользователей, (2) количество уникальных композиций, прослушанных одним пользователем, и (3) средняя продолжительность композиции.

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

Факты и смысл

  • Количественные метрики характеризуются высокими объемами и низкой связью с контекстом; они дают фактические данные и помогают понять поведение пользователей: это количество активных пользователей в день (DAU), отток, вовлеченность, объем продаж ит.д.

  • Качественные метрики это низкие объемы и высокая связь с контекстом; они придают смысл количественным данным и ставят их в определенный контекст: это могут быть беседы с клиентами, записи экрана, результаты опроса фокус-групп.

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

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

Практические советы по работе с метриками

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

Слепо используемые в качестве целей метрики утрачивают смысл

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

  1. Коэффициент показ сеанс: процент вошедших в систему пользователей относительно количества открывших экран входа.

  2. Коэффициент попытка входа сеанс: процент вошедших в систему пользователей относительно количества воспользовавшихся интерфейсом экрана входа.

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

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

  • взрослые технически грамотны, показатель попытка входа сеанс для них составляет 71%,

  • пожилые ориентируются хуже, поэтому в их случае это будет 50%.

Вы запускаете эксперимент, который увеличивает количество попыток входа в систему пожилыми. Их доля увеличится, но только 50% таких попыток будут успешными, поэтому используемая в качестве истинного севера метрика попытка входа сеанс снизится с 65% до 63%:

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

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

Метрики должны быть понятными

Метрики не только оценивают прогресс в достижении цели они помогают сплотить команду и позволяют сотрудникам действовать с большей автономностью. Для этого метрика должна быть понятна большой группе самых разных людей иначе это плохая метрика. Для высокотехнологичных команд (например, работающих над поиском) есть исключения, но, как правило, чем проще, тем лучше. Подумайте, сможете ли вы быстро объяснить суть метрики генеральному директору?

В основе самых важных решений почти никогда не бывает идеальных данных

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

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

  • Эмпатия представляет собой интуитивное понимание пользователя или клиента их проблем, ценностей и мировосприятия.

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

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

  1. Обратимость. Насколько обратимо это решение? Превышает ли цена принятия неправильного решения издержки от ожидания точных данных?

  2. Эмпатия. Можно ли заменить нужные данные эмпатией? Без одного из этих ориентиров обойтись можно но без обоих обойтись нельзя.

Резюме. Десять важных вопросов

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

  1. Какой цели вы пытаетесь достичь? Какие у вас миссия и видение?

  2. Как узнать, что цель достигнута?

  3. Как оценивать прогресс в достижении этой цели?

  4. Какие действия вам нужны от пользователей и как оценить, выполняются ли они?

  5. Как измерить совокупное поведение пользователей, определить контекст и выработать эмпатию?

  6. Метрики абсолютные или относительные? Цель привлечь определенное количество пользователей или определенный процент?

  7. Как понять, что продукт надежно работает у 99,9% пользователей?

  8. Можете ли вы объяснить выбранный истинный север максимум двумя предложениями?

  9. Какие контрольные метрики вы отслеживаете в экспериментах?

  10. Как пользователи относятся к продукту?

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

Если статья оказалась полезной можете ознакомиться с остальными в блоге reeve.blog, которые появляются там регулярно (более-менее).


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Root Cause Analysis как метод предотвращения багов

02.03.2021 22:15:14 | Автор: admin

Привет! Мое имя Юра Гомон, яBATech Lead вNIX ивот уже 8лет занимаюсь бизнес-анализом, помогая реализовывать веб- имобильные решения для бизнеса, атакже автоматизировать бизнес-процессы. Мое имя кажется Вам знакомым, т.к. недавно я опубликовал на Хабре свой BADigest.

Цель статьи напомнить бизнес-аналитикам ометоде Root Cause Analysis (далее RCA) иподелиться опытом его применения для предотвращения багов.

В сети очень много информации по RCA, потому не хочу повторяться в отношении теории. Если Вы еще не использовали Problem-solving техники и, в частности, RCA, рекомендую ознакомиться с материалами по ссылками ниже, а уже затем переходить к статье:

В своей статье, планирую поделиться кейсами из практики, где RCA очень помогло не делать ошибок в будущем либо предотвратить потенциальные последствия.

Кейс первый ополитиках

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

Аналог сообщения, которое увидели пользователи. Оригинал несохранился :) Источник:Bytebitebit

Разумеется, это вызвало, мягко говоря, недоумение. Вглазах пользователей работа оказалась заблокированной. Мало того, что угроза кражи паролей, так еще ипредложение продолжить, ноуже unsafe. Страшно.

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

Почему пользователи видят эту страницу?
Посмотрим А-а, так это заэкспайрился SSL-сертификат, продлим, ивсе будет впорядке.
Апочему это несделали заранее?
Никто непоставил напоминание, атри года быстро пролетели.
Резонно. Как думаете, почему непоставили?
Хм, по-моему, это первый проект, где была потребность виспользовании SSL. Это уже после вас стали сертификаты покупать идругим.
Так это ивдругих системах может случиться?
Пожалуй, пойдем везде проверим, поставим напоминалки ивгайдлайны внутренних систем добавим, что надо незабывать это делать.

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

Что изэтого стоит вынести? Ответственные, те, кто знаком сметодами RCA иFive Whys, нетолько исправили ошибку, ноначали задавать вопросы, чтобы найти истинную причину. Как только это случилось, проблему превентивно закрыли везде, где она могла произойти, тоесть предотвратили баг безопасности вдругих системах. Косвенно это привело ктому, что вкомпании стали уделять еще больше внимания безопасности.

Кейс второй олюдях

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

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

  1. Менеджер задокументировал ключевые поинты разговора счеловеком названные импричины.

  2. Предположил варианты сосвоего опыта.

  3. Собрал доказательства существованию причин, проанализировал.

  4. Попытался связать разные причины водну систему, поскольку редко бывает так, чтобы причина была только вчем-то одном.

Граф причин проблемы, воссозданный сослов рассказчика

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

  1. Сначала человек стал засиживаться вофисе после работы почти каждый день.

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

  3. Следом вместо домашней еды онстал питаться подножным кормом.

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

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

Кейс третий оработе стребованиями

Когда БАвходит впроект, который идет уже некоторое время, первая задача разобраться стребованиями, тоесть провести аудит. Обэтом кейсе яделалдоклад наNIX Multiconfв2019году. Сегодня раскрою некоторые детали того случая сточки зрения применения RCA: как искали причины того, почему впроекте начало появляться много багов.

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

Коммуникация

Невозможно было найти ответ или решение через время. Обсуждение требований велось вAsana, Slack, JIRA, через почту, вонлайн- иофлайн-документах. Среди всех источников небыло единого:

  • клиент писал там, где ему было удобно втекущий момент;

  • остальные команды неподдержали нашу критику, поскольку имитак норм;

  • бюджет наведение SRS, митинг-минуток иструктурирование информации невыделялся.

Наша команда неполучала ответов вовремя. Другие команды непонимали наших вопросов:

  • трудности перевода;

  • если непинговать, томогли забы(и)вать нам ответить;

  • пинговать из-за большой разницы сдвумя другими таймзонами было затруднительно.

Стейкхолдеры

Наша команда получала разную информацию изразных источников.

Небыло обмена решениями сдругими командами:

  • небыло четких зон ответственности вплане шаринга информации;

  • структурированные минутки исинки команд требовали времени, которое нехотели выделять.

Клиент часто менял требования/ принимал решения. Настолько часто, что одна команда успевала получить одно, авторая уже другое:

  • уклиента небыло четкой бизнес-идеи, онстарался быстро адаптироваться под нужды целевой аудитории;

  • клиент хотел реализовать как можно больше фич, невзирая наобщий концепт приложения, атакже удовлетворить всех пользователей;

  • назаказчика давили инвесторы, которые требовали постоянного увеличения аудитории ифинансовых результатов.

Уже этих причин вполне достаточно, чтобы понять масштаб трагедии, источник потенциальных дефектов. Безусловно, снашей стороны также были проблемы. Например, техлид выполнял рольБА ипытался кое-как зафиксировать требования врамках своей загрузки, азначит, недостаточно ревьювил более молодых разработчиков. Однако больше всего проблем было из-за хаоса вкоммуникации, отсутствия продуктовой стратегии, нефиксирования требований вдостаточном объеме. Все это привело кневозможности планировать архитектуру иписать код требуемого качества.

Недожидаясь правок понескольким десяткам других пунктов, ЛПРы состороны команды реорганизовали перечень каналов связи иоставили всего три: обсуждение идей велось вAsana, дизайна итребований всоответствующих каналах Slack, тамже создали канал для общих вопросов. Кроме того, все решения покаждой функции стали фиксировать вJIRA, куда перевели только тетаски, которые должны были идти вразработку. Вдополнение ввели жесткие правила понеизменности скоупа врамках спринта (либо полной приостановке ипланированию спринта снуля) идлительности спринта.

Витоге чудесным образом количество дефектов стало резко уменьшаться. ЛПРы воодушевились успехом ипродолжили вносить изменения, которые также несли положительный результат. Но, как оказалось, положительным оноказался только для нас, т.к. вскоре клиент попрощался снами под предлогом того, что небыл готов ктакому уровню бюрократии :) Если заинтриговал, товдокладе поссылке выше больше подробностей.

Ичто?

Есть вещи, которые вот уже 8лет, смомента как явошел вIT, янеперестаю евангелизировать, поскольку нахожу имприменение либо вижу отражение вокружающем мире. Среди них философияпиши-сокращай, модель Кано, принцип Парето, think out ofthe box итак далее. Как выуже догадались, RCA входит вэтот перечень. Авсе потому, что важнейшая, если непервичная задачаБА заключается втом, чтобы понять почему. Будь топроблемная функция всистеме, ошибки вбизнес-процессах, нюансы человеческого поведения, негативные события вокруг все имеет глубокие корни.

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

RCA, конечноже, несеребряная пуля, ноинструмент, который однажды сможет предотвратить очередную проблему. Многие изнас пользуются RCA интуитивно, поскольку любознательность присуща людям, работающим вIT. Однако, использование техники наполную выведет вас нановый уровень при поиске причин ошибок.

Подробнее..

HR Tech М.Видео-Эльдорадо как продуктовый подход позволил нам сделать свой интранет с нуля за полгода

01.03.2021 14:22:08 | Автор: admin


Объединенный интранет группы компаний М.Видео-Эльдорадо завоевал главный приз Russian Intranet Awards в 2020 году и серебро Intranet and Digital Workplace Awards. Этот внутренний продукт был разработан с нуля за шесть месяцев. То, что это удалось сделать в такие сроки и уровнем ценности, признанным внутри компании и за её пределами результат применения продуктового подхода и гибких практик. Рассказываем, почему они были выбраны и какие элементы этой методики стали ключевыми.

Предыстория


В 2018 году произошло слияние компаний М.Видео и Эльдорадо, которые к тому моменту были крупнейшими ритейлерами всего спектра электроники и бытовой техники в России. В объединенной компании трудятся около 30 тыс. человек. В ней более тысячи магазинов, которые работают более чем в 200 городах России.

Для того, чтобы создать единую компанию, требуется масса усилий. М.Видео и Эльдорадо долгие годы самостоятельно формировали свои корпоративные культуры, и они совсем не были похожи друг на друга. И теперь для почти 30 тысяч сотрудников необходимо было транслировать не только уникальную стратегию для каждого бренда, но и единое видение группы компаний.

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

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



Зачем группе М.Видео-Эльдорадо нужен объединенный интранет


В принципе, ответ на этот вопрос очевиден. Цель интранета максимально задействовать человеческий потенциал компании. Чтобы работать с максимальной отдачей и получать от своего труда не только зарплату, но и удовлетворение, нужно знать, чем живет компания, как развивается ее бизнес, какие ценности она исповедует, иметь возможность найти перспективы для себя и команды. И все это можно получить в интранете.

Чтобы правильно расставить приоритеты именно принцип Парето был одним из основных в организации бэклога будущего продукта. На практике это достигается организацией высокой доступности 20 % ключевой информации о сотрудниках и компании, которая даёт 80 % результативности.

Например, 10 ключевых розничных метрик доступных в смартфоне на ладони директора магазина будут удобнее для принятия оперативного решения, чем многоуровневый отчет в BI системе на ПК. Детальный отчет конечно нужен, но в самом начале надо понять общую картину, а это всегда обобщенная и компактная информация.

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



Постановка задачи


До объединения в каждой компании использовалась своя интранет-платформа. Это были SAP FIORI и SharePoint. Каждая из них хороший инструмент, они позволяют агрегировать и визуализировать информацию, размещать сервисы. Но ни та, ни другая платформы нас не устраивали с точки зрения масштабируемости затрат на поддержку.

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

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

Чтобы быть Market-Fit в первую очередь мы пообщались с пользователями. На начальном этапе особенно важно понять, что им требуется от приложения или сервиса. И мы провели опрос репрезентативной группы. Обобщенно, мы спрашивали, что им важно для организации эффективной работы, что не устраивало в старых сервисах, какой функциональности им нужно еще.

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

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

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

Нам необходимо было найти поддержку во всех вертикалях. И мы активно общались с руководителями структурных подразделений, объясняя суть проекта и рассказывая о своих подходах. До каждого из бизнес-ангелов мы доносили список задач, стоящих перед компанией и расчеты того, как проект повлияет на их решение. Работа владельца продукта на начальном этапе очень похожа на работу предпринимателя, который должен доказать жизнеспособность своей идеи перед инвесторами.

Это принесло свои плоды, когда был готов MVP и метрики подтвердили жизнеспособность идеи. К этому моменту о проекте знали практически все руководители, мы успешно его защитили и целевое решение интранета вошло в портфель цифровых инициатив компании, получив серьезные инвестиции.



Продуктовый подход


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

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

Кстати, не все в центральном офисе оценили такой ход, так как для этой персоны (менеджер офиса) на этапе MVP у нас не было значимых фич. Выбор ключевой персоны определяющий для этапа MVP. Это было одним из вызовов для команды менеджмента продукта.

Основные документы


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

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

Видение продукта необходимо и для создания приоритизированного списка требований (верхнеуровнего бэклога), которые предъявляются к разрабатываемому продукту. Приоритеты в нем определяет владелец продукта. Этот документ позволит синхронизировать ожидания от проекта со стороны руководства и заказчиков. И его, так же как и видение, необходимо постоянно поддерживать в актуальном состоянии.



Scrum


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

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

Одним из способом работать с неопределенностью в таких случаях было сочетание agile-подхода и фреймворка Scrum.

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

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

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

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

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



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

Если вы только идете в этот фреймворк запаситесь терпением, постарайтесь обеспечить команду балансом где 1 FTE опытного сотрудника обслуживает или менторит 1 или лучше 0,5 FTE джуна/миддла и найдите грамотного скрам-мастера с техническим бэкграундом. Погрузиться в детали нашего опыта можно тут: часть 1, часть 2, часть 3.

И, тем не менее, Scrum позволяет сформировать реальную картину происходящего и вовремя внести необходимые коррективы.



Правильно определенный стратегический фокус и организация потока работы через инкрементальные поставки, признание ошибок и своевременные выводы позволили нам в итоге получить выдающиеся результаты. Мы провели работу над ошибками, сохранили ключевых членов команды, построили MVP за 3 месяца, а масштабируемое решение за 6.

Что дальше?


Сегодня наш проект и команда продолжает развиваться. Мы наметили переход на LeSS фреймворк, получили кратный рост метрик и сейчас переходим в парадигму внутрикорпоративного SuperApp.

P.S. На данном этапе нам очень нужны талантливые программисты. Если вы такой, приходите, будет интересно.
Подробнее..

Как мы в IVI используем массивы в ClickHouse для подсчета продуктовых метрик

25.02.2021 14:18:30 | Автор: admin

IVI кросс-платформенный сервис, а значит, мы должны анализировать метрики всюду: на вебе, телевизорах и мобильных приложениях. Продукт непрерывно развивается, чтобы стать максимально эффективным, удобным и повысить ценность и привлекательность подписки. Перед тем, как внедрить какую-то новую фичу, мы проводим a/b-тесты и исследуем, на сколько востребованным окажется нововведение и как оно повлияет на конверсию или смотрение. Одновременно у нас может проверяться до 70-ти гипотез, от которых непосредственно зависят планы по развитию продукта.

Для того, чтобы правильно оценить успешность или неуспешность теста, требовалось технологичное решение. Тут рассказывали о том, как мы перешли на ClickHouse (а также о его проблемах на январь 2018). Новая схема ETL позволила нам иметь хранилище, толерантное к дубликатам. При ошибке в коде мы всегда можем откатить consumer offset в kafka и обработать часть данных снова, не прилагая лишних усилий для движения данных. Хотим рассказать о том, как мы в IVI используем ClickHouse, чтобы посчитать метрики для решения разных продуктовых задач и понять, что мы действительно делаем продукт лучше, а не придумываем фичи, которыми никто не будет пользоваться.

О массивах и махинациях с монетизацией контента.

Сперва введем ряд обозначений, которые будем использовать. На IVI есть несколько моделей монетизации. AVOD большой каталог бесплатных фильмов и сериалов, для просмотра которых придётся посмотреть рекламу. SVOD контент по подписке, расширенный каталог без рекламы. TVOD/EST контент, который доступен за отдельную плату и не входит в SVOD. EST покупка навсегда, TVOD аренда фильма, нужно начать просмотр в течение 30 дней, а закончить за 48 часов. Почему так дорого? У меня есть подписка, а я еще должен платить за отдельные фильмы? Ну совсем! Да этому фильму уже 20 лет, а я должен за него заплатить?! 600 рублей за аренду?! - подобное я слышу от друзей, таксистов, врачей по ДМС, преподавателей в университете и даже от родителей. Давайте разбираться.

Есть фильм, а есть правообладатель. Последний решает, в каком формате станут продавать контент. Заключается контракт, в котором описано, по какой модели будет доступен фильм, и если в контракте указано Доступна только TVOD-модель (как было, например, для онлайн-премьеры Человека-невидимки или Эммы), то условия должны быть выполнены. Но времена меняются, контракты перезаключаются, а контент, который был доступен только по модели TVOD/EST, может перетечь в подписку (т. е. в SVOD). И естественно, нельзя не поделиться этой информацией с пользователями.

В результате изменения модели монетизации контента перед нами встает задача объяснить бизнесу, как влияет коммуникация о переходе контента из TVOD/EST в SVOD на выручку и отток. Любая коммуникация с пользователем это ресурсы: человеко-часы, деньги на смс и прочее. Соответственно, нужно убедиться в том, что эти затраты оправданы (ведь экономика должна быть экономной). Мы стараемся проводить большинство коммуникаций в виде a/b-тестирования. Во-первых, чтобы убедиться в их полезности, а во-вторых, чтобы понимать, какие работают, а какие нет.

Переформулируем задачу для себя: провести a/b-тест, связанный с коммуникацией о переходе контента в SVOD из TVOD/EST, чтобы оценить изменение метрик. Выберем для себя ряд показателей, которые будут ключевыми в принятии решения:

1) количество зашедших на карточку контента;

2) количество смотрящих;

3) количество оформивших подписку SVOD;

4) количество купивших TVOD/EST;

5) выручка SVOD;

6) выручка TVOD/EST;

7) конверсия в оформление подписки после захода на карточку контента;

8) конверсия в покупку TVOD/EST после захода на карточку контента.

Для нас важна последовательность действий пользователя из тестовой группы: увидел коммуникацию -> заинтересовался предложением -> оформил подписку (или посмотрел перечисленные тайтлы). Как правило, эта последовательность отличается от блуждания: зашел на ivi -> погулял по карточкам контента -> посмотрел бесплатно -> погулял по карточкам контента -> купил подписку (контент) -> посмотрел контент.

У нас есть инструмент, который позволяет группировать события в массивы по признакам и по флагам в сессии (подробнее о массивах в ClickHouse тут).

У каждого массива в БД своя функция, например, массив, в котором хранятся a/b-тесты, массив с url ресурса, массив с событиями и их индексами в сессии и т.д. Вот маленькая шпаргалка, то, что необходимо понять перед составлением сложных мозгодробильных запросов:

arrayElement( "Вытащить в массиве элемент номер

details.int_value, В массиве таком-то

indexOf( найти номер элемента в массиве

details.name, В массиве таком-то

id' элемента такого-то

)

) in (1,2)

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

берем только необходимые события захода на карточку контента, просмотров и покупок;

джойним на покупки, чтобы посчитать выручку;

собираем в массивы с группировкой по пользователю и дате и с помощью функции arrayCumSum инкрементально размечаем события перехода на карточку контента;

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

создаем флаги наличия просмотра или покупки в рассматриваемых цепочках;

снова разворачиваем массивы для того, чтобы было удобно посчитать необходимые события с помощью агрегатных функций;

считаем события в необходимой агрегации.

Итого. Массивы и возможность взять узкий срез помогли нам корректно оценить результаты эксперимента. Кратко они звучат так: общайтесь с пользователями, им это нравится.

Когда массивы излишни

Давайте отдельно поговорим о кейсе, когда нет смысла использовать массивы.

На IVI есть классная фича вход по коду (см. видео). Если вы авторизованы через мобильное приложение, то все, что вам надо для авторизации на ТВ ввести код с телефона в приложении IVI в своём Smart TV. Для пользователей, у которых нет чуда техники magic mouse, это по-настоящему полезная штука.

Вход по кодуВход по коду

Если мы хотим понять, сколько человек активно пользуется входом по коду, массивы нам не нужны, достаточно просто сделать count() по событиям. Джойны ClickHouse даются нелегко, как и некоторые сабселекты. Но в ряде кейсов сложные конструкции и не требуются, достаточно простого решения, ведь просто не значит неправильно.

Задача: оценить, как часто люди используют флоу входа по коду на Smart TV. Это нужно, чтобы понять, достаточно ли мы уведомляем людей о новых фичах. Ведь важно не только иметь классный функционал, но и понимать, сколько человек о нём знают и пользуются.

Так выглядит стандартная схема авторизации/регистрации на Smart TV:

Нужно проанализировать воронку:

  1. количество пользователей, использующих Вход по коду ко всем авторизовавшимся;

  2. количество пользователей, авторизованных по почте ко всем авторизовавшимся;

  3. количество пользователей, авторизованных по телефону ко всем авторизовавшимся.

Так мы оценим, какой % людей использует функцию входа по коду. Делаем поправку на то, что в данном случае мы оцениваем только кросс-платформенных пользователей, которые проявляют активность и на Smart TV, и на телефоне.

Использование массивов для решения задачи авторизации/регистрации пустая трата времени. Достаточно проследить за тем, сколько людей и на каком шаге отваливаются.

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

Пару слов о проблеме выбора.

Если вы дочитали до этого места, то вот ещё кое-что интересное.

Как лучше показывать акционные предложения на телевизоре? Не стоит множить кнопки на экране, ставя перед пользователем проблему выбора. Мы решили провести небольшой эксперимент, в рамках которого запустили продуктовую коммуникацию, разработав два дизайна одного и того же предложения. На варианте 1 есть только одна кликабельная кнопка, ДА (рис. 1). На варианте 2 кнопок две ДА и Не сегодня. Кроме того, в каждом варианте есть аппаратный back и крестик в правом верхнем углу, их тоже учитываем. Сделав обычный select from посчитали CTR (количество кликов на кнопку/количество показов экрана) и поняли, что лучшее, что есть в выборе его отсутствие. Вариант 1 оказался заметно продуктивнее.

P.S. Благодаря эксперименту мы также узнали о том, что крестик носит скорее эстетический характер, а большая часть пользователей предпочитает аппаратный back: в среднем 7 из 10 человек нажимают на back вместо того, чтобы навести magic mouse на Х.

Рис.1

Рис.2

Подробнее..

Наш процесс разработки. Побег из черной дыры

25.02.2021 08:12:25 | Автор: admin

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

Мне кажется, что в любой компании, деятельность которой как-то связана с IT, отдел разработки является двигателем бизнеса. Leadership team дает направление движения и прокладывает основные координаты, а development дает тягу и мчит компанию в хорошем случае вперед, по проложенному маршруту. Ну или в некоторых случаях куда-то еще. Мы называем наш development процесс и команду Warp Drive, и в этой статье я расскажу про то то, как он построен и про основные принципы его работы.

Для начала картинка, основных составляющих нашего движка. Упрощенная схема выглядит примерно так:

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

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

В целом процесс, по которому мы идем основан на agile практиках. На вход в двигатель поступают требования от бизнес\команды руководства. Это то, что впоследствии будет преобразовано в составляющие конечного продукта, фичи и апдейты. Раз в 2 недели мы проводим Warp Jump (Sprint Planning) где истории назначаются на конкретных людей в команде и мы идем по стандартному 2-х недельному спринту. В результате прыжка в продукте появляются новые фичи, и они потихоньку накапливаются в Dev Environment. Там они проходят проверку качества, и затем деплоятся на Prod. Для простоты Staging/QA environments в нашей схеме пропущены.

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

Итак - желтые фичи находятся в состоянии квантовой неопределенности. Все новые фичи, которые появились в Dev начинают с этого состояния. Это означает, что на данный момент, мы не имеем точного представления о том, является ли эта фича полезной конечному пользователю, или же она только отвлекает\не работает\работает не как надо\не используется. Ответы на эти вопросы мы можем получить только после того, как фича была задеплоена на Prod Environment и мы увидели обратную связь от пользователей. Если пользователь доволен - фича переходит к подтвержденно-хорошее состояние (зеленая), если что-то не так - подтвержденно-плохое состояние (красная) и должна быть либо отправлена на доработку, либо удалена из системы.

Синие фичи, это Technical Debts, т.е. те улучшения, которые девелопмент команда запланировала сделать для своей собственной эффективности. Это может быть или улучшение инфраструктуры проекта, или архитектурный рефакторинг, либо что-то еще. Т.к. участники Warp Drive сами являются заказчиками Tech Debts и мы знаем, что конкретно мы хотим, то такие фичи не проходят через фазу квантовой неопределенности и поэтому классифицируются отдельно от бизнес фич\требований и обычно просто соответствуют состоянию Confirmed Good. В целом процесс перестроения и патчинга двигателя на полном ходу с помощью Tech Debts завораживает, но я думаю все мы в IT индустрии к этому уже давно привыкли.

Далее пройдемся по деталям и поговорим про анатомию одной конкретной фичи.

Из чего же состоит одна фича на нашей схеме? Во первых в нее входят затраты времени на сбор требований и понимание того, какой мы видим ту или иную функцию. Затем, перевод требований в истории, которые непосредственно пойдут в разработку и их приоритизация. Дальше идут Front-End/Back-End development, иногда подключаем DevOps, если нужно еще и environment докрутить. Затем идут затраты на тестирование/QA. И еще один пункт, это поддержка того, что уже работает в Prod.

Для наглядности, развернем эту картинку на полосу конвейера конвертации топлива warp drive(времени) в одну фичу.

Затраты на реализацию одной фичи у нас делятся на 2 типа: повторяющиеся (на схеме отмечены звездочкой), и неповторяющиеся. Для простоты будем считать, что собирать требования, разбивать на истории, проводить backend/frontend development нам нужно только один раз за жизненный цикл фичи. В то же время есть повторяющиеся операции, которые скорее всего понадобится делать снова и снова, уже после того, как данная функция была выпущена в PROD environment. Такими операциями могут быть тестирование, поддержка, иногда конфигурация среды и прочие сервисные штуки.

Таким образом мы получаем, что каждый раз, когда мы релизим что-то в PROD, за счет повторяющихся составляющих фичи, мы увеличиваем операционную стоимость нашего продукта. Если один релиз скорее всего пройдет незаметно, то релизы множества различного функций со временем накапливаются и начинают работать законы масштабируемости. И, как мы обсуждали ранее, не все фичи одинаково полезны. Одним из побочных эффектов нашего Warp Drive являются фичи в Confirmed Red State(красные). Если мы оставляем в системе красные фичи, которые не несут полезной функциональной нагрузки, они не просто увеличивают кодовую базу приложения, но и прибавляют к стоимости поддержки всего продукта. Если не обращать на этот фактор внимание, со временем продукт обрастает функциями, которые не нужны пользователю, и за него еще и платить нужно все больше и больше. И поэтому это очень важно, для поддержания эффективности продукта с точки зрения usability и операционной стоимости стараться держать положительный баланс зеленых фич приложения, и конечно же избавляться от красных. Именно для этого мы держим постоянный контакт с конечными пользователями и требуем от них обратной связи на те или иные функции. Это является частью нашего feature management process.

Еще одним моментом, который влияет на эффективность нашего Warp Drive, является эффективность каждого участника процесса. Основой продуктивности обычно являются не технологии, а слаженность взаимоотношений внутри команды. Но технологии и удовлетворенность работы с конкретными технологиями тоже конечно важны. Следующая диаграмма показывает крутящий момент и общую мощность которую может выдать наш Warp Drive, когда мы работаем над тем или иным функционалом.

Здесь мы видим соответствие участников процесса технологиям, которые используются для разработки фич, таким как front-end development, back-end development, support, requirements gathering, и т.д. Нет, процентные показатели на данной диаграмме это не опыт участников в какой-то технологии. Это количество внутренней энергии и заинтересованность человека в чем-то. Например, если мы дадим Василию ковырять Front-End, наверное не стоит ожидать от него супер продуктивности, просто потому что у него с этой частью как-то не сложилось и он оценил свою вовлеченность в эту область в 10%. Василий предпочтет настроить вместо этого базу данных и будет при этом работать с высокой отдачей, потому что это та деятельность, которая ему нравится, и которая наполняет его энергией.

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

Надеюсь, кому-то будет полезен наш опыт и те опорные точки, которые мы учитываем в работе. Если кому-то интересна бизнес часть нашей работы, прошу посетить подкаст моего кофаундера Брендона. Сори, на английском, но есть субтитры. Как и во многом другом, двигатель и командный пост должны дополнять и помогать друг-другу. Многие решения, которыми мы руководствуемся на уровне разработки, продиктованы именно нефункциональными бизнес требованиями.

https://brandoncwhite.com/startup-podcast-build-business-brandon-straight-talk-for-entrepreneurs/

Спасибо за внимание.

Подробнее..

Ваш дизайн говно! гайд по созданию дизайн-принципов для продуктовой компании

24.02.2021 12:05:30 | Автор: admin

Делимся алгоритмом работы над созданием дизайн-принципов, который сработал для нас и может пригодиться кому-то ещё.

Интродакшн

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

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

Проблема, которую мы решали

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

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

Небольшое отступление про компанию и команду

Kolesa Group продуктовая IT-компания, основанная в Казахстане. Мы создаем и развиваем классифайды сервисы для публикации объявлений для людей и компаний в Казахстане и Узбекистане.

У нас 4 основных продукта:

  • Kolesa.kz классифайд в категории Авто с MAU в 5 млн пользователей. Это 32 % всех интернет-пользователей в стране.

  • Krisha.kz классифайд в категории Недвижимость с MAU 3.5 млн пользователей. Это 23 % всех казахстанских интернет-пользователей.

  • Market.kz классифайд для всех категорий товаров и услуг. Ежемесячная аудитория более 2 млн человек.

  • Avtoelon.uz автоклассифайд в Узбекистане. MAU 2 млн пользователей.

Процесс

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

Шаг 1. Рисерч и поиск референсов

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

Вот подборка ресурсов, где собраны референсы от других команд:

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

Шаг 2. Исследование внутри компании и создание опросов

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

В опроснике были вот такие открытые вопросы:

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

  2. Напишите, что именно хочется исправить в наших продуктах и какие характеристики интерфейсов или процессы разработки хочется добавить.

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

Кроме внутреннего опроса, мы собрали распространенные проблемы в продуктах из базы службы заботы о пользователях (звонки, письма, отзывы в app-маркетах). Это помогло сегментировать проблемы, например, технического или интерфейсного характера.

Примеры проблемПримеры проблем

Шаг 3. Подготовка к шторму

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

На доске подготовили такие штуки:

  • Вытащили примеры принципов некоторых дизайн-команд, которые покрывали наши проблемы.

  • Вытащили результаты опросов.

  • Подготовили площадку для боя. В этой области будет проходить брейншторм. У нас это проходило в Miro.

Шаг 4. Собственно брейншторм

Сам брейншторм был строго ограничен по времени и разделен на этапы. Прежде всего мы обсудили 3 главных вопроса:

  • Почему мы создаем принципы?

  • Для кого мы их создаем?

  • Как те, для кого они будут сделаны, смогут их использовать?

Обсудив вопросы, модератор брейншторма обозначил правила игры, и все участники приступили к штурму.

  1. Сначала каждый участник писал на стикерах ПЛОХИЕ реализации и характеристики интерфейса или пользовательских качеств в продуктах. Ставили таймер на 10 минут.

  2. Затем рядом с каждой плохой реализацией каждый участник должен написать решение проблемы, чтобы ПЛОХОЕ стало ХОРОШИМ 20 минут.

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

4. В итоге у нас вышло несколько категорий, которые мы тоже объединили в сегменты:

A) человекоориентированность, прозрачность и честность в продуктах;

B) осознанность в проектировании, консистентность, качество продукта, эстетичность;

C) контроль состояния, понятная коммуникация, простота и очевидность;

D) командность.

5. Затем каждый участник отдал голос наиболее важным, на его взгляд, категориям 3 минуты.

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

Что осталось?

  1. Осталось придумать названия для принципов и их описания. Нам важно, чтобы названия были запоминающимися и их описания развернуто объясняли суть.

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

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

3. Так мы зафиксировали важные моменты, на которые всегда нужно обращать внимание при проектировании, и выставили их по пирамиде, в которой самый важный принцип находится в самом низу и является фундаментом всего.

Вот что у нас получилось:

[Сначала люди]

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

[Сознательный подход]

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

[Очевидность]

Наши интерфейсы и внешние коммуникации едины, понятно объясняют, на каком шаге находится человек сейчас, и помогают, если что-то пойдёт не так.

[Коллаборация]

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

[Инновации]

Создаем передовые методы, инструменты и технологии для развития дизайн-процессов и качества продуктов. Делимся экспертизой с людьми, которые создают полезные продукты и сервисы для людей во всем мире.

Корабль поплыл

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

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

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

Заметить эффективный рост качества продукта только от внедрения таких принципов сразу невозможно, пока мы только следим за показателями NPS и внешним feedback loop (звонки, письма, отзывы в app-маркетах).

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

Подробнее..

Нужно ли стартапу в 2021 выдавать опционы сотрудникам? Разбираем что это и как оформить

23.02.2021 12:21:01 | Автор: admin

В 21 веке, где ни одного программиста не удивишь теннисным столом, PS5 и ящиком снеков в офисе, нужно задумываться о новых способах мотивации. Ни один стартап не может позволить себе конкурировать с зарплатами талантливых сотрудников, в том числе программистов, гигантов технологического рынка. Чтобы заинтересовать сотрудника в свой проект, чтобы он также как и владелец переживал за развитие компании нужно делиться. Делиться временем. Делиться хорошим вознаграждением за проделанную работу. И делиться акциями или правильнее опционами на акции. За время и деньги все понятно. С опционами разберемся.


image


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


Проще говоря, опционы или как принято называть Опционные программы это вознаграждения сотрудников. Используются как инструмент мотивации персонала, популярны в мировой практике, особенно в США, но с каждым годом в странах СНГ об этом инструменте хотят знать все больше.


Как опционы работают в США

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



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


Оформление опционного соглашения на акции (stock option agreement) в компании США.


Stock option agreement состоит из четырех основных документов:


Stock Option Plan (план опционов на акции). Основной документ компании по выпуску опционов на акции. Содержит условия предоставления опционов, включая цену покупки и любые ограничения.


Individual Stock Option Agreement (соглашение об индивидуальном опционе на акции). Индивидуальный контракт между компанией и опционером. Указывается количество опционов, на которые сотрудник имеет право, типы предоставленных опционов, график перехода прав и другие условия выдачи для конкретного сотрудника.


Exercise Agreement (соглашение об исполнении). Подробно описываются условия, на которых сотрудники могут использовать опционы.


Notice of Stock Option Grant (уведомление о предоставлении опциона на акции). Может не включаться в общие документы, уведомление о предоставлении опциона на акции обычно также включается в соглашение об опционе на акции.


Наделение правами на акции называется вестингом (vesting). Сотрудник не сразу получает все акции, их приобретение растянуто во времени в соответствии с графиком (vesting schedule). Чем дольше работает держатель опциона, тем на большее количество акций он может претендовать.


Стандартный график вестинга составляет 4 года. В первый год не предусмотрена выдача акций клифф (cliff). По завершению клиффа предоставляется право на 25% от пула всех акций по опциону. Дальше оставшиеся 75% распределяются на равные доли и выдаются раз в квартал. Но такой график не является обязательным, каждая компания может составить свой график вестинга.


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



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


Большие корпорации Google, Microsoft, Skype и другие, которые могут себе позволить и большие зарплаты и огромные премии и самые лучшие поощрения для талантливых и ключевых сотрудников, предоставляют и опционы, но каждая компания делает это по своему красиво.


В Microsoft действовала программа на базе опционов для сотрудников. В 2017 году было принято решение ввести новую программу для сотрудников Restricted Stock Units (ограниченные акции). Скорее всего, это было вызвано разочарованием среди работников, чьи опционы не имеют особой ценности, потому что лежащие в их основе акции никогда не росли в цене. Сотрудникам предоставляются реальные акции, а не просто возможность их приобретения. Уловка состоит в том, что акции не могут быть проданы (отсюда и название ограниченные акции), и компания имеет право выкупить акции, если сотрудник не достиг определенных результатов на работе или уходит из компании в течении определенного времени. Например, компания имеет право выкупить 100% акций сотрудника, если сотрудник не остается в компании в течение одного года, 80%, если сотрудник не остается в компании в течение двух лет и так далее. С течением времени компания уже не сможет выкупить акции у сотрудника.


Как опционы работают в России

В опционной программе всеми известного банка Тинькофф участвуют как менеджеры высшего звена, так программисты, разработчики, аналитики, юристы, PR-специалисты и маркетологи. По последним данным, под их управлением находится акций более чем на $176 млн. Для поощрения сотрудников в группе Тинькофф зарезервировано свыше 5% всех акций. Программа акционирования в Тинькофф устроена таким образом, что работник получает акции пакетами в течение нескольких лет, а размер дивидендов зависит от выполнения группой годовых показателей. Совет директоров одобрил первую выплату промежуточных дивидендов за прошлый год на общую сумму приблизительно в $58,4 млн.


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


Варианты оформления опционов для сотрудников


  • Основатель делится частью своей доли с ценным сотрудником. В результате последний впадает в зависимость от акционера. Чтобы исправить положение, придётся поработать с документами. В договор между акционером и сотрудником необходимо внести дополнительные пункты регулирующие получения акций сотрудником. Такой договор не будет являться автоматическим для каждого сотрудника и с каждым сотрудником нужно заключать отдельный договор.
  • Отложенный платёж. Основатели компании почти не получают 100% суммы сразу после её продажи. Это позволяет сохранить их интерес к дальнейшему развитию бизнеса или его интеграции в экосистему стратегического инвестора.
    Применим только в случае M&A-сделки когда стартап покупается целиком или скупаются акции у его действующих акционеров. Отложенный платёж не подходит для мотивации сотрудников, у которых нет доли в компании.
  • Соглашение с сотрудником о предоставление сотрудникам опционов. Опцион на долю в стартапе это соглашение, позволяющее сотруднику через определенное время приобрести долю в компании по заранее оговоренной цене, основанной на оценке, действующей в момент заключения соглашения. Такой опцион традиционно дается под условие достижения сотрудником или компанией определенных ключевых показателей эффективности (KPI). Обычно на момент приобретения доли ее реальная стоимость значительно повышается, и работник становится заинтересован в выполнении KPI и росте рыночной стоимости стартапа. Компания и ее основатели могут увидеть реальный результат от деятельности сотрудника и только после этого передать ему определенную долю.
  • Опционная программа через корпоративный договор для ООО.
    Заключая с таким сотрудником корпоративный договор, необходимо сделать его участником предприятия. В договоре прописываются все возможные условия и ограничения. Можно ограничить сотрудника в самостоятельности в принятии решения, например, согласовать условие о том, что сотрудник обязуется придерживаться позиции, аналогичной основателя, а в случае нарушения такого условия основатель может требовать обратного выкупа переданной доли или получить какую-нибудь неустойку. Но суды при ущемлении прав одного из участников ООО становятся на защиту ущемленной стороны.

Опционы на акции становятся все более распространенным способом привлечения и удержания сотрудников, в том числе и программистов для компаний.
Нужны ли они программистам? Тут выбор только за вами. Они не так просты, как зарплата, но у них есть потенциал большой зарплаты. Условия опциона устанавливаются индивидуально каждой компанией. Поэтому если вы идете на это, следует хорошо изучить договор: сколько опционов предоставляет компания и каков срок перехода прав, цена гранта, которую вы заплатите, когда воспользуетесь этими опционами. Как и когда вы будете исполнять опционы, и от чего это будет зависеть.


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

Подробнее..

Продуктовая аналитика на практике при помощи R

26.02.2021 14:22:55 | Автор: admin

Проблематика

Современная мета управления продуктом подразумевает управление на основании данных.

Все хотят аналитического подхода и способности принимать решения на куче данных о продукте которые есть. Но в реальности есть недостаток информации о том, как именно это делать. Какие инструменты использовать, как принимать решения и как исследовать данные. Я бы хотел поделится именно практическим аспектом этого вопроса в формате одного кейса.

Вводная часть

Начало 2020 года, вы - обычный продукт-менеджер, которому предложили развивать кредитный продукт в другой стране. Оффер принят, документы оформлены, пора за работу.

Первое, что приходит в голову посмотреть, что там с экономикой продукта. И как вообще ведет себя продукт.

Еще через пару дней совещание, на котором вас просят ответить на несколько вопросов:

  1. Сейчас мы платим за привлечение клиента 695494. Какая стоимость привлечения для нас является приемлемой? Имеет ли смысл повысить стоимость привлечения на клиента, чтобы получить больший объем?

  2. Насколько здоровой выглядит экономика портфеля и какая динамика здесь и сейчас?

  3. Мы недавно изменили подход к размеру выдачи и стали в первые кредиты выдавать меньшие чеки. Как это сказалось на продукте?

В общем-то понятные вопросы, на которые стоит уметь отвечать любому владельцу продукта.

Но есть проблема. Метрики, конечно, все посчитаны: LTV, CAC и прочее. Есть финансовая отчетность, где видны все расходы и доходы, и видно, что продукт в небольшом операционном плюсе.

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

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

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

Анализируй это

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

Для того, чтобы анализировать, понадобятся следующие инструменты: R ,Rstudio,dbeaver(или аналог). Далее рассматривается реальный пример, как могут выглядеть эти данные и что с ними можно сделать.

Итак, транзакции. Напишем в базу нечто вроде select * from transactions t и посмотрим результат.

Rows: 2,226,532Columns: 10$ borrower_id          2, 2, 2, 6, 6, 12, 12, 12, 12, 16, 20, 20, 20, 20, 22, 23, 23, 33, 33, 39, 39, 36, 36$ con_id               1, 1, 1, 2, 2, 4, 4, 4, 4, 5, 7, 7, 7, 7, 8, 9, 9, 10, 10, 11, 11, 12, 12, 12, 12, 13$ disbursement_date    2017-11-23, 2017-11-23, 2017-11-23, 2017-11-24, 2017-11-24, 2017-11-27, 2017-11-27, $ prolongations_count  1, 1, 1, 0, 0, 1, 1, 1, 1, 0, 3, 3, 3, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1$ loan_type            "pdl", "pdl", "pdl", "pdl", "pdl", "pdl", "pdl", "pdl", "pdl", "pdl", "pdl", "pdl", "$ date                 2017-12-15, 2017-11-23, 2017-12-06, 2017-11-24, 2017-12-25, 2017-12-29, 2017-11-27, $ type                 "Payments::Transaction::ContractAddTransaction", "Payments::Transaction::DisburseTran$ amount               250000, 1000000, 1200000, 2500000, 3500000, 1040000, 1500000, 10000, 1470000, 1500000$ id                   325, 2, 127, 5, 587, 557500, 557499, 557504, 557507, 17, 182865, 182874, 182869, 1828$ deleted_at           NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, NA, N

Видим всю историю транзакций по всем клиентами. Проанализируем состав полей(обычно можно посмотреть в документации, но кое-что понять можно и так).

У нас есть идентификаторы заемщика, контракта, и транзакции. Дата выдачи кредита (disbursment_date). Отметка о пролонгации кредита (prolongations_count) - перенос даты выплаты за отдельный платеж. Размер и дата транзакции. Отметка о "мягком" удалении.

Главное - тип транзакции(ContractAdd- возврат денег заемщиком, DisburseTransaction - выплата денег заемщику).

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

Выручку по продукту формируют два финансовых потока: от нас к пользователю и от пользователя к нам.

И в нашей табличке есть все данные, чтобы это посчитать.

Также узнаем курс местной валюты к доллару(для примера возьмем, что курс без динамики и составляет 0.00003 доллара за местную валюту).

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

  • для любителей R, данных в табличке прилично, больше 2 млн. Для таких датасетов предпочитаю data table. Но можно и на tidyverse(по запросу покажу как)

Теперь посмотрим на структуру данных и займемся обработкой.

Чуть обработаем их и приведем данные в нужный нам формат. Назовем транзакции удобно и сделаем отрицательными транзакции выдачи кредитов (поля z_type и am):

lk %>% data.table()->lk1 #Создаем отдельный объект вида data tablelk1[,':='(z_type=z_type<-fifelse(#  создаем отдельную переменную - которая отвечает за тип транзакций type=='Payments::Transaction::ContractAddTransaction','add','disb'),am=amount*fifelse(z_type=='add',1,-1))][1:20,c(-1,-11,-8,-6)] #убираем ненужные колонкиlk1[disbursement_date<'2020-01-01' & date<='2020-03-01',c(-1,-11,-8,-6)]->lk1glimpse(lk1) #посмотрим на получившийся фаил
$ borrower_id          2, 2, 2, 6, 6, 12, 12, 12, 12, 16, 20, 20, 20, 20, 22, 23, 23, 33, 33, 39, 39, 36, 36$ con_id               1, 1, 1, 2, 2, 4, 4, 4, 4, 5, 7, 7, 7, 7, 8, 9, 9, 10, 10, 11, 11, 12, 12, 12, 12, 13$ disbursement_date    2017-11-23, 2017-11-23, 2017-11-23, 2017-11-24, 2017-11-24, 2017-11-27, 2017-11-27, $ prolongations_count  1, 1, 1, 0, 0, 1, 1, 1, 1, 0, 3, 3, 3, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1$ date                 2017-12-15, 2017-11-23, 2017-12-06, 2017-11-24, 2017-12-25, 2017-12-29, 2017-11-27, $ amount               250000, 1000000, 1200000, 2500000, 3500000, 1040000, 1500000, 10000, 1470000, 1500000$ id                   325, 2, 127, 5, 587, 557500, 557499, 557504, 557507, 17, 182865, 182874, 182869, 1828$ z_type               "add", "disb", "add", "disb", "add", "add", "disb", "add", "add", "disb", "disb", "ad$ am                   250000, -1000000, 1200000, -2500000, 3500000, 1040000, -1500000, 10000, 1470000, -150

Давайте посмотрим на главное и посчитаем, прибыльный ли портфель.

Для этого посмотрим транзакции за все время. И так как цифры крупные, посмотрим сразу в миллионах:

lk1[,.(total_in_mln=sum(am*for_ex)/1e6),.(z_type)]

total_in_mln

add

58.33176

disb

-45.49114

Видим ясный и понятный результат: транзакции от заемщиков (add) значительно превышают транзакции от выдачи кредита (disb). А ведь часть кредитов наверняка только выдана и по ним даже не подошла дата выплаты.

И здесь же разберемся с темпом, с которым выдавали кредиты:

lk1[!is.na(disbursement_date)&z_type=='disb',.(sum=sum(am*for_ex*-1,na.rm = T)/1e6),.(date=floor_date(disbursement_date,'month',))][,ggplot(.SD,aes(date,sum,label=round(sum,2)))+geom_col(fill=polar_night[2])+ff+tt+  geom_text(aes(y=sum+0.1),col=aurora[1])+  labs(x='месяц выдачи',y='выдача в миллионах долларов',  title='Выдача кредитов в месяц')]

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

Вернемся к Юнит экономике

Глобально мы занимаемся масштабированием пользователей, ведь кредит без человека выдать сложно.

А юнит экономика в таком контексте- это сколько мы зарабатываем или теряем на одном пользователе, заплатив за его привлечение.

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

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

lk1[][,':='( min_date=min(disbursement_date)),.(borrower_id)][,#найдем дату начала работы каждого заемщикаc("gen",'dif'):=.(floor_date(min_date,'1 month'),as.numeric(date-min_date))][, #месяц в котором появился заемщик и растояние в днях между датой его рождения и датой транзакцииn:=uniqueN(borrower_id),][, #количество уникальных клиентов  .(sum=sum(am*for_ex),n=unique(n)),  .(dif)][order(dif)][,":="(bal=bal<-sum/n,cum=cumsum(bal))][,    ggplot(.SD,aes(dif,cum))+ #строим график   geom_line()+   tt+ff+        labs(x='дни жизни заемщика',y='доход в USD',col='поколение',        title='LTV клиента по поколениям и по годам')+   scale_y_continuous(breaks = seq(-200,200,20),   labels =paste0('$',seq(-200,200,20),'k' ))+   scale_x_continuous(breaks = seq(0,1000,20))  ]

Получившаяся кривая показывает его LTV c динамикой по времени. И это уже близко к ответу на первый вопрос о стоимости привлечения пользователя.

Но перед тем как пустится в эти рассуждения, стоит вспомнить, кто такой, этот средний пользователь. Мало ли, может, лучшие времена продукта давно позади.

Поэтому стоит посмотреть этот же график, но разбив по поколениям и посмотрев последние 24 поколения. Сразу же наложим сюда стоимость привлечения и разобьем по годам(чисто для удобства сравнения):

lk1[,':='( min_date=min(disbursement_date)),.(borrower_id)][,c("gen",'dif'):=.(floor_date(min_date,'1 month'),as.numeric(date-min_date))][,n:=uniqueN(borrower_id),.(gen)][,  .(sum=sum(am*0.00003),n=unique(n)),  .(gen,dif)# сгруппируем данные  по поколениями][order(gen,dif)][,":="(bal=bal<-sum/n)][,':='(cum=cumsum(bal),m_dif=max(dif)),.(gen)][dif<=m_dif-30 & gen %between% c('2018-01-01','2021-03-31')][, ggplot(.SD,aes(dif,cum,col=factor(gen)))+ geom_line()+ facet_wrap(~factor(year(gen),levels = c(2019,2018)),nrow=2)+tt+ff+ labs(x='дни жизни заемщика',y='доход в USD',col='поколение', title = 'LTV клиента по поколениям и по годам')+ scale_y_continuous(breaks = seq(-200,200,20), labels =paste0('$',seq(-200,200,20),'k' ))+ scale_x_continuous(breaks = seq(0,1000,20))+ geom_hline(yintercept = 695494*for_ex,color='red',size=1)+ geom_hline(yintercept = 0,color='dark red',linetype='dashed')+ geom_text(inherit.aes = F,aes(x=as.Date(600), y=695494*for_ex+3,group=1),label='Стоимость привлечения клиента = $20.86', col='red',size=6)+tt+ff+ theme(legend.text = element_text(size=20),       legend.title = element_text(size=25))+  guides(colour = guide_legend(override.aes = list(size=10)))]

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

  1. Точка, из которой начинаются линии - размер первого кредита.

  2. Чем выше траектория, тем больше денег на одного пользователя мы заработали в этом поколении.

  3. Чем раньше траектория поколения пересекает 0, тем быстрее мы начинаем зарабатывать на привлеченном пользователе.

  4. Чем раньше линия пересекает линию стоимости привлечения, тем раньше мы зарабатываем достаточно, чтобы окупать его в данном поколении.

Выводы

  1. Продукт становится лучше. Траектории более поздних поколений пересекают ноль и стоимость привлечения раньше, чем траектории старых поколений (150 дней против 180).

  2. Разница в темпах окупаемости объясняется скорее стартовой точкой и первой парой кредитов. Например, поколения конца 2018 года окупались лучше, имея меньшую сумму первого кредита и большую сумму второго. Это можно понять по провалу на траектории на 10-40 днях. Так же в 2019 году: поколения с меньшей средней суммой первого кредита окупали себя намного быстрее.

  3. На дистанции в один год мы заработаем на одном пользователе от 40 до 60 долларов. Максимальный размер заработка неизвестен. Ни одно поколение пока не вышло на плато, но экстраполируя, оценка в 120-150 долларов на дистанции в 3 года выглядит разумной

  4. Наиболее существенное влияние на траекторию оказывают события первых 90 дней, после этого темп роста плюс минус одинаковый.

Мы тут ради ответов, а не картинки смотреть

Воспользуемся полученными знаниями и порассуждаем об ответах на вопросы к предстоящему совещанию

1. Сейчас мы платим 695494. Какая стоимость привлечения для нас является приемлемой? Имеет ли смысл повысить стоимость привлечения на клиента, чтобы получить больший объем?

Ситуация выглядит следующим образом - у нас есть успешный продукт, который мы не масштабируем - и это проблема. Ожидания по доходности от клиента на дистанции год - 40-60 долларов. Текущие затраты на привлечение $20.8 (695494* 0.00003)

В принципе - увеличение стоимости привлечения наша экономика выдержит, портфель не станет убыточным. Но в продукте - длинный срок окупаемости клиента.

Если мы можем позволить себе тратить сейчас - чтобы заработать потом - эксперименты оправданы.

2. Насколько здоровой выглядит экономика портфеля и какая динамика здесь и сейчас?

Портфель устойчиво положительный, с динамикой к росту за счет практик развития клиентов в первые дни жизни. Главное пространство для идей - механика работы с клиентами возраста 100+ дней.

Там существенных прорывов пока не было.

3. Мы недавно изменили подход к размеру выдачи и стали в первые кредиты выдавать меньшие чеки. Как это сказалось на продукте?

Вообще - видно что поколения в которых первый кредит был меньшим по размерам окупали себя чуть лучше. Четкий ответ - только через АБ тест.

Итог

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

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

Из этих же данных несложно собирается еще несколько важных оценок и выводов , но о них в дуговой раз.

Подробнее..

Как организовать эффективное управление продуктом в b2b

21.02.2021 14:07:08 | Автор: admin

Есть ли разница между созданием продукта для потребителя и для бизнеса? Очевидно, что есть, хотя продуктовый менеджмент в b2b очень похож на b2c, здесь также есть пользовательские проблемы и опыт, гипотезы и требования, цели и метрики. Но есть и важное отличие в b2b принимать решения о покупке продукта и пользоваться им часто могут разные люди.

Поэтому c одной стороны время и затраты на начало пользования продуктом бизнесами значительно выше, чем на потребительском рынке. А с другой компаниям гораздо тяжелее отказаться от уже используемого продукта, чем отдельным пользователям. Кроме этого, входящий трафик в b2b и b2c сегментах существенно отличается: у второго он обычно значительно выше.

Я Group Product Manager компании iDeals, которая создает b2b-продукт виртуальные комнаты данных (VDR). В этой статье подробно расскажу о том, как мы выстроили продуктовый процесс и что делаем на каждом из этапов.

Для чего

Продуктовый процесс:

  • уменьшает субъективизм в принятии решений продуктовыми менеджерами,

  • упрощает понимание того, что и в какой момент времени необходимо делать,

  • добавляет прозрачности как внутри продуктовых команд, так и за их пределами для смежных подразделений.

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

Продуктовый процесс

Каждый шаг продуктового процесса называется в соответствии с тем, в каком состоянии находится или что происходит с идеей / гипотезой. Для простоты отслеживания всех существующих идей мы используем что-то похожее на Kanban доску, где имя каждой колонки это одноименный этап.

Идея

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

  • анализа рынка и конкурентов;

  • качественных исследований пользователей и клиентов (интервью, опросы и т. д.);

  • количественных исследований пользователей и клиентов (Heap, Bigquery, Google analytics и т. д.);

  • обратной связи от потенциальных и нынешних клиентов и пользователей;

  • идей от стейкхолдеров или других команд;

  • внутренних запросов от других команд;

  • выводов после измерения показателей успеха.

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

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

Примеры идей:

Привет! А можно ли как-то увидеть все свои заметки из комнаты данных? Я бы хотел видеть их в одном месте, чтобы не кликать на разные файлы, для которых я их сделал.

Здравствуйте!

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

Гипотеза

Гипотеза отличается от идеи глубиной проработки. Обычно в ней 4 блока, которые по сути отвечают на следующие вопросы:

  1. Какая проблема решается? Идея в формате гипотезы, которая содержит информацию об аудитории, проблеме и условиях, когда она возникает.

  2. На кого повлияет? Более детальная информация об аудитории или персоне, которая испытывает проблему.

  3. На что повлияет? Приблизительная оценка бизнес-показателей, на которые повлияет возможное решение проблемы, описанной в гипотезе. Например, удовлетворенность клиентов или уровень конверсии из пробного (триального) аккаунта в клиентский.

  4. Как сейчас решается проблема? Информация об обходном пути внутри продукта или за его пределами, с помощью которого сейчас решается проблема.

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

На этом этапе в процесс вступает приоритизация, которая призвана бороться с субъективизмом и ориентировать продуктовый процесс на работу только с самыми влиятельными и важными идеями. Для этого в iDeals мы используем модифицированный подход RICE от Intercom (Reach * Impact * Confidence / Effort), который дополнили еще одним параметром Strategy (S) и в итоге получили RICSE (Reach * Impact * Confidence * Strategy / Effort):

  • Reach (охват) определяет, на какое количество пользователей, транзакций или, в нашем случае, проектов (комнат) повлияет решение проблемы из гипотезы.

  • Impact (влияние) условный коэффициент того, как сильно решение проблемы из гипотезы повлияет на пользовательский опыт аудитории. Мы используем шкалу от 0 до 3 с шагом 0.25, каждый из шагов значит силу влияния: от 0 нет влияния, до 3 влияние огромное.

  • Strategy (стратегия) показывает, на сколько это решение ложится в наши долгосрочные планы. Мы используем три значения стратегии: 0,3 нет соответствия стратегии; 0,8 частичное соответствие; 1 полное соответствие.

  • Effort (трудозатраты) это высокоуровневая оценка, для которой мы используем числа Фибоначчи, к которым привязаны календарные периоды: 1 до 2 недель; 3 до месяца; 5 до квартала; 8 до двух кварталов; 13 два квартала и больше (или по факту, когда оценка крайне неточна, но понятно, что решение будет очень трудозатратным).

  • Confidence (уверенность) условный коэффициент уверенности во всех других показателях и может принимать значение от 0,1 до 1. Обычно мы используем шаг 0,2 для каждого показателя, в котором есть сомнения. Например, если мы не очень уверены в охвате, то уверенность 0,8, а если еще и во влиянии 0,6 и т.д.

На этом этапе, мы используем приблизительные показатели и не сильно углубляемся в правильную оценку. Например, для Reach (охват) достаточно понять, что если определенную функцию используют в неком количестве проектов, это число и будет использоваться как Reach. На следующем этапе эту цифру мы проверим более подробно и получим максимально близкое число.

Пример гипотезы:

Какая проблема решается?

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

На кого повлияет?

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

На что повлияет?

  • Уменьшение расходов на отправку кодов для двухфакторной аутентификации через СМС и звонки.

  • Уменьшение количества случаев, когда из-за невозможности доставить код пользователь не может войти в систему.

  • Повышение уровня удовлетворенности пользователей.

Как сейчас решается проблема?

Отключением двухфакторной аутентификации.

Валидация

При валидации мы пытаемся получить более правильную оценку всех показателей RICSE, а также максимально приблизить Confidence (уверенность) к 1. Таким образом, весь этап валидации это попытка оцифровать уверенность и оценить неопределенность. На данном этапе мы подключаем продуктового аналитика, вместе собираем данные и строим первые прогнозы по гипотезе.

Этот этап имеет два возможных пути решения:

  1. У нас есть все необходимые данные для подтверждения гипотезы и движения дальше.

  2. У нас нет данных для подтверждения гипотезы.

В первом случае мы проверяем ретроспективно, исходя из разных данных, которые у нас уже есть. Для этого используем типичные инструменты: Google Analytics, Heap, BigQuery; опросы для количественных данных, интервью, запросы и отзывы клиентов для качественных.

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

Окончание этапа обновленные показатели RICSE и отчеты, Excel таблицы, записи интервью и другие данные, которые подтверждают эти показатели.

Гипотезы с наибольшей приоритизацией берутся в дальнейшую проработку.

Пример гипотезы и валидации:

Гипотеза

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

Данные для валидации:

По данным за 4-й квартал 2020-го года около 30% всех проектов имеют больше одного архива в формате ZIP, RAR или 7Z, но при этом только 1.7% из проектов с архивами хоть раз использовали функцию разархивации.

Решение (PRD)

Данный этап целиком и полностью посвящен самому решению и созданию product requirements document (PRD / документ с требованиями к продукту) и состоит из следующих шагов:

  • исследование рынка на предмет того, как лежащая в основе гипотезы проблема решается прямыми и непрямыми конкурентами, а также продуктами из других отраслей;

  • определение персон, которые являются покупателями и пользователями решения;

  • определение возможных флоу, которые являются характерными для разных персон;

  • создание пользовательских историй (user stories) для понимания полной картины и всех возможных нюансов;

  • обсуждение уже полученных наработок с технической командой на предмет того, является ли это все возможным, нужно ли проводить дополнительные технические исследования или создавать технические концепты (proof of concept);

  • детальная проработка пользовательского опыта и интерфейса (UX / UI);

  • проработки UX / UI и консультации с технической командой могут быть итеративными;

  • создание динамических прототипов для подтверждения жизнеспособности и удобства разработанного решения с реальными или максимально похожими по профилю пользователями;

  • определение необходимых маркетинговых активностей: коммуникация через имейл / продукт; материалы для маркетинг-сайтов, влияние на прайсинг и планы и т.д.;

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

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

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

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

Таким образом получается, что формула RISCE: React * Impact * Strategy * Confidence / Effort получает подтверждения по всем элементам и гипотезы / решения вновь приоритизируются уже учитывая все переменные в формуле.

Дорожная карта (Roadmap)

В конце каждого квартала продуктовые менеджеры вместе с инженерными менеджерами и командами составляют дорожную карту (Roadmap) на ближайший квартал для каждой технической команды (их у нас 6). В нее попадают уже подготовленные решения. Иногда и гипотезы для технической или продуктовой проработки, которые имеют наивысшие значения приоритета по RICSE.

Также мы оставляем часть инженерного времени (до 15-20%) на доработки, связанные с инструментами для внутренних потребителей (команды поддержки, продаж и тд.), техническим долгом и идеями, которые не имеют твердого подтверждения данными, но кажутся перспективными.

Для прозрачности и простоты отслеживания дорожной карты мы используем специальный шаблон в Notion. Каждые пару недель продуктовые или инженерные менеджеры обновляют прогресс и статус каждого пункта. К этому шаблону также имеют доступ руководители маркетинга, поддержки, продаж и других, чтобы иметь возможность в любой момент узнать статус интересующего решения.

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

Имплементация

В условиях iDeals команды работают по процессу, который очень близок к Scrum, со всеми соответствующими артефактами: итеративная разработка, ежедневные встречи по 5-10 минут для быстрой синхронизации, еженедельные встречи для обсуждений новых пользовательских историй, каждые две недели планирование очередной итерации (Спринта) и проведение ретроспективы по прошлой.

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

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

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

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

Верификация

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

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

Вывод

Создаете ли вы продукт в b2b или b2c сфере, он должен быть понятным, простым в использовании и эффективным. В обоих случаях пользователи такие же люди, как вы, поэтому для работы с продуктом также необходимо общение с ними, исследования и отслеживание различных метрик.

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

Как устроен продуктовый процесс в вашей компании? Делитесь в комментариях!

P.S. Спасибо Дмитрию Ковалю за помощь в подготовке статьи.

Подробнее..

Масштабируем продакт-менеджмент как управлять продуктом, который разрабатывают 50 команд

24.02.2021 20:16:16 | Автор: admin
Всем привет!

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

image

Интересующимся и желающим пообщаться на эту тему добро пожаловать под кат.

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

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

  • Какая-то понятная система или компонента, которая участвует в очень большом и сложном бизнес-процессе;
  • Владелец продукта человек бесспорно знающий куда эту систему развивать;
  • Набор документации в разной степени актуальности;
  • набор тестов, автоматизированных и не очень.

Знакомая картина?

Так выглядит типичная, и не самая худшая система разработки ПО. Обычно, к такому виду приходят департаменты разработки компаний с успешными продуктами лет через 10-15. Успешные продукты приносят деньги, деньги вкладываются в разработку. Разработка растет как на дрожжах, ее линейно масштабируют и приходят к ситуации, когда проектные менеджеры уже не могут держать в голове все зависимости, множество команд начинают тянуть одеяло на себя, и, порой вредят продукту, нежели развивают его. В такой ситуации вполне нормально, когда одна команда стремится к собственному успеху, уже не переживая, что их коллеги испытывают какие-то проблемы и их общая фича не будет из-за этого доставлена. В порядке вещей разрабатывать тот функционал, который громче всех просят бесконечные стейкхолдеры, а не тот, который нужен пользователям. Не редкость и разработка в стол. Процесс ведь идет требования приходят, реализуются, тестируются, поставляются. За ширмой из суеты и шума легко спрятать главное разработка продукта уже далеко не такая эффективная, как раньше.

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


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

Не похоже на историю выше, верно?

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

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

  • Пользователей кастдевил продакт? Теперь ваши владельцы продукта о них не вспоминают, они носятся от одного стейкхолдера к другому, пытаясь понять за какие требования хвататься в первую очередь;
  • Была ясная и прозрачная юнит-экономика? Теперь владельцы продукта не считают даже PnL, загружая всю команду на пол спринта сторями с сомнительной пользой;
  • Были job story, customer journey map и прочие персоны? Теперь в сторе пишут Как продакт оунер я хочу чтобы это было сделано, потому что это нужно департаменту Operation and Maintanence;
  • Было понимание ответственности за результат и сроки? Теперь каждая команда сама за себя, ваши фичи доставят на релиз-другой позже.

Сложность управления разработкой для масштабных продуктов растет по экспоненте. Что же делать?

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

Списочком

Являются ли они серебряной пулей?

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

И могу сказать следующее:

  • это дорого;
  • это не быстро;
  • это очень рискованно;
  • конечный успех сильно зависит от культуры компании. Если люди понимают и верят успех вероятен.

Единственно ли верен подобный подход? Давайте посмотрим, что еще можно сделать.

image

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

Продукт. Продукт должен приносить ценность. Рассмотрите зоопарк ваших систем и компонент с точки зрения ценности. Выделите все потоки ценности (value streams) для конечных клиентов, контрагентов или третьих лиц и разделите карту систем по таким потокам. Каждый владелец продукта должен иметь в управлении полную цепочку систем, имеющих ценность. Дайте ему пару аналитиков, если объем ответственности слишком велик.

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

Пользователи. В сторону стейкхолдеров. Только пользователи могут дать верное представление о ценности продукта. Владелец продукта должен ориентироваться на результаты интервью и анализ тикетов поддержки в своих гипотезах.

Гипотезы. Никаких больше имплементаций функционала в слепую. У каждого эпика или фичи должны быть ожидания по влиянию на метрики. Реализуя фичи и проверяя их А/B тестами, владельцы продукта должны понимать успешна была гипотеза или нет.

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

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

Снова про мониторинг продуктов как Postman избавляет поддержку от написания кода

26.02.2021 10:11:26 | Автор: admin

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

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

  1. Составить карту пользовательских сценариев описать по шагам все действия, которые пользователи выполняют в продукте.

  2. Пройти по интерфейсу, зафиксировать запросы, которые стоят за каждым действием пользователя.

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

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

Как работать с Postman

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

  • Окружения содержат значения переменных, с которыми мы работаем в рамках сценариев адреса серверов, имена папок и т.д. Фактически одно окружение это один продукт.

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

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

Как мы встроили Postman в свой процесс

Мы применяем Postman для разработки сценариев мониторинга, тестирования и проработки интеграционных взаимодействий.

  • Сценарии экспортируются в JSON-файлы и сохраняются в Git-репозиторий TFS.

  • В пайплайне TFS прописывается проверка по расписанию. Стоит отметить, что для нас интеграция с TFS это ещё одно преимущество Postman, поскольку с этого года все наши команды работают именно здесь. В TFS можно сразу увидеть результат выполнения запросов, что очень удобно, если Postman используется для отладки продукта. У нас речь про мониторинг, так что не будем углубляться.

  • JSON-файл вызывается через утилиту Newman это инструмент для запуска коллекций из командной строки, который также разработала команда Postman. Он умеет выполнять запросы, принимать ответы на них, высчитывать метрики, которые указаны в сценарии.

  • Результаты выполнения сценариев сохраняются в БД Influx, откуда данные отправляются в дашборды Grafana. Здесь можно настроить критические пороги, чтобы автоматически сообщать, если какой-то показатель выходит за заданное значение.

Итого

Когда мы отрабатывали технологию мониторинга, мы планировали использовать Zabbix. При ближайшем рассмотрении выяснилось, что для наших целей он не подходит написать сценарий нативными средствами невозможно, приходится готовить их на Python. Причём без такого инструмента, как Postman-овские коллекции, делать это приходится каждый раз заново.

Здесь же вся логика зашита в интерфейс. Так что инженеру достаточно подставлять нужные данные в отдельные участки кода. Это существенно снижает порог входа для всех, кому нужно работать с запросами, будь то разработчики, аналитики, тестировщики или кто-то ещё.

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

Подробнее..

Зачем бизнесу внедрять PIM системы и как это сделать эффективно

26.02.2021 10:11:26 | Автор: admin

Эта статья основана на нашем опыте внедрения PIM системы OpenPIM.Эффективное управление информацией о товарах имеет решающее значение для любой организации. В течение многих лет электронные таблицы были инструментом управления данными по умолчанию, но по мере того, как компании расширяют свой каталог продуктов и выходят на большее количество каналов и рынков, ограничения электронных таблиц становятся очевидными. В результате все больше и больше предприятий внедряют PIM системы для управления информацией о своих продуктах.

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

1. Определите цели и объем вашего проекта PIM

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

Вот несколько примеров целей, в достижении которых может помочь PIM:

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

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

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

  • Ускорение вывода на рынок: быстрее распространяйте новые продукты и контент по различным каналам, включая онлайн-магазины, мобильные платформы и многое другое.

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

  • Масштабирование в новые регионы: управление переводом и автоматизация конвертаций единиц измерения делают локализацию намного быстрее и эффективнее.

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

Затем вы можете начать думать о фазах вашего проекта. Стоит ли смоделировать весь каталог и начать управлять всеми своими продуктами с самого начала? Или вам следует начать с ограниченного подмножества ваших брендов, продуктов, каналов или регионов? Это решение будет зависеть от ваших бизнес-целей, а также от сложности и зрелости вашей организации.

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

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

Независимо от подхода, убедитесь, что он соответствует вашим бизнес-целям, и задайте себе следующие вопросы:

  • Можем ли мы начать с подмножества продуктов или следует заняться всем каталогом?

  • Какие каналы наиболее важны для нашего бизнеса?

  • Является ли какой-либо регион более важным, чем другой?

  • Насколько важно время вывода на рынок для вашей компании?

2. Определите команду и процессы

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

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

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

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

3. Определите структуру вашего каталога

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

Распространенная ошибка организаций - начать использовать PIM как удобный интерфейс базы данных вместо того, чтобы использовать все его инструменты и функции. PIM - это больше, чем просто интерфейс для создания, чтения, обновления или удаления данных о товарах. PIM позволяет вам эффективно моделировать ваш каталог для всех ваших каналов и регионов.

Структура вашего каталога должна учитывать и поддерживать:

  • Категории продуктов, семейства, варианты и атрибуты продуктов в разбивке по различным каналам.

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

  • Атрибуты, зависящие от локали, такие как валюты и описания.

  • Определенные отношения и ассоциации между продуктами.

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

4. Определите источники и соберите данные

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

Примите во внимание следующее:

  • Каковы ваши самые надежные источники?

  • Что будет источником каждой части данных о вашем продукте?

  • Какие источники содержат лучшие данные по определенным атрибутам?

  • Какие бывают форматы?

  • Могу ли я разрешить поставщикам предоставлять данные о товарах?

5. Автоматизируйте управление каталогом с помощью бизнес-правил и массовых действий

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

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

Использование бизнес-правил позволяет автоматизировать такие действия, как:

  • Автоматическая категоризация новых продуктов по семейству.

  • Копирование значения из одного атрибута в другой.

  • Установка значения по умолчанию для пустого поля.

  • Назначение семейств на новые продукты.

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

Вместо того, чтобы вручную выбирать товары на вкладках Excel и рисковать забыть товар или внести ошибки при публикации, бренды и ритейлеры должны автоматизировать процесс создания коллекций с помощью PIM. Предположим, ваше исследование показывает, что в этом сезоне коричневые куртки-бомберы стали очень популярны. Просто создайте индивидуальную коллекцию со словами коричневый, куртка-бомбер и мужчины, и все подходящие товары будут сгруппированы вместе. Более того, когда члены команды импортируют новые продукты, они автоматически добавляются в список, если соответствуют существующим критериям. Точно так же вы можете создавать ассоциации других связанных продуктов, чтобы создать возможности для перекрестных продаж - например, сопоставив коричневые кожаные перчатки с куртками-бомберами.

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

Подробнее..

Production Ready как проверить работоспособность продукта

01.03.2021 14:22:08 | Автор: admin

Сегодня мы поделимся критериями, которые используют команды True Engineering, чтобы удостовериться в качестве продукта при поставке на Prod.

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

Эти единые представления и составляют понятие Production Readу. Когда команда договаривается о требованиях, которым должен соответствовать продукт, разработчикам становится проще работать. Все вкладывают в понятие готовности единый смысл, значит результат не меняется от разработчика к разработчику не будет такого, что кто-то не стал делать логирование, потому что посчитал, что почему-то не нужно. У менеджера проекта меньше головной боли он знает, в каком состоянии получит продукт и что можно гарантировать заказчику.

Наш набор критериев Production Ready объединил и наши собственные знания, и лучшие практики из внешнего мира разработки. Этот момент стоит отдельно подчеркнуть необязательно брать под копирку чужой опыт, у вашей команды может быть свой стиль работы. Главное, чтобы он был эффективным и соответствовал единому стандарту.

Итак, как мы понимаем, что наш продукт действительно Production Ready?

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

  2. Продукт имеет хорошо продуманную архитектуру. То есть она формируется не стихийным образом. Если решение заранее спроектировано, его архитектура учитывает возможные риски и перспективы развития. Такой подход позволит команде продумать отказоустойчивость продукта, заранее определиться с техническими средствами, которые обеспечат нужную функциональность, и проверить их совместимость. Иначе в будущем может выясниться, что внедрить нужную фичу нельзя без того, чтобы переделывать фундаментальные модули продукта. От архитектуры зависят другие критерии мы ещё не раз к ней вернёмся.

  3. Систему можно протестировать. В данном случае мы не имеем в виду 100-процентное покрытие тестами (хотя это тоже полезная вещь). Важно закладывать саму возможность оценить работоспособность системы до того, как она запущена в бой. Не так важно, будут ли это ручные проверки или автоматизированные тесты главное, чтобы продукт сам по себе мог получать тестовые данные и выдавать результат. На низком уровне это означает, например, что в решении нет сильно связанных классов и каждый модуль можно проверить с помощью абстракций и mock-ов. На верхнем что у вас есть тестовое окружение и проверки работоспособности не вызовут проблемы у реальных пользователей.

  4. Продукт работает стабильно. Не бывает систем, которые работают бесперебойно 100% времени, поэтому под стабильностью следует понимать соответствие SLA. Эти требования меняются от продукта к продукту, а иногда - даже от одного модуля системы к другому. У сайта-визитки и учётной системы принципиально разные требования к стабильности. Самое главное, чтобы они были прописаны в SLA, а команда гарантировала их выполнение.

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

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

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

  8. Продукт работает. Это может показаться очевидным, но нужно понимать, что пока решение не запущено на боевом сервере и с ним не работают реальные пользователи, систему нельзя считать готовой. Если код, который выполняет все требования, лежит в Gitlab, а не запущен на сервере, продукт не готов.

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

Единые критерии Production Ready помогут вам добиться одинакового результата, вне зависимости от того, кто создаёт продукт или кто управляет каждым конкретным проектом. Рекомендуем брать этот метод на вооружение всем, кто хочет выстроить для своей команды простые, прозрачные и логичные правила разработки.

Подробнее..

Масштабируем продакт-менеджмент, часть 2 продукт

01.03.2021 16:18:41 | Автор: admin

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

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

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

В разных компаниях по разному организуют разработку таких систем. В одних компаниях можно увидеть команды разработки, которые ответственны за несколько компонент, в других наоборот, одну компоненту может разрабатывать несколько команд. Однако чаще всего на одну систему приходится одна команда разработки. Это классический и наиболее распространенный подход компонентных команд (component teams).

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

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

Чем это грозит?

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

Как же тогда определить, что такое продукт?

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

Ценность понятие субъективное. В процессе взаимодействия с решением у покупателя возникнет некоторое собственное ощущение того, насколько простым, приятным, удобным и полезным это взаимодействие. Именно за это покупатель и платит.

Оплата в свою очередь это самый просто маркер для выделения продукта. То, за что пользователь готов платить, и называется продуктом. В данном случае это некоторый набор из систем, людей и процессов, обеспечивающий поток ценности пользователю (operational value stream).

В таком случае владельцу продукта с методологической точки зрения более правильно было бы реализовать разработку сразу нескольких систем, участвующих в потоке ценности. Такие команды разработки называются продуктовыми или функциональными (feature teams или cross-component teams).

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

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

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

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

И еще раз о том, зачем выделять продукт.

В случае, когда продукт выделен правильно, владелец продукта имеет возможность:

  1. Влиять на все компоненты, составляющие поток ценности;

  2. Видеть реальные метрики продукта, а не косвенные, отраженные в компоненте;

  3. Опрашивать пользователей напрямую, понимая их проблемы, а не получать интерпретацию от продакт менеджера / главного владельца продукта

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

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

Спасибо за внимание, в следующей статье поговорим про метрики.

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru