Продукт

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

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

Почему всё это называют одним словом? Во-первых, так говорят клиенты. У них основная деятельность находится в другой области, поэтому практически любые работы с сайтом, кроме полноценного редизайна или новой разработки, они склонны называть поддержкой. Во-вторых, это пошло от самих веб-студий. Их основной продукт — создание сайтов, а всё, что происходит после запуска, автоматически отправляется в категорию «поддержка». Необязательно срочно придумывать для каждой услуги новое название. Но при обсуждении поддержки нужно четко зафиксировать, что именно вы делаете, а что не делаете. За что отвечаете, в какие сроки реагируете, какие задачи принимаете и что оплачивается отдельно. Тогда у клиента не будет ожидания, что в рамках гарантии вы бесплатно разработаете новую функцию или будете дежурить и решать падение сайта под нагрузкой в выходные. Называть разные услуги одним словом можно. Главное — чтобы все одинаково понимали, какая именно услуга была куплена. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵

M&Ms — менеджмент — Как уследить за всеми? — спросил фаундер стартапа. — В неделю по десять новых сотрудников выходит. — По быстрым сигналам Менеджер группы Van Halen требовал, чтобы за кулисами музыкантов ждала тарелка M&Ms без единого коричневого драже. «Звездный выпендреж», — подумал я. Оказалось — хитрый метод управления. «Если мы видели хоть одну коричневую конфету — проверяли все. Организатор на площадке не читал договор — будут технические проблемы, которые могут разрушить шоу и даже поставить под угрозу жизнь группы», — рассказывал Дэвид Ли Рот. Чем больше масштаб компании — тем меньше возможностей следить за всем. Да это и не нужно. Достаточно определить «коричневый M&Ms» — выделить ключевое качество и простой метод его проверки. Например, в Stripe считают, что налоговые консультанты должны быть пунктуальны и точны. Поэтому встречи с ними назначают на 12.47. Те, кто приходят в 13.00, попадают под аудит. Вывод прост: случайная выборка в широком диапазоне снимает головную боль ——————————- Пост написан год назад. С приходом ИИ стал еще актуальнее :)

Чек-лист, что должен проверять продакт в AI-продуктах и чатах в частности 1. Правило 5–10 кейсов. Составь базвый золотой датасет из 5–10 эталонных юзкейсов (например, для AI-саппорта: возврат денег, смена адреса, жалоба на хамовитого курьера) и автоматизируй их проверку. 2. Один скорер = одно измерение. Главная ошибка PM - оценивать ответ модели одной общей метрикой «хорошо/плохо». Для кейса с возвратом денег разбей оценку на три отдельных скорера: • Точность (Accuracy): нашел ли бот правильную транзакцию? • Тон (Tone): вежлив ли бот, выразил ли эмпатию? • Безопасность (Policy): не пообещал ли бот возврат денег в обход регламента? 3. Human Review нельзя убирать. Автоматический код легко проверит, сделал ли бот запрос к базам данных. Но оценить, не звучит ли ответ как бездушный робот, пока может только человек. 4. Разрыв между топом и медианой. Команды с авто-эвалами видят, что новое обновление модели сделало бота супер-вежливым, но снизило точность поиска заказов на 10% и откатывают деплой. Команды без эвалов выкатывают регресс в прод и ловят волну негатива от клиентов. 5. 3 фазы внедрения на примере AI-саппорта: • Инкубация: собираем золотой датасет частых вопросов клиентов. • Шлифовка: weekly-демо, жесткие критерии (*«бот должен прикрепить ссылку на форму возврата, но не закрывать тикет сам»*) и просмотр цепочки рассуждений бота (Debug Mode). • Масштабирование: авто-тесты перед каждым деплоем и Slack-канал, куда автоматически падают все «дизлайки» от пользователей с логами беседы. 6. Чек-лист: как внедрить Evals за 5 шагов: • Собери реальные логи чатов, где бот ошибся. • Сформируй из них точечный датасет на 10–50 примеров. • Сравни две версии промпта side-by-side на одном и том же датасете. • Настрой автоматический ночной прогон тестов (Nightly Evals). • Настрой алерты на дизлайки пользователей прямо из продакшена. 7. Метрики качества AI-бота: • Accuracy: % корректно решенных вопросов без эскалации на оператора. • Tone & Brand Alignment: соответствие гайдлайнам компании. • Schema Compliance: отдаёт ли бот корректный JSON для API вызовов. • Latency & Cost: задержка ответа (в сек) и стоимость токенов на диалог. Источник: https://www.braintrust.dev/blog/evals-for-pms](https://www.braintrust.dev/blog/evals-for-pms #PG_education

