Product management

Язык программирования это тоже продукт. Он помогает разработчикам выражать свои идеи так, чтобы их мог интерпретировать компьютер. Может показаться, что развивать язык это брать последние достижения теории языков программирования, реализовывать их и из года в год выкатывать разработчикам. Это не так. Егор Толстой, Kotlin Product Manager, и Андрей Бреслав, руководитель проекта Kotlin, рассказали, зачем JetBrains бесплатный язык программирования, как он устроен и откуда приходят новые пользователи. Статья вдохновлена выпуском подкаста make sense о Kotlin.

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

Мы начали делать Kotlin десять лет назад, а первый релиз вышел зимой 2016 года. Изначально он задумывался как язык, который улучшит жизнь Java-программистов. Сейчас на Kotlin пишут даже приложения для браузеров и iOS. Современный Kotlin универсальный язык программирования с большим количеством приятных для разработчиков фич, статически типизированный, заточенный под большие проекты и поддержку крупных кодовых баз.

В серии статей мы расскажем про то, как Kotlin организован с продуктовой точки зрения, как устроен менеджмент продуктов у программистов для программистов, что такое developer experience, как его можно измерить и улучшить.

Зачем JetBrains делает бесплатный язык программирования

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

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

У JetBrains есть четыре причины заниматься созданием языка.

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

Но при этом Kotlin поддерживается в IDE от JetBrains, которые не заточены под какую-то конкретную технологию. Например, та же IntelliJ IDEA поддерживает Kotlin и какая-то часть ее продаж приходится на Kotlin-разработчиков. Это достаточно сложно отследить, но мы видим, что среди пользователей платной версии IntelliJ IDEA их немало.

Узнаваемость бренда. Если раньше JetBrains была компанией, которая делает классные IDE, то теперь мы компания, которая сделала Kotlin. А это совершенно другой уровень интереса просто потому, что за кофе люди чаще обсуждают языки программирования, чем IDE. И нам это действительно помогает. Если когда-то в самом начале JetBrains был локомотивом для Kotlin, то теперь уже оба бренда помогают друг другу и мы видим, что все больше людей знает про JetBrains благодаря Kotlin.

Kotlin как наш собственный инструмент. У нас в JetBrains много разработчиков, и от их продуктивности сильно зависит эффективность компании. Идея начать делать Kotlin вообще родилась из того, что мы не хотели продолжать использовать Java. И сейчас Kotlin используется почти во всех наших продуктах. Например, в IntelliJ IDEA на Kotlin написано 1,5 миллиона строк кода. А недавно мы запустили Space инструмент для интегрированной работы команд, который написан на Kotlin сразу для всех платформ: Android, iOS, сервер, веб, десктоп. Ребята, которые его разрабатывают, говорят, что без Kotlin такой продукт создать было бы в разы сложнее.

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

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

Как устроен язык программирования

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

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

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

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

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

Интегрированная среда разработки (IDE). Правильно работать с синтаксисом позволяет поддержка языка в IDE, том самом Word для программистов. Что делает IDE:

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

• подсвечивает некорректный код;

• запускает код и помогает искать в нем ошибки;

• упрощает частые преобразования.

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

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

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

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

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

Подробно и глубоко компилятор Kotlin мы разбирали в отдельном выпуске подкаста Podlodka.

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

Сообщество. Программы, правила, инструменты и все такое это замечательно, но Kotlin это в первую очередь люди. За последний год почти 6 миллионов людей работали с кодом на Kotlin, из которых 1,2 миллиона делали это регулярно.

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

Влияние языка программирования на продукт и людей

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

Итак, на что влияет язык:

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

• Надежность и стабильность продукта. Отличный пример billion dollar mistake.

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

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

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

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

Откуда берутся новые пользователи

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

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

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

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

Приток новых пользователей идет из трех основных источников.

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

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

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

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

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

Для анализа мы используем известную классификацию стадий роста продукта из книги Crossing the Chasm. Ранние последователи у нас сейчас есть практически во всех сегментах разработки. Люди используют Kotlin для Data Science, пишут на нем игры, решения для IoT и даже занимаются научными вычислениями физическим моделированием процессов и подобными вещами. В сегменте кроссплатформенной мобильной разработки мы только подходим к бездне, в бэкенд-разработке перешагиваем ее, а в Android вовсю захватываем Late Majority и смотрим на Laggards.

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

Ценность инструмента для разработчиков

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

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

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

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

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

Эти базовые ценности мы используем, чтобы выстроить value proposition (ценностное предложение) для любого сегмента. Например, в нашем кроссплатформенном мобильном SDK KMM, мы делаем упор на:

• Переиспользование одной и той же бизнес-логики на двух платформах во избежание ошибок.

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

• Простое встраивание в существующие большие кодовые базы.

Кто такие менеджеры продуктов в Kotlin

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

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

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

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

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

Статья вдохновлена выпуском подкаста make sense о Kotlin с Андрем Бреславом и Егором Толстым. В подкасте make sense Юра Агеев, основатель ProductSense, вместе с гостями говорит о том, что важно при создании продуктов. Еще несколько интересных эпизодов:

