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

Привет! Я Антон Жиянов, продакт в dadata.ru, автор «Интерфейсов без шелухи» и Oh My Py.

Пара слов о «Дадате», чтобы задать контекст. Облачный B2B, основное использование — через API, маленькая распределённая команда, несколько десятков тысяч пользователей.

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

• продукт и фичи
• B2B и кровавый энтерпрайз
• API и документация
• техподдержка
• разработка
• интерфейс
• люди

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

Продукт и фичи

У меня скорее смешанное отношение к новым фичам. Конечно, люблю бизнес-фичи, которые увеличивают прибыль и охват. Они такие вкусные, ммм.

Легко и приятно делать всякую мелкую полезную фигню. Доработать слегка демку, сделать понятнее что-нибудь в личном кабинете, добавить красивую страницу для ошибки.

Радостно уменьшать хаос и увеличивать порядок в продукте. Упорядочить документацию, сделать нормальное сравнение тарифов, поменять формулировки в интерфейсе, которые всех путают.

Весело пилить performance-фичи. Тут достаточно намекнуть разработчику и подождать, пока он всё отлично сделает. А потом ходишь надутый от гордости и всем рассказываешь, как МЫ увеличили скорость в два раза. Разве не ради этого мы стали продактами, друзья?

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

Категорически не годится брать в работу непрофильную муть, которая размывает фокус продукта. «Мы же обрабатываем адреса для интернет-магазинов, так давайте заодно агрегатор доставки сделаем». Ну уж нет.

Но ничто не сравнится с удовольствием УНИЧТОЖАТЬ старые фичи. Например, у нас была регистрация через соцсети с дополнительным экраном в конце. С каким удовольствием я его выпилил!

Как издеваться над фичами

Собирательство фич

Типичная проблема продакта: начали делать фичу, она не зашла, а бросить жалко (и «а вдруг взлетит»). Так и тащат за собой недостроенную звезду смерти.

«Собирательству» фич подвержены даже лучшие из нас. Первые версии iOS были логичными и выверенными до мелочей. Сейчас айось — это какой-то безумный игровой автомат: куда не ткни случайно, отовсюду что-то выезжает и выскакивает.

Другая западня — добавить фичу, потому что потенциальный клиент говорит «добавьте, и тогда я куплю». Ага, конечно. Я вообще считаю, что к мнению неплатящих пользователей стоит относиться ооочень скептически.

Спецификации

Поскольку люди в отрасли не могут жить спокойно, каждые три года они придумывают новую концепцию. Персоны, юзкейсы, юзер стори, джоб стори, CJM, whatever. Всё это лирика.

Реально важно одно:

Для каждой фичи или сценария понимать, кто потребитель и зачем это ему.

Выясняется серией вопросов постановщику задачи.

Кто и зачем — это важно. Конкретная методика — карго-культ.

Бодрость и свежий взгляд

Главная проблема «долгоживущих» продакт-менеджеров и вообще любых сотрудников: со временем у человека замыливается глаз. Команда перестаёт видеть очевидные извне проблемы продукта и упускает возможности.

Знаю один сервис, где нельзя зарегистрировать двух пользователей с одинаковым именем (то есть не может быть две «Анны», например). Основатель мне на полном серьёзе объяснял, что это фича и так и должно быть.

Хотя со стороны очевидно, что это полная дичь.

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

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

B2B и кровавый энтерпрайз

Делать продукты для бизнеса одно удовольствие! Люди настолько привыкли к плохим продуктам и плохому сервису, что когда вы делаете хорошо — работает как вау-фактор.

B2C в этом смысле труднее, потому что там у людей завышенные ожидания. А в B2B — наоборот, заниженные. Хотя и в B2C плохих продуктов хватает. Особенно плохо с саппортом — обычно он предельно механистичный и бездушный, и чем крупнее сервис, тем хуже.

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

B2B тоже бывает очень разный. Есть low-touch sales, когда сайт продаёт сам, без сейлов, только за счёт маркетинга. Это достаточно похоже на B2C, «Дадата» именно так работает.

А есть high-touch aka «кровавый энтерпрайз», где отдельные продавцы, выездные демонстрации, пресейлы, пилотные проекты и вот это всё. Это уже совсем другая история, сильно отличная от B2C.

У Страйпа есть неплохая статья о разновидностях B2B.

Счета и акты

Самое «весёлое» в российском B2B — это документооборот, так же известный как «счета и акты». Если вы прискакали из мира мобилок на розовом пони, эта штука срежет вас как наточенный серп.

Бухгалтеры через одного не умеют платить без счёта (хотя вообще-то прекрасно можно жить без него). Сначала мы пытались бороться и объяснять, потом плюнули и подключили чудесного «Финолога».

С актами сложнее, поэтому мы честно печатали их каждый квартал, подписывали и рассылали по почте. Но с сотнями клиентов это превратилось в АД. Да ещё 20% актов теряла либо почта, либо бухгалтерия клиента.

