Давайте разбираться. И копнём аж до начала прошлого века.

Исторический контекст

Gantt, 1910-1918

Когда ещё не было даже намёков на современный проджект-менеджмент, инженер Генри Гантт впервые рисует «Gantt charts» для Baltimore & Ohio RR и корабельных верфей. Простейшие полоски-задачи + календарная шкала оказываются чудом наглядности. Минобороны США нанимает Гантта, чтобы распланировать переброску корпуса во Францию. Так больше века назад рождаются первые серьёзные инструменты для управления проектами.

Brand Man, 1931

Спустя больше десяти лет Нил Макэлрой в Procter & Gamble требует выделить отдельную позицию «brand men», отвечающую за прибыль конкретного мыла, которым торговала компания. Именно этот шаг принято считать зарождением продакт-менеджмента (хотя в тот момент это была история больше про бренд, чем про продукт в его современном смысле).

Lean, 1940+

В 1940х Тайити Оно и инженеры Toyota собрали конвейер, который тянет детали «под заказ» вместо того, чтобы гнать их на склад: принцип Just-in-Time стал ядром Toyota Production System (TPS). Философия свелась к борьбе с любым «мусором» — лишними операциями, запасами, дефектами и простоями — и к непрерывному улучшению (кайдзен).

К 1978ому TPS оформилась в книгу Оно, а западный менеджмент получил словарь Lean и идею, что скорость достигается не сокращением сроков, а плавным потоком ценности.

CPM, 1957

Инженер Морган Уокер (DuPont) и математик Джеймс Келли (Remington Rand Univac) за два с небольшим года собирают алгоритм Critical Path Method: вычисляем цепочку задач с нулевым запасом, накладываем на неё график — и видим, где сгорают деньги. Первый пилот прошёл в DuPont летом 1957го, технология мгновенно улетела в строительство и оборонку.

PERT, 1958+

ВМС США (да-да, снова оборонка), разрабатывая ракету Polaris, создаёт PERT — предка большинства инструментов проектного управления. Program Evaluation and Review Technique (метод оценки и анализа программ) помогал определить последовательность задач, оценить время выполнения каждой и построить критический путь проекта. Родившееся как решение для военпрома, очень скоро PERT (как и CPM) перекочевали в строительные компании, где также требовалась чёткая и единая методология планирования.

PMI, 1969+

Пятеро энтузиастов регистрируют Project Management Institute в Пенсильвании. Спустя некоторое время им ещё предстоит формализовать профессию Project Manager (PjM), но тогда PMI только зарождается. Активную работу над стандартами они начнут позже, в 80ых. А уже в 1996ом выпустят первое издание PMBOK Guide и формально кристаллизуют те самые 9 (на тот момент) областей знаний.

Program Manager, 1984

В команде MS Excel появляется первая должность Program Manager (Джейб Блументаль): человек пишет 300-страничную спеку, общается с юзерами, торгуется с девелоперами и по сути владеет «что и зачем» продукта, оставляя «как» инженерам. Такой PM сидит в «триаде» вместе с Dev & Test и гонит фичи короткими релизами.

Почти оновременно Microsoft выпускает Microsoft Project 1.0 — дешёвый Gantt-конкурент для PC, который быстро приучает менеджеров к сетевому плану и критическому пути. Шаблон «Program Manager + внутренняя тулза для графиков» разлетится по всей индустрии и станет базой для современных Product/Program Management.

CMM, 1988+

Уортс Хамфри, ветеран IBM (в которой гигантские мэйнфрейм-проекты требовали железной дисциплины) оформляет свои наработки в идею Capability Maturity Model — пятиступенчатую «лестницу зрелости» процессов, родившую моду на метрики, peer-review и PM-офисы. Параллельно корпорация активно внедряет Integrated Product Development и к середине 1990-х уже учит тысячи инженеров единому языку рисков и базовых KPI проекта.

