Technology Strategy Patterns — выпуск 1

Николай представляется человеком, который всю жизнь сваливает данные в огромную кучу и садится сверху: его нанимают архитектором, а дальше он дорастает до руководителя. Раньше он возглавлял платформу данных, сейчас ведёт data engineering и аналитику в ManyChat, преподаёт в университете в Барселоне и ходит в другой книжный клуб, для разработчиков, где читали книгу про data-intensive-приложения и брали интервью у автора. Александр описывает книгу так: автор собрал инструменты консультантов, которые умеют красиво рассказывать о счастливом будущем, любит философию и о сложном говорит сложно, а структуру взял у «банды четырёх» — только паттерны здесь для анализа и создания стратегии. Николай замечает, что в эпоху Agile компании годами быстро закрывают тактические задачи «как землеройки», а победы всё нет; стратегия же — заранее выбранная большая цель, которая держит фокус. Александр играет в шахматы с детства и на менеджерских интервью слышит красный флаг во фразе «начнём, а потом быстро поитерируем»; обратная беда — стратегия на три года, нарисованная и убранная в стол.

Николай, проснувшийся 24 февраля в университетской квартире в Барселоне с картой ВТБ в кармане, соглашается, что планирование спасает не всегда, но преимущество есть даже у того, чья стратегия так себе. На слайдах — пять шагов первой главы: контекст, рынок и конкуренты, технологический ландшафт, свои опции, их оценка и рекомендации, за которые консультантам платят большие деньги. Николай добавляет «нулевой пункт», который часто опускают, в том числе, по его наблюдениям, в Avito: понять, кому ты стратегию рассказываешь. В ответ звучит пример: прийти к гендиректору с финансовым образованием со словами «open-source-технология Hadoop показывает замечательные результаты по последним тестам аналитиков» — верный путь услышать «очень интересно, мы с вами свяжемся». Дальше надо привязаться к проблеме, по которой у вас консенсус: собеседник видит, что воевать вы собираетесь в одну сторону. Александр признаётся, что раньше сам «рассказывал про технологию» и попадал случайно, а после одного неудачного перехода стал спрашивать уже на интервью, что болит у будущего руководителя.

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

В книге есть компания, которая годами скупала других и встраивала их в свою экосистему, но пропустила историю с облаками; по прозвучавшей в разговоре оценке, потом порядка сорока миллиардов за десять лет ушло на переписывание. Николай называет привычку инженеров «искать проблемы под фонарём»: у вас плохо — значит, нужны микросервисы, Go и Hadoop. Александр возражает альтернативными издержками: внутреннее распознавание речи для колл-центров хочется продать наружу, но упаковка в коробку и внедрение у других отвлекают силы, которые на банковских и страховых продуктах дают другой выхлоп. Николай разводит два случая: хороший — выйти не со словами «я гений, у меня инсайт», а с проблемой, альтернативами и критериями выбора; тяжёлый — спор с непризнанием проблемы, когда «нам нужен Hadoop», а не работают продажи. Хорошего архитектора сравнивают с врачом, которому кричат, где болит, а он спрашивает: «а вы ещё и чихаете?». Второй из пяти пунктов — язык: статьи Николая про хранилища обсуждают, внезапно, лингвисты из Австралии, а в ManyChat сосуществовали контакт, человек, юзер и подписчик, и понадобилось немало времени, чтобы все сошлись на «контакте».

Опции автор просит представлять MECE-списками — взаимоисключающими и совместно исчерпывающими. В разговоре это переводят на язык математики: полное разбиение множества на непересекающиеся сегменты, как четыре масти или четыре времени года; элементы должны быть одного порядка, и когда среди сторон света вместо запада возникает юго-запад, привыкший к MECE человек сразу спрашивает, что случилось. Александр проверяет на своём кейсе: разработать внутри, заказать снаружи или купить — это MECE? Николай отвечает, что иногда система не нужна вовсе, задачу делают руками, поэтому он сделал бы два MECE-списка: сначала «делать или не делать», потом ветвящийся. Список — критерий профпригодности: у пропущенной опции два объяснения, плохо структурированный разум или манипуляция, и оба — красный флаг. Так один из участников и читает любую архитектуру или стратегию — строит списки в голове, даже если их нет в тексте, и ищет, что забыли; шанс продать стратегию обычно один.

Дальше матрица приоритетов: по горизонтали размер результата, по вертикали простота. Крутых идей всегда больше, чем сил, поэтому сначала берут низко висящие фрукты, а «легко, но мало» автор ставит вторым приоритетом и «большое влияние, но умрёшь по дороге» — третьим. Николай возражает: именно так копится техдолг — компания не дойдёт до распила монолита, пересборки архитектуры и функциональных команд, пока не упрётся; иронично, что так предлагает книга о технологической стратегии. Выход — резать большое на части с накапливающимся эффектом, но легко брать в долг, когда отдавать будет другой. К схеме, где решение складывается из точек данных, Николай скептичен: инсайт и обоснование гипотезы — две большие разницы. На инсайт данных хватает очень часто, мозг увидит облако в куче песка, а на значимый рост или результат A/B-теста часто нет. Продажи мороженого коррелируют с пожарами, скрепки — с нападениями пиратов, а строгого аппарата для причинности нет: её проверяют, убирая фактор, чего астрономы, например, сделать не могут.