Архив недели @igrekde
Понедельник
Всем привет!
Меня зовут Егор, я – продакт языка программирования Kotlin в @JetBrains и ведущий подкаста @PodlodkaPodcast.
Самый важный совет, который я дам за эту неделю – подписывайтесь на мой личный твиттер @igrekde, там безумно хорошо и премиальный контент.
На этой неделе буду рассказывать про проведение интервью, Scrum, участие в митапах и делиться ссылками на телеграм каналы
хаха нет конечно
[Пн] Язык программирования как продукт
[Вт] Роль продакта в Kotlin
[Ср] Developer Experience – что это и как с ним работать
[Чт] Как продакту стать чуть менее бесполезным технически
[Пт] Как подсидеть продакта
[Сб] Анализ рынка разработчиков
[Вс] Тут много кандидатов, решу потом!
Ну и накидывайте ваших вопросов, буду отвечать либо сразу, либо включать в другие треды
Для начала, давайте разберемся, насколько вы вообще знакомы с языками программирования
Для разогрева давайте определимся, что такое язык программирования с точки зрения продакта. Я сейчас придерживаюсь такого определения:
«Это система строительных блоков и инструментов, которые помогают разработчикам выражать свои намерения в машиночитаемом формате»
Для людей не из IT я обычно объясняю это так:
Представьте себе Word. Вот мы делаем так, чтобы в похожих на Word редакторах можно было описывать свои идеи таким образом, чтобы из этого потом получалось приложение для мобилок или десктопа.
Зачем вообще JetBrains вкладывает деньги в создание своего языка:
- Повышение узнаваемости бренда компании среди разработчиков
- Использование для разработки своих продуктов
- Потенциальная монетизация через доп тулинг
- Потому что делать свой язык – чертовски круто!
Почему вообще появляются новые языки программирования? Да все просто. Разработчики – большой (20.5 млн) постоянно растущий (+8.5% в год) рынок, у которого много болей как с решением существующих задач, так и с появлением принципиально новых.
Эти боли берутся из-за того, что многие языки – general-purpose решения, которые не очень круто отрабатывают в конкретных узких кейсах. Посмотрите на то, как JavaScript пытается зайти в сегмент мобильной разработки, например.
Другая проблема – большой груз ответственности и накопленное легаси. Из-за этого многим языкам сложно развиваться эволюционно, и они не успевают за изменением потребностей аудитории. Вот так и появляется окно возможностей вроде того, что было для Kotlin на Android.
Вот как устроен Kotlin с продуктовой точки зрения. В треде детально рассказываю про все сценарии и компоненты.
Начнем с самого основного сценария – «реализовывать свои идеи», по-простому – «писать код». Это та задача, которая стоит перед языком в первую очередь – он должен предоставлять классный опыт по трансляции своих мыслей в конструкции, понимаемые твоей платформой.
Синтаксис языка – это набор правил, по которым пишется программа. За набор этих правил отвечают дизайнеры языка. Код в первую очередь пишется для людей, которые его читают и редактируют, поэтому основная задача дизайнеров – сделать язык выразительным.
Правильно работать с этим синтаксисом позволяет поддержка языка в IDE, том самом "Word для программистов", который:
- подсказывает тебе подходящие по смыслу конструкции
- подсвечивает некорректный код
- запускает код и помогает искать там ошибки
- упрощает частые преобразования
Помимо этих базовых операций, IDE – целый комбайн разных фич, которые упрощают конкретные пользовательские сценарии. Например, работа с системой контроля версий, отладка микросервисов, простое управление инфраструктурой. Задача Kotlin – качественно встраиваться в эти сценарии.
По сути, IDE – это инструмент, который позволяет тебе получать обратную связь о своих действиях с кодом. Все основное взаимодействие с IDE можно представить в виде вложенных фидбэк-лупов. Чем глубже, тем важнее хороший перфоманс и тем критичнее разрывы контекста разработчика.
@produnderhood Проблемы с легаси языком - это С++. Там действительно нельзя прикрутить что-то новое, потому что надо поддерживать старое.
Да, отличный пример! Кому интересно – можете послушать выпуск Подлодки, где в частности про это разговаривали.
podlodka.io/136 twitter.com/noraltavir/sta…
Следующий компонент – интероп. Для Kotlin это возможность интегрироваться в экосистемы других языков. Например, вызывать Kotlin из Java, и вызывать Java из Kotlin.
Это важный компонент языка, потому что:
- у разработчика появляется возможность переиспользовать готовые компоненты других экосистем и не писать их самому
- можно встраивать Kotlin в свой проект постепенно, не переписывая все с нуля
Последний большой кусок сценария, связанного с написанием кода – библиотеки. Задача разработчика – найти качественные строительные блоки, поверх которых он напишет бизнес-логику и получит готовый продукт. Чем слабее развита библиотечная экосистема, тем обычно тяжелее разработчику
Внутри команды мы разрабатываем только самые базовые библиотеки, которые, по сути, являются частью самого языка. Например, stdlib, корутины, сериализация. Все остальное мы отдаем на реализацию сообществу, и работаем над тем, чтобы авторам библиотек было удобно.
Весь сценарий "Реализовывать свои идеи" заключается именно в написании и чтении кода. Следующее, что с чем сталкивается разработчик – потребность этот код собрать для того, чтобы его можно было распространять и запускать на конкретной платформе.
Компилятор – это специальная программа, которая переводит код на Kotlin в машиночитаемый формат. Kotlin умеет компилировать код сразу для трех окружений – JVM, JS и Native. Это значит, что технически Kotlin можно исполнять практически на любой платформе, которую вы знаете.
Помимо просто перевода, компилятор делает еще много всяких полезных вещей – проверяет код на ошибки, оптимизирует его объем. Дико советую выпуск подкаста с одним из разработчиков нашего компилятора, где разобрали все детали.
podlodka.io/167
Пользователь взаимодействует с компилятором чаще всего опосредованно через IDE или билд-систему. Основная точка касания – это ошибки, которые компилятор выдает в случае некорректного кода. Тут важно сразу подсказать, а что разработчику делать с ними дальше.
Сборка итогового приложения – это многоступенчатый процесс, где компиляция – только один из шагов. Нужно собрать все проекты, связанные с текущим, прогнать дополнительные задачи (например, тесты и статический анализатор). В этом и помогают билд-системы – Gradle и Maven.
На Gradle, в частности, лежит и другая важная задача – оптимизировать процесс сборки приложения путем кеширования промежуточных результатов. А это очень круто – потому что процесс сборки может занимать минуты, если не десятки для крупных проектов.
Продакту важно понимать, какие сценарии использования билд-систем чаще всего есть у пользователей, какие этапы занимают больше всего времени, что работает стабильно, а что – нет. Это помогает в приоритизации.
Мне не хватает образования, чтобы разобраться в gradle.
Но Gradle – это слишком сложно, поэтому надо двигаться дальше. Вот вам пруф:
twitter.com/_bravit/status…
Следующий сценарий – "изучение своего ремесла". Высокоуровнево мы декомпозируем его вот так:
- онбординг
- поиск решения конкретной прикладной задачи
- изучение способов работы с продуктом
Основные инструменты для онбординга – сайт kotlinlang.org, интерактивный плейграунд play.kotl.in, и конкретные гайды и hands-on'ы на сайте. Задача онбординга – помочь новому пользователю быстро получить первый результат и завлечь его в дальнейшую разработку.
Важный компонент, который появляется на этом сценарии – документация. Мы стараемся держать ее максимально полной, потому что она – первое место, куда пользователь идет, чтобы с чем-то разобраться (не считая Stack Overflow, конечно).
Основные принципы нашей документации:
- Helpful
- Easy to find
- Clear and concise
- Always up-to-date
- Consistent with the whole ecosystem
Помимо нашей команды техписов, в этот сценарий активно контрибьютит сообщество, разрабатывая собственные курсы и туториалы. Кстати, один из рейтингов языков программирования, PyPL, оценивает популярность языка как раз по количеству доступных туториалов.
pypl.github.io
Рядом с этим сценарием стоит "Получать помощь". Когда разработчик сталкивается с проблемой, он может найти помощь на четырех уровнях:
- в самом продукте
- в документации
- в сообществе
- в команде технического саппорта
Например, какая-то конструкция не собирается компилятором. Первое, куда смотрит разработчик – на ошибки в консоли в IDE. Тут мы можем его поймать, хорошо объяснить проблему и подсказать дальнейшие шаги. Если понятнее ничего не стало, он ныряет в документацию или Stack Overflow.
Кстати, про то, как разработчики используют SO, есть очень классная бумага. Советую почитать.
ieeexplore.ieee.org/stamp/stamp.js…
Если нагуглить решение проблемы не получилось, разработчик может пойти за помощью в сообщество – либо в какой-то локальный чат, либо в публичный Slack, и задать свой вопрос там. И вот если люди в сообществе не смогли подсказать ему правильный ответ, в дело вступает наш саппорт.
Задача ребят – помочь пользователю найти какой-то воркэраунд, занести информацию о проблеме в багтрекер и в случае критичности донести информацию до команды разработки или продактов. Вот и сам багтрекер: youtrack.jetbrains.com/issues/KT
Тред получился длиннее, чем я хотел – поэтому быстро посмотрим на последний сценарий, "Самореализовываться". Многие разработчики хотят делать что-то помимо перекладывания json'ов или покраски кнопок, поэтому они ищут возможности в экосистеме своего любимого инструмента.
Стандартные способы такие:
- Помочь другим пользователям советами в том же Slack
- Пошарить свои знания, выступив с докладом, или написав статью
- Поделиться своими наработками в опенсорсе, опубликовав библиотеку или какой-то инструмент
Подобью итоги треда. Kotlin состоит из кучи компонентов, разрабатываемых как внутри команды, так сообществом.
Для того, чтобы обеспечить крутой опыт определенному сегменту разработчиков, нужно не просто дать им компилятор, но и проработать все остальные сценарии.
Про что интереснее послушать сегодня?
Мини-тред про то, как мы подходим к сегментации пользователей.
Базовая сегментация основана на разделении по области решаемых задач. Например, сегменты могут выглядеть вот так:
- Android
- Server-side
- Frontend
- Gamedev
- Data science
Пользователи в этих сегментах очень сильно ожидаются по своим болям и ожиданиям от инструментов. В каждом из сегментов есть своя экосистема, в которую мы каким-то образом интегрируемся.
Эти сегменты возможно выделить в продуктовой аналитике и смотреть на их поведение отдельно друг от друга. Делать это помогают специальные эвристики, учитывающие используемую IDE, таргеты в билд-файле и еще ряд параметров.
Что интересно – они не взаимоисключающие. Один пользователь может легко попадать сразу в несколько сегментов, если он пишет приложение в Android Studio, а бэкенд для него – в IDEA.
Как мы используем такую сегментацию:
- Для определения стратегических целей всей команды
- Для классификации пользовательских запросов и болей
- Для того, чтобы лучше понимать, что происходит в аналитике и строить гипотезы
- Для планирования в конкретных командах
Иногда нам требуется другой подход. Например, в Kotlin Multiplatform Mobile мы сегментируем аудиторию по типу разрабатываемых приложений:
- Rich clients (много бизнес-логики)
- Thin clients (мало бизнес-логики, много UI)
Это помогло выделить пользователей, жизнь которых мы можем сделать намного лучше (команды разработки, которые делают приложения с большим количествлм бизнес-логики) – и сфокусироваться на их болях.
Минус такой гранулярности – в аналитике уже эти сегменты так просто не выделишь.
Из других подходов, которые периодически используем:
- По уровню: новичок/мидл/пауэр юзер
- По типу компании: продукт, фриланс, аутсорс
- По степени участия в коммьюнити: автор библиотек, автор статей и прочее
- По стране
Одна из причин, по которым JetBrains делает Kotlin – это продуктивность при разработке других своих инструментов. Поэтому отдельным сегментом мы выделяем наших внутренних пользователей и используем его при приоритизации бэклогов команд.
Вторник
Кстати, я курирую этот самый коллективный аккаунт. Ближайшие слоты – через пару месяцев, так что пишите мне в телеграм, если готовы поучаствовать!
telegra.ph/Pamyatka-dlya-…
Сегодня расскажу, чем занимаются продакты в Kotlin. Для начала – простая табличка ожиданий от роли.
Главная задача продакта – лучше всех знать свой сегмент пользователей, их боли и сценарии. Эту информацию он синтезирует, чтобы:
- строить видение своей части продукта и ставить цели
- приоритизировать важное и ценное
- планомерно двигаться к целям
- рассказывать об этом команде
Информацию эту продакт обычно получает из:
- самостоятельной работы с продуктом (да-да, мы стараемся сами регулярно писать код)
- интервью с разработчиками
- продуктовой аналитики (поведенческая + использование фичей)
- чтения статей и просмотр докладов
- анализа обратной связи
Больной вопрос про глубину технического погружения. От продакта не ожидается быть экспертом в разработке – в команде вокруг и без того достаточно крутейших инженеров. Но, например, хорошо бы уметь самому пользоваться дебаггером, чтобы понимать, какой UX норм, а какой не очень.
Общее правило – продакт не должен быть бесполезной прослойкой между пользователем и командой. Он не просто проксирует услышанную информацию о проблемах, а должен быть способен самостоятельно проанализировать ее и сделать выводы про критичность и влияние на пользовательский опыт.
Каждую неделю все продакты определяют 3-4 своих основных фокуса на неделю и вписывают их в общий файл. Это помогает нам поддерживать прозрачность того, кто чем занимается, находить точки пересечения и держать фокус на важном.
Рабочие недели продактов сильно различаются в зависимости от контекста их направления – кто-то плотно работает с конкретной командой разработки по спринтам, кто-то – больше занимается исследованиями рынка, кто-то фокусируется на подготовке контента и прокачке онбординга.
Значимая часть работы продакта – проведение рисерчей. Вот примеры из бэклога:
- Simplify YouTrack issue creation process
- Find out the detailed user scenarios for using Kotlin in CLI
- Research IoT/embedded market
- Make stdlib help more intuituve
- Prepare Gradle CJM
Сейчас в команде 6 продакт-менеджеров и 1 аналитик:
- PM1 – Kotlin Multiplatform Mobile
- PM2 – Kotlin for Server-side
- PM3 – Kotlin/JS, Website, Analytics
- PM4 – Kotlin for Android
- PM5 – Kotlin IDE Plugin
- я – тимлид, опыт внутренних пользователей и разнорабочий
Бэкграунд у всех очень разный. Вот несколько профилей:
- Биоинформатика и тестирование
- Java, продуктовый менеджмент и девадвокатство
- Продуктовый менеджмент
Мораль такая – опыт разработчика для роли продакта хоть и желателен, но необязателен.
Кстати, мы сейчас активно нанимаем еще одного продакт-менеджера – kotlin-product.tilda.ws. Если вам интересно делать крутые штуки, пишите мне в телегу, пообщаемся!
@produnderhood А это вольный пересказ реального дока или у вас и правда всё на русском языке?
В продуктовой команде сейчас только русскоязычные люди, поэтому внутренние доки пишем на русском языке. Все, что предназначено для прочтения другими командами – на английском. twitter.com/_beargummy/sta…
Если у вас есть еще какие-то вопросы про роль – задавайте, а я потихоньку двинуть к следующему треду!
В мае 2019 года я поступил в бизнес-школу Сколково на MBA. Рассказываю о том, зачем это образование может понадобиться айтишнику, о механике поступления, полученном профите, процессе обучения и разных инсайтах. etolstoy.com/mba
Тред про это здесь писать не буду, но на вопросы тоже поотвечать готов! twitter.com/igrekde/status…
А теперь пора поговорить про то, как принимается решение, что нужно делать в продукте и что выпускать в следующем релизе.
Сейчас мы активно перерабатываем процесс целеполагания. Есть стратегические фокусные зоны – что надо делать, почему это важно, как оценим успех. Эти зоны определяют, куда должна быть направлена большая часть усилий всех команд.
Пример – "Improve JVM server-side adoption", целевая метрика – активные пользователи серверсайда.
Все команды работают, опираясь на эти фокусные зоны. Чтобы было понятнее, расскажу пару конкретных примеров того, как продакты в конкретных командах формируют свой бэклог и планы.
Начнем с @a_kapanina. Первая картинка – схема болей пользователей, связанных с Kotlin Multiplatform Mobile. Вторая картинка – разложенные по CJM боли и делайтеры, приоритизированные командой.
Источники знаний о болях:
- Интервью
- Багтрекер и обратная связь
- Опыт команды
Работа продакта выглядит так:
Собрать контекст – что у пользователей болит и почему это важно
Выделить ключевые боли и делайтеры
Разложить их по пользовательскому пути
Приоритизировать их вместе с командой
Нагенерить гипотезы решений
Вуаля, бэклог готов!
Второй пример – команда, которая занимается Kotlin плагином для IDEA. Помимо тех же самых источников, что и в прошлом примере, они активно занимаются сегментом наших внутренних пользователей – тех, кто разрабатывает IDEA, YouTrack, Space и другие продукты.
Вот как выглядел процесс:
Провести серию интервью внутренних пользователей и собрать актуальную картину их проблем
Обогатить знания о болях через аналитику
Приоритизировать с учетом актуальности для внешних пользователей и сложности
Проверить о внутренний CAB
Пример про обогащение знаний. Пользователи жалуются на то, что ряд рефакторингов работает нестабильно в Java/Kotlin проектах. Вопрос – как определить приоритеты.
Помочь в этом помогает:
- Аналитика частотности использования фичей IDEA
- Опрос внутренних пользователей
Короче говоря, в разных командах механизмы анализа и приоритизации работают по-разному. Отдельное время закладывается на поддержку существующих пользователей, разбор pull request'ов от сообщества, 20% проекты членов команды.
Четверг
Цель сегодняшнего треда – дать вам представление о том, как разработчики взаимодействуют со своими инструментами и чего от них ждут.
Основной материал для треда – собственные наблюдения и выдержки чужих исследований.
Речь пойдет про Developer Experience, сокращенно DX. Вообще, это модное название для UX, которое мы иногда используем, чтобы чувствовать себя особенным.
Есть исследования, которые доказывают, что DX положительно влияет на общий перфоманс команды при работе над проектом. Поэтому думать о нем важно для бизнеса.
researchgate.net/publication/25…
Два года назад Forrester провел для JetBrains исследование, насколько использование IDEA повышает продуктивность команды. Мопед не мой, но авторы топят за бешеный ROI в 850%. Почитать точно интересно.
resources.jetbrains.com/storage/produc…
Как измерить DX? Напрямую – никак. Работая в Авито, я пытался это сделать разными NPS, CSAT и прочими довольно бесполезными для такой задачи метриками – и ничего не получил. К DX проще относиться, как к чисто качественной истории, которая влияет на лояльность и retention.
Я встречал несколько моделей, описывающих DX. Например, в виде пирамиды Маслоу:
- Functionality
- Usability
- Pleasure
Functionality. Продукт закрывает все задачи разработчика. На этом уровне важно знать все сценарии разработчика.
Usability. Существующую функциональность использовать просто и удобно.
Pleasure. Взаимодействие с продуктом приносит набор сильных положительных эмоций.
Центром опыта разработчика чаще всего является IDE – среда, в которой он проводит большую часть своего времени. Он использует ее чтобы читать код, писать, дебажить и выполнять разные другие операции.
Ультимативная задача IDE – удерживать разработчика в состоянии потока. Это достигается за счет его удержания в циклах обратной связи, из которых ничто его не выдергивает и не отвлекает – перфоманс, креши, отсутствие видимого фидбэка, сложный доступ к каким-то частым операциям.
Опять же, сошлюсь на клевую бумагу, авторы которой исследовали влияние UX в IDE на состояние потока и мотивацию разработчика.
researchgate.net/publication/30…
В другой бумаге, которая больше недоступна для скачивания, я встречал набор правил, основанных на "Дизайне привычных вещей" Нормана. Они описывают составляющие крутого DX в IDE.
Consistency. Визуальный стиль, возможный набор действий, получаемый фидбэк должны быть консистентны.
Customization. Каждый пользователь должен иметь возможность настроить IDE под себя.
Visibility. На каждом этапе нужно предоставлять релевантную информацию о том, что происходит.
Affordance. Структура и лейауты должны не вызывать WTF.
Feedback. Система обратной связи должна показывать разработчикам подтверждения всех их действий.
Constraints. Там, где возможно сломать что-то из-за неправильного ввода или действий пользователя, нужны ограничения.
Recognition of error. Вид ошибки и ее текст должны быть вменяемыми и понятными человеку.
Help. Система помощи должна быть полной и доступной.
Сейчас мы измеряем DX так:
- Пользовательские интервью, где просим рассказать о тех случаях, когда хотелось материться на тулинг
- UX-сессии, где глазками смотришь, как разработчик пытается понять твой интерфейс
- Лайв-кодинг или скринкасты с комментариями всего, что происходит
Если вам интересно побольше покопать в DX, то поделюсь ссылками на бумаги и статьи, часть из которых я сам еще не разобрал.
"Programmer eXperience: A Systematic Literature Review" – researchgate.net/publication/33…
"Assessing DX of a GUI Designer" – researchgate.net/publication/30…
"Improving the success rate of applying the extract method refactoring" – sciencedirect.com/science/articl…
"Factors That Influence DX in Mobile Software Ecosystems" – researchgate.net/publication/31…
"Developer Testing in the IDE: Patterns, Beliefs, and Behavior" – gousios.gr/pub/developer-…
"How Friendly Integrated Development Environments Are?" – researchgate.net/publication/33…
"Developers Deserve Security Warnings, Too" – saschafahl.de/static/paper/d…
"Comparing the Usability of Cryptographic APIs" – ieeexplore.ieee.org/document/79585…
"Design framework enhancing developer experience in collaborative coding environment" – researchgate.net/publication/31…
"Developer Experience Matters" – girliemac.com/blog/2016/08/1…
"Detecting API Usage Obstacles: A Study of iOS and Android Developer Questions" – plg.uwaterloo.ca/~migod/papers/…
"You Get Where You’re Looking for: The Impact of Information Sources on Code Security" – ieeexplore.ieee.org/document/75465…
"The Impact of Developer Experience in Using Java Cryptography" – arxiv.org/pdf/1908.01489…
"Patterns of Developer Experience" – softwareas.com/patterns-of-de…
Закончу тред ссылкой на одну из ключевых практик, которые помогают поддерживать классный DX в продуктах JetBrains – догфудинг. Если ты не используешь свой продукт каждый день и не ощущаешь пользовательские боли – никакие другие практики не помогут.
youtube.com/watch?v=afZnpM…
Пятница
Пятница, ретроспективы и демо уже прошли, а планирование нового спринта еще далеко за горизонтом. Самое время для того, чтобы составить план того, как подсидеть продакта в своей команде!
По совету за каждый ретвит, погнали!
Известен факт, что продакт – это не настоящая профессия, а просто модное название для разнорабочего в IT. Каждый продакт в глубине души чувствует себя уязвимым из-за этого, так что давите на больное!
Посчитайте, сколько стоит рабочий день вашей команды, и начните вести на вайтборде статистику – сколько прибыли принес ваш продакт, и какой бюджет бездарно прожег. Повесьте доску на видном месте – пусть это будет первое, что он видит утром, и последнее, что видит вечером!
Продакты не разбираются в технологиях и обучаются новым терминам по принципу нейронных сетей. Начните употреблять на дэйликах названия несуществующих технологий. Продакт моментально подхватит их и начнет использовать в своей речи, чтобы казаться своим парнем!
Когда он в следующий раз с горящими глазами придет рассказывать вам про No-Code, ответьте, что в режиме No-Product вы уже давно живете, давайте хотя бы код оставим.
Каждый раз, когда он спрашивает тебя "Что бы ты хотел?", кидайтесь в него книгой "Спроси маму". Она довольно тонкая, так что можно сразу связкой из трех штук.
Постоянно кидать в него разными вещами, к слову, вообще нормальный и надежный способ подсидеть.
Продакт – не часть команды. Никогда не давайте ему этого забывать. Если он пытается подсесть к вам в столовой, все дружно встаньте и молча перейдите за другой стол.
Подарите ему круглые очки, черную водолазку и джинсы. Когда он в таким виде придет на демо и начнет что-то рассказывать, пошутите, что до айпода его новой фиче далековато еще.
Не стесняйтесь тратить хотя бы 80% времени команды на действительно важные задачи – например, распилить монолит, или склеить микросервисы обратно. Если продакт скажет что-то против – упрекните его в технической безграмотности и напомните еще раз, что он не Стив Джобс.
Если он хотя бы раз использует фразу "Если бы Генри Форд слушал людей, то дал бы им более быструю лошадь", напомните, что он не только не Стив Джобс, но и не Генри Форд. А вместо быстрой лошади у него пока что максимум мертвый бобер.
Навсегда запомните, что PM расшифровывается как проджект менеджер и никак иначе. Используйте это знание во всех коммуникациях с командой, пусть бесится.
Расклейте написанные продактом PRD с техническими деталями по стенам офиса и громко смейтесь, проходя мимо. Пусть думает, что в очередной раз спалил свою техническую безграмотность, и судорожно ищет свой прокол.
Пройдите Go Practice Simulator. Как известно, это автоматом делает вас продактом – а кто последний прошел, тот и сильнее.
Постоянно скидывайте продакту конкретные жалобы пользователей и упрекайте, что он их не решает. А как только одну из них он возьмет в работу, пилите за то, что он идет на поводу у громкого меньшинства.
Суббота
Давайте выберем, про что поговорить на выходных. Ну или накиньте свои темы в комментарии!
Воскресенье
Рынок разработчиков – очень клевый. Он довольно большой (20.5 млн), растет (+8.5% в год), со вменяемым уровнем конкуренции, высокой платежеспособностью, понятными маркетинговыми каналами.
Давайте разберемся, откуда брать данные по рынку и инсайты, чтобы запустить свой проект!
Начнем с самых крупных и надежных источников. Stack Overflow Survey. 65.000 ответов, хорошая разбивка по географии и направлениям разработки. А главное – можно получить сырые данные и спокойно их изучать самому.
insights.stackoverflow.com/survey/2020
Вот еще одни крутые ребята, Slash Data. Они специализируются на изучении рынка разработчиков и периодически выкладывают разные полезные репорты. Ключевой – Global developer population report, откуда как раз та цифра про 20.5 млн и взята.
slashdata-website-cms.s3.amazonaws.com/sample_reports…
В основном отчеты платные, но посмотрите, какая мякотка – за такие можно и занести!
А недавно они выкатили свой сервис, который позволяет поиграться со всеми данными, на основе которых строятся эти отчеты. Сейчас проверил – там уже 15 датасетов доступно, так что можете начинать проверять свои гипотезы с минимальным порогом вхождения.
dashboard.slashdata.co
Еще один крупный ежегодный опрос проводят мои коллеги из JetBrains. Фокус в опросе делается на те технологии, для которых мы делаем тулинг. Сырые данные тоже лежат в открытом доступе.
jetbrains.com/lp/devecosyste…
Последний в этом списке – GitHub Octoverse. Тут аккуратнее, потому что выводы, сделанные на основе опенсорс проектов, могут быть нерепрезентативны для всей популяции.
octoverse.github.com
Конечно, есть еще дорогущие отчеты всяких гартнеров, форрестеров и их друзей – но я более чем уверен, что в большинстве случаев вам вполне хватит открытых данных.
Если же вам нужно копнуть в какой-то сегмент поглубже, стоит поискать более узкоспециализированные отчеты.
Например, вот такие:
JS: stateofjs.com
Kotlin: jetbrains.com/research/kotli…
Microservices: tsh.io/state-of-micro…
Testing: practitest.com/resource/state…
А можно парочку интересных и/или неожиданных инсайтов попросить? Чтобы не окунаться в сырые данные :) twitter.com/produnderhood/…
Почти по всем ссылкам помимо сырых данных есть и инфографика, чтобы по верхам пройтись. twitter.com/andirnotes/sta…
Отдельная история – индексы языков программирования, который в разных срезах показывают, какие языки сейчас «популярны». Вот только на них надо смотреть очень критично, потому что замеряют они иногда очень странные штуки.
TIOBE. Считает популярность по количеству результатов запроса «<language> programming» в 25 различных поисковиках. Методология с первого взгляда звучит вполне ок, но на практике результаты довольно бесполезны – Visual Basic на 8 месте говорит за себя.
tiobe.com/tiobe-index/
RedMonk. Мой любимый из всех. Смотрит сразу на две проекции – количество проектов на GitHub и вопросов на Stack Overflow. Основная критика крутится вокруг того, что Stack Overflow – не для всех языков основная площадка, а GitHub не повторяет всю индустрию.
redmonk.com
PYPL. Смотрит на то, как часто люди гуглят туториалы по конкретному языку. Критика состоит в том, что метрика сильно отстает по времени от реальности. Ну и сильно biased в сторону преподаваемых в универах языков.
pypl.github.io/PYPL.html
IEEE. Агрегируют больше всего данных, позволяют поиграться с изменением значимости разных факторов. Наименее субъективные из всей подборки.
spectrum.ieee.org/static/interac…
Помимо рейтингов и отчетов можно самим закопаться в API различных ресурсов. Вот с чем периодически сталкиваюсь я:
- Google Trends
- GitHub
- Stack Overflow
- Twitter
- Статистика загрузок в пакетных менеджерах
С последними есть полезный лайфхак. Если API не торчит наружу, а официальная статистика скудная, напишите мейнтейнерам реестра и попросите пошарить вам более подробные данные. Мне помогало!
Тут отдельно спрашивали, что делать, если хочется узнать о нетехнических особенностях разработчиков как ЦА. Ответ простой – пилите опросы сами, выкупайте места в Telegram-каналах или на других площадках, наслаждайтесь результатами.
Наличие огромного количества профессиональных сообществ – одна из особенностей рынка разработчиков, которые сильно упрощают работу продакта, например, в моменты поиска кандидатов для интервью.
Одна из кайфовых практик – завести фейковый аккаунт и под ним забрасывать в чат сообщества волнующие вас вопросы. Это позволяет избежать искажений в обратной связи из-за привязки к тому, кто конкретно вопрос задает.
Ну а что касается качественных данных, тут все совсем просто. Серчите нужные теги в Twitter, Reddit, Medium, ходите по релевантным митапам и задаете глупые вопросы, слушаете подкасты про индустрию.
На этом, кажется, все – накидывайте ваши вопросы 🙂
Мета-тред со всеми темами, про которые я писал на этой неделе. Лайки, шеры, вот это все!
Для разогрева давайте определимся, что такое язык программирования с точки зрения продакта. Я сейчас придерживаюсь такого определения: «Это система строительных блоков и инструментов, которые помогают разработчикам выражать свои намерения в машиночитаемом формате»
Вводный тред – что такое язык программирования и зачем JetBrains было делать свой.
twitter.com/produnderhood/…
Вот как устроен Kotlin с продуктовой точки зрения. В треде детально рассказываю про все сценарии и компоненты. https://t.co/7DC6hkJlaC
Язык программирования как продукт
twitter.com/produnderhood/…
Мини-тред про то, как мы подходим к сегментации пользователей.
Сегментация пользователей Kotlin
twitter.com/produnderhood/…
Сегодня расскажу, чем занимаются продакты в Kotlin. Для начала – простая табличка ожиданий от роли. https://t.co/dXSX52De1E
Зачем нужны продакты в Kotlin и чем они занимаются
twitter.com/produnderhood/…
А теперь пора поговорить про то, как принимается решение, что нужно делать в продукте и что выпускать в следующем релизе. https://t.co/MRqS6oIitD
Как наполняется бэклог и принимаются решения о том, что выпускать в релизе
twitter.com/produnderhood/…
Цель сегодняшнего треда – дать вам представление о том, как разработчики взаимодействуют со своими инструментами и чего от них ждут. Основной материал для треда – собственные наблюдения и выдержки чужих исследований.
Про Developer Experience
twitter.com/produnderhood/…
Пятница, ретроспективы и демо уже прошли, а планирование нового спринта еще далеко за горизонтом. Самое время для того, чтобы составить план того, как подсидеть продакта в своей команде! По совету за каждый ретвит, погнали! https://t.co/DxuCInLyHO
Как подсидеть продакта
twitter.com/produnderhood/…
Рынок разработчиков – очень клевый. Он довольно большой (20.5 млн), растет (+8.5% в год), со вменяемым уровнем конкуренции, высокой платежеспособностью, понятными маркетинговыми каналами. Давайте разберемся, откуда брать данные по рынку и инсайты, чтобы запустить свой проект!
Как анализировать рынок разработчиков
twitter.com/produnderhood/…
Мы продолжаем нанимать продакт-менеджеров. Главное, что ищем:
- Продуктовый опыт и наличие большого количества кейсов за плечами
- Любознательность в отношении технологий и готовность в них погрузиться
- Хороший английский
Все детали на супер лендосе kotlin-product.tilda.ws
Если то, о чем я рассказывал в течение недели, показалось вам интересным – присылайте свое резюме мне в Telegram (etolstoy), я буду рад обсудить ваш опыт. А если вакансия не для вас – то покажите ее своим друзьям!
А самое главное – не теряйтесь после этой недели. С вас подписка на другие соцсеточки, где я часто пишу что-то интересное.
За шуточками и шитпостом: twitter.com/igrekde
За полезными заметками: t.me/tolstoylive
За годными лонгридами: etolstoy.com