Итог: если Microsoft сделал PM «хозяином продукта», то IBM закрепила за PM роль «сторожа процесса и качества», а их сочетание и сформировало то самое гибридное понимание Project/Product/Program Management, которым мы с вами пользуемся сегодня.

Scrum, 1993+

В 1995ом на конференции OOPSLA Джефф Сазерленд и Кен Швабер презентуют Scrum. В нём закрепляются роли Scrum Master и Product Owner.

Это не «дата рождения» скрама, скорее дата его первой формализации. До этого он уже жил в коридорах Easel Corporation: Сазерленд, Скумниоталес и МакКенна за несколько лет до этого докрутили идеи Такаути и Нонаки, собрали первую скрам-команду и начали итеративно выпускать программные тулзы.

Стоит отметить, что роль Product Owner в оригинальном Scrum была скорее про ответственность за ценность продукта, чем за детальный бэклог, как это часто понимают сегодня.

Agile, 2001

Cемнадцать практиков (Кент Бек, Мартин Фаулер, Джим Хайсмит и другие), устав от тяжеловесных процессов в их компаниях, заперлись в лыжном домике в Юте. В результате такого заточения родился Agile Manifesto: четыре коротких ценности (люди и взаимодействия, работающий софт, сотрудничество с заказчиком, готовность к изменениям) и двенадцать принципов. Ключевая мысль: лучше непрерывно доставлять маленькие порции ценности и общаться вживую, чем тонуть в документах, планах и контрактах.

Манифест мгновенно поколебал иерархию «Project Manager — процесс — документация». Команды получили моральное право ставить ценность продукта выше сроков, а менеджеры — экспериментировать с ролями PM, PO, PjM.

Именно после Agile Manifesto взлетели Scrum-гайды, Kanban-доски и подходы Discovery/Delivery: теперь задача менеджера была в том, чтобы убрать препятствия и помочь команде быстро учиться на фидбэке, а не просто «выполнить план по Гантту».

Kanban, 2004-2007

Картонные канбан-карточки, которыми Toyota в 1950х синхронизировала поставки, в 2004ом перенёс в софт-разработку Дэвид Андерсон. Канбан-доска с колонками «To Do — Doing — Done» и жёстким лимитом параллельных задач дала командам прозрачный поток без ломки оргструктуры.

С 2007го метод разлетелся по Agile-сообществу: сроки и риски теперь выводят из статистики цикла, а роль проджекта смещается к Flow/Delivery Manager, который охраняет WIP-лимиты и lead-time. В итоге Kanban стал легковесной альтернативой спринтам и вписался даже в ML-пайплайны, где важнее стабильный поток, чем фиксированные итерации.

Inspired, 2008-2018

Но на этом история не заканчивается. В конце десятых Марти Каган публикует культовую книгу «Inspired». В ней Product Manager сравнивается с «мини-CEO» продукта и ставится выше Product Owner’а. Тысячи пятых точек мгновенно воспламеняются — и этого огня хватает, чтобы осветить путь нового подхода в Долине. Да так мощно, что переиздание выходит аж через 10 лет после первой версии книги.

SAFe, 2011

Организация Scaled Agile формализует фреймворк SAFe, где Product Manager управляет общим бэклогом, а PO — бэклогом команды. SAFe создаётся как альтернатива классическому скраму с его гиперсамостоятельностью отдельных команд и призван выстраивать и поддерживать зависимости в кросс-командных или кросс-платформенных продуктах.

AI & Data PM, 2020+

Появляются специализации AI Product Manager и Data Product Manager, акцентирующие владение данными, ML-моделями и этичной эксплуатацией искусственного интеллекта. Потихоньку они начинают вносить коррективы в устоявшиеся роли — и об этом мы тоже поговорим позже.

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

Пять школ управленческого Дао

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

Silicon Valley

В стартапах Кремниевой Долины PM задаёт стратегию, а PO её реализуют. Тут во всей красе расцветают идеи Кагана. Логика проста: рынок быстрый, а для быстрого рынка нужна единая визия (чтобы внутренние и связанные продукты не разорвало, как того хомячка от капли никотина).

