Представим, что команда ищет причину медленной работы API, программного интерфейса сервиса. Разработчики подозревают базу данных и добавляют подробную трассировку запросов. Ожидаемого подтверждения они не получают. Зато на графике видят другое: сервис при каждом обращении заново устанавливает защищённое соединение с соседней системой.

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

Можно назвать результат удачей. Но одной удачи недостаточно. Без трассировки необычное поведение осталось бы невидимым. Без понимания сетевого обмена разработчики приняли бы его за несущественную деталь. Без проверки они получили бы только любопытную догадку.

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

Нельзя запланировать, что именно обнаружит команда в следующую среду. Зато можно устроить работу так, чтобы неожиданный факт не потерялся, а на его проверку не понадобился отдельный год исследований.

Случайность - только половина определения

Слово serendipity придумал английский писатель Хорас Уолпол. В письме Хорасу Манну от 28 января 1754 года он вспомнил сказку «Три принца Серендипа». Её герои находили то, чего не искали, благодаря сочетанию случая и наблюдательности. Уолпол описал это как открытия, сделанные с помощью accidents and sagacity - случайностей и проницательности. Письмо сохранилось в издании переписки Уолпола Йельского университета.

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

Полезно различать четыре ситуации.

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

Как наблюдение становится открытием

Стефан Макри и Энн Блэндфорд провели подробные интервью с 28 исследователями из 11 преимущественно междисциплинарных областей. Участники вспоминали случаи, когда неожиданно находили полезную информацию в научной работе или обычной жизни.

Авторы обнаружили в рассказах общий процесс:

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

Например, исследователь ищет материал для одного проекта и замечает статью, которая отвечает на давний вопрос из другого. В момент встречи ещё ничего не открыто. Он должен понять, к какой задаче относится статья, оценить идею и что-то сделать: прочитать первичный источник, обсудить связь с коллегой или провести проверку.

Авторы подчёркивают, что ценность часто становится понятна постепенно. Человек несколько раз возвращается к найденной связи, пробует её развить и пересматривает оценку. Лишь оглядываясь назад, он называет всю последовательность серендипностью. Coming across information serendipitously: Part 1 - A process model.

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

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

Подготовленный ум замечает больше

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

Предварительные знания не гарантируют открытие, но позволяют распознать значение нового факта. Уэсли Коэн и Дэниел Левинталь назвали похожее свойство организации поглощающей способностью (absorptive capacity). Под ней они понимали способность заметить ценность новой внешней информации, усвоить её и применить. По их модели эта способность зависит от уже накопленных связанных знаний и разнообразия опыта. Absorptive Capacity: A New Perspective on Learning and Innovation.

На практике это объясняет, почему широкая осведомлённость и глубокая специализация нужны одновременно.

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

T-shaped generalist: глубокая специализация и широкий кругозор

Такой профиль знаний часто описывают метафорой T-shaped generalist, или «Т-образный специалист».

Вертикальная черта буквы T означает глубокую компетентность в основной области. Например, разработчик хорошо понимает устройство распределённых хранилищ, умеет разбирать их сбои и проверять изменения под нагрузкой. Горизонтальная черта означает, что он достаточно знает о сетях, эксплуатации, безопасности, продуктовых метриках и устройстве бизнеса, чтобы задавать содержательные вопросы и понимать ограничения коллег.

Слово generalist здесь не означает, что человек одинаково хорошо делает всё. У него остаётся основная специализация. Широта нужна, чтобы понимать язык других специалистов, замечать связь между областями и вовремя обращаться за более глубокой экспертизой.

Для серендипности полезны обе части T:

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

В примере с медленным API основной специализацией может быть серверная разработка, а понимание сетевого обмена относится к соседней области. Разработчику не обязательно становиться сетевым инженером. Достаточно распознать, что число новых защищённых соединений выглядит неправильно, сформулировать вопрос и привлечь коллегу, если первая проверка требует более глубоких знаний.