о выстраивании отношений с командой разработки и важности технических навыков;

об аутсорс-разработке, работе с заказчиком и развитии бизнес-мышления;

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

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

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

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

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

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

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

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

Основные принципы и подходы:

I этап - подбор кандидатов:

1. В небольшие проекты или стартапы (зачастую в рамках личного нетворкинга) кого-то приглашаю я, а кто-то проявляет инициативу сам.

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

II этап - отбор потенциальных стажеров:

1. Тестовое задание до личной встречи, что, как можно лучше, расскажет о теоретических знаниях (hard skills).

2. Личная встреча или общение, дает четкое понимание о личных качествах (soft skills) и представление о том насколько кандидат подходит и сможет вписаться в текущие процессы, разделить и перенять дух команды.

3. Импровизация от кандидата. Интересный кейс был в Vodafone Ukraine - когда кандидаты создавали свою презентационную видео визитку и раскрывали свои личности через креатив.

III этап - развитие молодых специалистов:

1. Обучение: формирование образовательного процесса и вовлечение в него стажеров.

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

3. Доступность: готовность отвечать на вопросы, уделять достаточно времени и быть открытым к диалогу.

4. Чуткость: понимание рабочего настроения и внутреннего ощущения стажера.

IV этап - вовлечение новых коллег:

1. Равноправие: стажеры - полноправные члены команды и нет никакого разделения.

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

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

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

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

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

Одним из наиболее успешных за последнее время стал кейс в инновационном направления Vodafone Ukraine:

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

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

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

Отзыв product owner Марины:

Чувствовалась поддержка, ты давал нужные знания, инструменты для развития

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

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

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

Отзыв product owner Максима:

"Для меня стажировка принципе отложилась в памяти как супер крутое время и в том числе благодаря крутым наставникам.

Соответственно, самое позитивное:

1) готовность инвестировать время в мои знания. А с учетом постоянной нехватки времени - это супер круто

2) правильные советы и в нужное время

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

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

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

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

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

Отзыв tech lead Федора:

1. Был опыт наставничества ранее, но с меньшим пониманием процессов и чуть в другом аплуа. Ранее скорее я был в роли тимлида + разработчика, а сейчас скорее техлид + PM и немного CTO

2. Думаю тут все сложилось. И я хотел попробовать в таком формате и ты предложил. win-win

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

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

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

Отзыв fullstack backend разработчика Александра:

Кураторы адекватные, менторы толковые

Учат понятно, потенциал видят) поддержка есть)

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

Зачастую отсутствие обратной связи в режиме one-to-one создает проблему, которая может привести к негативу, разладу в работе и уходу человека из команды.

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

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

Отзыв product ownerЭда:

В компании Vodafone я менял направление работы 3 раза: стажировка стратегом, работа PM партнерских развлекательных сервисов и, наконец, junior PM продуктов с собственной разработкой (eHealth, eLearning). Собственно последний этап и был самым интересным. Каждый день драйвило то, что именно вы с командой определяете список задач в гибких условиях, а от твоих действий зависит результат всего продукта. Эта зависимость и мотивировала гуглить новую информацию или спрашивать совет старших, а информация касалась буквально всего: интернет-маркетинг, брендинг, копирайтинг, кросс-функциональная коммуникация и многого другого.

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

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

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

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

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

Их было шестеро - барабанщик, басист, клавишник, гитарист, баянист и человек с татуировками. Как-то так начинался бы фильм о нас, о музыкальной группе Sun-Techniki.

Вы, возможно, скажете ШТА?! Я точно на Хабре? Причём тут какой-то фильм о музыкальных сантехниках?

Да, это Хабр, и это рассказ про музыкальную группу, состоящую из сотрудников одной продуктовой IT-компании.

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

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

Рассказ получился объёмным, поэтому без оглавления никуда:

1. Старт проекта / Прикидываем программу выступления

2. Управление проектом / Дисциплина бьёт талант

3. Прототип / Щупаем номера

4. MVP (точнее, MAP) / Минимально допустимое выступление

5. Тестирование, багфиксинг / Гоняем программу, находим места для улучшений

6. Релиз (раскатка) / Выступление

7. Ретроспектива

8. Заключение / Почему вам тоже стоит заниматься музыкой

9. Бонусы

Вступление закончено, начинаем!

Старт проекта / Прикидываем программу выступления

Дедлайн / Дата выступления

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

Содержание проекта / Треклист

Начинаем мы с кандидатов в треклист выступления. У выступления есть стандартный общий план:

• выход (что-то пафосное, заряжающее, вызывающее аппетит)

• разогрев (может быть совмещён с выходом)

• заполнение (обычно что-то спокойное)

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

• финал, в котором должен произойти катарсис и поставлена точка

Ресурсы / Кто участвует в выступлении

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

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

Брейншторм

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

Про брейншторм на Хабре писали, например, тут: 15 способов превратить мозговой штурм в результат огонь

Брейншторм у нас не совсем классический - после вброса кандидата мы сразу обсуждаем его. Кандидат отбрасывается если:

• кто-то против. Достаточно одного голоса.