PM: Формирует продуктовую стратегию и roadmap, основываясь на рынке и данных пользователей. Проводит discovery, определяет метрики и координирует нескольких PO. Решает, какие фичи войдут в продукт, а какие на помойку. Влияет на бюджет (но не управляет им).

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

PjM: Редко встречается, может координировать ресурсы или зависимости. Полномочия PjM здесь ограничены логистикой, в продукт он не лезет.

Чистый Scrum

Здесь PO — единственный владелец ценности внутри команды, мать, отец и мотивационная морковка. PM (если он вообще есть) остаётся вне проектных процессов. В скраме основная ставка на автономность и скорость.

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

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

PjM: Отсутствует, его функции выполняет Scrum Master.

SAFe

PM ведёт Agile Release Train (ART, огроменный поезд всех спринтов и зависимостей), а PO управляет одним небольшим вагончиком своей команды. Такая двухэтажная модель нужна, когда Agile раскатан на десятки людей и нужно общее PI-планирование (за которое тоже кто-то должен отвечать).

PM: Управляет program backlog (приоритизированный список фич для ART), задаёт стратегию, согласовывает её с бизнесом. Участвует в PI-планировании. Решает, какие фичи войдут в Program Increment, влияет на ресурсы.

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

PjM: Координирует зависимости между командами, следит за сроками PI. Контролирует риски и сроки, но не продуктовые решения.

PMI/Waterfall

В PMI роль Project Manager (PjM) старше всех: он отвечает за «срок-бюджет-скоуп» и регулярно докладывает заинтересованным сторонам. Продуктовые роли тут, по большей части, консультирующие.

PM: Определяет границы продукта, консультирует по требованиям, проводит исследования рынка. Влияет на требования, но подчиняется PjM.

PO: Обычно отсутствует или уточняет требования как аналитик.

PjM: Планирует этапы, распределяет ресурсы, контролирует риски, отчитывается перед steering committee.

FMCG

Компании типа Fast Moving Consumer Goods исторически больше про офлайн, поэтому PM здесь — владелец P&L (бабла, по факту) и бренда. PO часто отсутствует или входит в digital-подразделения как Digital PM, ведь основное IT-направление в таких компаниях — маркетинговое.

PM: Отвечает за стратегию бренда, маркетинг, ценообразование. В digital управляет цифровыми продуктами (например, loyalty apps или e-commerce). Шарит за стратегию, бюджеты и приоритеты digital-продуктов.

PO: Детализирует бэклог для цифровых продуктов, работает с командами разработки. Приоритизирует задачи digital-продукта в рамках стратегии PM.

PjM: Управляет проектами (например, запуск кампаний), координирует ресурсы. Контролирует сроки, но не стратегию.

Не всё так просто

Как я уже писал, роли миксуются. Где-то это осознанное решение, продиктованное продуктовыми, рыночными и бизнес-реалиями. А где-то PO и PM перепутаны просто по тупости и незнанию. Вот вам парочка примеров, когда классические подходы работают не совсем так, как были задуманы:

• Когда у вас двойной трек discovery & delivery, то даже при связке «PM выше PO» стратегия и тактика бегут параллельно. PM генерит гипотезы, PO быстро проверяет их с командой и говорят PM, куда генерить дальше.
• Матричные компании типа SAP или Siemens часто держат PM и PjM на одном уровне, решая спорные вопросы коллегиально. Это заложено в саму суть их оргструктуры.
• В банках, фарме и подобных направлениях регуляция и специфика отрасли толкает PjM наверх даже при Agile: сроки релизов настолько жёстко привязаны к аудиту и сертификации, что визионерство тихонечко курит в сторонке.

Как меняют рынок AI PM & Data PM

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