Мортен Хансен и Болко фон Этингер использовали похожую метафору для руководителей. Вертикальная часть обозначала ответственность за результат своего подразделения, а горизонтальная - обмен знаниями между подразделениями. По их описанию, такие связи помогают переносить удачные практики и соединять идеи, которые иначе остались бы внутри отдельных групп. Introducing T-Shaped Managers: Knowledge Management’s Next Generation.

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

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

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

Хороший эксперимент оставляет место для неожиданного

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

В одном из описанных случаев контрольное условие сработало лучше экспериментальных. Исследователи не списали результат на помеху, а сосредоточились на нём и обнаружили другой механизм переноса дезоксирибонуклеиновой кислоты (ДНК). Данбар отмечал, что неожиданные результаты контрольных условий встречались в лабораториях регулярно и становились источником открытий, когда учёные продолжали их исследовать. How Scientists Really Reason: Scientific Reasoning in Real-World Laboratories.

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

Для этого нужны вполне обычные вещи:

• метрики по отдельным этапам, а не только среднее время всей операции;
• трассировка запроса через границы сервисов;
• контрольное выполнение с прежней конфигурацией;
• профилирование реальной нагрузки;
• проверка инвариантов, которые не должны нарушаться;
• журнал не только успешных действий, но и причин отказа.

Наблюдаемость обычно обсуждают как способ быстрее подтвердить известную гипотезу. Но у неё есть вторая роль: помочь команде увидеть то, о чём она не догадалась спросить.

Правило простое: эксперимент должен уметь не только ответить «да» или «нет», но и показать, где реальность разошлась с ожиданием.

Команда видит то, чего не видит отдельный специалист

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

Социолог Рональд Бёрт изучал сеть рабочих контактов 673 руководителей цепочки поставок в крупной американской компании по производству электроники. 455 участников ответили на вопросы о своих профессиональных связях и предложили идеи по улучшению работы. Руководители, чьи контакты связывали слабо общавшиеся группы, чаще предлагали идеи, которые эксперты компании оценивали как полезные.

Бёрт объяснял связь так: внутри тесной группы люди получают похожую информацию, а на границе групп встречают другие способы мыслить и действовать. Там легче перенести практику из одного контекста в другой. Structural Holes and Good Ideas.

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

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

• разбирать на общем техническом обзоре не хронологию инцидента, а обнаруженный механизм;
• приглашать на ревью архитектурного решения человека из соседней предметной области;
• показывать короткие демонстрации не только успешных функций, но и неожиданных результатов экспериментов;
• записывать в ADR, коротком документе об архитектурном решении, не только выбранный вариант, но и отвергнутые варианты с причинами;
• временно подключать разработчика к задаче другой команды, если там возник знакомый класс проблем.

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

Почему эффективность мешает находкам

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

Джеймс Марч описывал похожее напряжение как выбор между исследованием (exploration) и использованием известного (exploitation). Организация должна одновременно искать новые возможности и улучшать уже работающие решения. Использование известного быстрее даёт понятный результат, поэтому со временем процессы естественно начинают поддерживать именно его. В короткой перспективе система становится эффективнее, но постепенно сужает набор вариантов, из которых сможет выбирать дальше. Exploration and Exploitation in Organizational Learning.

В разработке перекос заметен по простым признакам:

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

Полная свобода не решает проблему. Если каждый инженер следует за любой интересной аномалией, команда перестаёт завершать основную работу. Серендипность плохо чувствует себя и в конвейере без отклонений, и в бесконечном исследовании всего любопытного. Календарь с задачей «с 14:00 до 15:00 совершить неожиданное открытие» тоже вряд ли спасёт положение.

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

Практика ограниченного исследования

Команде не нужен отдельный процесс управления серендипностью. Достаточно встроить несколько действий в обычную разработку.

Сохраняйте отклонение вместе с контекстом