💁‍♀️ Просматривала вчера новый Agile Practice Guide, и там была отсылка к Google’s Project Aristotle. Они исследовали 180 команд, чтобы понять, какие факторы делают команды эффективными. Главным из них оказалась — психологическая безопасность (psychological safety). Что она подразумевает, поговорим попозже. А сейчас интересно другое — Google НЕ нашёл значимой связи между эффективностью команд и: - Совместной работой в одном месте - Принятием решений строго консенсусом - Экстраверсией участников команды - Индивидуальной результативностью - Объёмом нагрузки - Позицией членов команды - Размером команды - Стажем работы Ну, про размер команды, конечно, очень спорно, но им виднее...)

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

Все-таки опыт тестирования пригождается в разработке каких-то своих продуктов. Сейчас на Stepimy у меня такой флоу: 1. Есть локальный, QA и Prod стенд. 2. После выкатки фичи запускается смоук. 3. Перед тем, как отправить в прод, запускается регрессия + проверки по миграции данных. 4. Когда накапливается какое-то количество фич, я делаю аудит по безопасности, производительности, удобству использования и по всем остальным нефункциональным характеристикам. Если есть возможность через тот же Codex проверить Claude Code, то тоже это делаю. 5. Вся информация о релизах добавляется в релиз ноутс. 6. Само собой есть возможность написать в поддержку, то есть мне, и получить фикс быстро и даже реализовать какое-то улучшение, о котором я и не думал. Сейчас проходит бета-тест с авторами Stepik и очень много дельных комментариев получаю от них. В общем, вайбкодинг может быть интересным. По сути собрал команду из агентов.

Где возникают ошибки Можно предложить следующую модель получения результата: цель → намерение → действие → система → результат Все это находится в окружении, которое влияет на наши действия. 1. Намерение Насколько намерение помогает достичь цели, или насколько у меня правильный образ действия, того, что я хочу сделать. Дон Норман называл эту стадию понимание «концептуальной модели системы». В ряде случаев концептуальная модель простая: если нажать на педаль тормоза, то машина остановиться. Но в ряде случаев концептуальная модель может быть запутанной: чтобы открыть дверь — её надо толкнуть или потянуть на себя? Я уже не говорю про более сложные системы. Насколько система представляет собой ясную схему, что и как надо сделать, чтобы получить желаемый результат? 2. Действие Несовпадение намерения и действия — действительно ошибка человека. Я хотел повернуть налево, но повернул направо. Я хотел нажать на тормоз, а нажал на газ. Насколько система позволяет сделать неправильное действие. Кроме этого важную роль начинают играть другие факторы: усталость исполнителя, отвлекали ли исполнителя во время важных действий и т.д. 3. Система или черный ящик. Сама система может работать с ошибками. Люди могут неправильно понять, то что мы им говорим, информация передается с ошибками. Механизмы могут быть спроектированы с ошибками, софт ошибается. 4. Окружение Это та обстановка, в которой мы действуем. Либо это культура организации, это социоэкономические факторы и т.д. Окружение может влиять на ошибки, которые возникают в процессе. Есть ли давление, чтобы добиться хороших результатов. Насколько система требует не ошибаться или система требует достичь цели любой ценой. Это культура компании, тон сверху, психологическая безопасность и все подобные вещи. Сюда же относятся ошибки, которые можно называть «внешними событиями». Мы ехали по правилам, в нас врезалась машина. Но мы же все сделали правильно. ;) Как видно, отклонения или ошибки могут возникать на любом уровне в этой модели. Но на каждом уровне ошибки возникают по разными причинами и требуют разных методов для предотвращения. #ЧФ #ошибки