• штука очевидно нам не по зубам на текущий момент. Такой кандидат обычно идёт в бэклог - в следующий раз может быть мы будем к нему готовы.

• вещь никак не сочетается с другими кандидатами или темой (конь-цепцией). Тоже в бэклог.

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

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

Очевидно у нас означает мнение большинства. Мы отлично знаем, что нет ничего очевидного.

Как пример пункта 5 - я всегда хотел на восьмое марта (а лучше на 14 февраля) выпустить кавер на трек Pussy от Rammstein. Моё извращённое чувство юмора считает, что это постирония и очень смешно. Но как Product Manager я понимаю, что core segment аудитории этот пассаж не оценит.

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

Управление проектом / Дисциплина бьёт талант

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

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

План (Work Breakdown Structure a.k.a. Иерархическая структура работ)

Ключевые вещи в проектном управлении - это WBS (Work Breakdown Structure), майлстоуны (то есть промежуточные дедлайны), зависимости, ресурсы и управление рисками.

Про проектное управление: PMBoK за 2.5 часа: интервью с Иваном Селиховкиным

Про конкретно WBS: 4 инструмента по полочкам. Управление проектами с WBS, Диаграммой Ганта, CPM и Time-Cost или Преимущества Иерархической Структуры Работ (WBS) для менеджеров ИТ проектов

Про оценку задач: Оценка. Рассчитать и уложиться

Про управление рисками расскажу сам ниже.

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

Капитанские, но, оказывается, не всем очевидные принципы построения WBS:

• строй WBS справа налево (вот так: <--), то есть:

  • справа напиши результат - концерт готов

  • задай вопрос что мешает считать, что результат достигнут? - номера не готовы, сцена не готова

  • и так рекурсируй до элементарных задач

• после составления WBS пройди уже слева направо (-->) и на каждую задачу задай вопрос а почему я не могу эту задачу выкинуть?

• майлстоуны аналогично - справа налево (опять <--). Потому что дедлайн у нас задан заранее

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

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

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

Инструментарий

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

• тексты и прочие заметки по номерам

• документ по планам и рискам (в нём несколько секций, в том числе и оперативные - worklog, brainstorm, шорт-лист треков и подобное)

• чеклист на сам концерт, он же райдер ;)

• после концерта в каталог добавится документ по ретроспективе

Отдельно, в корне, лежит документ с общим бэклогом.

Управление рисками

Отдельно коснусь моей любимой темы - управление рисками. Почему тема любима - потому что она незаслуженно игнорируется очень многими. А ведь это просто и полезно!

Как и обещал, про риски рассказываю прямо здесь, без ссылок.

Алгоритм:

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

2. У риска оценивается вероятность срабатывания и тяжесть последствий

3. Риски сортируются по вероятности и тяжести, и в работу берётся N топов в каждой категории. N зависит от бюджета на работу над рисками

4. Риску прописываются два плана:

   1. План А - что надо сделать для уменьшения вероятности срабатывания риска

   2. План Б - что надо будет сделать для уменьшения тяжести последствий в случае срабатывания риска

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

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

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

Резервный трек отбирается так, чтобы его можно было легко и быстро подготовить. Как вариант резервного трека можно взять старый трек, который мы уже когда-то готовили. Если даже План Б провалился, то есть План Б2 - выкинуть трек вообще и выходить сокращённой программой. Ну либо затащить слабый номер харизмой ;)

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

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

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

Прототип / Щупаем номера

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

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

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

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

Это всё и выясняется на прототипировании, или, как мы это называем, на прощупывании.

MVP (точнее, MAP) / Минимально допустимое выступление

Из продуктового опыта мы знаем, что лучше всего сделать MVP (Minimum Viable Product), и потом его дободрить. Почему? Тема для отдельной статьи ;)

В нашем случае более правильно говорить не MVP, а MAP - Minimum Awesome Product. Ни нам, ни нашей публике не нужно тухлое выступление, нужно awesome выступление!

Про MVP: MVP: что это такое и как работает? (а тут разбор знаменитой картинки с самокатом: Как определить функционал MVP и влюбить клиента в пилотную версию продукта) и сорри за Medium, но на Хабре не нашёл подходящей статьи: The MVP is dead, long life to the MAP.

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

Вовлечение / Эмоциональная кривая

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

Отличаемся от других / Фишки номеров

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

Кто услышит тут отсылочку к совершенно другому произведению - пишите в комментах! И отдельное спасибо программе "Соль" за proof of concept участия баяна в этой песне.

UI, UX / Тексты

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

С IT-продуктами аналогично - нужны фишечки, нужны эмоции и нужны тексты, ибо тексты - это UX. И нужно это как можно раньше, ибо чем раньше найдена проблема, тем дешевле её исправление.

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

Тестирование, багфиксинг / Гоняем программу, находим места для улучшений

До этапа MVP ты думаешь, что всё будет классно, вы опять зажжёте, будете прекрасно восприниматься, всё хорошо и всё такое. Но когда MVP по сути готов, происходит скачок требований, и ты начинаешь докапываться до себя. Здесь не то, и тут не так. Это ужасно, с этим нельзя выходить на сцену, это позор! Тут главное не опускать руки, спокойно остановиться, осмотреться и понять, что конкретно нужно доработать.