Спас только переход на электронный документооборот (мы используем «Диадок»). Теперь электронный акт у нас бесплатный, а бумажный — только курьером за отдельные деньги. Это прям хорошо помогло.

Договор

Веселее счетов и актов может быть только ДОГОВОР! Каждый третий клиент хочет его заключить, обязательно на бумаге, с мокрой печатью и подписью директора собственной кровью.

• Как это у вас нет договора? Вы работаете по оферте? Хорошо, нам подходит. Распечатайте её, подпишите, поставьте печать и высылайте Почтой России.
• Как это оферта не требует согласования и подписания? Ну хорошо, можете не присылать бумагу, пришлите скан.
• У наших юристов нашлось 128 замечаний к вашей оферте. Можете оперативно внести исправления? Заранее спасибо.
• Ну хорошо, мы согласны работать по оферте. Давайте только сначала подпишем соглашение о работе по оферте.
• Нет, мы категорически не согласны работать по оферте, обязательно нужен договор. Сколько-сколько он стоит? Мы готовы работать по оферте.

И вот это всё продолжается в бесконечных вариациях. Доброжелательность и терпение — ваши друзья.

Тарифы и цены

Тарифные планы в B2B обычно сложные. У нас, например, есть подписка с лимитами по фичам и объёмам, и есть отдельная оплата за каждую запись, да ещё с несколькими слоями скидок. Всё это усложняет жизнь как клиентам, так и команде.

Вот хороший обзор разных ценовых моделей для облачных сервисов.

Часто B2B прячут цены. Хотя мы сделали всё прозрачно, и прекрасно зашло.

Ловушки

В B2B клиенты любят (1) требовать сроки по конкретным фичам и (2) просить индивидуальные доработки. Называть сроки — плохая идея. А индивидуальные доработки — ОЧЕНЬ плохая идея.

Мы обычно называем сроки с точностью до года 🤷 Сильно реже — до квартала. Точнее — никогда.

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

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

Кровавый энтерпрайз

Самый насупленный и серьёзный B2B — это не облако, а «коробка», которая настраивается и внедряется под специфику заказчика. Там прямо чувствуешь, как у тебя отшелушивается худи и начинает расти галстук.

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

Но лучше всего — живительные пинки здравого смысла от коллег, конечно.

Так что если вы всю жизнь в B2C и приуныли, можно попробовать коробочный B2B. Море интересных ощущений гарантирую. У меня коллега так сделал, и в результате столько добра причинил, что его просто ложками можно есть (добро, не коллегу).

API и документация

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

С другой, стороны, неудачные решение в UI легко поменять. А ошибки в API остаются на всю жизнь, и это большая боль.

Конечно, в книжках вам расскажут про версионирование API, но по факту всё обычно останавливается на второй-третьей версии, и дальше API только обрастает «мясом», постепенно теряя простоту и логичность.

Не знаю здесь универсальных рецептов. «Дадате» помогают две вещи:

1. Сначала делать как можно проще, усложнить всегда успеем
2. Писать понятную документацию (OpenAPI — НЕ понятная документация)

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

Шикарная документация у Страйпа. Посмотрите и сравните с обычной автогенерённой по OpenAPI докой. А вот как у Страйпа реализовано версионирование API «под капотом».

Очень помогает сделать по примеру на каждый популярный юзкейс. Хорошо предусмотреть популярные языки — JS, PHP, Python, C#, Java. Для этого можно использовать Postman, например — он умеет генерить код на разных языках.

Сторонние модули

Самое веселье начинается, когда сторонние компании начинают делать интеграции к вашему продукту. Например, «Дадата» интегрируется с Битриксом, amoCRM, и кучей других сервисов. Всё это — партнёрские интеграции.

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

В итоге неизбежно появляются глючные интеграции. Винят за них, естественно, вас, а не партнёра (ಠ_ಠ)

Бывают реально странные случаи. Один человек сделал модуль для нашего бесплатного сервиса. Я посмотрел, вроде всё ОК, выложил на сайт. И тут люди начинают жаловаться, что с них списывают деньги за использование модуля. Начинаю разбираться, залезаю в исходники. А там аккуратно в самом сердце модуля спрятан вызов другого нашего сервиса, уже платного. Зачем разработчик так сделал? Непонятно.

Хеппи-энда для партнёрских интеграций я не вижу. Смотрел, как дела у других крупных сервисов. Везде одно и то же: где модули пишут сторонние разработчики — там сразу проблемы. Пользовательский рейтинг немного улучшает положение, но тоже не панацея.

Инструменты

Про Postman я уже сказал — он просто маст хэв.

requestbin.fullcontact.com логирует все приходящие в него запросы. Помогает, если нужно посмотреть, в чём проблема с запросами пользователя. Ещё более мощная штука — mitmproxy

С помощью APIembed можно встроить примеры вызова API на разных языках.

Совершенно гениальная штука badssl.com — он имитирует все возможные проблемы с SSL-сертификатами и конфигурациями.

Техподдержка

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

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

