Предположим, вы сделали робота для общественных пространств. Он будет помогать людям.

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

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

actions = [
  "махать флагом",
  "чесать котов",
  "смешить детей",
  "рвать шаблоны",
]

Как бы из этого списка сделать счётчик? Так не надо, конечно:

from collections import Counter

counter = Counter()
for action in actions:
    counter[action] = 0

>>> counter

Counter({
  'махать флагом': 0,
  'чесать котов': 0,
  'смешить детей': 0,
  'рвать шаблоны': 0})

Намного роднее воспользоваться dictionary comprehension (простите, что на англ — непереводимая игра слов):

counter = Counter({action: 0 for action in actions})

Или малоизвестным методом dict.fromkeys():

counter = Counter(dict.fromkeys(actions, 0))

Первый аргумент — список ключей, второй — умолчательное значение. Удобно, а?

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

survey = {
  "Чем известен Джони Айв?": [
    "Придумал анимированные эмодзи",
    "Снялся в фильме про белую комнату",
    "Изобрёл мышку с зарядкой в пузе",
  ],
  "Почему важно надувать щёки?": [ ... ],
  "Сколько у вас статей про дизайн-системы?": [ ... ],
}

Вы написали код, который показывает на экране каждый вопрос с вариантами ответа:

for question, answers in survey.items():
    print(question)
    print_answers(answers)

Но есть нюанс — варианты должны быть пронумерованы. Как бы это сделать?

def print_answers(answers):
    i = 1
    for answer in answers:
        print(f"{i}: {answer}")
        i += 1

Чем известен Джони Айв?
1: Придумал анимированные эмодзи
2: Снялся в фильме про белую комнату
3: Изобрёл мышку с зарядкой в пузе

Да, но нет. Очень часто, когда видите в коде i = .. и затем i += 1 — это красный флаг. Лучше так:

def print_answers(answers):
    for idx, answer in enumerate(answers, start=1):
        print(f"{idx}: {answer}")

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

P.S. Если это для вас слишком просто, представьте себя сумасшедшим любителем однострочников и попробуйте расшифровать такое:

deque(map(print, map(lambda item: f"{item[0]}: {item[1]}", enumerate(answers, start=1))), maxlen=0)

Получил такой комментарий на заметку про быстрый и медленный алгоритмы:

Мне кажется, тут не совсем корректное сравнение. sorted оптимизированная и написана на С, в то время как insort — просто питоновская функция. Она гоняет питоновские структурки и при любом раскладе будет работать медленно.

Это вообще популярная точка зрения, что если что-то написано на «быстром» языке, то оно уж всяко будет быстрее, чем написанное на «медленном».

Конечно же, это не так. Алгоритмы отличаются асимптотической сложностью — в том примере было O(n logn) против O(n²). В такой ситуации O(n logn) будет всегда быстрее для достаточно большого n, даже если написать его на джаваскрипте и интерпретировать встроенной в Windows js-машиной, а O(n²) написать на самом быстром в мире C.

Другое дело, что оговорка «для достаточно большого n» может оказаться решающей. Бывает, что асимптотически более быстрый алгоритм начинает выигрывать, скажем, при n > 10 млрд — а у вас в программе всегда n < 1 млн. Именно поэтому стоит реализовать и сравнить в действии оба алгоритма, если нет 100% уверенности.

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

P. S. Модуль bisect на самом деле реализован на C. Если интересно, как выглядит «сишная» часть питона, посмотрите — это один из самых простых модулей.

На днях я предложил подписчикам канала Oh My Py такую задачку:

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

Как думаете, что будет работать быстрее:

• Складывать приходящие числа в неупорядоченную кучу, отсортировать в конце.
• Постоянно поддерживать отсортированный список (с помощью bisect), в конце просто вернуть его.

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

Давайте разберёмся, так ли это.

Решение

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

Мы знаем, что сортировка на n числах занимает O(n logn) операций. Это сложность варианта «сортировать в конце».

Мы также знаем, что один бинарный поиск занимает O(log n) операций. В варианте «поддерживать отсортированным» мы выполняем поиск n раз, значит итоговая сложность O(n logn).

Там O(n logn) и тут O(n logn) — значит, варианты равнозначные, расходимся.

На самом деле нет ツ Посмотрите на реализацию варианта «поддерживать отсортированным»:

def keep_sorted(generator):
    collection = []
    for number in generator:
        index = bisect.bisect(collection, number)
        collection.insert(index, number)
    return collection

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

Таким образом, на каждое число алгоритм тратит O(n) операций, а на n чисел — O(n²). Это сильно медленнее, чем O(n logn).

Проверка

Чтобы не быть голословным, я реализовал оба варианта и сравнил их в действии.

Подготовка

Сначала подготовим генератор чисел:

import random

# будем генерить числа от 1 до 1 млн
RANGE_SIZE = 1 * 10**6

def number_generator(count):
    for _ in range(count):
        number = random.randint(1, RANGE_SIZE)
        yield number

Затем реализуем алгоритм «сортировать в конце»:

from collections import deque