Product Walkthrough / Прогоны, сценические образы

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

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

Как не вспомнить анекдот:

Ветеринар на на приёме у Терапевта:

Терапевт: На что жалуетесь?

Ветеринар: Не, ну так-то каждый может!

Бета / Последние штрихи, препродакшн

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

Про HADI-цикл: Кейс: как ускорить развитие проекта

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

Релиз (раскатка) / Выступление

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

Работа с аутсорсерами / Саундчек

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

О да, это всё должно быть в WBS, о котором я говорил в начале статьи.

Очень важно, нет, не так ОЧЕНЬ ВАЖНО провести нормальный саундчек. Нормальный - это значит прогнать программу несколько раз. В нашем случае программа обычно полчаса, значит, на саундчек нужно три часа. Это не считая монтажа оборудования, который может занимать часа два (иногда и больше).

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

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

Чеклисты

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

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

Про ТЗ: Стандарты и шаблоны для ТЗ на разработку ПО

Ретроспектива

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

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

Обратная связь (ищем Market Product Fit)

Нередко на аудиторию запускается анонимный опросник. Мы пробовали разные форматы - NPS, market product fit, и так далее, я полагаю, тут всё очень индивидуально. Также мы слушаем, что говорят люди, какие фотки и видео они выкладывают в инстаграм, какие видео на нашем канале набирают больше просмотров, ну в общем после релиза происходит этап валидации успеха и анализ произошедшего. Результаты этого анализа используются при подготовке следующего концерта.

Про market product fit: Market Fit или как найти точку G у стартапа

Growth hacking / Щупаем аудиторию быстро

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

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

А на самом деле мы ведь больше для себя это делаем, а не для аудитории. Просто так уж сложилось, что нам с нашей аудиторией по пути. Всем бы продуктам так, да? ;)

Заключение / Почему вам тоже стоит заниматься музыкой

Может показаться, что всё это очень скучно и очень сложно. Сложно - да, скучно - нет. Я ведь не рассказал про творческую часть, там очень много фана. Само выступление - это чистый фан, чистый адреналин/дофамин/окситоцин/whatever. Иногда ты думаешь - ну ёлки, ну зачем я опять в это ввязался, но эти шестьсот часов подготовки стоят тридцати минут выступления. И тысяча часов тоже были бы адекватной ценой.

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

Так вот, я таки понял, чтобы что.

Средство против выгорания

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

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

Как не выгорать? Это просто (картинка с Тони Роббинсом):

1. заниматься интересным ненаскучивающим делом

2. регулярно в этом деле побеждать (получать подкрепление)

3. работать с удовольствием

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

Музыка - это хороший вариант такого занятия. То есть музыка - это средство против выгорания. А у айтишников в музыке есть преимущество - мы умеем в процессы, у нас есть дисциплина.

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

Бонусы

• Как все начиналось? История становления музыкальной группы Sun-Techniki

• Наш ютуб-канал. Подписывайтесь, ставьте лайки и всё такое :) Может быть когда-нибудь встретимся на каком-нибудь музыкальном фестивале.

Привет, Хабр!

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

Держите руку на пульсе

Раньше уведомления YouTrack можно было просматривать только во внешних приложениях в почте, Jabber или Slack. В новой версии мы представляем центр уведомлений место, куда приходят все оповещения об актуальных изменениях, комментариях, упоминаниях и реакциях. Красный кружок на колокольчике подскажет, что у вас есть непрочитанные уведомления.

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

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

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

Время под контролем: теперь и в YouTrack Lite

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

Связь с внешним миром: ссылки в строковых полях

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

Поиск полного дерева подзадач

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

Этот синтаксис можно применять не только к типу связи подзадача, но и ко всем типам связи с направленностью объединение, например, к дубликатам (совокупность дубликат: ID задачи)

Иерархия групп

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

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

Дополнительные поля в профилях пользователей

Помимо учетных данных, имен и электронных адресов, в профилях пользователей теперь можно указывать дополнительную информацию например, телефонные номера или должности сотрудников. Рабочие процессы (workflows) YouTrack тоже могут оперировать этими полями. Например, вы сможете разрешить выполнение определенных действий только генеральному директору компании. Кроме того, настраиваемые атрибуты могут быть синхронизированы с AD-сервером (или любым LDAP-сервером) и доступны через REST API Hub, что открывает еще больше возможностей для автоматизации.

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

Лучше один раз увидеть, чем сто раз прочитать. Напомню, что YouTrack со всеми его новшествами можно попробовать бесплатно. Мы будем рады вашей обратной связи!

Команда YouTrack

Для будущих студентов курса "Product Manager IT-проектов" и всех интересующихся темой управления командой подготовили статью, автором которой является Сергей Колосков.

Также приглашаем всех желающих посмотреть открытый демо-урок Как продакт-менеджеру найти метрику роста и свести Unit-экономику?
За 1,5 часа на примерах реальных продуктов вы узнаете:
- почему успех продакт-менеджера это рост главной метрики продукта;
- как определить метрику роста;
- как построить аналитику и продукт вокруг метрики роста;
- научитесь расчету unit-экономики, как это делают продакт-менеджеры;
- узнаете, что может сделать продакт-менеджер для улучшения unit-экономики.

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

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