Обращения в техподдержку как прожектором подсвечивают все проблемы продукта — глупо этом не пользоваться. Я до сих пор читаю все тикеты, на некоторые сам отвечаю. Бодрит невероятно, всем рекомендую.

Саппорт не только показывает проблемы, но и подсказывает новые фичи. Главное — не верить «плюсам», которые пользователи ставят при голосовании, а выяснять конкретный сценарий использования в каждом случае.

Саппорт — это ещё и невероятно увлекательно. Нигде вы не встретите столько новых людей и офигительных историй, как в техподдержке.

Например, благодаря саппорту я умею вызывать API «Дадаты» на C#, Java, JS, Python, PHP, Go, Delphi, VBScript и PL/SQL. Некоторые из этих примеров я предпочёл бы забыть.

Обратная связь

Интересно вышло с оценкой качества поддержки. Интерком начал использовать шкалу из 5 эмодзи:

😠 🙁 😐 😃 😍

Многие скопировали. А Интерком через два года заменил 😍 на 🤩 — потому что мужики отказывались ставить сердечки другим мужикам ツ

Лично я предпочитаю бинарную шкалу «понравилось / нет» + текстовый комментарий. Но все гуру поддержки такой подход категорически осуждают.

Инструменты

Самый известный, конечно, Intercom. Мы используем Userecho — он не такой проработанный в мелочах, но зато обладает ОГРОМНЫМ количеством фич.

Если продукт как-то связан с JS (у нас, например, js-виджет, который использует куча пользователей), то незаменимая штука — Codepen. Там и примеры, и воспроизведение проблем, и всё что хочешь. Намного приятнее, чем JSFiddle.

В комментариях посоветовали CodeSandbox — я пока не пробовал, но выглядит ещё круче Кодпена.

Если надо получить информацию о браузере пользователя, то https://yandex.ru/internet/ (хотя там внизу дурацкая надпись «Если вы лично не обращались в службу поддержки Яндекса, не передавайте никому данные с этой страницы»)

Если какая-то замороченная проблема, которую не получается воспроизвести на Codepen, можно попросить человека записать все запросы через Хром и прислать HAR-архив.

Разработка

Вывел для себя два правила:

1. Всегда лучше брать готовое, чем писать самим.
2. Автоматизировать процесс только после того, как отработали вручную.

Для любых «непрофильных» фич лучше использовать готовые решения. У нас это весь бэкофис, саппорт, счета и акты, платежи, метрики, админка.

Бэкофис для небольшой команды вообще прекрасно делается на гуглодоках или Airtable. Ещё интересно выглядит Retool, но в работе я его не пробовал.

Одна из главных печалек для меня — что пришлось делать собственный биллинг. Сейчас я бы наверняка взял Stripe. Из российских интересно выглядит PricePlan, но у него какая-то безумная комиссия и не видно развития.

Not invented here

Not Invented Here у продактов в России цветёт буйным цветом. Главная заповедь плохого продакта:

Лучше сами, но никогда, чем чужое, но сейчас

Реально, сколько раз сталкивался. Говоришь им «ребята, у вас с вводом адреса беда, возьмите „Дадату“ и исправьте за неделю». Отвечают «да, мы знаем, сделаем сами, уже в беклог добавили». Заходишь через два года проверить — ничего не изменилось. ЗАТО САМИ.

MVP и говнокод

Очень опасная тема. Я думаю, что говнокодить можно, только если вы 100% знаете, что код на выброс или будет полностью переписан в течение года.

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

По моим наблюдениям, нормальный модульный код с разумно организованными зависимостями и тестами подходит для 95% случаев. Оставшиеся 5%, когда можно яростно говнокодить, в реальности встречаются редко.

Интерфейс

В B2B продуктах особые красоты не требуются, достаточно аккуратного UI без явных косяков. Главное — понятность.

Часто встречаю: нарисовали красиво, а основной сценарий в интерфейсе не проработан. Вплоть до того, что баннер «СКИДКА 10%» напрочь закрывает кнопку покупки. Это провал.

Ещё беда: идиотские ограничения. Имя «Ян» ввести нельзя, слишком короткое. С емейлом info@dadata.ru регистрироваться нельзя, слишком общий. Адрес без улицы ввести нельзя — программист не знает, что существуют деревни. Тоже провал.

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

А вот как проектировать настройки.

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

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

Суперсила продакта

Напоследок пара слов о продакт-менеджерах в целом. Я думаю, что суперсила продакта — это здравый смысл. Пока всех остальных участников команды вечно заносит чёрти куда, продакт сохраняет здоровый скепсис и критическое мышление.

Поэтому я не верю в чуваков, которые думают, что голая пассионарность приведёт продукт к цели. Давайте начистоту, ребята:

Мы ни разу не Джобсы и не Маски

Наша задача — не бежать впереди толпы с горящим сердцем в руке. Наша задача — баланс.

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

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

По-настоящему хорошие продуктовые решения возможны, только когда ты погружён в предметку. Если продакт каждый год на новом проекте — это всё равно что его нет. Зачем он такой нужен?

