Бессерверные архитектуры фундаментальным образом сказываются на лимитирующих факторах, сковывающих разработку продукта.
Продакт-менеджеры в организации выступают во множестве амплуа. Иногда их называют «голос клиента», иногда отводят роль «корпоративного котопаса». Это толстокожая братия, люди, неумолимо ведущие вас к сдаче продукта, несмотря на всякую этику или оправдания. Хороший продакт-менеджер редко становится чьим-нибудь кумиром, но именно благодаря труду таких людей воплощено большинство технологических решений, которыми вам когда-либо доводилось пользоваться.
PM всегда подыскивает как можно более качественные инструменты для решения задачи. Мы знаем, что конкуренты постоянно наступают на пятки, клиенты устали ждать, поэтому нам постоянно приходится действовать умнее, расторопнее и эффективнее. С появлением бессерверных технологий не сразу стало понятно, как они впишутся в вишлист продакт-менеджмента. Однако, поработав с этими технологиями год, я вижу, что они решают некоторые проблемы разработки ПО, которые казались нам вечными.
Парадокс: размер команды и ее производительность
Первое правило продакт-менеджмента гласит: объем работы к исполнению постоянно растет. Бэклог продолжает пухнуть, а схлопывается до нуля он лишь в одном случае: когда продукт упраздняется. Самое сложное – превратить важнейшие элементы вашего бэклога в готовый к сдаче продукт. При прочих равных считается, что должна наблюдаться следующая зависимость:
Если один землекоп может утилизировать 1 тонну грунта в день – предполагается, что 10 землекопов могут утилизировать 10 тонн. Как правило, управление ресурсами в компаниях строится именно по такому принципу: хотите увеличить продажи – наймите побольше продажников. При разработке ПО, когда бэклог растет, возникает соблазн просто увеличить команду. Однако, в случаях со сложными продуктами и сервисами со временем обычно вырисовывается примерно такой график:
Редко увидишь, как огромная команда работает стахановскими темпами; зато гораздо чаще бывает, что небольшая команда с завидным постоянством прогрессирует семимильными шагами.
Многим стартапам свойственна такая ошибка: как только продукт становится успешен, в штат добавляются все новые разработчики и менеджеры. Вскоре неожиданно выясняется, что скорость начинает падать. В чем же дело? В том, что первые разработчики были талантливее, в том, что в компании разрослась бюрократия, в том, как планировалась архитектура?
Думаю, все это лишь симптомы, а не корень проблемы. Сама проблема сводится к взаимодействию трех критических факторов, лишь двумя из которых можно непосредственно управлять:
- Хрупкость — влияние новых изменений. Если новая фича затрагивает лишь часть машины, то ее легко протестировать и реализовать. Если же она сказывается на всех элементах машины, то тестирование становится сложнее и одновременно важнее, а реализация требует на порядок больше времени.
- Объем работы — минимальный кусок работы, который может быть выполнен командой и дает на выходе продуктивную фичу. Например, продуктивным является результат «Заплатить при помощи Alexa», а не «собраться и обсудить, как реализовать платежи при помощи Alexa».
- Сложность — какой объем знаний требуется для реализации фичи. Способен ли разработчик, знающий, как написать фичу самостоятельно, сделать то же самое в рамках организации? Какие дополнительные изменения должны произойти, чтобы прогресс стал постепенно замедляться, а продукт перестал обрастать фичами, ценными с точки зрения клиента?
Меня особенно занимает, почему же на заре существования все эти факторы уравновешены оптимально: там нет ничего хрупкого, объем работы не особенно велик (и с заказчиком обычно можно договориться), а сложность практически отсутствует. Так, если команда должна создать GDPR-совместимый сайт, то у них найдется время на исследование этой проблемы, решение будет сделано быстро, а команда будет уверена, что сайт работает именно так, как запланировано.
В более крупных компаниях эти факторы комбинируется, в результате чего растет размер команды, а объем выполняемой работы сокращается. Для создания GDPR-совместимого сайта в такой компании потребуется подпись юриста, одобрение маркетологов, согласование проекта на уровне совета директоров, A/B-тестирование наименее подрывной реализации, согласование перерывов в разработке с командой админов, согласование с планами по развертыванию, принятыми в других командах – список можно продолжать. Даже при таком объеме контроля и количестве процессов команда гораздо менее уверена в том, что у нее получится, из-за хрупкости всей системы и множества неизвестных в экосистеме.
Расширив этот пример до размеров реального проекта, в котором могут присутствовать десятки фич и сотни изменений, несложно понять, как из-за взаимовлияния этих факторов график соотношения «размер команды/объем работы» превращается из первого во второй. По мере роста команды вы обречены успевать все меньше работы в единицу времени, как бы вы ни пытались обхитрить организационную махину. Или так только кажется – но, что же в таком случае делать?
Как хакнуть все три фактора
Эта проблема уже много лет не дает мне покоя, что и побудило меня взяться за изучение ее возможных причин. Только ли на стартапах возможен стремительный прогресс? Какое-то время я именно так и считал, сталкиваясь со сложностями управления продуктом в крупных организациях. Однако, затем я присмотрелся ко всем трем факторам гораздо внимательнее.
Хрупкость всегда вам во вред — она провоцирует вечно растущий технический долг в любом проекте любого размера. Ситуация напоминает «полураспад наоборот»: любой элемент программы со временем растет и из-за этого (в ходе разработки) становится все хрупче, причем, все это усугубляется с каждой новой строкой кода.
Объем работы связан не с конкретной фичей продукта (“Заплатить при помощи Alexa”), а, скорее, с отличиями в очертаниях инфраструктуры, если сравнить состояния «до» и «после». Чем сложнее становится «после», тем сильнее сокращается объем выполняемой работы. Вот почему во многих компаниях при планировании работы акценты смещаются с потребностей клиента (“Заплатить при помощи Alexa ”) на потребности организации (“Встретиться и обсудить, кто должен заняться реализацией фичи «Заплатить при помощи Alexa»).
Сложность — это совокупность социальных, организационных и технических факторов, непосредственно влияющая на длительность поисков подходящего разработчика, на возможность относиться к программистам как к многостаночникам, которым можно поручить любую работу. Причем, именно сложность – тот самый аспект, который, скорее всего, останется невидим, недокументирован и недопонят. Разработчик может дома написать React-приложение и сам выполнить его релиз, но в организации ему придется совершить с десяток лишних шагов, которые отберут у него время, а интересные пользователю фичи при этом совершенно не изменятся. Программист же потратит на них большую часть рабочего дня.
Вместе три этих фактора образуют порочный круг, так что объем выполняемой работы уменьшается, хрупкость возрастает, разработчику удается завершать все меньше и меньше фич, а ваш продукт обрастает сложностью как невидимой тиной. Следовательно, разрастание команды не помогает, а скорость удается повысить лишь сознательно лукавя с цифрами и показателями. Классический симптом: в отчетах по спринтам появляется позиция «проведено совещание».
В крупных компаниях мне приходилось наблюдать пару ущербных подходов, призванных сломать этот цикл. Первый – «Масштабный Agile», выливающийся в огромные совещания, в которых участвуют абсолютно все участники разработки той или иной фичи и предпринимаются попытки по координации работы. Таким образом пытаются скоординировать работу и понять сложность. Такой подход – благо для компаний по разноске еды, доставляющих феерические ланчи, но в нашем случае не работает. Дело в том, что по мере увеличения численности группы приоритетных проектов становится все больше, а сами они уменьшаются. Поэтому фундаментально решить проблемы хрупкости и сложности не удается. Со временем масштабный Agile дает тактический перечень задач, напоминающий список покупок, и все меньше походит на целостный путь от одной продуманной фичи к другой.
Во-вторых, внутрикорпоративные “инновационные группы” часто пытаются продвигать периферийные изменения, в надежде, что эта работа приживется в хрупкой машине, и вся структура изменится к лучшему. Такой подход дает причудливый побочный эффект: закрепляется убеждение, что вносить изменения в процесс вправе лишь такие «группы инноваторов». Поэтому подобный метод также не решает проблем с организационной сложностью.
Насмотревшись за много лет на разнообразные провалы, я пришел к выводу, что требуется хакнуть все три фактора, чтобы предотвратить их совокупное воздействие на выполняемую работу и справиться с инерцией:
- Хрупкость не должна возрастать в последующих версиях или по мере старения продукта.
- Кусок работы не должен быть меньше, чем требуется для создания фичи, значимой с точки зрения пользователя.
- Сложность не должна сказываться на труде отдельно взятого разработчика.
Если удастся взять на вооружение эти идеи, то вы убережетесь от рока, преследующего все программные продукты в истории человечества. Звучит отлично, но как же этого добиться?
Если удастся взять на вооружение эти идеи, то вы убережетесь от рока, преследующего все программные продукты в истории человечества. Звучит отлично, но как же этого добиться?
Бессерверные технологии ломают ограничения
Благодаря возникновению облачных технологий, удалось проложить важные тропки к новому «хакнутому» состоянию. В целом, с появлением облаков процесс поставки программного продукта стал компактнее, поскольку массу рутинных вещей провайдер стал делать за вас. До появления облаков, если вам нужно было реализовать новую пользовательскую фичу, то приходилось заказать сервера, установить оборудование на стойках, договориться о прокладке сетей в датацентре, а затем поддерживать это оборудование, которое со временем изнашивается. В облаке все это можно арендовать, избавившись таким образом от десятков оргмоментов и сэкономив целые месяцы.
Кроме того, избавляясь от необходимости апгрейда оборудования в датацентре и обеспечивая доступ к аппаратному обеспечению по требованию, мы снижаем как хрупкость, так и сложность. Пустить программы в ход становится гораздо проще, чем в старые времена. Однако, со временем значительно возросло бремя, связанное с администрированием обширной виртуальной инфраструктуры, а многие устаревшие методы доставки остались без изменений. Пользуясь облаками, команду можно существенно нарастить, прежде, чем работа начнет замедляться – однако, она начнет замедляться, так или иначе.
Бессерверные технологии радикально меняют эту динамику. Бессерверное приложение состоит из небольших фрагментов кода, написанных вашей командой (т.н. «клей») и функциональных «черных ящиков», которыми управляет облачный провайдер. Черный ящик просто принимает конфигурацию и реагирует на изменения. В приложении с качественной архитектурой на стандартные черные ящики ложится существенная часть эксплуатационной работы, связанной с функционированием приложения. Само приложение – более не монолитная функция, а федеративная структура из функций и черных ящиков.
На практике это драматически сказывается на трех факторах, упомянутых мною выше:
- Хрупкость уменьшается благодаря нулевым затратам на управление инфраструктурой и слабому связыванию. В наших собственных проектах доводилось наблюдать, что база кода в результате таких изменений иногда может сократиться вдесятеро.
- Размер «куска работы» обычно сопоставим с затратами на создание новой фичи, поскольку становится тривиально создавать новые версии функций или совершенно новые функции, которые ранее не требовались.
- Сложность не затрагивает разработчика – если он может написать функцию, обрабатывающую платеж с кредитной карты, то практически ничего сверх этого кода в бессерверном приложении делать не придется, никаких организационных оберток и никакого учета экосистемы, из-за которого работа могла бы замедлиться.
При управлении даже очень крупными бессерверными приложениями продакт-менеджеру легко присмотреться именно к тем считанным элементам, которые были затронуты сделанными изменениями. Кроме того, несложно запускать две версии конкурентно, расставив флаги фич. Более того, обычно даже не требуется сносить старые версии кода.
В бессерверных приложениях инфраструктура всегда достраивается на периферии, и вы пишете лишь необходимый минимум кода, объединяющий полностью управляемые сервисы. Задумываться о них с эксплуатационной точки зрения не приходится никогда. Мы не пытаемся управлять монолитом, прибирать за собой старый код или рассматривать всю систему с высоты птичьего полета.
Почему это безмерно важно
По мере того как темп внесения изменений увеличивается, становится все сложнее спрогнозировать, как станет в будущем выглядеть ваша программа, или чего от вас захотят пользователи. Поэтому все более бесплодными становятся попытки писать код «на века», такой, что обязательно должен работать в будущем, несмотря ни на какие изменения. Мы убедились, как плохо в большинстве компаний обстоят дела с переиспользованием кода, и как приверженность к устаревающим платформам тормозит прогресс.
Сейчас все устроено так, что старая система разрабатывается и поддерживается настолько долго, насколько это возможно, пока ее поддержка не начинает отбирать у программиста почти все время. После этого компания начинает все с нуля уже с новой системой, торжественно обещая не повторять ошибок, допущенных в старой. Когда три фактора рано или поздно удушают и новую систему, происходит технологический «лесной пожар», после которого опять приходится все начинать заново.
Мы повернуты на борьбе с симптомами сложности, именно поэтому так много парадигм приходит и уходит, не оставляя существенного следа в истории продакт-менеджмента. Бессерверная разработка, в свою очередь, позволяет команде свести к минимуму нарастание сложности и продолжать выдавать ценный продукт в довольно ровном темпе, не попадаясь в классические ловушки, которые целыми десятилетиями остаются бичом всякой разработки ПО.
Бессерверная парадигма только начинает развиваться, но уже кажется исключительно многообещающей. Во времена, когда клиент требует от вас новых фич как никогда ранее, продакт-менеджеры наконец-то могут обзавестись платформой, позволяющей мыслить именно исходя из подготовки новых фич. Этот процесс не тормозится возрастающей организационной сложностью, а также не стопорится из-за излишней хрупкости.
Автор: ph_piter