Общее проникновении AI заставляет менеджеров организовывать чёткую петлю обратной связи модели: без доменной экспертизы продукта ИИ-агенты учатся крайне неффективно и не приносят столько прибыли, сколько могли бы. McKinsey в своём недавнем отчёте указали, что AI PM должны развивать навыки работы с low-code платформами и агентскими фреймворками. Без этого не получится координировать сложные AI-системы и ускорять продуктовые циклы.

Но работа с готовыми моделями ещё не всё. Нужно, чтобы кто-то курировал сквозной жизненный цикл датасета и культуру «data-as-a-product»: качество схем, метаданные, соблюдение privacy-ограничений и прочее. Так потихоньку рождается роль Data Product Manager: человека, без которого консистентность данных (и, как следствие, всего остального) фактически недостижима.

Так что если вы снова запутались, расслабьтесь: дальше будет только хуже.

Пара слов в защиту здравого смысла

Но давайте вернёмся к знакомым PO с PM и PjM. Как быть-то? Кому верить, какой школе? А никакой. Верьте реалиям бизнеса/продукта и здравому смыслу.

Считайте команды. Если у вас одна кросс-функциональная — один человек легко совместит роли PM и PO. Три-семь команд? PM ставьте на стратегию, PO — в каждую команду. Контракт с фиксированным объёмом и датой? Вам не нужны визионеры, вам нужен сильный PjM.

Давайте власть тому, кто держит метрику. Если PO отвечает за NPS, он должен иметь право отменить любой фич-реквест. Если квартальная премия PM зависит от LTV клиента, странно не давать ему на это влиять.

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

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

• PM: Шарит за экономику, стратегию, продуктовые границы и визионирует как не в себя.
• PO: Меняет приоритет без бюрократии, раскатывает релизы, выстраивает коммуникации.
• PjM: Парится о сроках и процессах, подсвечивает риски и организует всё, что ещё не организованно.

Итого

Я не рассказал про тьму аспектов. Про культурные различия (США, Европа, СНГ, Азия), про всякие LeSS, Prince2 и прочее. Но от этого суть статьи не меняется.

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

Запись PO, PM, PjM: кто такие и при чём тут мыло, ракеты и застройщики первой появилась на Павел Шерер.

Я начинал свой путь в дизайне, когда все эти ваши юиксы обитали, преимущественно, на Западе. А сииксов вообще не было. Тогда всё это называлось просто «юзабилити». Ещё живя в Саратове (не пытайтесь покинуть Саратов), я выступал за расширение этого понятия. Читал наивные лекции о том, что «пользователь пьян», был одним из евангелистов пользовательского опыта как подхода.

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

Так случилось с персонами Алана Купера (моделями типичных пользователей), картами пути клиента (CJM) и даже со скрамом.

UX сузили до интерфейсов, а CX (опыт клиента) возвели в ранг «нового короля». Меня это иногда подбешивает, и я решил немного подушнить. Теперь я буду просто давать ссылку на эту статью.

Но чтобы было понятнее, давайте разберёмся на простом примере.

Пример: бронирование билета в авиакомпании

Как все себе представляют это разграничение сейчас:

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

Если вы улучшите только UX-форму оплаты, NPS может не сдвинуться, потому что претензии к колл-центру останутся. И наоборот: идеальный CX-чеклист не спасёт, если кнопка «Оплатить» лагает.

Да, UX и CX связаны, но я считаю, что в 2025 году UX остаётся фундаментом. Давайте разберём, почему.

Почему UX главнее

UX включает в себя CX, а не наоборот. Да, всё идёт к слиянию, но это не будет «поглощением» сииксом юикса. Это либо будет что-то новое (об этом чуть ниже), либо юикс останется собой. И вот почему:

Оригинальное определение

Дон Норман ещё в девяностых определил UX как «все аспекты взаимодействия конечного пользователя с компанией, её услугами и продуктами»:

«User experience» encompasses all aspects of the end-user’s interaction with the company, its services, and its products.