Продакт-менеджмент, как и любой менеджмент — не универсальная дисциплина. Универсальный продакт — плохой продакт. Продакт, который нежно любит предметку — хороший, берегите его.

⌘ ⌘ ⌘

Здесь могли бы быть рекомендации книг, курсов и телеграм-каналов. Но вместо этого лучше рекомендую побольше полагаться на критическое мышление. Очень помогает отсеивать шлак и оставлять ценное — как на работе, так и по жизни.

Спасибо!

На днях Трамп оговорился, назвав Тима Кука «Tim Apple». Американские СМИ потешались над этим целый день.

А мне кажется, это отличная идея — CEO компании временно брать фамилию по названию компании.

Во-первых, это удобно: не надо запоминать фамилию, достаточно имени. Аркадий Яндекс, Герман Сбер, Татьяна Вайлдбериз, Олег Тиньков (oh wait).

Во-вторых, стартаперы начнут придумывать нормальные названия компаний: вряд ли кому-то захочется назваться «Алексей ЛидТуКол» или «Евгений Дптх».

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

А уж лояльность бренду как вырастет!

По моим наблюдениям, разработчики (и дизайнеры, в меньшей степени) очень любят запрещать. Я это называю «синдром айти-вахтёра».

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

Повторное голосование запрещено

А если нажать много раз — будет чудесная картина, которая изображена на скриншоте. Присмотритесь, у каждого сообщения есть собственный прогресс-бар обратного отсчёта. Инженерный дизайн ツ

Вопрос: Как бы вы поступили с этим сообщением?

Решение

Вот результаты голосования подписчиков:

Приятно видеть такое единодушие ツ Разберём варианты:

Всё нормально, оставлю так

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

Но всё же для пользователя сообщение бесполезно.

Переформулирую в позитив

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

Уберу текст, покажу визуально

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

Задизейблю кнопку, если уже есть голос

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

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

После голосования кнопка остаётся визуально «нажатой», чтобы человеку было понятно — голос уже отдан:

Снимать голос при повторном тыке

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

Но тут в интерфейсе два раздельных действия (плюс и минус). И снимать плюс при повторном нажатии на плюс — нелогично.

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

Питон — не исключение. Возьмём функцию, которая сравнивает дату-время с точностью до минуты:

from datetime import datetime, timezone

def equal(dt1, dt2):
  return dt1.replace(second=0, microsecond=0) == \
    dt2.replace(second=0, microsecond=0)

И сравним «сегодня» и «сейчас»:

>>> equal(datetime.today(), datetime.now())
True

Оказывается, это одно и то же ツ Метод today() возвращает не начало дня, как можно было бы ожидать, а текущий момент времени.

А что насчёт времени по UTC?

>>> equal(datetime.now(timezone.utc), datetime.utcnow())
False

Неожиданно, now() с часовым поясом UTC и utcnow() возвращают разные значения. Это потому, что now() возвращает объект с часовым поясом, а utcnow() — без. Хотя дата-время у них и совпадают.

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

Если система обрабатывает заявки, редко бывает, что все они одинакового веса. Чаще встречаются разные приоритеты: клиенты бывают обычные и VIP, баги бывают минорные и критические, заказы бывают «до 1000 ₽» и «10000+ ₽».

Если приоритетов нет, обслуживать заявки просто: кто раньше пришёл, того раньше и обслужили (first in, first out — FIFO). С приоритетами сложнее: более важные заявки должны идти вперёд, но среди заявок с одинаковым приоритетом по-прежнему должен действовать принцип FIFO.

Допустим, была у нас система без приоритетов:

from collections import deque

def process(requests):
    while requests:
        client, task = requests.pop()
        print(f"{client}: {task}")

requests = deque()
requests.appendleft(("Лукас", "нарвать бананов"))
requests.appendleft(("Зоя", "почесать спинку"))
requests.appendleft(("Френк", "насыпать зёрен"))

>>> process(requests)
Лукас: нарвать бананов
Зоя: почесать спинку
Френк: насыпать зёрен

Обработка по порядку, всё честно. А теперь допустим, что у заявки появился вес:

• → Лукас, вес 1
• → Зоя, вес 1
• → Френк, вес 10

Френк с весом 10 должен пойти первым. А Зоя и Лукас — после него, в порядке поступления: сначала Лукас, потом Зоя.

Реализовать эту логику поможет модуль heapq:

import heapq
import time
requests = []

heapq.heappush(requests,
  (-1, time.time_ns(), "Лукас"))
heapq.heappush(requests,
  (-1, time.time_ns(), "Зоя"))
heapq.heappush(requests,
  (-10, time.time_ns(), "Френк"))

Здесь первым аргументом мы передаём вес заявки. heapq.heappush() ставит первыми элементы с меньшим значением, так что берём вес со знаком минус.

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

Проверим результат:

def process(requests):
    while requests:
        _, _, client = heapq.heappop(requests)
        print(f"{client}")

>>> process(requests)
Френк
Лукас
Зоя

Порядок!

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

