Процессы и инструменты: слова затухают, тулинг остаётся

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

В аутсорсе ему не нравилась расхлябанность коллег: он начал объединять людей вокруг результата, втянулся в тимлидство и стал читать книги про управление. Дальше была крупная компания-интегратор сразу на управленческой позиции, потом Яндекс, дочерняя компания Ростелекома и несколько стартапов.

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

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

Дальше он нарисовал критическую цепь и снял метрики: в сроки команда не попадала. Топ-менеджмент предложил добавить разработчиков в узкое звено, он возражал, что узкое место — тестирование, без которого финансовый инструмент выпускать нельзя. Эксперимент с аутсорс-разработчиками только нагрузил тестирование сильнее и не приблизил запуск; Александр вспоминает «Мифический человеко-месяц» Брукса. По словам Павла, брокера выпустили в сроки, которые он рассчитал по ограничениям процесса.

Тогда же он завёл прогон Oracle-скриптов через git ради диффа и ревью — и удивился, что многие про git не знали.

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

Потом были институт delivery-менеджеров, который, как он подчёркивает, запускали несколько человек, сообщества тимлидов и delivery-менеджеров, курсы, объёмная внутренняя база знаний и трек фасилитации, сервисом которого он теперь пользуется сам; попутно он честно отучился на преподавателя канбана.

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

Александр разворачивает ту же мысль со стороны инженерии: процесс, изменённый словами, затухает, если не снизить когнитивную нагрузку. Можно долго объяснять, как правильно ходить в чужой API — ретраи, лимиты, circuit breaker, — а можно дать SDK, где это уже сделано, и люди начнут пользоваться правильно из коробки; их команды, заменяя внешнюю аналитику собственным сервисом, сразу отдают SDK для отправки событий.

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

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

Сегодняшняя зона ответственности Павла — управление совместной работой, и все продукты в ней выросли независимо, но вокруг одного источника данных, Jira. Автоматический гант по приоритизации и методу Монте-Карло сам выстраивает сроки и учитывает даже отпуска: он решает ту же проблему синхронизации команд, которую когда-то считали карандашом на листочке.

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

Отдельно появился dependency table для PI-планирования по SAFe: технология красивой визуализации связей лежала без применения, пока команды нефинансовых сервисов не пришли с болью синхронизации, а Настя Медведева не предложила приложить одно к другому. Инструмент узкий, зато синхронизируется с Jira и связывает задачи пачками.

Отчёт по многим командам назвали «C level» по просьбе самих топ-менеджеров, хотя Александр считает, что это дашборд для мидл-менеджмента.

Второй трек — общая доска для совместной работы. Сделка на закупку Miro была почти закрыта, когда вендор сообщил, что не гарантирует работу сервиса в России; китайская альтернатива ответила примерно так же, а на локальном рынке инструментов оказалось мало. За два года команда сделала свою доску, недавно выпустила её наружу и, по внутренним исследованиям, закрыла большую часть сценариев, ради которых пользовались Miro; на момент записи Павел ожидает новых санкционных ограничений с 15 сентября.

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

Confluence и Jira тоже придётся чем-то заменять, но «убивший дракона сам становится драконом»: клон переносит ограничения, но не обязательно получает преимущества, накопленные годами, например маркетплейс. Яндекс, вспоминают участники, сначала пробовал повторить чужой трекер, а потом сделал собственный под свои задачи: тем, у кого задачи похожи, он подходит, остальным — нет.

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