Управление эффективностью в техе и продукте

Ведущий начинает с зала: поднимите руку те, кого за последние полгода руководители спрашивали про эффективность процессов — или кто сам захотел с ней что-то сделать; остальные, шутит он, пришли поесть, благо еда в Авито тоже есть. Ярослав Тулупов, директор по разработке Авито Pro — монетизация, реклама, опыт селлеров, размещение товаров, финтех, — описывает эффективность как задачу сильно распределённой структуры с вертикалями и горизонталями и приличным дефицитом всего: и людей, и железа. Его горизонталь делает решения для всех вертикалей, от авто до недвижимости; бизнес прибегает с новой классной идеей, денег на неё нет, и вопрос в том, как впихнуть невпихуемое в ресурсный колодец и что остановить ради нового. Часть ответа — технологии против рутины: внутренний PaaS, где разработчик запускает сервис одной кнопкой.

Влад Плющев отвечает за технологии b2c-бизнеса Сбера: структуре около полутора лет, она делает сервисы для клиентов-физлиц. Его формула — «делать правильные вещи правильно». Правильные вещи начинаются со стратегии и приоритизации: если продукт не укладывается в нормы по cost-income, дешевле отказаться на входе, чем потом подбирать процесс, инструмент и команду. Ведущий возражает, что лучше всех приоритизируют компании, у которых мало денег: когда денег на три фичи, думаешь десять раз. Влад соглашается, что КПД не сто процентов, и добавляет ограничение: у Сбера есть обязательная повестка — продукты, от которых нельзя отказаться даже при плохих показателях, и важно принимать это осознанно. За двенадцать лет там он вывел, что можно посеять любое зёрнышко и оно взойдёт: аудитория найдётся всегда, а отделить эффект проекта от общего контекста в стране почти невозможно.

Илья Лосев руководит сервисом Яндекс Задания — тем, что осталось от Толоки после её ухода из России: там, где машинная логика пасует, к бизнес-процессам подключают людей. Подразделение считает и собственный внутренний PnL, и PnL продукта наружу. Ресурсы внутри Яндекса достаются сложнее, чем в Сбере, где он работал раньше: «составил презентацию, пришёл, рассказал, получил половину ресурсов», — на этом зал смеётся. Да и выданный ресурс — только право нанять: сотрудник сразу падает в PnL вместе с налогами и обязательными костами вроде печенек на кофепоинтах, так что штатный человек по цене сопоставим с подрядчиком. Исполнителей у сервиса примерно столько же, сколько сотрудников во всём Яндексе, и по ним считают LTV и стоимость найма. В IT за год выстроили три метрики: полезная capacity, time-to-market и сходимость бэклога, близкая к ста процентам. На вопрос из зала про аутсорсинг он отвечает коротко: Яндекс им практически не пользуется — слишком много ноу-хау внутри.

Александр, технический директор в Т-Банке, отвечающий за клиентские интерфейсы, маркетинг и вовлечение, начинает с простого: зарабатывать больше, тратить меньше — и тут же раскладывает это по типам структур. У бизнес-линий вроде дебетовых, кредитных и инвестиционных продуктов есть свой PnL, и там всё считается. У сервис-линий вроде привлечения эффективность видна косвенно: стоимость привлечения пользователя против NPV-модели продукта. У платформ инвестиции большие, альтернатив нет, и экономику строят от вопроса, что было бы, если бы платформу пришлось покупать снаружи: в девятнадцатом году, вспоминает он, порядка двадцати-двадцати пяти процентов продуктовых команд пилили собственные инструменты для работы с кодом, CI/CD и мониторинга. Вторая половина — «делать правильно»: в свежей статье Гугла про developer productivity эффективность меряют от ежедневных сценариев инженера и тюнят процессы проектирования, кода, качества, деплоя и эксплуатации.

Ведущий закидывает гипотезу: любую систему оценки на уровне команд будут читить. Александр вспоминает закон Гудхарта — когда метрика становится целью, хорошая метрика превращается в плохую: пока по ней принимают решения, всё нормально, но как только по ней оценивают работу, люди красят светофоры в зелёный. Помогает система метрик, которую сложно покрасить целиком: красишь одну грань кубика Рубика — остальные рассыпаются. Помогает и deep dive в духе Amazon: если топ-менеджеру хватает зелёного отчёта, ему такой и принесут; сам он с тысячей инженеров в зоне ответственности ходит и спрашивает. Ярослав добавляет физический смысл: в Авито смотрят не только на девятки сервисов, но и на стабильность критических сценариев — смог ли пользователь оплатить. Сценарии его команды платежей были зелёными, хотя он знал, что это неправда. Влад приносит образ арбузной метрики: сверху зелёная, надрежешь — внутри красное. Илья честно называет метрики разработки самой ненавистной темой: строки кода и частоту коммитов читят на изи.

Вторая большая тема — вопрос, который гендиректора регулярно задают техническим директорам: задачу делают десять человек, а хотелось бы пять. Илья предлагает не сваливаться в численность: в один бюджет помещаются двое сеньоров или примерно пять джунов, а сами вопросы возникают чаще, когда CEO плохо погружён; дальше договариваются о грейс-периоде, за который либо снижают стоимость и смотрят, на какие процессы это влияет, либо перестраивают команду. Александр раскладывает работу на change и run: если продукт только эксплуатируют, людей может хватить и меньше, но развитие встанет, а сокращать — значит от чего-то отказаться. Влад сводит всё к доверию между двумя уровнями управления и к драйверным моделям, снявшим массу споров: вырос драйвер — получаешь штат в рамках процесса. Ярослав называет два рычага: вынести операционные процессы из инженерной функции и вложиться в платформу, чтобы следующий кусок бизнеса стоил в разработке около нуля. Советы в финале короткие: читать контекст, думать и учиться говорить «нет» самому себе.