Product design debt versus Technical debt at andrewchen
Статья Andrew Chen проводит параллель между техническим долгом и дизайн-долгом продукта. Инкрементальный подход к разработке — agile, A/B-тестирование, MVP — неизбежно порождает не только технический долг в коде, но и накопление хаотичных элементов в интерфейсе: лишних вкладок, кнопок и ссылок. Классический пример — вкладки Amazon, которые пришлось полностью переработать, а MySpace так и не расплатился со своим дизайн-долгом, что привело к потере трафика. Автор сравнивает загромождённые домашние страницы с визуальным хаосом Лас-Вегаса и объясняет это «трагедией общин»: каждая команда добавляет своё, разрушая общую эстетику. Наиболее уязвимы продукты с множеством функций — соцсети, порталы, игры, ритейл и классифайды. Facebook приводится как положительный пример: компания решилась на глобальный рефакторинг, превратив всё в единую ленту новостей и убрав лишние элементы навигации.
Вкладки Amazon — классический пример дизайн-долга продукта и процесса рефакторинга для его погашения
Инкрементализм создаёт технический долг, а также дизайн-долг продукта Большинство стартапов сегодня строят продукты, используя различные философии agile — как в формальном смысле, так и в виде неформальных принципов вроде «выпускай рано и часто», «ошибайся быстро», «выпусти и итерируй» и т. д. В сочетании с A/B-тестированием, customer development и научным, гипотезо-ориентированным подходом к бизнес-задачам вы получаете мощный коктейль методик для построения современного стартапа максимально итеративным способом. Такой инкрементализм по большей части прекрасен, и людям в целом стоит практиковать его больше.
Интересное начинается, когда вы проходите пару месяцев продуктового цикла. Часто вы обнаруживаете кучу незавершённых экспериментов, инфраструктуру, не рассчитанную на масштабирование, и мешанину кода, который нуждается в рефакторинге. Большинство инженеров знают, что в таких случаях лучшая практика — НЕ переписывать код, а постоянно рефакторить его и держать так называемый «технический долг» под контролем.
Однако есть и обратная сторона медали — дизайн продукта. После того как вы добавили кучу новых фич и разместили их все на главной странице, возникает дизайн-долг продукта. Вкладки Amazon наверху — отличный пример: у вас есть дизайн-философия, построенная вокруг вкладок, вы масштабируете её насколько возможно, а затем вам приходится рефакторить дизайн.
Можно утверждать, что MySpace — это компания, которая так и не погасила свой дизайн-долг продукта, и её трафик пострадал в результате.
В общем, давайте углубимся в эту тему, начав с технического долга.
Технический долг Большинство моих читателей, вероятно, знакомы с концепцией технического долга, но позвольте кратко пересказать суть из этой отличной статьи на эту тему:
Первый вид технического долга — тот, что возникает непреднамеренно. Например, архитектурный подход оказывается подверженным ошибкам, или начинающий программист просто пишет плохой код. Этот технический долг — нестратегический результат плохой работы. В некоторых случаях такой долг может накапливаться незаметно, например, ваша компания может приобрести другую компанию, которая накопила значительный технический долг, который вы обнаружите лишь после поглощения. Иногда, по иронии судьбы, этот долг может возникать, когда команда спотыкается в попытках переписать платформу, обременённую долгом, и непреднамеренно создаёт ещё больше долга. Назовём эту общую категорию долгом Типа I. Второй вид технического долга — тот, что создаётся намеренно. Обычно это происходит, когда организация сознательно решает оптимизировать настоящее в ущерб будущему. «Если мы не выпустим этот релиз вовремя, следующего релиза не будет» — распространённый рефрен, и зачастую весьма убедительный. Это приводит к решениям вроде: «У нас нет времени объединять эти две базы данных, поэтому напишем промежуточный код для их синхронизации, а объединим после релиза». Или: «У нас есть код от подрядчика, не соответствующий нашим стандартам; приведём его в порядок позже». Или: «Мы не успели написать юнит-тесты для кода за последние 2 месяца проекта. Напишем эти тесты после релиза». (Назовём это Типом II.)
Разумеется, нас больше интересует второй тип. У Eric Ries есть отличная статья о том, почему нормально принять технический долг. Ещё одна прекрасная статья — от Joel on Software под названием Duct Tape Programmer. Все эти статьи стоит прочитать.
Я не буду подробно останавливаться на определении, поскольку другие статьи прекрасно справляются с этим — вместо этого считаю важным поговорить о том, почему итеративный подход склонен порождать технический долг. Это происходит не всегда, но соблазн возникает постоянно.
В конечном счёте проблема в том, что если вы пытаетесь узнать что-то о бизнесе, а технология лишь поддерживает этот эксперимент, в 99% случаев не стоит делать всё «правильно». Причина в том, что вы не знаете, сработает ли что-то, и поэтому не хотите вкладываться в масштабирование или перетряхивать всю кодовую базу ради чего-то, что может оказаться одноразовым. Поэтому вы просто выкатываете 10%- или 25%-версию продукта (теперь это принято называть Minimum Viable Product) и пишете как можно меньше кода для этого.
Проблема в том, что когда фича оказывается успешной, команда крайне редко возвращается и переписывает её — каждый эксперимент порождает новые вопросы, и соблазн состоит в том, чтобы перейти к следующему вопросу.
Дизайн-долг продукта Схожая проблема — дизайн-долг продукта, который влияет на пользовательский опыт, а не на базовую технологию. Те же соблазны, что ведут к техническому долгу, ведут и к дизайн-долгу продукта, потому что делать всё «правильно» всегда сложнее, и это почти никогда не является рациональным вложением ресурсов. Покажите мне сайт с великолепным визуальным дизайном, и я гарантирую, что они не проводят A/B-тестирование.
Дизайн-долг продукта возникает из-за сценариев вроде следующих:
«Я хочу протестировать эту новую фичу, куда бы её поставить? Может, во вкладки?» «Можно мы закинем этот эксперимент на главную и посмотрим, кликают ли люди?» «Наша навигация уже немного выходит из-под контроля, но если мы её переделаем, большинство разделов сайта потеряют кучу трафика» «Мы только что добавили функцию Списков и хотим её продвинуть — можно просто добавить кнопку рядом с именем каждого пользователя?» «Yahoo только что купил наш стартап, и они собираются разместить нас на своей главной странице!»
(последнее — шутка)
Суть в том, что по мере углубления продуктового опыта в какой-то момент изначальная дизайн-философия — просто добавлять больше ссылок на страницу, больше вкладок или больше кнопок — перестаёт масштабироваться. Но реорганизовать весь сайт часто сложно, особенно если это означает краткосрочное падение трафика, поэтому «безопасным» решением становится постепенное добавление элементов, пока пользовательский опыт не становится ужасным.
Отдельное уважение Facebook за то, что они посмотрели на свой продукт и решили, что нужно сначала рефакторить всё в единый поток новостей из «всякого», а затем все свои функции — в универсальный контейнер приложений. Они также проделали большую работу по фактическому удалению пунктов из меню и навигации.
Почему главные страницы превращаются в визуальный Лас-Вегас Инкрементально разрабатываемые интерфейсы, которые никогда не рефакторятся, со временем часто превращаются в визуальный Лас-Вегас. Ну знаете, что-то похожее на это:
Почему Вегас выглядит именно так? Я бы предположил, что все эти здания в конечном счёте посягают на общественное благо эстетики, и световое загрязнение становится трагедией общин. Если бы все эти здания погасили свет, возможно, относительное распределение бизнеса осталось бы прежним, но мы никогда этого не узнаем, потому что этого никогда не произойдёт :-)
Важные навигационные зоны — главные страницы, входящие, уведомления и т. д. — устроены точно так же. Каждый дополнительный пункт меню — не такое уж большое дело, он даёт много пользы дальше по воронке, но вносит небольшую инкрементальную стоимость. Но если делать это достаточно часто, вы начнёте загрязнять общую дизайн-эстетику, которая является общественным благом, разделяемым всеми функциями.
Для стартапов это не должно быть большой проблемой, потому что у вас должен быть продуктовый менеджер, который управляет всем опытом и может решить проблему общественного блага. Но есть опасность в культурах стартапов «снизу вверх», где любой может запустить A/B-эксперимент, что, с одной стороны, прекрасно, а с другой — создаёт UX-загрязнение. Другой класс культур, где это становится проблемой, — культуры, оптимизирующие под краткосрочные результаты, где может быть «фича недели!», на которой хотят сфокусироваться и которую нужно преувеличивать каждую неделю.
Для зрелых компаний с несколькими командами, конкурирующими друг с другом, это может стать ключевой проблемой, потому что тогда это действительно превращается в общественное благо внутри компании.
Типы продуктов, наиболее подверженные дизайн-долгу В конечном счёте, я считаю, что продуктовые опыты, предлагающие миллион мелких функций, — именно те, которым стоит быть начеку.
А именно:
Социальные сети и сообщества, которые хотят объединить чат, форумы, опросы, видео, блоги и т. д. Порталы, которые хотят объединить новости, коммуникации, инструменты и т. д. Игры, которые хотят объединить множество разных миссий, коммуникацию, персонажей, монетизационные активности Ритейл-продукты, которые хотят объединить множество товарных категорий и SKU Сайты объявлений, которые хотят продавать множество различных услуг, товаров, людей и т. д.
Все перечисленные продукты сложны в дизайне, потому что они по своей природе должны быть открытыми и поддерживать множество разнообразных активностей, но постоянный рефакторинг интерфейса становится настоятельной необходимостью, поскольку начальные навигационные парадигмы, скорее всего, не будут масштабироваться.
Некоторое время назад я написал статью конкретно о социальных сообществах под названием Social Design Explosion.
Идеи о том, когда и как погашать дизайн-долг продукта? Предпринимателям, которые создают продукты на основе метрик, но при этом привержены отличному пользовательскому опыту, — буду рад услышать, когда и как вы погашаете дизайн-долг продукта. Пишите в комментариях!
Хотите ещё?Если вам понравился этот пост, подпишитесь или следите за мной в Twitter. Вы также можете найти больше эссе здесь.
Я выпускаю качественную еженедельную рассылку о том, что происходит в Кремниевой долине, с фокусом на стартапы, маркетинг и мобильные технологии.
Мнения, выраженные в «контенте» (включая посты, подкасты, видео), размещённом на этом сайте или опубликованном в социальных сетях и на других платформах (совокупно — «каналы распространения контента»), являются моими собственными и не отражают позицию AH Capital Management, L.L.C. («a16z») или её аффилированных лиц. AH Capital Management является инвестиционным консультантом, зарегистрированным в Комиссии по ценным бумагам и биржам. Регистрация в качестве инвестиционного консультанта не подразумевает особых навыков или подготовки. Публикации не адресованы каким-либо инвесторам или потенциальным инвесторам и не являются предложением о продаже или приглашением к покупке каких-либо ценных бумаг и не могут использоваться или служить основой для оценки достоинств какой-либо инвестиции.
Содержание не следует рассматривать или использовать в качестве инвестиционных, юридических, налоговых или иных рекомендаций. Вам следует консультироваться с собственными советниками по юридическим, деловым, налоговым и другим вопросам, связанным с любыми инвестициями. Любые прогнозы, оценки, предположения, цели, перспективы и/или мнения, выраженные в этих материалах, могут быть изменены без предварительного уведомления и могут отличаться или противоречить мнениям, выраженным другими лицами. Любые графики, представленные здесь, предназначены исключительно для информационных целей и не должны служить основой для принятия инвестиционных решений. Определённая информация, содержащаяся здесь, получена из сторонних источников. Хотя она взята из источников, считающихся надёжными, я не проводил независимую проверку такой информации и не делаю заявлений относительно её долгосрочной точности или уместности для конкретной ситуации. Содержание актуально только на указанную дату.
Ни при каких обстоятельствах публикации или иная информация, представленная на этом сайте — или в связанных каналах распространения контента — не должна рассматриваться как предложение о покупке или продаже какой-либо ценной бумаги или доли в каком-либо объединённом инвестиционном фонде, спонсируемом, обсуждаемом или упоминаемом сотрудниками a16z. Также это не следует рассматривать как предложение о предоставлении услуг инвестиционного консультирования; предложение об инвестировании в управляемый a16z объединённый инвестиционный фонд будет сделано отдельно и только посредством конфиденциальных документов предложения конкретных объединённых инвестиционных фондов — которые следует прочитать полностью и только тем, кто, среди прочих требований, соответствует определённым квалификациям в соответствии с федеральным законодательством о ценных бумагах. Такие инвесторы, определяемые как аккредитованные инвесторы и квалифицированные покупатели, как правило, считаются способными оценить достоинства и риски предполагаемых инвестиций и финансовых вопросов. Не может быть гарантий, что инвестиционные цели a16z будут достигнуты или что инвестиционные стратегии окажутся успешными. Любые инвестиции в фонд, управляемый a16z, сопряжены с высокой степенью риска, включая риск потери всей инвестированной суммы. Любые упомянутые, указанные или описанные инвестиции или портфельные компании не являются репрезентативными для всех инвестиций в фонды, управляемые a16z, и не может быть гарантий, что инвестиции будут прибыльными или что другие инвестиции, сделанные в будущем, будут иметь аналогичные характеристики или результаты. Список инвестиций, сделанных фондами под управлением a16z, доступен по адресу https://a16z.com/investments/. Из этого списка исключены инвестиции, для которых эмитент не предоставил разрешение a16z на публичное раскрытие, а также неанонсированные инвестиции в публично торгуемые цифровые активы. Прошлые результаты инвестиций Andreessen Horowitz, объединённых инвестиционных фондов или инвестиционных стратегий не обязательно свидетельствуют о будущих результатах. Пожалуйста, посетите https://a16z.com/disclosures для получения дополнительной важной информации.
Об авторе
Andrew Chen — партнёр в Andreessen Horowitz, где он инвестирует в игры, AR/VR, метавселенную и потребительские технологические стартапы. Он автор книги The Cold Start Problem о запуске и росте стартапов через сетевые эффекты. Проживает в Венис, Калифорния (подробнее)