Сегодня было, пожалуй, самое эпичное демо нашего продукта (omnu) за всё время. Кажется, ретроградный Меркурий решил провести его вместе с нами. За первые 30 минут не сгенерировалось вообще ни одного меню. Всё зависало. Вместо изображения кофейного напитка сгенерировалась булочка. Мы попытались это исправить… и булочка появилась уже прямо в кофе. В какой-то момент мы уже просто смеялись, потому что происходило буквально всё, что только могло пойти не так. И вот после такого демо в конце ребята говорят: «Мы хотим с вами работать. У вас очень крутой продукт. И вообще хотим, чтобы наше имя появилось у вас на главной странице.» Наверное, это ещё одно напоминание, что люди покупают не отсутствие багов. Они покупают понимание проблемы, скорость, с которой ты её решаешь, и видение того, во что продукт может превратиться. Хотелось бы, конечно, чтобы следующие демо проходили чуть менее… хлебобулочно. Но если уж фейлиться, то пусть все фейлы заканчиваются именно так 💛 @wealldesigners

Почему цифры на слайдах врут Топ-зацепок к тому, что вам показывают (1) Метрики часто подменяют стратегию (сурrogation) Люди мысленно заменяют абстрактные стратегии измеримым показателем. Например, учитель учит сдавать тесты, а не понимать предмет Компания Wells Fargo хотела построить долгосрочные отношения с клиентами и измеряла это кросс-продажами дополнительных счетов. Итог: 3,5 млн счетов, открытых без согласия клиентов. Разрушено ровно то, ради чего все затевалось (2) Как только показатель становится целью, он перестает быть хорошей мерой (Закон Гудхарта) Любая наблюдаемая статистическая закономерность склонна к разрушению, как только на нее оказывается давление с целью контроля Те, кто ставят цель, часто имеют неполное представление о процессе. Внимание, направленное на абстрактные метрики, оставляет что-то важное в тени KPI Тестировщиков в ИТ могут измерять по количеству найденных багов. Но в итоге, ребята могут создавать баги-пустышки или начать дробить большую задачу на мелкие, чтобы повысить такую метрику (3) Улучшение метрики может означать ухудшение реальности Представьте себе хирургов, которые заполняют отчеты о хирургических операциях. Чтобы повысить свои показатели, некоторые хирурги отказывают пациентам с худшими шансами на успешный исход Это значит, что тяжелобольным становится все сложнее найти хирурга. Люди умирают, метрика улучшается (4) Вы не можете понять, почему происходит Х, рассматривая только те случаи, когда Х происходит (ошибка выжившего) Очень хороший пример, когда наши эмоции, в том числе, толкают в сторону неверных выводов –  Представьте себе случай массовой стрельбы, освещенный в СМИ. Часто в биографиях стрелков обнаруживают, что они играют в "жестокие" видео игры. Но вопрос не в том, играют ли они, а в том: - играют ли они больше других? - становятся ли люди жестокими, играя в жестокие видео-игры или люди играют в такие игры, потому что жестоки сами по себе? - к чему приводят такие игры: к увеличению насилия или к безопасному выплеску? (5) Спрашивайте, чего в данных нет Вы исследовали людей, которые у вас что-то не купили, хотя были на вас подписаны? А как насчет людей, которые не купили, потому что даже о вас не знали? Ушло 100 клиентов, вы опросили 20 ответивших и сделали выводы? А что с молчунами? Бонус Данные никогда не сырые, вы просто иногда впервые с ними сталкиваетесь. Данные осмысляются, фиксируются и собираются, в результате человеческих решений: что именно измерять, когда, где и каким методом У цифры всегда есть автор со своими особенностями и интересами 🔗 Кружок кройки бытия

Программа при запуске хочет, чтобы я открыл файл Один из паттернов в интерфейсе, который меня бесит — это когда запускаешь программу на Маке, а она тут же открывает диалог открытия файла. Ну типа, думает она, пользователю же я низачем не нужна без файлов, ему же по-любому нужно будет открыть? — вот я и помогу! Это, как и кнопка «наверх» внизу страницы и кнопка «На главную» на пустом экране — тоже пример того, когда мне протягивают костыль, а я не хромой. Во-первых, я сам решу, открывать мне файл или нет. Может, я зашёл просто версию посмотреть или обновление установить? Или я звпустил программу впрок, но прямо сейчас не собираюсь ничего с ней делать. Просто не лезь со своим диалогом и не мешай мне пользоваться компьютером! Во-вторых, даже если я и собираюсь открыть файл, ну не через диалог открытия файла же я это буду делать! Это самый неудобный способ открыть файл в мире. Файл почти наверняка у меня где-то и так под рукой: в письме, в телеге, на рабочем столе, в папке, в веере Downloads в доке. Я его просто оттуда затащу да и всё. Нафиг мне твой диалог сдался вообще? Если программа пытается по-умному что-то предусмотреть или предугадать — это хорошо. Но важно, чтобы результат этого предугадывания не был помехой пользователю.

