🖥 Защита от дурака

(Картинка взята из паблика Адовый UX)

Иногда наблюдаю, как менеджеры и инженеры старательно продумывают «защиту от дурака»: всевозможные проверки в системе, чтобы пользователь физически не мог совершить неправильное действие.

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

Вот вы сделали форму, в которую можно ввести дату рождения. Фронтендеры обмазались валидаторами, бекендеры на сервере на всякий случай тоже проверяют, что дата корректная. А пользователь, родившийся 11 октября, банально перепутал число и месяц, потому что недавно вернулся из длительной командировки в США. Или вам для проверки зоны доставки нужно чётко проверять адрес пользователя, поэтому вы подключили словарик с разрешёнными адресами, чтобы наверняка. Вот только внезапно в городе почему-то появилась улица с таким же названием (ну ошиблись, ну бывает), и пользователь смог выбрать адрес, который, по сути, вы обслужить не можете.

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

🔷В примере с формой я бы рядом с инпутом даты рождения ещё текстом написал «11 октября», привлёк бы внимание. А если пользователь всё же ошибся, то спокойно дал бы ему отредактировать это поле в любой удобный ему момент, а не требовал бы с паспортом прийти в ближайшее отделение моего сервиса.

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

⁉️Кстати, кого правильнее назвать дураком, если, пользуясь вашим тщательно продуманным интерфейсом, пользователи постоянно совершают в нём ошибки?

➡️ Energy Management на замену Time Management

Ещё когда был студентом, меня окунуло в хайп вокруг тайм-менеджмента. Нужно всё успевать! И управлять календарём. И с утра есть лягушку, а слона поедать по частям. И ещё помнить, что 15-минутная встреча на 100 человек на самом деле стоит даже больше 25 часов времени. И так далее.

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

Например. У вас есть команда из 5 человек. И проект, который нужно запустить через месяц. Вы берёте производительность труда одного человека в день, умножаете на 20, потом ещё на 5 — вот столько задач может успеть сделать команда. Верно же?

1️⃣ А если у вас на самом деле в этой команде у всех давно не было отпуска? А если в мире рядом происходит очередной звездос? А если на улице небо серое и не отрендеренное? А если задачи в проекте безумно скучные, но надо? А, ну и если на недавнем ревью что-то никому особо зарплату не подняли, потому что кризис?

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

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

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

✉️ Массовые рассылки и Новый год

За что я люблю новогодние праздники, так за то, что почти все сервисы в этот момент решают меня с ними поздравить. И в этот момент я такой: «Ага! Попались!»

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

А вот в Новый год маркетологи не могут сдержаться. Нужно и итоги года разослать, чтобы быть «не как все», и скидку предложить праздничную, и просто поздравить, чтобы напомнить о своём существовании. И ведь рабочий приём же. Уверен, MAU в декабре чуточку растёт у тех, кто такие рассылки делает.

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

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

😿 Свобода воли, эксперимент Либета и барабаны

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

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

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

🔷Само же движение происходило ещё на 200 миллисекунд позже.

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

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

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

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

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

P.S. Не является медицинской рекомендацией, перед применением проконсультируйтесь со здравым смыслом. Автор поста просто делится мыслями и не несёт ответственности за ваши нейроны.

🔷 Подход «не навреди» при выкатке новой фичи

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

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

🔷Например, был сервис, который замечательно работал в Беларуси, но когда делали переезд на какого-то нового провайдера для оплаты, аккаунты беларусам тупо сломали. А после шквала обращений в поддержку всё-таки через пару месяцев дочинили и для беларусов. Уверен, что какие-то KPI в процессе сильно поднялись, или риски какие-то убрали, раз катнули с таким плохим тестированием.
🔷Или было замечательное с точки зрения доступности веб-приложение. Но при очередном редизайне в рамках ребрендинга доступность убили напрочь. Видимо, даже не подумали про тестирование a11y перед выкаткой. Или, что ещё хуже, «мы сейчас раскатим на тех, кто деньги приносит, а незрячие нам денег почти не приносят, их мало, ничего страшного, что мы их потеряем».
🔷Или какой-то банк начал по ночам проводить регулярные технические работы, из-за чего интернет-банкинг перестаёт работать в принципе, при этом никаких оповещений или графика работ нигде нету. «Ну разве кому-то ночью нужен интернет-банкинг?»

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

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

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

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