def sort_after(generator):
    collection = deque()
    for number in generator:
        collection.append(number)
    return sorted(collection)

И алгоритм «поддерживать отсортированным»:

import bisect

def keep_sorted(generator):
    collection = []
    for number in generator:
        bisect.insort(collection, number)
    return collection

Синхронная работа

Сначала рассмотрим вариант, когда генератор и обработчик работают строго последовательно: генератор присылает число, обработчик складывает его к себе, генератор присылает второе число, обработчик снова складывает, и так далее. Пока обработчик не закончил с числом, генератор не может прислать следующее.

Будем проверять на 1 млн чисел.

count = 1 * 10**6

Сортировать в конце:

%%time
sort_after(number_generator(count))
;

CPU times: user 1.33 s, sys: 20.1 ms, total: 1.35 s
Wall time: 1.35 s

Держать отсортированным:

%%time
keep_sorted(number_generator(count))
;

CPU times: user 1min 25s, sys: 74.9 ms, total: 1min 25s
Wall time: 1min 25s

Вариант «сортировать в конце» оказался быстрее в 63 раза (1.35 секунды против 85 секунд).

Асинхронная работа

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

Здесь придётся работать в два процесса (отдельно генератор, отдельно обработчик), так что будем использовать очередь для синхронизации. Генератор будет складывать в неё числа, а обработчик — забирать.

Кроме того, добавим генератору задержку:

import random
import time

def number_generator(queue, count, delay):
    for _ in range(count):
        number = random.randint(1, RANGE_SIZE)
        queue.put(number)
        time.sleep(delay)
    queue.put(None)

Алгоритмы «сортировать в конце» и «поддерживать отсортированным» не слишком поменяются. Просто теперь они получают числа не из генератора, а из очереди:

from collections import deque

def sort_after(queue):
    collection = deque()
    while True:
        number = queue.get()
        if number is None:
            break
        collection.append(number)
    return sorted(collection)

import bisect

def keep_sorted(queue):
    collection = []
    while True:
        number = queue.get()
        if number is None:
            break
        bisect.insort(collection, number)
    return collection

Добавим вспомогательную функцию, которая создаёт процессы и запускает тест:

from multiprocessing import Process, Queue

def main(processor, count, delay):
    print(f"count = {count}, delay = {delay}")
    queue = Queue()
    generator = Process(
        target=number_generator,
        args=(queue, count, delay),
        daemon=True,
    )
    consumer = Process(target=processor, args=(queue,), daemon=True)
    
    generator.start()
    consumer.start()
    generator.join()
    consumer.join()

Будем проверять на 1 млн чисел и интервале между приходом чисел в 1 микросекунду:

count = 1 * 10**6
delay = 1 * 10**(-6)

%%time
main(sort_after, count, delay)
;

count = 1000000, delay = 1e-06
CPU times: user 3.12 ms, sys: 5.48 ms, total: 8.6 ms
Wall time: 29.3 s

%%time
main(keep_sorted, count, delay)
;

count = 1000000, delay = 1e-06
CPU times: user 3.81 ms, sys: 6.43 ms, total: 10.2 ms
Wall time: 1min 43s

Кажется, что разрыв сократился (29 секунд против 103). Но на самом деле эти 29 секунд уходят не на полезную работу, а на «обвязку» — возню вокруг time.sleep() и межпроцессное взаимодействие. Чтобы убедиться в этом, сделаем ещё один алгоритм, который вообще не сортирует приходящие числа, а просто возвращает их в финале как есть:

def do_not_sort(queue):
    collection = deque()
    while True:
        number = queue.get()
        if number is None:
            break
        collection.append(number)
    return collection

%%time
main(do_not_sort, count, delay)
;

count = 1000000, delay = 1e-06
CPU times: user 2.93 ms, sys: 5.58 ms, total: 8.52 ms
Wall time: 29.1 s

Таким образом, «чистое» время работы «сортировать в конце» по-прежнему составляет около 1 секунды, а «держать отсортированным» — в десятки раз больше.

Ноутбук

⌘ ⌘ ⌘

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

Френк решил открыть магазин диковинок. Прайс-лист огромный, приведу только несколько позиций:

from collections import namedtuple
Product = namedtuple("Product", ("price", "name"))

products = [
  Product(1500, "живой багет"),
  Product(3300, "мельница для сыра"),
  Product(6500, "костюм картошки"),
  Product(9900, "беспилотная сова"),
]

Магазин открылся, торговля идёт бойко, но есть проблемка. Покупатели донимают вопросом «у меня есть X рублей, какую самую дорогую дичь я могу купить за эту сумму?».

Френк очень плохо считает (неудивительно для голубя), поэтому требуется наша помощь. Давайте сначала решим «в лоб»:

def suggest(max_price):
    best_product = Product(0, None)
    for product in products:
        if product.price > max_price:
            continue
        if product.price > best_product.price:
            best_product = product
    if best_product.name is None:
        return None
    return best_product

>>> suggest(5000)
Product(price=3300, name='мельница для сыра')

Работает как часы! Только Френк жалуется, что suggest() что-то долго думает (прайс-лист огромный, помните?). Это неудивительно, мы ведь каждый раз перебираем все товары — сложность алгоритма O(n)

