В общем, мне зашло. Читать лекции в телеге — бесподобно. Не паришься про лексику, можно забить, если кто-то себя узнает в очередном примере. Ни цензуры, ни программных комитетов (при всём моём к ним уважении).
Кароч. Давайте придумаем новую тему. Я зафигачу презу и соберёмся, пообсуждаем.
О чём я могу рассказать, многие из вас уже знают, но на всякий:
- всё, что связано с проектным управлением: процессы, найм/увольнения, бюджеты, риски
- продуктовый дизайн: от объединения юзер и джоб сторей до когнитивных искажений
- аналитика, как системная, так и бизнес: могу про сиквенсы и бигдату, могу про бэпэмээн с файербэйзом
- отдельная тема технический дизайн: я разраб и местами архитектор, могу на пальцах объяснить всякие очереди сообщений и микросервисы
- всякое про лигал: партнёрства, договоры, эндиэй, депонирование и прочее
- ну и наше любимое: аишки; от базовых вещей, вроде промптов и токенов до полной жести: архитектур, датасетов, до- и переобучения
Кидайте в комментарии свои пожелания, выберем самое популярное и/или интересное
Кароч. Давайте придумаем новую тему. Я зафигачу презу и соберёмся, пообсуждаем.
О чём я могу рассказать, многие из вас уже знают, но на всякий:
- всё, что связано с проектным управлением: процессы, найм/увольнения, бюджеты, риски
- продуктовый дизайн: от объединения юзер и джоб сторей до когнитивных искажений
- аналитика, как системная, так и бизнес: могу про сиквенсы и бигдату, могу про бэпэмээн с файербэйзом
- отдельная тема технический дизайн: я разраб и местами архитектор, могу на пальцах объяснить всякие очереди сообщений и микросервисы
- всякое про лигал: партнёрства, договоры, эндиэй, депонирование и прочее
- ну и наше любимое: аишки; от базовых вещей, вроде промптов и токенов до полной жести: архитектур, датасетов, до- и переобучения
Кидайте в комментарии свои пожелания, выберем самое популярное и/или интересное
4🔥20❤4👍3😁1🎉1
Давайте опрос. Сначала выберем направление:
Final Results
36%
Проектное и продуктовое управление
43%
Продуктовый дизайн
37%
Аналитика
28%
Технический дизайн
4%
Юридические темы
37%
AI
Ну что, продуктовый дизайн победил. Ожидаемо, но немного скучненько. Я сделаю несколько през, начнём с дизайна, потом пойдём в AI, аналитику и проектное/продуктовое управление.
Выбираем тему для дизайна:
Выбираем тему для дизайна:
Final Results
33%
Пудра на труп: почему фигма вас не спасёт
39%
В жопу тренды: зачем вам boring design
44%
5 ошибок, которые убивают продуктовый дизайн
49%
Пользователь — не идиот, он просто торопится
🔥5👏2🤨2👀1
Ну что, победил вечно спешащий пользователь. Через недельку будем с вами (и с ним) встречаться здесь, на канале.
И кстати. Я тут думал про формат и понял, что не хочу делать запись. Это позволит мне быть откровеннее и не париться ни о лексике, ни о других аспектах. Так что, сорян, только онлайн
И кстати. Я тут думал про формат и понял, что не хочу делать запись. Это позволит мне быть откровеннее и не париться ни о лексике, ни о других аспектах. Так что, сорян, только онлайн
❤14🔥6👀4👏2🫡1
Павел Шерер
Знакомьтесь, герой нашей следующей встречи. Андрей, 34 года. Менеджер среднего звена. Всё время на бегу: то звонок по работе, то дети, то курьер, то заказ на вайлдбериз. У него есть смартфон, интернет и 8 секунд терпения
Итак. Анонс, который можно (и нужно) расшарить всем причастным.
Вечером во вторник (29.04) мы будем обсуждать, почему ваши продукты не успевают за пользователями. Это не будет классической лекцией, мы сразу врубим всем микрофоны и вы сможете абсолютно безнаказанно меня перебивать. Я, конечно, подготовлю презентацию, но она будет, скорее, для галочки.
Уберите детей и снобов от экрана, будет жёстко
Вечером во вторник (29.04) мы будем обсуждать, почему ваши продукты не успевают за пользователями. Это не будет классической лекцией, мы сразу врубим всем микрофоны и вы сможете абсолютно безнаказанно меня перебивать. Я, конечно, подготовлю презентацию, но она будет, скорее, для галочки.
Уберите детей и снобов от экрана, будет жёстко
❤13🔥6🫡3
Пока мы ждём трансляции, давайте поговорим о реальных последствиях наших ошибок. Причём ошибок не всегда очевидных, а иногда даже вовсе неожиданных.
Когда юикс слишком хорош
Вот вы проектируете экраны, составляете диаграммы последовательностей, прорабатываете юикс до мелочей. Делаете всё, чтобы повысить эффективность бизнеса и улучшить пользовательское взаимодействие. Но бывают случаи, когда мы заходим слишком далеко по этому светлому пути.
Кто виноват? Дети, тыкнувшие куда не следует? Родители, доверившие детям свои девайсы? Нет, виновата компания. А конкретно — аналитики и дизайнеры, которые не учли банальную защиту подтверждением. Амазону, казалось бы, хорошо: меньше кликов, больше конверсия (и плевать, что 0.1% заказов будут оспорены). Но нет. Такие случаи вызывают общественный резонанс, страдает имидж компании, и в реальной перспективе её ожидает вполне конкретная недополученная прибыль.
Когда цена слишком высока
Ну что может случиться, если пользователь иногда ошибётся во вводе или нажмёт не туда? Подумаешь, потеряет пару секунд. Ничего страшного.
Проектирование взаимодействия — это всегда работа с пограничными ситуациями. Вы не можете себе позволить покрывать только статистически значимые случаи, вы должны продумывать и статистические аномалии, всплески. Нулевые состояния экранов, слабая скорость интернета и девайса, внезапное падение одного из сервисов, fat-finger errors: перечень практически бесконечен. И неважно, аналитик вы, дизайнер, разработчик или менеджер. Вы должны учитывать их все. Да, это может быть долго и дорого. Но если что-то делаешь, делай это хорошо.
Когда юикс слишком хорош
Вот вы проектируете экраны, составляете диаграммы последовательностей, прорабатываете юикс до мелочей. Делаете всё, чтобы повысить эффективность бизнеса и улучшить пользовательское взаимодействие. Но бывают случаи, когда мы заходим слишком далеко по этому светлому пути.
В 2019 в Сан‑Диего двухлетняя Рейна, играя с маминым телефоном, всего одним нажатием «Buy Now with 1‑Click» на Amazon приобрела диван за $430, о чём родителям стало известно лишь по уведомлению «Your couch has shipped» — всё из‑за того, что интерфейс оказался слишком простым, а внимание мамы отвлекли бытовые дела.
Через несколько лет в Массачусетсе пятилетняя Лайла нажала те же самые жёлтые кнопки и без ведома родителей заказала мотоциклы, ковбойские сапоги и игрушечный джип на сумму более $3 000, пока мать отвлекалась на дорогу в машине.
Кто виноват? Дети, тыкнувшие куда не следует? Родители, доверившие детям свои девайсы? Нет, виновата компания. А конкретно — аналитики и дизайнеры, которые не учли банальную защиту подтверждением. Амазону, казалось бы, хорошо: меньше кликов, больше конверсия (и плевать, что 0.1% заказов будут оспорены). Но нет. Такие случаи вызывают общественный резонанс, страдает имидж компании, и в реальной перспективе её ожидает вполне конкретная недополученная прибыль.
Когда цена слишком высока
Ну что может случиться, если пользователь иногда ошибётся во вводе или нажмёт не туда? Подумаешь, потеряет пару секунд. Ничего страшного.
Представьте, вы — опытная медсестра в ночную смену, система госпиталя тормозит, пациенты ждут. В декабре 2017 в Vanderbilt University Medical Center медсестра РаДонда Вогт ждала загрузки заказа на препарат Versed для 75‑летней пациентки перед МРТ. Система не выдала заказ вовремя, и, торопясь, она воспользовалась override‑функцией отладки — но вместо Versed взяла vecuronium, мощный паралитик. У пациентки остановилось сердце и она скончалась на следующий день. Сама Вогт призналась в ошибке сразу, но в итоге была привлечена к уголовной ответственности за «преступную халатность».
Ещё пример. Врачебная фат‑фингер ошибка при программировании инфузионного насоса. В 2022 ISMP Canada зафиксировала два случая, когда при вводе в насос параметров антидота N‑ацетилцистеина (лекарство при передозировке парацетамолом) смешали скорость «loading dose» и «maintenance dose». Из‑за этого препарат шёл слишком быстро, что привело к летальным передозировкам у детей.
Проектирование взаимодействия — это всегда работа с пограничными ситуациями. Вы не можете себе позволить покрывать только статистически значимые случаи, вы должны продумывать и статистические аномалии, всплески. Нулевые состояния экранов, слабая скорость интернета и девайса, внезапное падение одного из сервисов, fat-finger errors: перечень практически бесконечен. И неважно, аналитик вы, дизайнер, разработчик или менеджер. Вы должны учитывать их все. Да, это может быть долго и дорого. Но если что-то делаешь, делай это хорошо.
2👍12🔥9👏4❤3
Аналитик (а есть у профессии аналитика феминитив? аналитикесса?), которая подошла после выступления по поводу участия в проектах. Пиши в личку, созвонимся и сразу добавлю тебя в папку телеги, чтобы не потерять
😁8❤1
Через 4.5 часа стрим, поговорим о скорости ваших продуктов и почему важно успевать за пользователем. Сто процентов зайдёт дизайнерам, аналитикам, продактам и даже маркетологам. Давайте уже ускоряться агрументированно.
Шарьте всем причастным
Шарьте всем причастным
❤12🔥9🫡4
А давайте немного поговорим о банальном. У меня тут недавно пригорело на одном проекте, спешу поделиться: идите в жопу со своими CJM. Не подумайте, я отлично понимаю их значимость, но кажется, что мы с вами сделали культ из промежуточного артефакта.
Типичная сиджиэмка: пользователь просыпается, открывает сайт, логинится, выбирает товар, оформляет заказ — профит. Последовательно. Логично. Красиво. Как сценарий выпускного спектакля в театральной школе.
Но в реальности всё не так. Пользователь зашёл с мобилы, стоя в очереди. Промахнулся мимо нужной ссылки, нажал на баннер, перешёл на форму какой-то заявки, нажал на отмену, его редиректнуло на главную и в конце показало модалку «оцените наш сервис».
CJM на это не рассчитана. Она не живёт в отказах, тупиках, рандомных путях и параллельных процессах. Она — нарратив. Утопия. Диаграмма про то, как должно быть, если вдруг в мире наступит product heaven, а все люди превратятся в линейно действующих болванов.
В продуктовом дизайне CJM даёт лишь иллюзию контроля. Ты вроде бы всё распланировал, проработал и воплотил. Но система-то работает иначе: по своим законам, со своими ошибками, логикой, ограничениями и неожиданностями.
И вот ты уже проектируешь не поведение системы, а красивую легенду. По которой потом делают прототип, влюбляются в него, и с этим полусказочным артефактом бегут в разработку. А потом начинаются велокостыли и попытки натянуть кипиайную робу на и так страдающий продукт.
Я начинаю не с journey, а с архитектуры и состояний. С тем, что может пойти не так. С роли системы, а не только роли пользователя. С точек провала. Кто видел мои концепции, знает, что там всегда, в 100% случаев, есть раздел про риски и ограничения.
CJM хороша, чтобы поштормить о драйверах/барьерах, но я оставляю её для презентаций. Для реального дизайна — беру реальность. Да, она некрасивая. Зато работает.
Типичная сиджиэмка: пользователь просыпается, открывает сайт, логинится, выбирает товар, оформляет заказ — профит. Последовательно. Логично. Красиво. Как сценарий выпускного спектакля в театральной школе.
Но в реальности всё не так. Пользователь зашёл с мобилы, стоя в очереди. Промахнулся мимо нужной ссылки, нажал на баннер, перешёл на форму какой-то заявки, нажал на отмену, его редиректнуло на главную и в конце показало модалку «оцените наш сервис».
CJM на это не рассчитана. Она не живёт в отказах, тупиках, рандомных путях и параллельных процессах. Она — нарратив. Утопия. Диаграмма про то, как должно быть, если вдруг в мире наступит product heaven, а все люди превратятся в линейно действующих болванов.
В продуктовом дизайне CJM даёт лишь иллюзию контроля. Ты вроде бы всё распланировал, проработал и воплотил. Но система-то работает иначе: по своим законам, со своими ошибками, логикой, ограничениями и неожиданностями.
И вот ты уже проектируешь не поведение системы, а красивую легенду. По которой потом делают прототип, влюбляются в него, и с этим полусказочным артефактом бегут в разработку. А потом начинаются велокостыли и попытки натянуть кипиайную робу на и так страдающий продукт.
Я начинаю не с journey, а с архитектуры и состояний. С тем, что может пойти не так. С роли системы, а не только роли пользователя. С точек провала. Кто видел мои концепции, знает, что там всегда, в 100% случаев, есть раздел про риски и ограничения.
CJM хороша, чтобы поштормить о драйверах/барьерах, но я оставляю её для презентаций. Для реального дизайна — беру реальность. Да, она некрасивая. Зато работает.
7🔥23💯7👏6❤2🎉1
Техдолг.
Вообще не страшное слово. Это такой долг, который и можно, вроде, отдать, но всегда есть что-то поважнее. Мы ебошим хотфиксы в проде, оставляем «на потом» проектирование пограничных состояний, делаем архитектурные допущения. Не понимая, что каждое такое решение добавляет грамм взрывчатки под нашу задницу. Техдолг — это не пыль, которую можно загнать под ковёр, это тротил под фундамент проекта.
Не верите? Вот несколько примеров:
Вы можете подумать, что я против техдолга (а значит, против бизнеса, «за всё хорошее против всего плохого»). Это не так. Техдолг — это неизбежный спутник роста. Я против того, чтобы он неконтролируемо размножался.
Бизнес не видит немедленной ценности рефакторинга (зато видит повышение на 0.01% конверсии после редизайна корзины). Оценку рисков ведут в часах, а не в деньгах и репутации компании. Отсутствует единый реестр долга — всё лежит в головах или в разрозненных джира-тикетах.
Техдолг делает из кода легаси, UX наполовину состоит из заплаток, а аналитика не понимает, почему данные дублируются. И рано или поздно проект детонирует.
Что можно сделать, как обезвредить эту хрень?
1. Используйте Debt Ledger. Каждая затычка фиксируется с формулой: стоимость дефекта * вероятность * время до взрыва.
2. Миксуйте спринты: на 2 спринта фич — 1 спринт «детокса» кода, аналитики или юикса.
3. Капитализируйте техдолг. Покажите руководству, сколько будет стоить взрыв и сколько — его предотвращение.
4. Не будьте ленивым мудаком. Если можете что-то поправить прямо сейчас, правьте.
Вообще не страшное слово. Это такой долг, который и можно, вроде, отдать, но всегда есть что-то поважнее. Мы ебошим хотфиксы в проде, оставляем «на потом» проектирование пограничных состояний, делаем архитектурные допущения. Не понимая, что каждое такое решение добавляет грамм взрывчатки под нашу задницу. Техдолг — это не пыль, которую можно загнать под ковёр, это тротил под фундамент проекта.
Не верите? Вот несколько примеров:
В 2012 Knight Capital Group была крупнейшим трейдером акций с долей около 17% на фондовой нью-йоркской бирже. В очередном обновлении ребятки залили патч, который, как оказалось, реанимирует кусок легаси-кода. За 45 минут роботы накупили акций на $7 млрд. В итоге убыток в $440 млн компания не пережила и была поглощена конкурентом.
Через 10 лет, в 2022, зимний шторм немного подморозил авиасообщение в Штатах. У авиакомпании Southwest Airlines из-за резкого увеличения отмен рейсов прилегла устаревшая система расписания экипажей. Ребятам понадобилось восемь дней, чтобы её починить. Как итог, 16 700 отменённых рейсов, $800 млн прямых потерь.
Вы можете подумать, что я против техдолга (а значит, против бизнеса, «за всё хорошее против всего плохого»). Это не так. Техдолг — это неизбежный спутник роста. Я против того, чтобы он неконтролируемо размножался.
Бизнес не видит немедленной ценности рефакторинга (зато видит повышение на 0.01% конверсии после редизайна корзины). Оценку рисков ведут в часах, а не в деньгах и репутации компании. Отсутствует единый реестр долга — всё лежит в головах или в разрозненных джира-тикетах.
Техдолг делает из кода легаси, UX наполовину состоит из заплаток, а аналитика не понимает, почему данные дублируются. И рано или поздно проект детонирует.
Что можно сделать, как обезвредить эту хрень?
1. Используйте Debt Ledger. Каждая затычка фиксируется с формулой: стоимость дефекта * вероятность * время до взрыва.
2. Миксуйте спринты: на 2 спринта фич — 1 спринт «детокса» кода, аналитики или юикса.
3. Капитализируйте техдолг. Покажите руководству, сколько будет стоить взрыв и сколько — его предотвращение.
4. Не будьте ленивым мудаком. Если можете что-то поправить прямо сейчас, правьте.
6❤22👍7💯5🔥4
Ну что, пора выбирать тему следующего стрима. В этот раз поговорим про управление проектом/продуктом.
Если нужной темы нет, пишите в комменты
Если нужной темы нет, пишите в комменты
Final Results
38%
Этичная манипуляция: как продать идею команде (вольная трактовка выступления на DUMP)
26%
North Star Metric: почему NPS или прибыль не годятся для царь-метрики
26%
Увольняем с удовольствием: как сделать изгнание подарком
36%
Управление рисками: от старта проектирования до запуска
36%
Roadmap: договорённость, а не календарный план
4%
Против всех
3🔥8👏3❤2
Павел Шерер
Ну что, пора выбирать тему следующего стрима. В этот раз поговорим про управление проектом/продуктом.
Если нужной темы нет, пишите в комменты
Если нужной темы нет, пишите в комменты
Забыл сказать: шарьте опрос, так даже не подписчики смогут повлиять на результат (а я получу новых подписчиков)
👌6🫡3😎3😁2
Мне тут в личку вчера прилетело неожиданное. Пишу с разрешения источника прилёта.
Претензия была про мат. Мол, ты же профессионал, с хуя ли позволяешь себе ругаться перед аудиторией? Друзья, я по образованию не программист, а вообще филолог. Мат — естественная часть моего лексического разнообразия. Я не ругаюсь матом, я изъясняюсь с его помощью.
Обсценной лексикой я не брезгую в общении с семьёй, друзьями и клиентами. Единственное исключение — дети. Да и то лишь из-за воспитания (поверьте, ваши дети с садика знают все «плохие» слова).
Так что сорян, поборцы нравственности, но здесь так.
И кстати, раз уж на то пошло. Дайте мне благозвучный аналог слова «ебеня»
Претензия была про мат. Мол, ты же профессионал, с хуя ли позволяешь себе ругаться перед аудиторией? Друзья, я по образованию не программист, а вообще филолог. Мат — естественная часть моего лексического разнообразия. Я не ругаюсь матом, я изъясняюсь с его помощью.
Обсценной лексикой я не брезгую в общении с семьёй, друзьями и клиентами. Единственное исключение — дети. Да и то лишь из-за воспитания (поверьте, ваши дети с садика знают все «плохие» слова).
Так что сорян, поборцы нравственности, но здесь так.
И кстати, раз уж на то пошло. Дайте мне благозвучный аналог слова «ебеня»
💯17😁12🔥5
Павел Шерер
Ну что, пора выбирать тему следующего стрима. В этот раз поговорим про управление проектом/продуктом.
Если нужной темы нет, пишите в комменты
Если нужной темы нет, пишите в комменты
И у нас самая неубедительная победа за всю историю этого канала. Этичная манипуляция обошла риски и роадмап с отрывом в 1 (один) голос. Посему силой, данной мне авторством всего этого дерьма, нарекаю победителями сразу три темы. Будем миксовать
❤8😁4🎉3🔥2
В ближайший четверг, 15.05, поговорим про то, как этично манипулировать и продавать практически любую идею команде и руководству. Встреча будет без записи и цензуры. Встречаемся через пять дней тут, на канале.
Шарьте
Шарьте
🔥23🫡2