Если вы не ходите в спортзал по три раза в неделю. Если вы не бегаете марафоны и не стремитесь осилить Iron Man. Если вы не катаетесь на лыжах, борде, скейте, кайте, байке и самокате. Если вы не придерживаетесь диеты и бегаете по ночам к холодильнику.

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

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

То знайте — с вами всё хорошо. Плюньте в глаз тому, кто утверждает обратное.

Облачные сервисы для бизнеса обычно делают несколько тарифов с понятной ценой и один топовый в стиле «свяжитесь с нами».

У «Дадаты» тоже так было:

Не берусь судить, насколько такой подход хорош или плох в общем случае. Наверняка, у «Интеркома» и «Эйртейбла» он оправдан. Но по личному опыту в «Дадате» — от скрытого ценника одни проблемы:

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

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

Со временем нам это надоело, и теперь тарифы выглядят так:

Вопросы о цене почти полностью прекратились, а покупать меньше не стали.

⌘ ⌘ ⌘

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

Поток любопытствующих о цене коробки был нескончаемым. Каждый второй веб-мастер с виртуальным хостингом непременно хотел себе коробочную версию — пока не узнавал стоимость.

Мы решили её не скрывать:

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

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

За год после нововведения мы стали тратить меньше времени на ответы о цене, а «коробок» продали больше, чем прежде.

⌘ ⌘ ⌘

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

Но если тарифная сетка достаточно простая, зачем её скрывать? Так и вопросов меньше, и покупателям удобнее.

Сегодня новое соревнование — граждане города выбирают самое наглое животное. Результаты опроса поступили в виде неупорядоченного списка пар «количество голосов — участник»:

contenders = [
  (31, "индюк"),
  (22, "крыса"),
  (79, "кот"),
  (98, "голубь"),
  (13, "собака"),
  (95, "енот"),
  (15, "хомяк"),
]

Осталось, как обычно, выбрать трёх победителей. Как насчёт такого:

>>> sorted(contenders)[-3:]
[(79, 'кот'), (95, 'енот'), (98, 'голубь')]

Неплохо. Но, как вы помните, сортировка списка занимает O(n log n) операций. Жирновато, чтобы просто выбрать топ-3 элемента.

Вот альтернатива:

>>> import heapq
>>> heapq.nlargest(3, contenders)
[(98, 'голубь'), (95, 'енот'), (79, 'кот')]

Такой вариант использует только O(n) операций — при небольшом k (в данном случае k = 3). Для больших k вариант с sorted() эффективнее.

Ну а если k = 1 (выбираем одного победителя), то так:

>>> max(contenders)
(98, 'голубь')

Я даже знаю, как его зовут ツ

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

washington = [
    (99, "Френк"),
    (80, "Клер"),
    (73, "Зоя")
]

moscow = [
    (90, "Валера"),
    (88, "Мария"),
    (50, "Анатолий")
]

beijing = [
    (123, "Чан"),
    (109, "Пинг"),
    (70,  "Ки"),
]

Теперь ваша задача — выбрать трёх призёров. Я знаю как минимум один простой способ:

all = sorted(washington + moscow + beijing)
winners = all[-3:]

>>> winners
[(99, 'Френк'), (109, 'Пинг'), (123, 'Чан')]

Если всего n участников, такая реализация займёт 2n памяти и потребует O(n log n) операций. Довольно расточительно.

Можно сделать то же самое за константное время и память:

import heapq

all = heapq.merge(washington, moscow, beijing, reverse=True)

>>> next(all)
(123, 'Чан')

>>> next(all)
(109, 'Пинг')

>>> next(all)
(99, 'Френк')

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

P.S. Френк, всего лишь третье место. Не ожидал от тебя.

Эта статья — об одном из лучших изобретений Python: именованном кортеже (namedtuple). Мы рассмотрим его приятные особенности, от известных до неочевидных. Уровень погружения в тему будет нарастать постепенно, так что, надеюсь, каждый найдёт для себя что-то интересное. Поехали!

Введение

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

Часто создавать отдельный класс под это дело лень, и используют кортежи:

("pigeon", "Френк", 3)
("fox", "Клер", 7)
("parrot", "Питер", 1)

Для большей наглядности подойдёт именованный кортеж — collections.namedtuple:

from collections import namedtuple

Pet = namedtuple("Pet", "type name age")
frank = Pet(type="pigeon", name="Френк", age=3)

>>> frank.age
3

Это все знают ツ А вот несколько менее известных особенностей:

Быстрое изменение полей

Что делать, если одно из свойств надо изменить? Френк стареет, а кортеж-то неизменяемый. Чтобы не пересоздавать его целиком, придумали метод _replace():

>>> frank._replace(age=4)
Pet(type='pigeon', name='Френк', age=4)

А если хотите сделать всю структуру изменяемой — _asdict():

>>> frank._asdict()
OrderedDict([('type', 'pigeon'), ('name', 'Френк'), ('age', 3)])

Автоматическая замена названий

Допустим, вы импортируете данные из CSV и превращаете каждую строчку в кортеж. Названия полей взяли из заголовка CSV-файла. Но что-то идёт не так:

# headers = ("name", "age", "with")
>>> Pet = namedtuple("Pet", headers)
ValueError: Type names and field names cannot be a keyword: 'with'

# headers = ("name", "age", "name")
>>> Pet = namedtuple("Pet", headers)
ValueError: Encountered duplicate field name: 'name'

Решение — аргумент rename=True в конструкторе:

# headers = ("name", "age", "with", "color", "name", "food")
Pet = namedtuple("Pet", headers, rename=True)

>>> Pet._fields
('name', 'age', '_2', 'color', '_4', 'food')

«Неудачные» названия переименовались в соответствии с порядковыми номерами.

Значения по умолчанию

Если у кортежа куча необязательных полей, всё равно приходится каждый раз перечислять их при создании объекта:

Pet = namedtuple("Pet", "type name alt_name")

>>> Pet("pigeon", "Френк")
TypeError: __new__() missing 1 required positional argument: 'alt_name'

>>> Pet("pigeon", "Френк", None)
Pet(type='pigeon', name='Френк', alt_name=None)

Чтобы этого избежать, укажите в конструкторе аргумент defaults:

Pet = namedtuple("Pet", "type name alt_name", defaults=("нет",))

>>> Pet("pigeon", "Френк")
Pet(type='pigeon', name='Френк', alt_name='нет')

defaults присваивает умолчательные значения с хвоста. Работает в питоне 3.7+

Для старых версий можно более коряво добиться того же результата через прототип:

Pet = namedtuple("Pet", "type name alt_name")
default_pet = Pet(None, None, "нет")

>>> default_pet._replace(type="pigeon", name="Френк")
Pet(type='pigeon', name='Френк', alt_name='нет')

>>> default_pet._replace(type="fox", name="Клер")
Pet(type='fox', name='Клер', alt_name='нет')

Но с defaults, конечно, куда приятнее.

Необычайная лёгкость

Одно из преимуществ именованного кортежа — легковесность. Армия из ста тысяч голубей займёт всего 10 мегабайт:

from collections import namedtuple
import objsize  # 3rd party

Pet = namedtuple("Pet", "type name age")
frank = Pet(type="pigeon", name="Френк", age=None)

pigeons = [frank._replace(age=idx) for idx in range(100000)]

>>> round(objsize.get_deep_size(pigeons)/(1024**2), 2)
10.3

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

Так происходит, потому что обычные объекты в питоне таскают с собой увесистый дандер __dict__, в котором лежат названия и значения всех атрибутов объекта:

class PetObj:
    def __init__(self, type, name, age):
        self.type = type
        self.name = name
        self.age = age

frank_obj = PetObj(type="pigeon", name="Френк", age=3)

>>> frank_obj.__dict__
{'type': 'pigeon', 'name': 'Френк', 'age': 3}

Объекты-namedtuple же лишены этого словаря, а потому занимают меньше памяти:

frank = Pet(type="pigeon", name="Френк", age=3)

>>> frank.__dict__
AttributeError: 'Pet' object has no attribute '__dict__'

>>> objsize.get_deep_size(frank_obj)
335

>>> objsize.get_deep_size(frank)
239

Но как именованному кортежу удалось избавиться от __dict__? Читайте дальше ツ

Богатый внутренний мир

Если вы давно работаете с питоном, то наверняка знаете: легковесный объект можно создать через дандер __slots__:

class PetSlots:
    __slots__ = ("type", "name", "age")
  
    def __init__(self, type, name, age):
        self.type = type
        self.name = name
        self.age = age

frank_slots = PetSlots(type="pigeon", name="Френк", age=3)

У «слотовых» объектов нет словаря с атрибутами, поэтому они занимают мало памяти. «Френк на слотах» такой же лёгкий, как «Френк на кортеже», смотрите:

>>> objsize.get_deep_size(frank)
239

>>> objsize.get_deep_size(frank_slots)
231

Если вы решили, что namedtuple тоже использует слоты — это недалеко от истины. Как вы помните, конкретные классы-кортежи объявляются динамически:

Pet = namedtuple("Pet", "type name age")

Конструктор namedtuple применяет разную тёмную магию и генерит примерно такой класс (сильно упрощаю):

class Pet(tuple):
    __slots__ = ()
  
    type = property(operator.itemgetter(0))
    name = property(operator.itemgetter(1))
    age = property(operator.itemgetter(2))
  
    def __new__(cls, type, name, age):
        return tuple.__new__(cls, (type, name, age))

То есть наш Pet — это обычный tuple, к которому гвоздями приколотили три метода-свойства:

• type возвращает нулевой элемент кортежа
• name — первый элемент кортежа
• age — второй элемент кортежа

А __slots__ нужен только для того, чтобы объекты получились лёгкими. В результате Pet и занимает мало места, и может использоваться как обычный кортеж:

>>> frank.index("Френк")
1

>>> type, _, _ = frank
>>> type
'pigeon'

Хитро придумано, а?

Не уступает дата-классам