Надо бы отсортировать товары по цене и использовать алгоритм бинарного поиска, который работает за O(log n). Правда, не слишком греет перспектива реализации алгоритма — Френк требует сделать всё сию же секунду.

Нам поможет модуль bisect стандартной библиотеки:

import bisect

prices = sorted(p.price for p in products)

def suggest(max_price):
    best_index = bisect.bisect(prices, max_price)
    if best_index == 0:
        return None
    return products[best_index - 1]

>>> suggest(5000)
Product(price=3300, name='мельница для сыра')

Работает так:

• Создали отсортированный список цен.
• Покупатель принёс 5000₽ денег.
• bisect.bisect() определил, на какую позицию списка можно вставить 5000, чтобы список остался отсортированным (третья позиция, между 3300 и 6500).
• Элемент слева от этой позиции и есть интересующий нас товар («мельница» за 3300).

Френк доволен.

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

На деле он занимается форматированием календарей в HTML (именно то, что требуется в стандартной библиотеке любого языка) и предоставляет гениальные методы вроде itermonthdays, itermonthdays2, itermonthdays3 и itermonthdays4 (оцените богатство выбора, прямо как на воскресной ярмарке).

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

import calendar
wday = calendar.weekday(1959, 11, 5)

>>> calendar.day_name[wday]
'Thursday'

Или вспомнить, сколько дней в июне:

import datetime as dt
today = dt.date.today()
_, days = calendar.monthrange(today.year, today.month)

>>> days
30

Или проверить, високосный ли год:

>>> calendar.isleap(2020)
True

А генерировать HTML-календари с помощью calendar вы не будете, надеюсь ツ

У нас ответственная миссия: запустить в космос автомобиль. Сначала подготовим инфраструктуру — собственно машину и мега-пушку:

from dataclasses import dataclass

@dataclass
class Car:
    brand: str
    model: str
    driver: str

class SpaceCannon:
    def launch(self, cars):
        car = cars[0]
        print(f"{car.brand} {car.model} driven by {car.driver} sent to space!")

Проверим:

car = Car(brand="Tesla", model="Roadster", driver="Starman")
cars = [car]
cannon = SpaceCannon()
cannon.launch(cars)

Tesla Roadster driven by Starman sent to space!

Работает!

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

copied_cars = cars[:]
copied_cars.clear()

Оригинальный список при этом не пострадал, его можно спокойно запускать:

cannon.launch(cars)
Tesla Roadster driven by Starman sent to space!

О, тут инженерам ещё хохма в голову пришла:

copied_cars = cars[:]
copied_cars[0].brand = "ToSky"
copied_cars[0].model = "Zhiguli"
copied_cars[0].driver = "Roskosmos guy"

Очень смешно, отправить в космос чела из Роскосмоса на жигулях, ха-ха. Пошутили и хватит, запускаем Теслу:

cannon.launch(cars)
ToSky Zhiguli driven by Roskosmos guy sent to space!

Ну вот (((

Проблема в том, что cars[:] выполняет так называемое поверхностное копирование — сам список копируется, но в качестве его элементов используются ссылки на элементы оригинального списка.

Поэтому, меняя copied_cars[0], мы превратили оригинальную Теслу в Жигули (что само по себе заслуживает уважения, конечно).

Создать полный дубликат коллекции поможет модуль copy:

import copy

car = ...
cars = [car]
copied_cars = copy.deepcopy(cars)
copied_cars[0].model = "Zhiguli"
cannon.launch(cars)

Tesla Roadster driven by Starman sent to space!

Во, другое дело.

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

Удивительно, что не все этим пользуются. Вот, например, сериальный сервис «Амедиатека». Даже далёкие от темы люди знают, что самый популярный в мире аналог — «Нетфликс». Казалось бы, заплати $10, посмотри, как у них всё устроено, и перенимай хорошие решения. Но нет.

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

Но что может быть проще, чем кнопки паузы и перемотки? У Амедиатеки они мизерных размеров внизу экрана — попробуй, попади. У Нетлифкса — здоровенные и по центру. Что мешает сделать нормально — загадка.

Или вот функция «продолжить воспроизведение». Как это работает у Амедиатеки:

1. Тыкаешь на серию, которую уже смотрел раньше.
2. Вылезает попап (натурально, модальное окно!) с надписью «Continue playback?» и кнопками «Continue» и «Start Over».

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

Или то, что человек видит после логина. У Амедиатеки:

У Нетфликса:

Или функция skip intro / skip recap. Отличная штука, экономит от 30 до 120 секунд на серию, в зависимости от любви постановщиков к длинным вступлениям. Есть она у Нетфликса? Конечно. А у Амедиатеки? Пффф, разумеется нет.

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

Это эссе о развитии софтверных продуктов, собранное по результатам моей недели в коллективном твитере продактов @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. Если вы не катаетесь на лыжах, борде, скейте, кайте, байке и самокате. Если вы не придерживаетесь диеты и бегаете по ночам к холодильнику.

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

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

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