Стоимость владения 10 лет назад я купил свою первую машину – бирюзовый мини купер. До этого у меня был велосипед, который много есть не просил. Новым для меня стало то, что теперь надо тратить ~100$ в месяц на мойку, заправку, масло и т.д. – на велосипеде траты были сильно меньше. С софтом похожая ситуация – тоже иногда нужно доливать масло. Особенно теперь, когда везде АИ. Благодаря АИ делать новое вроде бы быстро и дешево. Очень круто, когда можешь за пару часов сделать микро-продукт и закрыть проблему, которая мешает жить. Заметил, что многие команды бросились “писать свое”: систему локализации, поисковик битых ссылок, обвес для аналитики. Часто это действительно оправдано, надо только помнить о стоимости владения. Все эти микро-продукты нужно будет кому-то поддерживать, как тот мини купер. Чинить баги, добавлять забытые юзкейсы – это все время команды. Чем больше у тебя таких продуктов, тем больше времени ты тратишь на то, что бы они просто продолжали работать.

Какие иконка и название должны быть у приложения для картографии? Большинство из нас скажет что с картой, компасом или глобусом. А называться должно что-то вроде geo/map/find или что-то подобное. И когда будут создавать такое приложение, попадут в лимбо неинтересных приложений, которыми никто не будет пользоваться. Идея Zenly была в том что приложение должно вызывать эмоции. Чуваки сделали приложение для геолокации с иконкой эскимо! И это рвёт шаблоны как чёрный квадрат в красном углу. Задумка авторов что они должны ассоциироваться не с картой, а с вот этим вот ощущением прогулки и встречи друзей, поэтому выбрали эскимо. Zenly стало гипер-популярным приложением с 40М пользователей в месяц (MAU) в пике. И 160М скачиваний. Это настолько много что это было 2 по скачиванию приложение в русском App Store, обгоняя instagram Snap выкупили его за $213M. Найдено на канале @voicestuff (btw один из новых админов)

Рост роли «AI Product Builder» Традиционные PM-роли сокращаются (до 30% в целом и до 70% в SaaS), вместо них растёт гибридная роль Product Builder — человек, который сочетает product thinking, техническую грамотность, дизайн и быстро прототипирует/шиппит с помощью AI. Количество таких специалистов резко выросло. Организации перестраивают весь product lifecycle вокруг AI. В статье Forbes (от 30 июля 2026): «The Rise of the AI Product Builder: The Future of Product Management» репортят что традиционные product managers будут исчезать к 2030 году. По данным 2026 CPO Impact Report от Products That Count: - ставки PM сократились на 30% в целом и на 70% в SaaS. - При этом появилась и быстро растёт новая роль — Product Builder. Драйверы Старое ограничение (стоимость и скорость исполнения) исчезло. Новое узкое место — человеческое суждение: что строить, когда строить и как создавать реальную ценность. ИИ может генерировать требования, прототипы, код, тесты и документацию. Но он не может решить: - решает ли инициатива значимую проблему клиента - соответствует ли она стратегии бизнеса - является ли лучшим использованием ресурсов === Большинство компаний просто ускоряют старые процессы с помощью ИИ → получают лишь инкрементальный эффект. Топы перестраивают весь product lifecycle под возможности ИИ. PM был в основном координатором Product Builder фокусируется на создании outcomes, используя ИИ Большинство организаций всё ещё построены вокруг функций (product / design / engineering с разными руководителями, метриками и процессами). Эти границы становятся всё менее оправданными. Главный вопрос: что происходит, когда важнее становятся capabilities (способности), а не functions (функции)? Что Builder PM не означает Это не «один человек делает три работы (product + UX + engineering) за одну зарплату». Это не промоушен, а часто просто cost-cutting под красивой обёрткой. Хорошие инженеры любят инженерию и не хотят становиться PM. Дизайнеры не всегда готовы писать бизнес-кейсы. Ролевая компрессия имеет пределы. Настоящий Builder PM — это product-менеджер, который умеет использовать ИИ, чтобы стать в разы эффективнее, не отказываясь от того, что делает его ценным. Это не единорог, а 10x PM. Речь о leverage (рычаге), а не о расширении обязанностей. Правильный reframing Вопрос не «как мне теперь заменить инженеров с помощью AI-кодинга?». Вопрос: как использовать ИИ, чтобы стать 3x / 5x / 10x product-менеджером? ИИ удешевил не только building, но и learning. Побеждает тот, кто быстрее учится (рынок, потребности..) Discovery нельзя пропускать Парадокс: в agent-heavy workflow нужно больше живого синхронизирования с инженерами и дизайнерами, а не меньше. Хорошие Builder PM: - регулярно проводят customer interviews (не только на старте) - строят постоянные каналы обратной связи - сознательно защищают время на discovery даже при росте скорости Главный рычаг — feedback loops Большинство команд просто «используют AI-инструменты». Лучшие строят системы, которые сами улучшаются. Пример: fintech-команда добавила в конец каждого ИИ-ответа вопрос «Это было правильно?». Ответ пользователя сразу шёл в обучение модели. ИИ становился умнее прямо в потоке работы пользователей. == 💡Задача лидера — не просто решать, куда вставить ИИ в продукт, а спроектировать всю систему product management, где ИИ создаёт рычаг, где риски, и где feedback loops делают систему умнее со временем. Именно так получается 10x.