Проблема 1: Много идей и разговоров, работа движется медленно

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

Диагноз: в команде нет людей на две роли:

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

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

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

Проблема 2: Ступор при проблемах и затруднениях

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

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

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

• Исследователь не генерит идеи. Но он много читает, активно общается и приносит новые идеи из внешнего мира: новые технологии, которые хорошо бы применить.

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

Проблема 3: Бесконечные споры между конкурирующими идеями

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

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

Лечение: развести Генераторов по зонам ответственности, или переключить одного из них в альтернативную роль, если она есть.

Проблема 4: Реализация сложных идей процесс, не результат

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

Диагноз: идеи от Генератора принимаются без рефлексии.

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

Проблема 5: Паралич принятия решений

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

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

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

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

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

Проблема 6: Слишком уверенный лидер

Диагноз: у руководителя-Шейпера нет уважаемого им оппонента Координатора для обсуждения решений. Это обратная сторона Шейпера без оппонента он ведет команду к поражению, а не к победе, но при этом уверен в правильности своих действий.

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

Проблема 7: Непродуктивная команда звезд

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

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

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

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

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

Проблема 8: Некому завершать работу

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

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

Педант (Completer Finisher) доводит дело до конца. Перфекционист, для которого главное качество и детали, а сроки могут подождать. Но без него оставшиеся 20% проекта никому не интересны.

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

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

Проблема 9: Нет сотрудничества

Симптомы: поиск виновных в проблемах и неудачах, отсутствие взаимопомощи, люди указывают на несовершенства других.

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

Душа команды (Team Worker) ненавязчиво налаживает отношения в команде, сглаживает углы и не участвует явно в управлении.

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

Формирование команды с учетом знаний о проблемах

Момент 1: Пригодность и приемлемость

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

• Пригодные и приемлемые им работа скучна, это просто ступенька карьеры.

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

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

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

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

При формировании команды:

• Нужны идеи, исполнители и организаторы.

• Нужен хотя бы один (а лучше несколько) Работников компании и желателен один Педант.

• На несколько ключевых ролей (ядро команды) выбирайте профессионалов (пригодных по знаниям и навыкам) и у которых нет резких конфликтов по ролям. Они обеспечат выполнение работы.

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

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

• Командный дух не обеспечивает успеха, а конфликт между Шейперами и Генераторами не стоит решать при помощи их примирения его надо делать конструктивным.

• Однородные команды слабы и часто выбирают себе подобных.

• Обязанности следует делить с учетом профессионализма и (обязательно!) ролей участников команды.

Момент 2: Состав сбалансированной команды:

• Руководитель Координатор, умеющий работать с талантливыми, но зачастую трудными участниками;

• Один сильный Генератор;

При этом хорошим будем следующее распределение умственных способностей:

• умный Генератор;

• еще один умный не-Генератор, который ему оппонирует;

• умный Координатор;

• остальные чуть ниже среднего уровня.

Момент 3: Размер команды

Оптимальный размер команды 5-7 человек:

• Ни 5, ни 7 человек не проигрывают и не выигрывают;

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

• 4 человека могут быть успешны, если представлены все роли. Но в этом случае у команды нет резерва;

• В команде от 10 человек неизбежно появляется ядро из 2-4 человек, принимающих решения и люди без включения в него.

Момент 4: Команды-победительницы

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

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

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

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

Узнать подробнее о курсе "Product Manager IT-проектов"

Смотреть открытый демо-урок Как продакт-менеджеру найти метрику роста и свести Unit-экономику?

Два года назад Computer Science Center провел экспериментальный запуск курса по управлению продуктами, о результатах которого мы рассказывали ранее. Эксперимент удался, и в 2020-21 учебном году прошла уже полноценная годовая программа повышения квалификации с поправкой на новые идеи и вынужденный онлайн-формат. Сегодня выпускники нашей программы поделились своими историями: почему они решили развиваться в продакт-менеджменте, как совмещали учебу и работу и с какими результатами вышли с курса.

До 20 июня открыт набор на третий поток обучения по направлению Product Management с преподавателями и наставниками из ведущих мировых IT-компаний. Подробнее о школе смотрите в записи Дня открытых дверей онлайн и на нашем сайте.

До и После: зачем вы изначально подавали заявку на конкурс и что получилось в результате?

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

Я дважды пытался запустить стартап и дважды спотыкался о собственную некомпетентность. Профессия Product Manager предполагает, что ты знаешь как из пункта А привести продукт в пункт Б. Когда я увидел, что на продакта будут учить в Computer Science Center, я сразу подал заявку: все мои знакомые, которые проходили курсы в CS центре, говорили о лучшем опыте обучения в своей жизни.

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

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