«Весь» опыт — это и офлайн-доставка, и колл-центр, и вообще всё, что маркетологи потом назвали CX.

Да, Норман прямо говорит, что сейчас классический human-(user)-centered design фокусируется на «сделать интерфейс понятным» и забывает о том, как производство, утилизация и экосистема влияют на людей и планету. То есть сам термин UX за 30 лет врос в digital-нишу и утратил изначальную широту. Однако это не делает его синонимом «юзабилити» и не превращает в «расширенный UI».

Ещё раз, хронология:

• 1993 — Норман вводит UX, чтобы расширить понятие «интерфейсы».
• 2010-е — маркетинг обратно сужает UX до UI.
• 2023 — сам Норман вытаскивает понятие дальше, к humanity-centered.

То есть, если продолжать наш пример с авиакомпанией, то в последний пункт добавляются вопросы выбросов CO₂, переработки одноразового пластика в салоне, программы компенсации углеродного следа и тп. И всё это продолжает влиять на пользовательский опыт в широком его смысле.

Международный стандарт

Я не особо люблю стандарты, но ISO 9241-210:2019 явно закрепил UX как «восприятия и реакции человека, возникающие до, во время и после использования системы». Это охватывает весь опыт, включая моменты, которые CX-команды считают «своими». CX не выходит за рамки UX.

Лингвистика

Слова имеют значение:

• «User» — любой, кто взаимодействует: покупатель, партнёр, сотрудник.
• «Customer» — только тот, кто платит.

Например, в Sony Playstation Store пользователи — это и отец (который выбирает игру и покупает её), и сын (который играет). А вот клиент — только отец, потому что платит именно он. Следовательно, все CX-сценарии с платящими клиентами являются подмножеством более широкого множества UX-сценариев.

Историческое родство

Сервис-дизайн и CJM выросли из UX-исследований, чтобы захватить бэкстейдж услуги. CX появился как маркетинговый «ребрендинг» этой надстройки. Исторически CX-инструментарий вышел из UX, а не наоборот.

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

Методологическая инклюзивность

A/B‑тесты, глубинки, этнография — это всё базовый UX‑арсенал, который CX‑команды заимствуют. Обратного движения почти нет.

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

Почему кто-то считает CX важнее

Сторонники CX скажут, что он ближе к бизнес-целям: удержание клиентов, рост лояльности, увеличение выручки. Например, компании вроде Amazon фокусируются на CX, чтобы каждый контакт с клиентом, от рекламы до возврата товара, был безупречным. Это помогает растить базовые метрики, вроде LTV. CX фокусируется на эмоциональной связи с брендом, что критично для долгосрочной лояльности клиентов.

UX же, по их мнению, слишком узок и зациклен на интерфейсах. Но это не так. UX охватывает весь опыт, включая моменты, которые CX считает «своими». Да, CX кажется ближе к бизнесу, но только потому, что UX шире.

Хороший UX тоже влияет на метрики: снижает churn rate (отток пользователей) и увеличивает retention (удержание), а это напрямую влияет на выручку компании.

Маркетинг сузил восприятие UX до дизайна кнопок, а CX возвёл в ранг «стратегического подхода». На деле же хороший UX уже включает заботу о клиенте — просто без маркетингового шума.

Почему спор постепенно стихает

Nielsen Norman Group недавно отметила тренд слияния UX и CX. Компании вроде Airbnb и Spotify создают кросс-функциональные journey-команды, где исследователи, дизайнеры, продакт-менеджеры и CX-специалисты вместе отвечают за весь путь клиента — от первого знакомства с брендом до повторной покупки. Например, в Spotify такая команда может работать над «опытом первого прослушивания», синхронизируя интерфейс приложения, рекомендации и поддержку.

Эта матричная структура снимает вопрос иерархии. Важнее не спорить о терминах и бодаться за семантику, а избегать «слепых зон» между отделами. Но даже в этой парадигме UX остаётся фундаментом, потому что именно он даёт инструменты для понимания пользователей.