Last minute — старый новый нормальный сценарий. Интересный парадокс. Многие люди считают и обьявляют себя организованными, ведут календари, планируют встречи, а в beauty все равно очень часто записываются в последний момент. Знакомо? А сегодня это еще ярче. Настроение, погода, мероприятие, отпуск, усталость!, всё зае.... - решение записаться все чаще принимается здесь и сейчас. Treatwell пишет, что 47% записей в beauty и wellness оформляются менее чем за 24 часа до визита. Еще интереснее другая цифра: 52% всех записей происходят вне рабочего времени салона. А воскресный вечер вообще становится одним из главных моментов планирования новой недели. Итак, если больше половины записей происходит тогда, когда салон уже закрыт, значит, наша задача сегодня сделать мощную цифровую витрину, так чтобы было просто, интуитивно понятно, быстро и работало. Правильно же? А мне вчера управляющая говорит: "никак не могу загрузить бровиста нового". Открываю я онлайн запись, а там фото а-ля девяностые, никакие описаний, никаких якорей, чего это, к ней никто не идет?! Смешные эти управляющие... Вообщем, кто о чем, а я опять о важности онлайн-записи.

Claude Cowork для продакта Окончательно перешел на Cowork при ежедневной работе с продуктом и готов поделиться лайфхаками, которые могут сделать его вашим надежным помощником. Каждый из нас держит в голове большой объем операционного контекста из сообщений, задач, выгрузок данных, обсуждений и т.д. Плюс знания о продукте, его аудитории, экспериментах и планах на будущее. Научите вашего клода этому и он станет намного полезнее. 📌 Рабочая папка на ноутбуке с Claude Cowork + md файл с её структурой и содержимым + задача на обновление каждое утро. Всё это можно создать простым запросом:

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

В итоге ваш клод знает всё, что вы используете ежедневно, знает дату обновления файлов, может делать другие регулярные задачи на основе свежих данных. 📌 Регулярное обновление базы знаний клода о продукте — md файл с ключевыми разделами о вашем продукте в Confluence + задача на обновление раз в неделю. Тоже можно создать простым запросом:

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

Полученный в результате запроса файл лучше проверить и отредактировать вручную. Клод старательный, он может добавить туда ссылки на неактуальные страницы и ссылки на контент не про ваш продукт. Не забудьте поставить задачу в расписание и запустить её вручную один раз — тогда клод сможет делать это в фоне без запроса доступа каждый раз. 📌 Саммари по обсуждениям в Slack Хоть внутри Slack и есть свой AI, который пытается давать умные подсказки и даже иногда рекомендует выпить водички 🙂, он часто не понимает приоритеты обсуждений и их тематику. Создайте список каналов по категориям. У меня это общие чаты команды, разработка, поддержка, маркетинг и общие важные каналы компании. В каждой от 3 до 10 каналов. Создайте регулярную задачу с помощью такого запроса:

Прочитай обсуждения в Slack и сделай отчет по категориям (список категорий и каналов). В каждой сгруппируй данные по каналам или темам; кратко изложи основные факты, цифры, решения, инциденты, запуски, препятствия и открытые вопросы; укажи имена участников. Выдели критические инциденты, запуски/пилотные проекты и повторяющиеся проблемы.

Мне это экономит очень много времени и, одновременно, позволяет быть в контексте не испытывая FOMO чего-то важного. В следующий раз расскажу про свой опыт использования Cowork для создания продуктовых артефактов и дашбордов. #claude #lifehacks

Дизайн второго порядка Есть вещь, которая долго не давала мне покоя. Почему огромное количество людей делают вещи, которые ухудшают систему, хотя сами они не злые и не глупые? Почему компании тонут в техническом долге. Почему города становятся неудобнее. Почему бюрократия растёт. Почему хорошие идеи почти всегда проигрывают. Кажется, что проблема в людях. Но, возможно, проблема в другом. Мы почти всегда проектируем действие. «Сделай правильно.» «Используй стандарт.» «Не пиши костыли.» «Думай о будущем.» Это дизайн первого порядка. Он пытается изменить человека. Но существует дизайн второго порядка. Он вообще не пытается менять человека — он меняет сам ландшафт. Представьте гору. Можно бесконечно убеждать шарик катиться вверх. А можно немного изменить форму поверхности, и тот же самый шарик сам покатится в нужную сторону. В большинстве организаций хорошие решения требуют идти против склона: ▪️ Рефакторинг ▪️ Документация ▪️ Честная коммуникация ▪️ Переиспользуемые компоненты ▪️ Стандарты Все знают, что они полезны. Но локально они почти всегда дороже. Поэтому система не эволюционирует к хорошему дизайну. Она эволюционирует туда, куда смотрит локальная выгода. И, кажется, именно здесь начинается дизайн второго порядка. Не спрашивать: «Как заставить людей делать правильные вещи?» А спрашивать: «Как изменить ландшафт так, чтобы правильная вещь стала самым дешёвым следующим шагом?» Мне кажется, именно это и есть архитектура будущего. Топ-менеджерам на заметку Не мотивируйте людей. Берите мотивированных и уменьшайте демотиваторы. Не ставьте цели. Стройте системы, в которых достижение целей становится неизбежным. Не спорьте про процессы и зоны ответственности. Меняйте дизайн команды — так, чтобы отделы и департаменты сами выбирали решения, которые согласуются между собой и работают как единый здоровый организм, двигающий компанию вперёд. Заметили общее?

Я уже писал про мои мечты о «правильном» визивиге. Первой идеей было поведение на границе регионов с разной разметкой. Идея в том, что к курсору прилипает стиль того, откуда он пришел. Пришел на границу из жирного? Будешь писать жирным. Пришел, наоборот, из обычного? Будешь писать обычным. В том же самом месте, на той же самой границе. Есть еще идея делать в одном месте два шага, но она мне нравится меньше. Сегодня вторая идея. Я посмотрел на списки. Для меня это всегда дичь. Например, я зашел сейчас в Ноутс. Сделал ненумерованый список. Написал первый пункт. Нажал Энтер. Создался второй пункт, автоматически, с маркером. Пока все хорошо. И вот я стою на пустом элементе. Как мне закончить список? Скажем, я набрал три пункта, стою на четвертом, а он мне уже не нужен. В обычном тексте ты видишь слева от курсора маркер, значит бэкспейс должен его удалить. Так? Так. А в визивиге не так! Бэкспейс вернет тебя в предыдущий пункт! То есть удалит и маркер, и перенос строки. Зачем? Не знаю. Как тогда закончить список? Нажать ЭНТЕР. То есть то, что обычно создает новый пункт, тут ничего не создает, а удаляет маркер слева!!! Как создать пустой пункт, если энтер его удаляет? А никак. Кстати, это поведение еще и разнится от программы к программе. Например, в Гуглдоках бэкспейс удалит маркер слева, но оставит оступ. Так можно сделать элемент списка без маркера. Зачем? Прост. Неудивительно, что люди не любят визивиг! Обычные кнопки ведут себя совсем не так, как в обычном тексте. Выделение работает не так: можно выделить строку от начала до конца, и признак «элемент списка» скопируется вместе с ним, хотя ты вроде бы об этом не просил. Сами маркеры списка тоже ни выделить нельзя, ни даже курсором на них встать. Почему? Что в них такого особенного? Короче, думал я, думал, и пришел вот к какому выводу. Маркеры списка нужно интерпретировать как обычный текст. Давать ходить в них курсором, выделять, копировать, вставлять, удалять бэкспейсом. Это будет самое простое, предсказуемое, интуитивное поведение. По сути, главная причина, почему мы все так любим плейнтекст и не любим визивиг в том, что в плейнтексте все работает понятно и предсказуемо: что выделил, то и скопировалось. Ну вот, нет причин, почему в визивиге оно не может работать так же. Если у вас совершенно случайно есть программа iA Writer, там списки рабоают почти правильно. Т.е. можно выделять/копировать/удалять маркеры так же легко, как обычный текст. Вот списки я хочу сделать так же, а bold/italic все-таки визивигом. Отдельно интересно, кто придумал конвенции вот эти, что энтер завершает список, например, или что бэкспейс склеивает элементы. Потому что это явно все друг у друга копируют, но как будто никто ни в какой момент не остановился и не подумал, зачем.