Я хотел изменить карьерную траекторию это очень значимое для меня решение. Раньше я работал в сфере ядерной энергетики: занимался как инженерными задачами, так и развитием бизнеса. Понимал, что хочу качественных изменений: новых знаний и практики для старта в IT. Обучение в школе по управлению продуктами от CS центра было для меня этой возможностью. С одной стороны, что-то близкое и знакомое (менеджмент, инженерия и бизнес-анализ), с другой новая сфера инженерии (цифровые продукты).

Результат сейчас обучение завершено. Закрыв одну дверь, я открыл две новые: Business Аnalysis и Product Management. Сейчас я работаю в IT-компании и двигаюсь по треку управляющего цифровыми проектами, потому что мне нужен базовый опыт. После перейду в управление продуктами. Рассчитываю совершить карьерный маневр в течение этого года.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Атмосфера на курсе: ощущения от взаимодействия с организаторами, преподавателями и друг другом.

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

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

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

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

Что дальше: что вы будете делать с полученными знаниями, опытом и связями после выпуска?

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

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

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

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

Новые идеи для работы и жизни

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

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

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

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

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

Заявки принимаются до 20 июня на https://pmcsc.ru/ ;)

Всем мы знаем, что пользователи делятся на группы в соответствии с пользовательскими метриками и долей рынка продукта (АВСDX-сегментация). И это деление говорит нам: делайте все в продукте для A, максимум, B-сегмента - для самых платящих и лояльных клиентов. И не обращайте особого внимание на не сводящих экономику продукта жалующихся и мало платящих сегментов С и D.

Сегодня, в преддверии старта курса "Product Manager IT-проектов" совместно с Сергеем Колосковым, преподавателем Otus и автором канала Fresh Product manager мы написали пост, как найти платящий сегмент для трех разных кейсов.

Если есть метрики / аналитика по продукту

1. Анализ Частотность - Деньги - Дата последнего действия (RFM - анализ по классике): таблица из баллов по показателям Recency давность (как давно ваши клиенты что-то у вас покупали), Frequency частота (как часто они у вас покупают), Monetary деньги (общая сумма покупок). Зная эти три метрики в общем виде, находятся лидеры по сумме, они и становятся для нас выявленным платящим сегментом. Например,

R - Recency:

1. 0-30 дней: 5,100 покупателей/подписчиков

2. 31-60 дней: 12,300

3. 61-90 дней: 32,800

4. 91-180 дней: 75,000

5. 181-365 дней: 123,400

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

F - Frequency:

1. 16+ покупок/действий

2. 11-15

3. 5-11

4. 2-4

5. 0-1

M = Monetary

1. $1001+

2. $601-1000

3. $351-600

4. $201-350

5. $0-200

Таким образом, мы получим без малого 125 групп. Клиенты 5R-5F-1M могли обратиться к вашим услугам лишь разово, потратив немалую сумму, но не рассчитывая на долговременное сотрудничество. А вот 5R-3F-1M с большей вероятностью стали недовольны услугами компании или потеряли к ней интерес. 1R-1F-1M сливки вашего клиентского списка. Если вы верно избрали пределы групп R, F и M, то этот сегмент должен быть крайне мал не более 5% адресной базы. Что бы вы ни делали, вам уже вряд ли удастся испортить отношения с такими клиентами.

2. Проблемно-решенческие интервью (как часть CustDev) с целью выявления общих паттернов и характеристик среди платящих (от 8 проблемных интервью на предполагаемый сегмент с проверкой гипотез) - проводим проблемно-решенческое интервью с целью выявления связи между гипотезой и сегментом. Сегмент может оказаться не один, необработанные сегменты можно взять из полного или упрощенного (по нескольким показателям) RFM - анализа. Идеально, когда CustDev дополняет RFM - анализ и наоборот. О том, как правильно проводить кастдевы, какие вопросы и как задавать в обзоре от канала Fresh Product manager.

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

Если нет метрик и аналитики по продукту

1. Упрощенный RFM-анализ (по выручке, по среднему чеку) - собирается из того, что можно собрать из бек-энда продукта или опросов по возможным показателям. Иногда их достаточно для выявления сегментов. То есть, самая простая выгрузка из базы и логов.

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

3. CustDev с целью выявления инсайтов для построения аналитики. И, конечно, проведение проблемно-решенческих интервью, в которых будут результаты упрощенного RFM - анализа или опросов. Цель все та же - нужно выявить посредством открытых вопросов схожие паттерны поведения и объединяющие факторы. В тему - отличный блог Синди Альварес, автора книги Продукт, который купят и канал с моими заметками про CustDev

Если нет продукта и аналитики

1. CustDev с целью формирования сегментов и проверки гипотез (От 40 проблемных интервью). Когда нет никаких зацепок и аналитики, собираются гипотезы как для продуктов, так и для сегментов - активных пользователей продуктов. Гипотезы самые смелые, проверка самая приключенческая.

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

3. Проверка поисковых запросов в Яндексе/Google (Wordstat и прочие) как мониторинг монетизации и необходимости продукта по семантике, проверка наличия целевой аудитории посредством проверки пула запросов в поисковиках. Важно копать именно узкие целевые запросы. Например репетиторы по математике покажет популярность для сегментов ОГЭ/9 класс, городов и пересечение с другими предметами.