«Не навреди» — повесьте где-нибудь перед глазами стикер, пригодится.

📘 Скорочтение как навык менеджера

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

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

Скорочтение — это не только про быстрое потребление текста, но и про навыки осознанной обработки этого текста. Читать по диагонали можно эффективно. За полёт в самолёте можно не просто прочитать треть бизнес-книги, но и законспектировать важное и полезное. Но это навык, который нужно развивать.

🔷Начать советую с книги Павла Палагина «Скорочтение на практике». Она с упражнениями.
🔷Потом закрепить техники из книги. Не просто «Угу, прочитал, что дальше?», а пару месяцев читать осознанно.
🔷Заведите себе время для чтения. У меня это время перед сном (стараюсь каждый день) и время в самолёте (а летаю в командировки я довольно часто).
🔷Храните книги рядом. У меня на всех устройствах есть как Яндекс.Книги (у яндексоидов есть бесплатный Яндекс.Плюс, почему бы им не пользоваться), так и просто приложение «Книги» от Apple. Читать могу начать хоть в такси, хоть в очереди в ЖЭС.
🔷Составьте список книг на ближайшее прочтение. Чтобы не выбирать долго и мучительно новую, а просто брать по списку.
🔷Не нравится книга — бросайте. Жизнь слишком коротка, чтобы заставлять себя читать через силу.
🔷Несколько книг в параллели — нормально. Я сейчас одновременно по 4 книгам двигаюсь. Но стараюсь не смешивать художественные книги во времени, с ними сложнее параллелить.

Мне такой подход позволяет читать около 30 книг в год, несчётное число материалов по работе и хобби в неделю. И переносить это всё во «второй мозг», чтобы не потерялось. Невероятно полезный навык для менеджера, имхо.

📒 Тире и дефисы

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

Несколько раз мне прилетало: «А зачем? Разве пользователь не поймёт, что в этом контексте чёрточка — это тире, а в другом — дефис?»

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

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

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

А ещё, блин, это ж чинится на раз-два. Погуглите «Типограф». Прикрутите в код автоматизацию про типографику. Дайте на ваш текст посмотреть GPT, в конце концов.

https://www.artlebedev.ru/typograf/ — забирайте в закладки.

📝 «Агрегатные состояния» пользователей

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

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

🔷Первые 15 минут набрасываем разные антонимичные состояния в виде карточек куда-нибудь в Miro или где вы там проводите похожие встречи. Например, «уставший — бодрый», «днём — ночью», «одинокий — семейный» и так далее. Полная свобода фантазии. Важно: заведите отдельное место для мемов, потому что они будут появляться на доске и даже помогать зарождаться новым мыслям, но визуально отвлекают.

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

🔷В каждом кластере выбираем по 1–2 «агрегатному состоянию», которые вокруг себя организовали самые крупные группы. Не просто так же ваша команда массово обратила внимание именно на такие состояния. Это кандидаты на обсуждение прямо здесь и сейчас.

🔷Ещё 15–20 минут к каждому выделенному состоянию придумываем эмоции и действия пользователей в этом состоянии. Например, из забавного на борде: «Был зол багом в системе, хлопнул ладонью по столу, теперь болит ладонь, не могу пользоваться мышкой». Или: «Неопытный пользователь, научился читать по-гречески, пока читал формулы рейтинга в вашем FAQ».

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

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

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

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

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

⁉️ Что делать, если хочется сменить команду

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

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

https://events.yandex.ru/events/ya-love-frontend-2025

Реестр ошибок

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

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

У меня это называется «Реестр ошибок» — прям вот так формально, чтобы не слишком привязываться эмоционально. Это простой список в Notion, с карточками. Каждая карточка — это конкретный кейс, где я в чём-то ошибся. И у неё есть такие поля:
🟠Дата — чтобы видеть динамику и связывать события во времени.
🟠Заголовок — короткое описание ситуации и ошибки, «обезьянопонятное» по Дорофееву.
🟠Описание — тело карточки, всякие подробности, рефлексия с табличками и картинками, если надо.
🟠Категория — селектор, чтобы можно было работать со схожими ситуациями отдельно.
🟠Состояние — мультиселектор, про моё состояние во время принятия решения (эмоциональное, физическое), чтобы видеть зависимости.
🟠Обработана — чекбокс, проработал я эту ошибку уже или нет.
🟠Что дальше — список действий, которые надо совершить, чтобы подобный род ошибок не повторялся.

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