Пользовательский опыт (UX) UX — это впечатление, которое человек получает от взаимодействия с продуктом: насколько всё понятно, удобно и приятно. Чем легче пользоваться сервисом, тем охотнее клиент остаётся и возвращается. Что формирует хороший UX? Минимум действий — чем быстрее пользователь достигает цели, тем лучше Быстрая загрузка — медленные платформы отталкивают Понятный интерфейс — всё должно быть логично и не вызывать вопросов Приятное оформление — гармоничные цвета, удобочитаемые шрифты и заметные кнопки увеличивают вовлечённость Компании вроде Airbnb или Notion инвестируют в UX, потому что довольные пользователи — это не только продажи, но и повторные визиты. Фаундер | Бизнес и Стартапы

Taste, Judgment and AI Вкус — это способность распознать качество и выдающееся мастерство, даже не имея на руках явных доказательств. Способность судить — это готовность сделать выбор и взять на себя риск, связанный с ним. Именно на этих двух качествах зиждется создание по-настоящему Великих Продуктов. Вкус во многом подобен фильтру и формируется благодаря практике и умению понимать, что именно делает что-то хорошим и выдающимся. Это результат многократных повторений, позволяющий взглянуть на множество вариантов и безошибочно указать на лучший из них (особенно в ситуациях, когда понятие «лучший» не имеет однозначного определения или вообще не существует). Невозможно развить вкус, если окружать себя однообразной информацией. Разнообразие — вот то одно, что заставляет задуматься или сформировать новые взгляды(!), а возникающие при этом противоречия помогают отточить способность отличать качественное от некачественного. Потому что невозможно понять, чего именно "чего-то не хватает", если никогда этого не видел, поэтому, чтобы развить подлинный вкус, нужно постоянно сталкиваться с неожиданным. Вкус важен, но из него сразу же вытекает следующий необходимый этап — способность судить Способность судить — это готовность поставить своё имя под принятым решением и нести за него ответственность. Это умение сделать взвешенный выбор в пользу того или иного решения по продукту, пойти на неизбежные компромиссы и суметь объяснить и отстоять своё решение, если что-то пойдет не так. Истинная способность судить проявляется только тогда, когда нужно выбрать тот-самый-верный-вариант именно при условии неизбежной ответственности. Вкус можно позаимствовать, скопировать, перенять у других, или подсмотреть. Сделать всё это с способностью судить невозможно, ведь принимать решения, значит связывать своё имя с его последствиями. Вспомните ощущения, когда вы одобряете релиз, зная, что тесты оставляют желать лучшего. Или когда выпускаете новый интерфейс в спешке, не проработав достаточное количество вариантов... Знакомые чувства?