Что дальше?

Скорее всего, UX и CX скоро окончательно сольются, но пока важно помнить: UX — это основа, на которой строится весь опыт. Если вы хотите создать продукт, который люди полюбят, начните с UX-исследований: глубинных интервью, юзабилити-тестов, анализа поведения. Это даст фундамент, на котором CX сможет выстроить лояльность и бизнес-результаты.

Мой призыв к дизайнерам и продактам: думайте не только об интерфейсах, но и о каждом моменте, где пользователь встречается с вашим продуктом, верните термину UX его изначальный смысл. Даже если планируете идти в сторону HX.

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

Запись UX vs CX: кто кого включает первой появилась на Павел Шерер.

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

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

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

И вот в этот момент происходит выбор.

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

Но бывает и так, что проект как-то не заходит. Ты сомневаешься в его успехе, сама его плоскость тебя не увлекает… И тогда все описанные выше факторы потихоньку начинают превращаться в поводы и вовсе не браться за работу. Иногда это является действительно верным решением. Работать без мотивации — тухлое дело, 10 упущенных лет из 10.

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

Антропология страха

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

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

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

Механизмы

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

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

Кто хочет, тот ищет возможности, кто не хочет — ищет причины

Сократ

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

Абстракция и её уровни

Когда нам приходится рассеивать неопределённость, мы, как правило, делаем это очень точечно. Мы начинаем сразу проектировать детали продукта, мыслим картинками и сценариями.

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

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

При чём здесь геймификация

В свое время Ричард Алан Бартл описал модель сегментации игроков по психотипам, и отдельную роль выделил Исследователям (Explorers), которые тщательно исследуют игровой мир, его механики и тайны. В основе их поведения лежит тот же инстинкт «рассеивания тьмы». Не удивительно, что большинство тех, кто занимается аналитикой и проектированием, имеет существенный перекос в сторону именно этого психотипа. Хороший проектировщик не обретёт покоя, пока в проекте есть белые пятна.

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

Запись Антропология старта первой появилась на Павел Шерер.

Этот баттл древнее, чем гугл.

Пришло и мне время влезть в этот срач.

Япония,  7 декабря 1941

На территории стран бывшего Союза есть извечный, казалось, вопрос:  дизайн — это про что? Про продукт в целом или только про его UI, внешнее проявление? И как к дизайну относится проектирование? А может, это вообще одно и то же?

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

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

Дизайн vs Design

Начнем с того, что «design» и «дизайн» — это одно слово (я этого вскользь уже коснулся, когда рассказывал про техническое проектирование). Можно долго обмусоливать тонкости перевода, особенности развития языка и прочие теоретизирования — но к истине это нас не приблизит.

Дизайн (он же «design») призван решать конкретные проблемы и задачи. Именно этим он отличается от иллюстрирования. Дизайн комплекснен.

Возьмем пример из автопрома. Просто сравните: «иллюстрация автомобиля» и «дизайн автомобиля».

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

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

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

Википедия

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

Здесь многие останавливаются и делают преждевременный вывод, типа «ага, значит дизайн — это про внешность, но с учетом кучи требований; значит, дизайну должна предшествовать другая работа — например, проектирование».

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

Дизайн vs Терминология

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

А теперь перенесемся в IT. Кто у нас тут? UX-дизайнеры, UI-дизайнеры, UX/UI-дизайнеры. А еще технические дизайнеры (чаще называемые у нас «техническими проектировщиками» или «инженерами-проектировщиками»). И куча других дизайнеров, на выбор: IxD, CX, IA и прочие, прочие. А во главе всего этого гордо восседают продуктовые дизайнеры.

Заметили? Продукт с самого начала создается дизайнерами. Эта терминология — тот самый отголосок здравого смысла, утерянного нами за последние 30 лет. Ниже я более подробно остановлюсь на исторических причинах того мракобесия и ереси, в которых мы с вами пребываем.

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