Как с этим списком работать?
🔷Когда я где-то ошибаюсь, то сразу завожу новую карточку. Заполняю теми данными, которые прямо сейчас есть под рукой, пока память свежа. И откладываю на неделю.
🔷Через неделю уже без лишних эмоций дозаполняю карточку, рефлексирую, заполняю «Что дальше». Эдакое ретро, только с самим собой.
🔷Раз в месяц делаю ревью всех карточек, чтобы взять в фокус какую-нибудь свою «слабость» на проработку.

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

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

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

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

➡️ Везение, кубики и карьера

[Изображение для поста взято на Unsplash]

В последнее время часто слышу: «Как же тебе повезло!», причём по разным поводам. Купил хорошую квартиру — «Классно, повезло найти», получил карьерное повышение — «Повезло, молодец!», читаю много книг — «Повезло, есть свободное время».

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

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

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

Приведу пример на игральных кубиках. Мы с друзьями раньше много играли в Dungeons & Dragons — настольно-ролевую игру, в которой вы вместе в каком-то мире выполняете квесты, прокачиваетесь, отыгрываете своих персонажей. И одной из главных механик в D&D являются кубики: D20 на 20 граней, D8 — на 8, D4 — вы поняли, и так далее. Когда мой персонаж должен совершить важное действие в игре, мастер игры скорее всего предложит мне кинуть кубик D20, а по результатам броска мы поймём, получилось у меня это действие или нет. Получается, что кубики, то есть рандом, влияют почти на всё в игре, верно?

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

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

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

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

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

🟣Влияние «джедайских техник» на личную жизнь

Если вы ещё не знаете про Максима Дорофеева и его «Джедайские техники», то категорически рекомендую найти книгу и почитать — классно структурирует мысли и прививает хорошие практики.

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

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

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

🔷Держать список задач в актуальном состоянии. Тут грешноват, не всегда в списке держу только нужное. Но стремлюсь к этому.

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

🔷Отключать нотификации во время работы над сложными вещами. Согласен, постоянно практикую. Телефон откладываю далеко, а на ноутбуке в принципе почти всегда нотификации выключены. Будет срочное и важное — ну так я в команде не один.

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

https://club.mnogosdelal.ru/post/3111/

Ежегодное исследование продуктового сообщества от ProductSense

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

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

🔷CPO и Head of Product в большинстве своём в айтишечке больше 10 лет. Есть два CPO, которые в IT от 1 до 2 лет, интересная карьера.

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

🔷Больше всего опрошенных — из бигтеха. Ожидаемо, их же в принципе больше, не просто так бигтех — биг тех.

🔷Удивительное для меня: развитием навыка «продажи и переговоры» занимались в 2024 году активно всего 4% респондентов. Зато аналитикой — 15%. Окей, аналитика очень важна для data driven подхода, полезный навык. Но я что-то как продакт очень много времени провожу именно на переговорах: со стейкхолдерами, потенциальными крупными пользователями, смежниками. И если бы навык переговоров у меня не был до этого чуточку прокачан, было бы сильно тяжелее.

🔷Забавно, что основным мотиватором сменить работу являются деньги (40% опрошенных), а затем карьера (29%), а при выборе работы изначально на первом месте был сам продукт и задачи (50%), и только потом деньги (43%). То есть такая грустненькая, но честная картина: люди сначала хотели хорошие задачи, а теперь хотят денег.

🔷Самые привлекательные компании для продактов: Яндекс, Авито, Т-Банк. Причём у Яндекса немаленький такой отрыв в некоторых категориях. А у всей тройки большой отрыв от всех остальных.

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

Естественно, в отчёте есть ещё очень много интересного, так что если ещё не читали, советую выделить минут на 20 на изучение.

https://productsense.io/research24

💻 Обучение через блогерство

У меня иногда спрашивают и я сам спрашиваю у других авторов телеграм-каналов: «Зачем ты ведёшь канал?». Что мне отвечают:

🔷Чтобы монетизировать. Есть опыт, про него готовы читать, можно собрать аудиторию в 1к подписчиков и больше, уже после этого к тебе придут предлагать разместить рекламу. Чем больше подписчиков, тем дороже реклама. Такой вот дополнительный доход, пока есть, о чём писать.

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

🔷Кибершаромыжничество (спасибо за термин Андрею Мелихову). Блог как способ конвертировать аудиторию в покупателей какого-то продукта. В таких блогах обычно видно повышенную активность перед очередным сезоном продаж, к слову.

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

🔷Делиться знаниями. Есть потребность делиться опытом или новостями, но нет желания монетизировать. Своего рода альтруизм.

Забавно, что никто из тех, с кем обсуждал эту тему, не ответил «Учиться». Не говорю, что таких нет, просто не пересеклись в беседе. Хотя это как раз мой случай. Очень хорошо эту идею сформулировал Максим Дорофеев в докладе на CodeFest про самообучение. Доклад не совсем про это, но такая мысль прозвучала несколько раз: чтобы чему-то научиться, нужно это попробовать на практике, а не просто открыть материал. Сначала открываешь ссылку, потому пропускаешь контент через себя (на это уже нужно потратить мозговые усилия), потом пробуешь это применить (тут прям много усилий надо), а потом делаешь вывод, работает оно или нет.

Я для себя как-то давно выбрал две основные причины «Зачем»: учить и учиться. Монетизировать пока не хочу, реклама из всех щелей бесит. Личный бренд я скорее через подкаст и доклады на конференциях прокачиваю. Продавать свои курсы мне не надо. А вот то, что есть не так много телеграм-каналов, которые делятся новостями фронтенда, когда-то побудило меня начать писать в @mefody_dev. Когда-то основным источником таких новостей были «Веб-стандарты», в которых я в том числе был редактором, но там формат короткий и почти без мнения редактора, а у себя в личном блоге можно писать что угодно. Сейчас каналов стало больше, но всё равно потребность у аудитории в таком контенте всё ещё есть.

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

К слову, недавно дал слабину, не проверил реальное поведение кода из старой статьи в одном блоге, в котором обычно всё по делу и верно, запостил «враньё» — тут же пришли подписчики в личку и подсказали, что я не прав. Исправил. Тоже полезно оказалось: буду проверять даже авторитетные блоги внимательнее, заодно узнал новое для себя.

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

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

🟣 «Просто не мешай команде работать»

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

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

🔷Дизайнер собирает макеты. И велик соблазн сразу сказать ему, как делать. Чуть ли не нарисовать за него, чтобы он просто раскрасил красиво и по гайдлайнам. Но вообще-то дизайн — это не просто кнопки красить. Это про смыслы, удобство, консистентность. И какая бы ни была у меня насмотренность, какое бы ни было сильное мнение — пока дизайнер не спросит его, терпеть. «Просто не мешай команде работать».

🔷Разработка реализует макеты. Грумим, убеждаемся, что все участники процесса понимают задачу одинаково, доуточняем тикеты. Разработка забирает задачу на декомпозицию, начинает обсуждать, как это нужно делать технически. А у меня ж опыт, 16 лет в профессии, я ещё на таблицах верстал и БД в phpMyAdmin настраивал! И так хочется советами поделиться! Терпеть. Перестал ходить на декомпозицию в принципе. А если моё мнение надо будет — спросят. Что приятно: и правда иногда спрашивают. «Просто не мешай команде работать».

🔷QA тестирует фичу. Последний рубеж перед выкаткой релиза. И снова хочется обратить внимание, что вот тут можно вот так сломать, а тут вот это надо проверить. А ещё в DevTools есть вот такая вкладка, она поможет проверить вот такой кейс… Терпеть. Надо обратить внимание — допиши в тикет, уточни требования ещё до взятия задачи в работу. Спросят — уточнишь. «Просто не мешай команде работать».

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

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

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

📝 Магия личного общения

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

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

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

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

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

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

Для меня работает смешанный формат, когда можно и из дома, и из офиса, и в командировку сгонять.
🔷Весь день во встречах — я из дома, чтобы не искать судорожно переговорки.
🔷Более-менее свободный календарь — можно из офиса поработать, периодически устраивая интересные беседы на кофепоинте.
🔷Нужно много всего порешать — командировка и личные встречи, закрыться в переговорке и сфокусироваться коллективным разумом. А потом неформально попить пива вечером, чтобы не только про работу.