Ошибка целеполагания В определении ошибки, что результат не совпадает с целью кроется философский вопрос. Может ли ошибка быть на уровне целеполагания? Мы решили сварить кофе, мы сварили кофе, но выяснилось, что мы хотели чай. Компания хотела добиться 10% роста, выхода на новый рынок или чего еще — но не получилось. Это ошибка или неудача компании или на этом рынке добиться 10% невозможно. Мы можем сколь-угодно хотеть стать самыми быстрыми бегунами, но если мы не станем — это наша ошибка или это изначально неправильная постановка цели? В СМАРТе одно из свойств цели — это достижимость. Однако, мало кто может сказать, достижима эта цель вообще или нет. С другой стороны, эволюционная цель, как ее ставят некоторые методологи, это цель, которую нельзя достичь. К ней можно лишь приближаться — и цель определяется как направление движения. Про эту особенность ошибки можно говорить достаточно долго. Мои размышления на этот счет можно свести к следующему: 1. неправильные цели могут быть. Они могут быть неправильными по направлению, по размеру, по скорости и т.д. и т.п. 2. самая большая ошибка в целеполагании — это не менять цель, когда мы поняли, что цель не правильная и/или недостижимая. #ЧФ #ошибки

Помните Ferrari Luce - первый электрокар Феррари, дизайн для которого делали вместе с Джони Айвом? В мае её показали, и тут же огребли цунами хейта. Акции Ferrari даже просели на 6-8% (хотя через неделю отскочили обратно), а экс-глава компании Лука ди Монтедземоло публично заявил, что с машины стоит снять лошадь - мол, не достойна она великого шильдика. Многие СМИ и тг-каналы тогда тоже активно мерились сарказмом. Я решил ничего не писать сразу - захотелось сначала посмотреть на продажи. И вот результат: весь план на 2026 год (порядка 500 машин) распродали за два месяца, задолго до первой поставки хоть одному клиенту. Тут велик соблазн сделать понятный (но неверный) вывод а-ля "любой пиар - хороший пиар". Но реальность чуть сложнее. Скорее, это идеальный кейс, когда хейт и правда раздувает продажи - но только потому, что хейтят и покупают совершенно разные люди. Кто хейтил Luce? Либо коллекционеры-пуристы, вроде известного автоэнтузиаста Джеффри Ченга, который прямо назвал тачку "мерзостью". Либо обычные смертные, которым до Феррари (вообще любой) как до Луны в известной позе. Ни в тех, ни в других Феррари этой тачкой не целился. А вот продвинутые китайцы и эйай-техно-бро из Долины смели весь предзаказ Luce как горячие пирожки. Китайская квота (88 машин) ушла почти мгновенно - и это при том, что местный BYD Yangwang и быстрее, и вдвое дешевле. Для обеих этих сегментов любой ДВС выглядит как говно мамонта из пещеры, электротяга = дефолт. А для состоятельных китайцев это ещё и способ понт 80 левела относительно малой кровью: обычную Феррари многие бы не потянули, а вот электричку за 4 млн юаней (примерно $500К - столько стоила Luce) - вполне. Гендир Феррари Бенедетто Винья на звонке с инвесторами сказал, что не менял бы в этом запуске вообще ничего, настолько всё хорошо прошло. Так вот, вывод. Не любой пиар хорош - вспомните Jaguar, который реально выкатил нейрослоповое клоунское ведро. Но хейт-фильтр действительно работает. Однако, только если хейтеры и реальные покупатели не только не пересекаются, но ещё и максимально хотят не быть похожими друг на друга. Affluent-китайцы и техно-стартаперы из Долины хотят разом отстроиться и от унылых олдмани-дедушек с их "это не настоящий Феррари", и от плебса на BYD, Тойотах и Фордах. Ну вот, Ferrari дала им такую возможность и выполнила годовой план за 2 месяца. Перфетто. Дизраптор

Всем привет! 👋 С пятницей... 🥳 Начинаем чтение 📚 с проработкой книги "Не усложняй! Управление проектами по методу P3.express". Сегодня знакомимся с оглавлением, введением, заключением. Пытаемся понять общую идею. Поехали...

Оглавление я, кстати, не нашёл. 😅 Может это прикол электронной версии этой книги? Кто читает или читал бумажную подскажите есть ли у вас оглавление?

Из изучения остального какие выводы я сделал... 1. Книга свежая, новьё, 2026 год. 2. Сам метод тоже молодой, но уже успел получить опробацию на практике, в том числе на наших просторах. 3. Автор практик с большим опытом преподавания, плюс подтвердил свои навыки и знания сертификацией. Что внушает доверие. 4. Сам метод рассчитан на то, чтобы любой желающий мог ознакомиться, разобраться и начать применять. Краткий итог... Желание прочитать у меня только увеличилось. Дальше больше... #P3_express@SYNC_club