😽 Давайте знакомиться!

Меня зовут Никита, и я руководитель продуктов Контеста в HR Tech Яндекса, доброжелюбный бородач в подкасте «Веб-стандарты» и автор канала про фронтенд @mefody_dev.

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

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

Здесь буду писать про то интересное, что происходит у меня на работе, делиться рандомными мыслями, скидывать ссылки на прочитанное — в общем, хаотичный поток сознания от человека, который пытается разобраться, что такое «быть продактом» и как эффективно руководить классными командами.

👀 Неудачи — это полезный опыт

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

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

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

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

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

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

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

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

📒 SCAMPER как способ придумать что-то новое

У меня часто бывает, что нужно что-то придумать. Вот есть фича, которую уже все сделали. Но если её банально скопировать у конкурентов, то пользователи скажут: «Ой, вы это у NNN скопировали». А совсем переделывать и не надо, потому что не просто так же её все сделали.

Когда-то прочитал про интересную методику креативности SCAMPER. Перед тем, как начать решать задачу, можно сделать следующее:

🔷S — Substitute. Заменить что-то. Был вот такой материал, станет другой. Делали задачу эти люди, начнут другие. (поддержкой занималась внешняя команда — нанять внутреннюю)
🔷C — Combine. Комбинировать. Соединять с другой функциональностью. Неожиданно использовать одновременно несколько функций. (была вилка, была ложка — вилка-ложка)
🔷A — Adapt. Добавить что-то. Новые элементы, новые функции. (снежинки на сайте, новый год же)
🔷M — Modify. Модифицировать. Изменить цвет, форму, размер. Подвигать кнопки. (тексту было тесно в таблице — добавили «воздуха» в дизайн)
🔷P — Put. Применить в другом месте. Достать из области применения и вставить в другую. (LLM умеет искать закономерности в тексте — внезапно научилась генерировать картинки)
🔷E — Eliminate. Удалить что-то. Упростить, избавить от ненужного. (пользователи не нажимают кнопку никогда — убрать кнопку)
🔷R — Reverse. Перевернуть, сделать наоборот. (делали утюги — начали делать немнущуюся одежду)

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

MVP головного мозга, или Экономически «обоснованный» рост техдолга

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

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

В итоге аббревиатура MVP для многих команд звучит не как проверка гипотезы, а как «херак-херак и в продакшен».

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

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

🔷Считать экономическую выгоду от возврата техдолга. Это прям сложный пункт, который нуждается в нетривиальном анализе трекера задач, разметке блокеров. Но на самом деле техдолг — это как двигатель, который не заводится с первого раза. Иногда вы тратите несколько секунд на заведение, иногда минуту. А иногда движок стопорится полностью, и теперь нужно вызывать эвакуатор. Посчитайте затраты времени на «тыр-тыр-тыр-тыр», умножьте на стоимость часа работы — вот вам и экономическая выгода. К слову, вполне нормально, если какая-то новая MVP-фича может принести сильно больше выгоды, чем переделка старой. Тут уже ничего не поделать.

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

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

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

😻 Упаковка календаря

Недавно коллеги во внутреннем приложении для сотрудников, как это сейчас модно, сгенерировали итоги года. В 2024 году у меня было 1612 встреч, 70167 минут я на них провёл. То есть в среднем у меня было по 4 часа рабочих и не только встреч в день.

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

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

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

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

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

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

🔷Бронирую слоты под концентрацию. Моя работа — это не только разговоры, её тоже нужно планировать.

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

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

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

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

🔷Резюмирую результаты встречи текстом. Чтобы потом не вспоминать и не перекидываться пустыми «А вот вы обещали, а вот мы договорились голосом, помните?». Не записано — не было. Записано — не нужна ещё одна встреча обсудить то, что забыли.

А у вас какие кунг-фу приёмы для календаря есть?

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

(Картинка взята из паблика Адовый 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 перед выкаткой. Или, что ещё хуже, «мы сейчас раскатим на тех, кто деньги приносит, а незрячие нам денег почти не приносят, их мало, ничего страшного, что мы их потеряем».
🔷Или какой-то банк начал по ночам проводить регулярные технические работы, из-за чего интернет-банкинг перестаёт работать в принципе, при этом никаких оповещений или графика работ нигде нету. «Ну разве кому-то ночью нужен интернет-банкинг?»

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

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

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

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

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