На этом всё. Приглашаем вас посетить бесплатный демо-урок по теме: CJM (customer journey map): от гипотез до продуктового сценария

Читать ещё:

• No-code: продакты против больших трат денег

Привет, Хабр. Для будущих студентов курса "Product Manager IT-проектов" и всех интересующихся подготовили авторскую статью. Также приглашаем записаться на открытый вебинар по теме "CustDev для самой быстрой проверки идеи".

Что такое проблемные интервью?

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

Чтобы провести беседу, нужен сценарий

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

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

• Случалось ли вам ?

• Попадали ли вы в ситуацию ?

• Как часто с вами происходит ?

• Когда вы последний раз оказывались в ситуации ?

• Вас беспокоит ?

• Как на вашу жизнь влияет ?

Примеры развернутых вопросов:

• Можете вспомнить случай, когда вы оказывались в ситуации ?

• Расскажите подробнее, как было в последний раз?

• Можете рассказать, как вы тогда поступили?

• Расскажите подробнее, как вы решали эту проблему?

• Вы всегда так поступаете?

• В других похожих случаях как вы поступали?

• Как вы решаете эту проблему сейчас?

• Какие трудности у вас вызывает это решение?

• Что вас не устраивает в нынешнем решении?

• Почему вы поступили именно так?

• Какие еще варианты вы рассматривали?

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

• Что происходило, когда вы не решали эту проблему?

• К каким трудностям это приводило?

• К каким расходам это приводило?

• Что вы теряли в той ситуации?

• Сколько времени или денег вы тратили на решение этой проблемы?

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

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

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

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

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

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

Основы основ

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

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

• Это не количественный тест, а качественный. Не нужно нанимать много людей и создавать репрезентативную картину. Главное понять могут ли люди справиться с заданием и устраивает ли продуктовую команду, как это происходит (мучительно или не очень). Достаточно заказать 3-4 теста, чтобы гарантированно получить один содержательный или обратить внимание на несколько эпизодов из разных тестов.

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

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

Про поиск дополнительных источников выручки и точек роста

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

Создание экосистемы для удержания клиента

Все мировые лидеры, будь то Facebook или Apple, уже давно идут в сторону экосистем, замыкая клиентов внутри себя. У нас это направление успешно развивают Яндекс и Сбер. Когда в рамках одной системы и одного id можно и заказать еду, и вызвать такси, и кино посмотреть, клиенту намного сложнее соскочить с продуктов компании. За счет таких расширенных предложений наращивается дополнительное конкурентное преимущество. Делать ставку только на одну услугу сегодня слишком рискованно.

Повышение маржинальности бизнеса

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

Как работать с командами и искать гипотезы роста

Работая с внутренними продуктами в компаниях, мы обычно полагаемся на возможный потенциал продукта в течение определенного периода времени. Например, можно ли за 3-5 лет получить доход в миллиард рублей? Чтобы найти и развить гипотезы роста с потенциалом дохода в сотни миллионов рублей, нужно пройти несколько важных этапов.Собирайте отзывы от потенциальных клиентов. Чтобы отойти от рыночных требований, а не от возможностей компании, необходимо выявить наличие ценности в продукте. Можно взять интервью у клиентов, проанализировать отзывы, рассчитать коэффициент НПС (отношение положительных оценок к негативам). Проанализируйте продажи. Если процесс продаж уже запущен, вам необходимо собрать данные, проанализировать воронку продаж и ключевые показатели продукта. Затем ответить на вопрос-что может быть рычагом в процессе продажи, как их увеличить? Множественный рост происходит в моменты продвижения с партнерами, он собрал воронку между каналами и запустил нового пользователя на борту.декомпозиции в интернете. Разработка стратегии на рынок. Это включает в себя позиционирование, ценообразование, каналы продаж, определение соответствия продукта ожиданиям целевой аудитории, продвижение по службе, корректировку от конкурентов. Внутри компаний, безусловно, есть свои особенности. Во многих случаях серьезным конкурентным преимуществом внутренних продуктов было бы наличие материнской компании, которая уже имеет знания о клиентах, облегчая аудиторию, сегментацию и таргетинг.

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

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

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

Узнать подробнее о курсе "Product Manager IT-проектов".

Записаться на открытый вебинар по теме "CustDev для самой быстрой проверки идеи".

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

Кстати, о "красивой упаковке" онлайн-сертификатов мырассказываем в этой статье.

ЗАБРАТЬ СКИДКУ

Есть ли разница между созданием продукта для потребителя и для бизнеса? Очевидно, что есть, хотя продуктовый менеджмент в 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. Спасибо Дмитрию Ковалю за помощь в подготовке статьи.

Эта статья основана на нашем опыте внедрения 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, такие как: валидацию и качество данных, экспорт данных и т.д.

Также опубликовано в отдельном блоге автора.

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

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

Регистрация по номеру телефона

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

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

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

Планирование эксперимента

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

Довольно часто в компаниях есть "обычный" уровень значимости, который выбирают просто потому, что так принято, - допустим, 95%. Однако не подойдёт ли в данном случае уровень значимости 90% или даже 80%? Ведь не хотелось бы отказаться от полезного улучшения, только потому что мы, мол, не абсолютно уверены в улучшении - на все сто ведь никогда нельзя быть уверенным.

