Свобода — это отсутствие зависимости.
Дада Бхагван
1.2
НЕИЗВЕСТНЫЕ ЗАВИСИМОСТИ
Мой друг работает в компании с годовым доходом в $23 млрд, где продуктовая команда X развернула компонент, который сломал продукт команды Y. Теперь клиенты команды Y должны раскошелиться на $5 млн за новый продукт Y. И это помимо $10 млн, которые они только что заплатили за свежий компонент X, потому что прежний уже устарел и не поддерживался. Клиенты в этой ситуации использовали продукты обеих команд — X и Y. Продукту Y нужен продукт X, чтобы корректно функционировать. Единственная возможность удовлетворить потребности клиентов команды Y — купить новый компонент X.
Итак, назрела настоящая PR-катастрофа в этой компании. Организация потеряет значительную долю рынка из-за того, что две продуктовые группы не общаются друг с другом. Команда Y не принимала никакого участия в решении команды X выпустить новую версию софта, от которого зависел их продукт. Начались взаимные обвинения и выяснения отношений, и теперь вице-президент готовится расстаться с головой. Если группы не владеют критически важной информацией, это им дорого обходится. Именно так происходит, когда возникают неизвестные зависимости.
Определим значение слова «зависимости». С моей точки зрения, можно говорить о трех типах зависимостей:
- Архитектура (программного обеспечения и аппаратной части) — где изменения в одной области могут нарушить функционирование другой области (например, вывести ее из строя).
- Экспертиза — когда нужна консультация или помощь человека с конкретными знаниями.
- Действие — когда достичь цели невозможно, пока не будет выполнено определенное действие.
Если ваш менеджер застрял на встрече и вы не можете получить его разрешение и зарегистрироваться на конференции до конца рабочего дня, то вы зависимый сотрудник. Другой пример — ждать тестовую среду или восстановление базы данных, чтобы продолжить работу.
Сильносвязанная архитектура — неизменная жертва неизвестных зависимостей. Когда решение удалить таблицу из базы данных оказывает негативное воздействие на другую команду, неизвестные зависимости отнимают много времени. Это пример зависимости исходного кода.
Навыки специалистов подвергаются особенно разрушительному воздействию этого расхитителя. Разработчик думает: «Есть ли в этом коде неизвестные уязвимости?» — и ждет мнения эксперта по безопасности. Однако тот занят выяснением, как и почему кто-то взломал его незащищенную базу данных. Вопрос требует вмешательства архитектора баз данных. «Данные в тестовой среде некорректны? Можно проверить?» Однако архитектор баз данных занят, он помогает эксперту по безопасности. Когда в команде только ты обладаешь особыми навыками, тебя будут разрывать на части. Востребованные узкоспециализированные умения часто недоступны. Расхититель по имени «Неизвестные зависимости» ухмыляется с наслаждением.
Схожая проблема связана с изменениями, которые выходят за рамки вашего контроля, — например, в лице сторонних вендоров. Крупные облачные провайдеры, такие как Amazon EC2, Microsoft Azure и Google Compute Engine, предоставляют соглашения о качестве своих услуг, которые гарантируют клиентам 99,95% времени работоспособности. То есть 22 минуты допустимого простоя в месяц. Когда ваш облачный провайдер недоступен, вы тоже недоступны, и расхититель по имени «Неизвестные зависимости» смеется над вами от души. Конечно, облачный провайдер — известная зависимость, но всегда ли вы знаете, когда его заклинит? Сколько времени команда тратит на поиск и решение проблем, прежде чем понять, что во всем виноват облачный провайдер, который напортачил в информационном центре со свечным графиком? Вы все равно в проигрыше, даже если это его вина, потому что вы ограничены соглашением. Возможно, вы получите компенсацию в виде дополнительного времени, но, если ошибка случится, как долго вы будете восстанавливать утерянные данные? Если подсчитать, какое количество часов команда тратит на урегулирование подобных ситуаций, то сколько времени украдено на самом деле?
Почему зависимости так опасны
На аgile-конференции 2015 года в Вашингтоне с крайне информативной речью по поводу зависимостей выступил Трой Магеннис. Он опирался на базовые принципы булевой логики (когда все параметры можно разделить на истину и ложь) и показал, что есть только одна комбинация действий, которая приносит результат четко в намеченный срок. Каждый раз, когда вы убираете одну зависимость, устраняется половина общей возможной задержки. Если для достижения результата нужно выполнить все пункты, каждая удаленная зависимость удваивает шансы на то, что вы достигнете результата вовремя .
Приведем пример. Если для достижения цели нужны два входных элемента, есть только один шанс из четырех, что вы получите результат вовремя. Один шанс из 2n — формула для расчета общего числа бинарных перестановок.
Да ладно, математика — это весело! Вы же поняли. В двоичной, бинарной, системе числа записываются с помощью двух символов — 0 и 1. Перестановка — это варианты сочетаний. Бинарная перестановка в таком случае — сочетание бинарных чисел. 2n — это 2 в степени n. Когда число входных элементов равно двум, n = 2, и мы имеем 2 × 2, то есть 4, или 22.
Давайте все запишем и посмотрим, как это работает. Два вводных элемента предполагают четыре возможных варианта.
Если нужны три входных элемента, только одним способом из восьми можно выполнить работу вовремя.
Достаточно, к примеру, убрать строгую зависимость от развертки, и вы удвоите шансы (с одного из восьми до одного из четырех) на то, что развертывание произойдет вовремя. Всегда есть только один вариант, что все будет сделано вовремя.
Представьте, что вы забронировали столик на четверых, каждый идет в ресторан самостоятельно. Вам поставили условие, что сесть за столик вы сможете только тогда, когда придут все четыре гостя. Количество возможных вариантов равно 16.
То есть 16 возможных комбинаций относительно того, окажутся люди на месте вовремя или нет. Если составить таблицу, то в 15 вариантах хотя бы один человек всегда опаздывает и есть только один случай, когда все приезжают вовремя. Зависимости оказывают асимметричное воздействие. С четырьмя зависимостями вероятность того, что вас не посадят за столик, составляет не 25%, а 93% (15 из 16). Высока вероятность того, что кто-то все-таки опоздает. Лучше сразу откланяться и отправиться в бургерную.
Рисунок 3 помогает визуально представить расчеты по трем зависимостям, где вероятность получить столик вовремя составляет 12,5%. Если добавить еще одну зависимость, шанс получить столик всего один из 16, или 6,25%. Если, конечно, ваши гости не работают в IT-отделе — в таком случае они ни за что не уйдут с работы пораньше, чтобы приехать в ресторан вовремя.
Рис. 3. Три зависимости
Вы поймете, что неизвестные зависимости крадут у вас время, если:
- работа требует особой координации и проект-менеджеры носятся взад-вперед, чтобы состыковать всех;
- люди недоступны, когда они нужны вам;
- изменение в одной части кода/плана неожиданно влияет на что-то другое.
Когда пиццерия доставляет больше двух единиц по одному адресу, в один конференц-зал, к примеру, будьте внимательны. По правилу двух пицц команда должна быть такой, чтобы ее можно было накормить двумя пиццами — примерно от пяти до семи человек, хотя все зависит от аппетита. Если три такие группы должны провести общую встречу, чтобы обсудить свои зависимости друг от друга, расходы на координацию будут высоки. От 15 до 21 человека, отстаивающих свою точку зрения, могут занять много времени. Когда на вашей памяти последний раз 15 человек приходили к соглашению? Если координационные требования высоки, люди недоступны, когда они вам нужны.
Небольшие команды быстрые и мобильные. Нет ничего лучше малой сплоченной группы, в которой умеют эффективно общаться и сотрудничать. Проблемы начинаются, когда зависимости охватывают несколько команд и все идет наперекосяк. Когда одна команда нарушает работу другой, внося противоречивые изменения, последствия могут быть разрушительными, как мы говорили в начале параграфа, где речь шла о компании с годовым оборотом в $23 млрд. Если мы пытаемся улучшить производительность отдельных команд, разбивая их на небольшие группы, не избежать скрытой опасности, особенно когда между ними существуют неизвестные зависимости.
Межкомандное общение — это всегда трудно. Когда несколько небольших групп со множеством взаимозависимостей уделяют много времени координации работы, чтобы не наступать друг другу на код (из-за слияния веток кода разных команд), их преимущества бледнеют. Малые группы могут увеличить расходы на интеграцию. Нам они нравятся, потому что мобильные и скорые. Однако подумайте вот о чем: как отдельная команда вы работаете быстро, но как организация — со скоростью улитки.
Наконец, вспомните общие характеристики слишком большого WIP: дорогостоящее переключение контекста и прерывание работы. Все, что отвлекает от дела, — одно из самых серьезных препятствий к качественному результату умственного труда, и это стоит примерно один триллион долларов в год .
КЛЮЧЕВЫЕ ВЫВОДЫ
- Если команды не знают о взаимоважной информации, компании это дорого обходится.
- Когда архитектура, специальные знания и задачи лежат мертвым грузом в режиме ожидания — это одна из самых распространенных зависимостей.
- Каждая зависимость повышает вероятность опоздания. Если возможно, сократите их число, чтобы сэкономить время и деньги и избежать других осложнений. И наоборот, каждая зависимость, которую можно найти и исключить, удваивает шансы на своевременное выполнение работы.
- Если работа требует высокой степени координации, люди недоступны, когда они нужны. То же самое касается экспертов — когда спрос на их навыки и знания высок, эксперты недоступны.
- Если говорить о зависимостях, рост результативности отдельной команды может пагубно отразиться на эффективности всей компании.