Раз уж мы заговорили о генерации кода. В питоне 3.7 появился убер-генератор кода, которому нет равных — дата-классы (dataclasses).

Когда впервые видишь дата-класс, хочется перейти на новую версию языка только ради него:

from dataclasses import dataclass

@dataclass
class PetData:
    type: str
    name: str
    age: int

Чудо как хорош! Но есть нюанс — он толстый:

frank_data = PetData(type="pigeon", name="Френк", age=3)

>>> objsize.get_deep_size(frank_data)
335

>>> objsize.get_deep_size(frank)
239

Дата-класс генерит обычный питонячий класс, объекты которого изнемогают под тяжестью __dict__. Так что если вы начитываете из базы вагон строк и превращаете их в объекты, дата-классы — не лучший выбор.

Но постойте, дата-класс ведь можно «заморозить», как кортеж. Может тогда он станет легче?

@dataclass(frozen=True)
class PetFrozen:
    type: str
    name: str
    age: int

frank_frozen = PetFrozen(type="pigeon", name="Френк", age=3)

>>> objsize.get_deep_size(frank_frozen)
335

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

⌘ ⌘ ⌘

Мне очень нравится именованный кортеж:

• честный iterable,
• динамическое объявление типов,
• именованный доступ к атрибутам,
• лёгкий и неизменяемый.

И при этом реализован в 150 строк кода. Что ещё надо для счастья ツ

Если хотите узнать больше о стандартной библиотеке Python — подписывайтесь на канал @ohmypy

33 комментария

У класса float есть прекрасный метод as_integer_ratio(), который представляет десятичную дробь в виде обычной — пары «числитель, знаменатель»:

>>> (0.25).as_integer_ratio()
(1, 4)

>>> (0.5).as_integer_ratio()
(1, 2)

>>> (0.75).as_integer_ratio()
(3, 4)

Так вот. Никогда им не пользуйтесь ツ Потому что:

>>> (0.2).as_integer_ratio()
(3602879701896397, 18014398509481984)

Виной всему стандарт представления дробных чисел IEEE 754, который реализует float.

Используйте Decimal:

>>> from decimal import Decimal
>>> Decimal("0.2").as_integer_ratio()
(1, 5)

Уверен, вы и так это знаете. Просто на всякий случай ツ

Допустим, вы пишете систему учёта посетителей для музея изящных искусств в Хиросиме (не спрашивайте). Одно из требований безопасников — команда tail, которая показывает трёх последних визитёров. Как её реализовать?

Конечно, можно складывать всех прибывших в список и по запросу выдавать из него последние 3 элемента:

TAIL_COUNT = 3
visitors = []

def handle(visitor):
  visitors.append(visitor)

def tail():
  return visitors[-TAIL_COUNT:]

handle("Питер")
handle("Клер")
handle("Френк")
handle("Кен Чан")
handle("Гоу Чан")

>>> visitors
['Питер', 'Клер', 'Френк', 'Кен Чан', 'Гоу Чан']

>>> tail()
['Френк', 'Кен Чан', 'Гоу Чан']

Но как-то не очень правильно хранить всех посетителей только ради того, чтобы показывать последних трёх, верно? Нам поможет collections.deque:

from collections import deque

visitors = deque(maxlen=3)

def handle(visitor):
  visitors.append(visitor)

def tail():
  return list(visitors)

handle("Питер")
handle("Клер")
handle("Френк")
handle("Кен Чан")
handle("Гоу Чан")

>>> visitors
deque(['Френк', 'Кен Чан', 'Гоу Чан'], maxlen=3)

>>> tail()
['Френк', 'Кен Чан', 'Гоу Чан']

deque (double-ended queue) хранит не более maxlen элементов, автоматически «выпихивая» старые при добавлении новых.

А ещё она добавляет элементы в начало и в конец за O(1), в отличие от списка, у которого это O(n). Идеально подходит, если коллекция часто модифицируется, а выбирать элементы по индексу не надо.

На скриншоте интерфейс управления почтовыми ящиками. В контекстном меню есть действия Empty (очистить ящик) и Delete (удалить ящик). Я постоянно их путаю, и удаляю ящики, вместо того, чтобы очистить.

Вопрос: Как минимально изменить интерфейс, чтобы уменьшить вероятность ошибки?

Решение

Вот результаты голосования подписчиков:

Я согласен с большинством — лучше убрать Delete в настройки. Удаление почтового ящика — редкая операция, ей нечего делать в контекстном меню. Empty же используется часто: это тестовая почта, ящики время от времени чистят.

Почему остальные варианты нравятся меньше:

• Переименовать, чтобы стало понятнее. Как не переименовывай, оба пункта останутся близкими по смыслу, а значит ошибки никуда не уйдут.

• Сделать Delete красным и добавить иконку. Это, скорее всего, сработает. Но визуальный акцент на редкой операции — так себе решение.

• Убрать Empty в настройки. Этот вариант я специально добавил, чтобы чуть усложнить выбор ツ Думаю, тут всё понятно.

В личку несколько раз прислали ещё один вариант:

• Добавить подтверждение на Delete. Оно там и так есть, ничуть не помогает. Подтверждения не работают, потому что для рутинных операций люди их не читают

Перенос Delete в настройки решает задачу, делает интерфейс проще и лёгок в реализации. Лучший вариант!

Сидите вы на работе и смотрите на дневную статистику по заявкам разных типов:

monday = {"question": 1, "problem": 3, "idea": 2}
tuesday = {"problem": 5, "idea": 1}
wednesday = {"question": 2, "problem": 2}

Задача — посчитать агрегированную статистику за все дни. Всё вроде понятно. Тут подходит тимлид и говорит, что если решите задачу однострочником, он подарит вам жёлтую резиновую уточку.

Устоять перед этим решительно невозможно.

Словари → счётчики

Сначала от словарей надо перейти к счётчикам. Воспользуемся для этого функцией map(). Она принимает на входе функцию и последовательность (iterable), после чего применяет функцию к каждому элементу последовательности и возвращает, что получилось. Например:

>>> mapped = map(abs, [-1, -2, -3])
>>> list(mapped)
[1, 2, 3]

abs() возвращает абсолютное значение числа, а list() тут нужен, чтобы отработал map (сам по себе он ленивый, пока не пнёшь — не полетит).

В нашем случае последовательностью будет набор дневных статистик, а функцией — конструктор счётчика:

>>> map(Counter, [monday, tuesday, wednesday])
<map object at 0x10cae2470>

map object — это итератор, который сделает из словарей счётчики, когда нам это действительно понадобится — в момент суммирования.

Счётчики → агрегат

Окей, теперь осталось только посчитать сумму от этого добра. Как мы знаем, у счётчиков перекрыт оператор сложения, так что почему бы просто не вызвать sum() на них?

>>> sum(map(Counter, [monday, tuesday, wednesday]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'Counter'

Эээ, что? Откуда тут int, мы же суммируем объекты Counter?

Оказывается, функция sum() принимает два аргумента:

1. последовательность, которую суммируем
2. первое слагаемое для итоговой суммы, по умолчанию — 0

Например:

>>> sum([1, 2, 3])
6

>>> sum([1, 2, 3], 10)
16

Получается, в нашем случае sum() пытается сложить 0 со счётчиком от monday, и, естественно, ломается. Решение — передать в качестве первого слагаемого пустой счётчик:

sum(..., Counter())

Объединяем всё вместе:

>>> sum(map(Counter, [monday, tuesday, wednesday]), Counter())
Counter({'problem': 10, 'question': 3, 'idea': 3})

Готово!

Почему вздыхает Гвидо

Гвидо ван Россум недолюбливает map() и, кажется, функциональщину как таковую. Вместо неё он предпочитает пользоваться comprehensions.

В нашем случае вместо map() можно использовать такую конструкцию:

(Counter(stat) for stat in [monday, tuesday, wednesday])

Используйте с осторожностью

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

daily_stats = map(Counter, [monday, tuesday, wednesday])
empty_stat = Counter()
sum(daily_stats, empty_stat)

А если не хотите, чтобы читатель мучительно вспоминал, что за такой второй аргумент в sum(), можно и вовсе сделать так:

daily_stats = map(Counter, [monday, tuesday, wednesday])
functools.reduce(operator.add, daily_stats)

Лично мне такой вариант даже больше нравится ツ

Вернёмся к примеру со статистикой по заявкам разных типов. Вот данные о вопросах, проблемах и идеях за три дня:

monday = {"question": 1, "problem": 3, "idea": 2}
tuesday = {"problem": 5, "idea": 1}
wednesday = {"question": 2, "problem": 2}

Как бы посчитать агрегированную статистику? Можно так, конечно:

def add_day(day_stats, stats):
  for key, value in day_stats.items():
    stats[key] += value
  return stats

stats = {"question": 0, "problem": 0, "idea": 0}
stats = add_day(monday, stats)
stats = add_day(tuesday, stats)
stats = add_day(wednesday, stats)

stats
{'question': 3, 'problem': 10, 'idea': 3}

Но вы наверняка догадываетесь, что это не наш метод. Поможет арифметика со счётчиками:

from collections import Counter

monday = Counter({"question": 1, "problem": 3, "idea": 2})
tuesday = Counter({"problem": 5, "idea": 1})
wednesday = Counter({"question": 2, "problem": 2})

stats = monday + tuesday + wednesday

stats
Counter({'problem': 10, 'question': 3, 'idea': 3})

Что насчёт самого популярного типа заявок?

stats.most_common(1)
[('problem', 10)]

А какие типы заявок встречались во вторник и в среду?

(tuesday | wednesday).keys()
dict_keys(['problem', 'idea', 'question'])

А сколько проблем было за все дни кроме понедельника?

(stats - monday)["problem"]
7

Думаю, вы уловили идею ツ

P.S. Хотите реально злую штуку? Вот как посчитать агрегированную статистику в одну строчку:

sum(map(Counter, [monday, tuesday, wednesday]), Counter())