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

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

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

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