Если частью вашего сервиса являются push-оповещения, кто будет отвечать за их присутствие в пользовательских сценариях? Правильно, UX-дизайнер. А кто будет продумывать интеграцию с инструментом рассылки этих самых пушей? Правильно, технический дизайнер (он же «системный архитектор», «инженер-проектировщик» и так далее). И по отдельности в конкретно этом случае они бесполезны: какой прок от пушей, если они пролетают «мимо» сценария использования? или чего стоит даже самый идеальный UX push-уведомлений, если он не реализуем технически?

А если мы создаем чат-бота для Telegram с собственной БД на сервере (спасибо, Вадим, за идею), нужен ли вообще нам будет UI как отдельная дисциплина? А если нет, то значит ли это, что и остальные дизайнеры (тот же UX) не будут задействованы? Значит ли, что отсутствие собственного интерфейса полностью убирает из нашего продукта дизайн как явление? А как же дизайн базы данных, дизайн взаимодействия?

Design vs История vs Понты

Однако есть одна область, которая не совсем укладывается в представленную сейчас мною картину. И эта область — одна из главных виновниц того, что смысл слова «design» оказался так сильно упрощен в русскоязычных странах. Речь о полиграфии. Когда рухнул не ко времени помянутый занавес, именоваться «полиграфистом» стало не круто. Еще даже хуже, чем просто «художником-оформителем». А спрос на их услуги рос не по дням: каждому новому ларьку требовался «дизайн логотипа» и собственная айдентика (по меркам того времени).

Понятие UX в то время еще только собиралось родиться даже на западе, а что уж говорить о странах, без оглядки поглощенных Ван Даммом и сникерсами. Те, кто «за бугром» назывались «designers», в распавшемся СССР успешно именовались «конструкторами». И не жужжали.

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

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

Проектирование vs Здравый Смысл

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

Проектирование, конечно, больше опирается на UX, бизнесовую и техническую составляющие: так, например, технический и UX-дизайнеры могут именоваться проектировщиками, но не перестают быть от этого дизайнерами. Как и продуктовый дизайнер, всеобъемлющим могуществом управляющий развитием проекта. Создание прототипов, проведение исследований, анализ данных, выстраивание технической архитектуры — это все проектирование.

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

Блог vs Facebook (UPD 16 мая 2018)

Сразу после публикации, в фэйсбуке возникла небольшая дискуссия, очень явно указавшая мне на «белые пятна» в посте. Отдельное спасибо Алексею Бородкину: он, как и очень многие, считает, что проектирование == дизайн. Чтобы до конца расставить точки, проясню несколько моментов.

При всем уважении к UI — он не может входить в проектирование. Да, есть цветовая дифференциация, акцентность, айдентика и прочее — но нет. Можно найти массу примеров мегапопулярных ресурсов, у которых убогий UI, но восхитительный UX (который и вытаскивает их в топ). Да, UI влияет на UX. Как и почти все, из чего только состоит сервис: от каналов привлечения до скорости загрузки страницы/экрана. Это не значит, например, что маркетинг тоже в полной мере входит в дизайн.

Проектировщик должен относиться к UI лишь на уровне «авторского надзора». Хотя никто не мешает ему совмещать эти две ипостаси.

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

Финал (UPD 14 августа 2021)

Спустя более чем три года, настало время расставить все точки по местам.

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

И куда дешевле было сначала всё досконально спроектировать, и лишь потом отдавать результат юайщику. То была эпоха серых квадратиков, схематично обозначающих картинки и блоки. Понимаете, к чему клоню?

В современном мире двигать кнопочки проще, быстрее и дешевле. И потому UX окончательно врос в UI (ну только поэтому, конечно, но это дало сильный толчок). И если вам кто-то скажет, что дизайн==проектирование, не спешите его разубеждать. Он прав. Но прав и я, который отделяет функцию от исполнителя.

Запись Дизайн vs Проектирование первой появилась на Павел Шерер.