P.S. Это ж как нас интернет и ковид поломали, что начинаешь чувствовать магию личного общения. Лет 200 назад альтернатив-то особо и не было ☺️

😻 «Давайте уже после майских»

Сколько раз вы эту фразу слышали слышали за прошлую неделю? Я вот её слушаю с середины апреля.

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

🔷«Всё равно на майских никто не работает». Wrong (подставьте противный звук)!
Ну вот у меня конкретно следующая неделя очень даже рабочая. Более того, из-за отсутствия встреч с отдыхающими коллегами это будет ещё и супер-продуктивная неделя. Как я уже писал в предыдущих постах, у меня распределённая команда, которая аж в 4 странах трудится. И у всех абсолютно разный набор выходных в течение года. Чтобы не продалбываться из-за когнитивного искажения «у меня выходные — у всех выходные», собрал себе фильтр во внутреннем сервисе Gap, где смотрю, когда кто в команде отдыхает. Там удобно дни в табличке из квадратиков закрашиваются в разные цвета в зависимости от типа отсутствия. Вы себе можете хоть в экселе такое собрать, хоть навайбкодить.

🔷«Вернёмся с выходных — быстро соберу задачи для команды». Wrong! Во-первых, даже если вы с командой по одному графику живёте, всё-таки сразу после майских команде уже надо будет чем-то заняться. Вариант «пусть достанут что-нибудь из беклога» — ну такое. Правильнее подготовить список задач ещё до майских и спокойно отдыхать. Во-вторых, после выходных внезапно вас завалит текучкой, а организм в рабочий режим не перешёл ещё. Так что снова есть смысл подготовиться до, а не после.

🔷«Да что там за выходные случится!». Wrong! Камон, это ж дни, когда куча народу сидит в интернетах активнее, чем в другие дни. Выходной, скучно, на шашлыки не позвали — пойду открою забытые вкладки в браузере. Если ваш сервис про внерабочую активность, вероятность роста трафика высокая. Значит, и упасть можно внезапно. Не забудьте назначить дежурство и ответственных за работоспособность сервисов, лишним не будет. А если сами будете вне зоны доступа, то подыщите себе подстраховывающего и команде про это расскажите.

🔷«Запустим эксперимент уже после майских». Wrong! Меня когда-то хорошие продакты научили, что если уж и майнить данные для А/Б, то ровно в такие большие выходные. Вы отдыхаете, а данные собираются. Вернулись — вот вам уже и сигналы для принятия решений готовые, катить на всех или не катить. Постарайтесь запустить до больших выходных, сэкономите кучу времени себе.

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

🔷«Там выходных много, чего-нибудь поделаю по работе от скуки». Wrong! Лучше потупите в сериальчик или книжку почитайте, если хочется мозг нагрузить. А ещё лучше разгрузите его природой или какой-нибудь дачной активностью. Работать в выходные — это звоночек, что у вас процессы где-то сломались. Вот закончатся эти самые выходные — идите чините эти процессы, а не затыкайте дырку «героизмом». Это, кстати, я самому себе пункт пишу, а то меня команда ловит иногда на антипримерах.

TL;DR
- Подготовьтесь к выходу из больших выходных до выходных.
- В выходные интернет работает.
- Отдыхайте!

😣 Бессмысленная автоматизация

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

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

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

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

Допустим, вы делаете какой-то лендинг, где собираете контакты будущих пользователей крутого продукта, который вот-вот выйдет на рынок. Где-то у вас безопасно хранятся емэйлы и ФИО, например. И вот в день выхода продукта вам надо будет сделать массовую рассылку на собранные емэйлы с красивым анонсом.

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

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

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

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

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

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

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

Пойду руками всякое поделаю, что ли. 😻

🍬 Продавцы конфет и интерфейсы

В одной из игр «Что? Где? Когда?» в 2012 году знатокам задали следующий вопрос:

Психолог Кавет Роберт в своей книге «Успех в общении с людьми» рассказывает такую историю: рядом с одной школой находились два магазинчика, в которых торговали сладостями. Сладости были одни и те же, цены — одинаковые, продавцы — любезными. Почему дети охотно брали сладости в одном магазинчике, а в другой ходить не любили?

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

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

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

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

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

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