Притчи продуктолога

2022-01-06 12:12:01 44. Самый большой баг в твоем продукте

В продуктовый менеджмент я пришел из дизайна и UX. Я всегда очень гордился своей дотошностью и вниманием к мелочам. Старался, чтобы мои продукты были удобными и красивыми, все баги исправлены, а пользователи счастливы. Когда находил ошибку или просто не элегантное решение в продуктах Гугла или Яндекса, сочинял мысленные послания их HR-ам: «Вы катитесь в пропасть, не видите очевидные косяки, но я могу вас спасти, я – гениальный дизайнер, возьмите меня на работу и все у вас наладится».

При запуске своего первого по-настоящему взрослого продукта я бескомпромиссно боролся за качество. Задерживал релизы, чтобы исправить все баги. И тогда мой босс сказал фразу, которую я помню спустя 15 лет: «Самый большой баг – это если о нашем продукте никто не узнает». Эта простая фраза очень зацепила меня и помогла измениться. Спустя годы я узнал про Agile, MVP и принцип «ошибиться скорее». Но фраза про самый большой баг в продукте до сих пор кажется мне самой точной.

#старыйпост Открыть/Комментировать

2022-01-04 12:12:01 41. Умение говорить с людьми на их языке

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

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

#старыйпост Открыть/Комментировать

2021-12-30 17:59:28 Ну, что, теперь как в Слаке можно ставить реакции на посты. Если кто не может (по тапу на Андроиде и удерживанию на Айфоне), значит надо обновить приложение. В старом приложении вы даже реакции других не увидите.

Ставьте свою реакцию на это сообщение для теста.

P.S. В отличии от Слака к посту ты можешь поставить только одну реакцию. Если выберешь другую, первая удалится. Открыть/Комментировать

2021-12-30 14:19:22 198. Впадают ли ойтишнеги в спячку?

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

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

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

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

Ойтишнег – друг человека. Берегите ойтишнегов! Открыть/Комментировать

2021-12-28 19:00:13 197. Я знаю, что ничего не знаю

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

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

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

Именно в умении «ошибиться быстро» и есть главное преимущество опытного продуктолога.

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

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

2021-12-21 19:24:24 196. Сколько стоит мой час?

Дочка подошла и спросила: «Тётя Маша просит смонтировать видео для Инсты, готова заплатить, сколько денег взять?» Мне задают подобные вопросы довольно часто. Не только молодежь, но и профессионалы с многолетним опытом. Получает человек зарплату, а тут решил поработать в консалтинге или на парт тайм, и оказалось, что не знает, сколько стоит час его работы.

Я предлагаю простой алгоритм:

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

2. Раздели на 21 рабочий день и на 8 рабочих часов. Получишь 595 руб/час.

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

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

Еще надо бы налоги учесть, а то в США их осознанно платят, а у нас только работодатели знают про это. Для самозанятых это 5%, для ИП это 9% (ставка 6%, но есть и другие выплаты), для договора подряда с ООО – 13%. Ну в общем, усредненно, еще на 1.1 умножайте, чтобы учесть налоги.

У нас получилось: 595*1.6*1.1 = 1000 руб/час. Кстати, вот простая формула для быстрых подсчетов: часовая ставка = 1% от месячной зарплаты. Открыть/Комментировать

2021-12-17 13:47:16 Нужен UX/UI в игровой проект на частичную занятость

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

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

Подробности о проекте и вакансии можно прочитать в тексте постоянной позиции:
https://almanac.io/docs/ux-ui-XdIrW4oOK3uHvwRceH0r3UuKC657AtjK
Для парт тайма требования могут быть пониже.

Если вы хотите на парт тайм — пишите мне в телегу @aleksritov Открыть/Комментировать

2021-12-16 12:11:16 29. Зачем вам нужен технический бэклог

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

1) ПОЛЬЗА. Задачи должны быть объединены в эпики, у каждого эпика – внятное полезное действие. Плохой эпик: «Отрефакторить сборку проекта». Хороший: «Ускорить сборку с 5 минут до 20 секунд». Плохой: «Переписать JS». Хороший: «Ускорить время разработки нового отчета с 2 недель до 1 дня».

2) ОЦЕНКА. Каждая задача по отдельности и состоящие из них эпики технического бэклога должны быть оценены в тех же единицах, что и ваш продуктовый бэклог. Store points, S/M/L, идеальные часы – не важно, главное оценить.

3) РЕГУЛЯРНОСТЬ. Работа над техническим бэклогом должна быть регулярной активностью в календаре. Наша команда собирается на полуторачасовой технический груминг раз в две недели.

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

#старыйпост Открыть/Комментировать

2021-12-16 12:10:58 28. Технический долг – «что делать»

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

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

1. Правильно оценить объем долга. Это самое сложное. Как сделать, расскажу в следующей притче.

2. Утвердить график выплаты долга. Выплаты должны быть регулярными и равномерными.

3. Если «платеж» просрочен, организовать серьезный разговор. Как это делают банки.

4. Если «платеж» просрочен несколько раз подряд – вызывать коллекторов. В нашем случае – вводить внешнее управление командой разработки.

Помните, любой долг берется легко, а отдается сложно.

#старыйпост Открыть/Комментировать

2021-12-14 12:12:01 24. Умение нанимать людей на работу – базовый навык

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

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

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

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

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

5. Умейте «продать» свой продукт кандидатам. Хорошие специалисты нужны везде, у них часто по несколько офферов на руках. Продавая свой продукт, не врите и не приукрашивайте. Вам нужен коллега на годы, а не на пару месяцев.

Сохраняйте терпение и оптимизм.

#старыйпост Открыть/Комментировать