Запись «иногда растёт задержка» почти бесполезна. Нужны условия, при которых это произошло, ожидаемое поведение, наблюдаемый результат и ссылка на данные.

Короткая запись может выглядеть так:

Наблюдение: при включённом пуле соединений число новых защищённых
соединений растёт вместе с числом запросов.

Почему странно: соединения должны переиспользоваться.

Возможная связь: задержка соседнего сервиса после обновления клиента.

Самая дешёвая проверка: сравнить два экземпляра с новой и прежней
версией клиента на одинаковом трафике.

Так команда может вернуться к сигналу позже, не восстанавливая обстоятельства по памяти.

Отделяйте интерес от ценности

Необычный факт достоин короткого вопроса, но не автоматически отдельного проекта. Перед исследованием полезно проверить три вещи:

1. С какой проблемой или возможностью связан сигнал?
2. Какой результат изменит решение команды?
3. Какая проверка даст ответ с наименьшими затратами?

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

Ограничивайте первую проверку

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

Полезно заранее задать время и условие остановки. Если за этот срок связь не подтверждается, команда возвращается к основной задаче или формулирует, каких данных не хватает. Серендипность не выдаёт бессрочный бюджет на любимую техническую идею.

Проверяйте находку независимо

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

• повторное наблюдение;
• сравнение с исходным вариантом;
• альтернативное объяснение;
• проверка на других данных или в другой среде;
• явное описание границ результата.

История становится интереснее, если случайная находка «всё объяснила». Система от этого объяснения надёжнее не становится.

Возвращайте результат в общую память

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

Что можно сделать лично

Для отдельного инженера серендипность начинается не с бесцельного чтения всей ленты. Полезнее сочетать несколько простых привычек:

1. Держать список открытых вопросов, а не только текущих задач. Новому факту тогда есть с чем соединиться.
2. Читать материалы из соседних областей, где встречаются другие механизмы и ограничения.
3. При неожиданном результате спрашивать: «Какое моё предположение он нарушает?»
4. Записывать находку до того, как внимание вернётся к основной работе.
5. Проверять первое объяснение до того, как рассказывать историю об открытии.

С первым советом связана известная история о Ричарде Фейнмане. Математик Джан-Карло Рота вспоминал, что Фейнман советовал постоянно держать в уме не десять, как иногда пересказывают эту историю, а дюжину любимых задач. Большую часть времени вопросы оставались без движения. Когда Фейнман узнавал о новом приёме или результате, он мысленно проверял, не подходит ли тот к одной из этих задач. Иногда связь находилась, и со стороны решение выглядело внезапной вспышкой гениальности. Ten Lessons I Wish I Had Been Taught.

Список создавал постоянный контекст для новых идей. Без открытого вопроса интересный метод легко остаётся просто любопытным фактом. Если вопрос уже сформулирован, человек может сразу проверить новое знание на подходящей задаче. Получается тот же механизм серендипности: встреча с методом случайна, но связь возникает благодаря заранее подготовленной проблеме.

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

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

Неслучайная случайность

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

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

Мы не управляем моментом встречи с неожиданным. Мы управляем тем, заметим ли его, проверим ли и превратим ли в знание. В этом смысле серендипность действительно случайна только наполовину.

Дополнительные материалы

1. Stephann Makri, Ann Blandford. Coming across information serendipitously: Part 1 - A process model
2. Kevin Dunbar. How Scientists Really Reason: Scientific Reasoning in Real-World Laboratories
3. Wesley M. Cohen, Daniel A. Levinthal. Absorptive Capacity: A New Perspective on Learning and Innovation
4. Ronald S. Burt. Structural Holes and Good Ideas
5. James G. March. Exploration and Exploitation in Organizational Learning
6. Morten T. Hansen, Bolko von Oetinger. Introducing T-Shaped Managers: Knowledge Management’s Next Generation
7. Gian-Carlo Rota. Ten Lessons I Wish I Had Been Taught

Комментарии в Telegram-группе!