Что результаты значат на самом деле

Допустим, мы выбрали 90%-тную значимость, опасаясь, что при большей тест может провалиться, а меньшую вроде бы никто вокруг нас не применяет. Запустили тест, он работал ровно пять полных недель (полных - чтобы сгладить возможное отличие поведения пользователей в будни и на выходных), каждый вариант увидело примерно 10000 человек, тест завершился успешно, калькулятор сообщил что-то вроде "p-value is 0.07, You can be 90% confident that this result is a consequence of the changes you made". Что же на самом деле это означает?

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

Если телефонные регистрации ничуть не лучше, в некоторых тестах они всё равно будут случайно выигрывать.

P-value AB-теста как раз и показывает, насколько редкое событие мы наблюдаем, если бы предложение вводить номер телефона на самом деле (на длительном периоде времени) ничего не улучшало, а возможно даже и ухудшало.

Представьте себе, что в такой печальной ситуации мы провели бы не один, а сотню одинаковых AB-тестов: каждый по те же пять недель, каждый по 10000 посетителей на вариант. В большинстве таких ста тестов телефонный вариант принесёт меньше регистраций, чем email-вариант или столько же, как и email-вариант. Однако в части тестов телефонный вариант может принести немного больше регистраций.

Наблюдаемое p-value 0.07 как раз и означает, что если телефонный вариант на самом деле ничуть не лучше email'ового, то оказаться впереди email'ового столь сильно или ещё сильнее, чем мы наблюдаем, он смог бы в семи тестах из ста.

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

Стоимость ошибочного выигрыша

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

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

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

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

Эту табличку можно найти в Google Sheets и скопировать себе.

Выбор уровня статистической значимости

Откуда же до начала эксперимента подставлять в такую таблицу ожидаемую пользу от справедливо выигравшего теста (5% в нашем примере) и возможный вред в случае ошибки (50% в нашем примере)? Лучше всего, конечно, опираться на историю подобных изменений. Если это далеко не первый эксперимент с улучшением воронки регистраций, и большинство из предыдущих увеличивало конверсию на пару процентов, то вряд ли даже очень значительная идея улучшит сильнее, чем на 5-10%.

Если истории подобных внедрений нет или она незначительна, то я не знаю метода лучше, чем экспертные оценки и страхи. Всё же вряд ли аж половина потенциальных пользователей не регистрируется, потому что не хотят / не могут вводить email, а телефон с радостью ввели бы. В лучшем случае миграция на номер телефона подтянет долю регистрирующихся с 7.7% может быть до 8% (улучшение на 5%). А вот если мы ошибаемся и пользователи на самом деле вообще не хотят доверять нам номер телефона, то можно/страшно потерять и половину регистраций.

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

Не уверены - проверяем строже

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

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

Небольшое улучшение, повторённое много раз, - большое улучшение

Дополнительные пара процента пользователей в год - не очень много, если только у вас уже не миллионы пользователей. Однако два десятка подобных скромных экспериментов проведённых один за другим уже принесут почти 50% дополнительных пользователей (20 повторений 2.25% улучшения из нашего примера принесут 56%: 1.0225^20 1.56 ).

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

Можно наблюдать и после принятия решений

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

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

Проверяйте идеи, имеющие смысл

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

Если вы занимаетесь сервисом не первый год и знаете, что им пользуются для заказа рабочих инструментов, то вряд ли даже очень неудобная регистрация оттолкнёт больше нескольких процентов пользователей - инструменты ведь заказывать таки надо. Соответственно в прикидочной таблице страх потери можно ограничить, скажем, в 20% и внезапно окажется, что нам достаточно уровня значимости в 85% или даже в 80%, что радикально сократит затраты времени требуемого для эксперимента.

Если вы знаете, что по результатам прошлых лет даже самые радикальные изменения не улучшают/ухудшают ситуацию больше, чем на несколько процентов (например, новые пользователи приходят в основном по сильной социальной рекомендации), то и в оценочную таблицу можно вписывать подобные цифры. Например, возможную пользу оценим в 2%, а возможный вред - в 5%. В результате снова окажется, что достаточно и 80% уровня значимости и эксперимент можно провести очень быстро.

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

Некоторые изменения имеет смысл проводить, даже если мы не можем подтвердить положительный эффект

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

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

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

  • Впрочем, именно математика у всех хороших калькуляторов практически одинакова: корректно посчитают и такой, и такой (платный), и такой калькуляторы - просто помните, как правильно интерпретировать результаты

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

  • "Эксперименты с возможной потерей клиентов тестируем с уровнем значимости 95%"

  • "Просто обычные небольшие улучшения тестируем с уровнем значимости 90%"

  • "Мелочи, вроде текстов и цветов в местах не касающихся оплаты товара, тестируем c 80%-тной значимостью и если калькулятор рекомендует длину эксперимента больше недели, то пропускаем тестирование совсем"

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

Благодарности

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

А как вы интерпретируете результаты AB-теста?

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