К основному содержимому
к выпуску
Конспект выпуска2022Fellow

Technology Strategy Patterns — выпуск 3

Третий выпуск по Technology Strategy Patterns — про два контекста: корпоративный и контекст вашего отдела. Прошлые встречи разбирали контекст мира и индустрии. Александр Поломодов, Вова Чистяков и гость Паша, технический директор, проходят семь паттернов корпоративной главы и два «отдельских», разбавляя их историями про найм, платформы и BPMN.

Code of Architecture · книжный клуб7 минут

Конспект сокращён относительно полного выпуска; примеры и оценки передают опыт и позиции участников.

Основная линия материала
01

Стейкхолдеры и матрица влияния

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

Основной паттерн — матрица стейкхолдеров, любимая консультантами два на два: влияние вашего проекта на человека против его влияния на вас. Влияние расшифровывают приземлённо: ресурсы, деньги, дополнительные команды и возможность не пустить сервис в production. С сильными нужна коллаборация вплоть до соавторства идей: за высоким влиянием обычно стоит большой опыт, к таким людям стоит прислушиваться, а их одобрение повышает шансы проекта; остальных достаточно информировать. Александр напоминает, что на курсах проектных менеджеров работе со стейкхолдерами отводят отдельное внимание — успех проекта зависит от попадания в их ожидания, и это искусство технари осваивают, когда начинают отвечать не за код, а за результат команды. Второй паттерн, RACI, раскладывает роли по активностям: responsible делает руками, accountable отвечает за результат, с consulted советуются, informed просто держат в курсе; забудете их проинформировать, проект не заблокируют, но обидятся и припомнят.

02

RACI, жизненный цикл, цепочка ценности

Responsible может быть несколько, accountable — один: яму копают двое землекопов, а спрашивают за неё с бригадира, и два аккаунтабла потребовали бы идеальной синхронизации, которой в реальном мире не бывает. Один из участников спорит: решение вполне можно принимать вдвоём, если стороны в одном контексте и есть отдельная процедура; Александр соглашается насчёт решения, но настаивает, что за имплементацию отвечает кто-то один, а выход за ожидаемые рамки возвращает вопрос голосующим. Дальше — жизненный цикл компании: старт, рост, зрелость, спад и завершение, которое не обязательно банкротство. Стадию предлагают читать по финансовым отчётам: рост прибыли выше 15% — захват новых рынков, 8–15% — приближение к зрелости, 5–8% — зрелость, меньше 5% — спад. Меняется и инженерная повестка: сначала главное — быстрее занять долю, потом нужна гибкость, чтобы дорабатывать продукты, ничего не ломая, а в зрелости приходят многопродуктовость, платформы и стандартизация. Паша добавляет, что в зрелости бизнесу больше всего даёт внутренняя эффективность, четыре девятки на ранних стадиях не окупаются, а позже надёжность становится условием существования.

Цепочка ценности продолжает прошлый выпуск: автор пяти сил, разобрав индустрию, отдохнул пять лет и написал следующую книгу уже про неё. Паша объясняет паттерн через конвейер: вы видите этапы, через которые проходит поставка ценности, и можете их измерить, оптимизировать и понять, сколько на них уходит времени и ресурсов; снизу лежат общие вещи вроде платформы. Александр вспоминает, как считал такую цепочку в Тинькофф, отвечая за небольшую тогда команду онлайн-привлечения. Ему нужен был инженер, просивший процентов на пять выше вилки, и вместо спора о правилах он посчитал эффект: сколько денег уходит на это звено и сколько оно приносит; модель известна, потратив рубль, получаем условно три, а стоимость привлечения держат в районе трети от приведённого дохода. Дерево решений показало, что месяцы поиска обойдутся дороже; инженер проработал два года, MVP взлетело, и сегодня из него вырос внутренний рекламный кабинет. Участники добавляют: саппортящую активность можно раскачать так, что она станет отдельным продуктом, — как AWS у Amazon.

03

Портфель продуктов и контекст отдела

Матрицу роста и доли участники ценят за общий словарь: сказал «дойная корова», и позиция продукта понятна без пояснений. Паша рассказывает, как они раскладывали так свой рынок сетей пиццерий в России, Белоруссии и Казахстане: казалось бы, крупнейшая сеть в регионе уже дойная корова, но рынок продолжает расти и в этом году сильно изменился, поэтому картинку приходится пересматривать. Участники добавляют, что набором продуктов можно считать и архитектурные проекты: стоит ли вкладывать в этот ещё денег. Следующий паттерн раскладывает продукты по зависимости от кора и по новизне, чтобы понять, что финансировать; его название один из участников вспоминает неуверенно. Карта инвестиций — снова два на два, из готовности рынка и сложности реализации: готово и легко — вкладываться, нужно, но сложно — сделать MVP, легко, но рынок не готов — мониторить. Пример автора — стартап с электронными замками для гостиниц, которые открываются со смартфона: смартфон есть не у всех, да и разряжается он постоянно.

Контекст отдела сводится к двум большим паттернам. Первый — принципы, практики и инструменты: идти надо от принципов, под них подбирать практики и только потом инструменты, иначе решением окажется Kafka просто потому, что кто-то хорошо умеет её настраивать. Автор предлагает разметить процессы по зрелости и нарисовать картинку «как живём сейчас — как хотим». Кто-то из участников признаётся, что в такой замудрённой форме упражнение не делал, но, становясь техническим директором нового куска, вёл похожую таблицу с текущим и целевым состоянием, целью и статусом. Ещё одна байка: бэковые процессы команд одного из участников описаны в BPMN — схем уже больше сотни, и поверх них рисуют верхнеуровневую абстракцию, иначе за деревьями не видно леса. Последний паттерн — портфель приложений: их ранжируют по ценности для бизнеса, стоимости эксплуатации и техническим рискам, а размер кружка — это число пользователей; отсюда видно, что отправить на пенсию, что стабилизировать, а что растить. Именно так, замечает Александр, аргументируют распил монолита: объяснять это надо бизнесовыми терминами, а не техническим сленгом. В следующий раз клуб начинает часть про то, как стратегию коммуницировать.

Выводы

Что стоит унести с собой

  1. 01Responsible на активность может быть несколько, accountable — всегда один; решение допустимо принять вдвоём, но за имплементацию отвечает конкретный человек.
  2. 02Стадия жизненного цикла меняет инженерную повестку: на старте важнее скорость захвата доли, в зрелости — внутренняя эффективность, платформа и надёжность как условие существования.
  3. 03Цепочка ценности переводит спор о найме в счёт: посчитанный эффект звена убедил взять инженера выше вилки лучше, чем ссылка на правила.
  4. 04Начинать надо с принципов, затем практики и только потом инструменты, иначе выбор сведётся к тому, какой инструмент лучше знает конкретный человек.

Источники