Информационные силосы между инженерией и продуктом
PM-ы и инженеры работают в разных инструментах, с разным языком и таймлайнами. Как формируется силос – и что действительно помогает.
By Ellis Keane · 2026-03-16
В какой-то момент «согласованность продукта и инженерии» превратилась в должность, а не в то, что просто происходит само собой, когда компетентные люди работают вместе. Компании теперь нанимают специальных людей, единственная цель которых – убедиться, что две группы умных людей – находящихся в одном Slack-воркспейсе, посещающих одни и те же стендапы и теоретически работающих к одним целям – могут реально понять, что делает другая группа. Информационные силосы между инженерией и продуктом, которые делают это необходимым, – это не проблема людей. Это проблема инструментов.
PM-ы и инженеры общаются достаточно много. Проблема в том, что они работают в совершенно разных системах, и силосы, которые образуются между этими системами, носят структурный характер – они вшиты в архитектуру того, как современные команды выбирают инструменты. Никакое количество «давайте согласовываться чаще» не исправит проблему, при которой сами инструменты ничего не знают друг о друге.
Две реальности
Здесь я опираюсь на наш собственный опыт построения Sugarbug, потому что мы живём этим каждый день и считаю, что конкретика полезнее абстракции.
Сторона PM-а (в нашем случае это в основном я) живёт в Notion. Там пишутся спецификации, отслеживаются приоритеты, записываются разговоры с клиентами, каталогизируются запросы функций в постоянно растущих списках. Notion – это место, где живёт «почему» – почему мы что-то строим, что на самом деле сказал клиент, какой стратегический контекст стоит за конкретным решением. Это беспорядочно, обширно, и именно здесь происходит большая часть важного мышления ещё до того, как написана хоть одна строка кода.
Тем временем наши инженеры живут в Linear и GitHub. В Linear хранятся задачи, спринт-циклы, цепочки зависимостей и блокирующие задачи. В GitHub – код, пул-реквесты, ревью-треды, где люди конструктивно (будем надеяться) спорят о деталях реализации. Там живёт «как» и «когда» – как что-то строится, когда будет выпущено, что мешает.
Обе реальности точны, обе необходимы, и они полностью разобщены друг с другом. Пробел между ними – это место, где требования устаревают и начинает накапливаться переработка.
Как на самом деле формируются информационные силосы между инженерией и продуктом
Соблазнительно думать, что это намеренный выбор – что кто-то решил держать информацию отдельно. На практике силос формируется через совершенно разумное поведение, которое никто не собирался делать вредным.
PM пишет спецификацию в Notion, делится ссылкой в Slack в инженерном канале и считает передачу завершённой. Инженер читает спецификацию, создаёт из неё три задачи в Linear и начинает работать. Пока всё работает.
Но потом спецификация меняется – разговор с клиентом смещает приоритет, или деловой контекст эволюционирует. PM обновляет документ в Notion и оставляет заметку в Slack об изменении. Инженер, глубоко погружённый в сессию кодирования, не видит сообщение в Slack несколько часов. К тому времени он уже построил две из трёх функций по старой спецификации, а третья задача в Linear по-прежнему ссылается на требования, которые больше не существуют.
Здесь никто не был небрежным. Никто «не смог донести информацию». Информация жила в одной системе, а работа происходила в другой, и связующей тканью между ними было сообщение в Slack, которое было погребено под другими тредами до того, как нужный человек его увидел.
Это происходит снова и снова – при каждой спецификации, каждом спринте, каждом квартале – и расхождение накапливается. Пробел между тем, что продукт думает, что происходит, и тем, что инженерия на самом деле строит, расширяется при каждой передаче, которая зависит от того, заметит ли человек сообщение в нужный момент.
Почему «лучшая коммуникация» не исправляет это
Я сидел на ретроспективах, где пунктом действий было «более проактивно сообщать об изменениях», и (с любовью говоря) это организационный эквивалент того, чтобы сказать кому-то быть просто более организованным. Звучит как что-то действенное, делает страницу в Confluence продуктивной на вид, и абсолютно ничего не меняет в системе, которая вызвала проблему. Мы проводили тот же пункт действий ретроспективы три раза – я проверял.
Причина, по которой лучшая коммуникация не решает информационные силосы между инженерией и продуктом, состоит в том, что коммуникация уже происходит – данные существуют, решения принимаются и записываются. Они просто записаны в инструментах, которые ничего не знают друг о друге.
Notion не знает, что спецификация была разбита на три задачи в Linear. Linear не знает, что требования, лежащие в основе задачи, изменились в Notion два часа назад. GitHub понятия не имеет, что пул-реквест на рассмотрении реализует функцию, приоритет которой только что был понижен на доске Notion PM-а. Каждый инструмент работает именно так, как задумано – просто они не были задуманы для совместной работы.
«Есть своеобразная тёмная комедия в том, чтобы проводить утро понедельника, подтверждая, что инструменты, за которые ты платишь, незаметно не разошлись с реальностью за выходные.» – Ellis Keane
Так что происходит следующее: PM-ы вручную дублируют изменения из Notion в Linear при смене спецификаций, инженеры пингуют PM-ов в Slack с вопросом «это ещё план?», а лидеры проводят утро понедельника, перекрёстно сверяя доски в поисках расхождений. Мы наблюдали, как сами тратим несколько часов в неделю на то, что представляет собой ручную синхронизацию данных между инструментами, которые теоретически уже должны знать друг о друге.
Как на самом деле выглядит системное исправление
Инстинкт, когда видишь пробел между двумя инструментами, – построить мост: автоматизацию Zapier, вебхук, скрипт синхронизации. Для простых, предсказуемых рабочих процессов (когда задача в Linear переходит в «Готово», обновляется статус в Notion) это работает нормально.
Но информационные силосы между инженерией и продуктом включают контекст, а не только статус. PM не просто изменил поле статуса; он переписал абзац в спецификации, который меняет смысл «готово» для двух из трёх задач в Linear. Простые вебхуки статуса пропускают изменения на уровне требований, если не добавить сверху логику диффа и семантическое отображение, что большинство команд так и не успевают построить.
То, что вам на самом деле нужно, – это нечто, понимающее связи между данными в разных инструментах – не просто «эта страница Notion связана с этой задачей Linear», но «этот раздел спецификации описывает требования для этой задачи, и этот раздел только что изменился». Цель – автоматически отображать правки спецификации на затронутые задачи, а не полагаться на то, что кто-то это заметит и распространит изменение.
Это и есть разница между слоем синхронизации и графом знаний. Слой синхронизации копирует данные между инструментами. Граф знаний отслеживает, как данные соотносятся, обнаруживает изменения этих связей и показывает изменения людям, которым нужно знать.
Мы строим Sugarbug, чтобы он работал именно так – соединяя инструменты, которые PM-ы и инженеры уже используют (Notion, Linear, GitHub, Slack, Figma), в граф знаний, который поддерживает связи между спецификациями, задачами, кодом и переговорами. Мы ещё на ранней стадии (честно говоря, многое ещё не решено о том, как сделать семантическое обнаружение диффов надёжным в масштабе), но базовый граф работает и уже уловил ситуации с расхождением спецификаций, которые превратились бы в переработку.
Информационные силосы между инженерией и продуктом формируются потому, что инструменты структурно разобщены, а не потому, что люди плохо общаются. Исправление заключается в соединении данных на уровне связей, а не в добавлении новых каналов коммуникации.
Что можно сделать на этой неделе
Я не буду делать вид, что единственный ответ – «используйте Sugarbug». Есть вещи, которые можно сделать прямо сейчас, с теми инструментами, которые вы уже используете, чтобы снизить худшие последствия силоса данных продукт-инженерия.
Делайте перекрёстные ссылки явными, двунаправленными и закреплёнными за ответственным. У каждой спецификации в Notion должен быть раздел «Задачи Linear» в нижней части со ссылками на задачи, которые она породила, а у каждой задачи в Linear должна быть ссылка обратно на исходную спецификацию. Назначьте одного человека на спецификацию отвечать за перекрёстные ссылки – не всю команду, одного человека с его именем. Мы пробовали версию «все ответственны» и (предсказуемо) никто не был ответственен. Ссылки будут расходиться со временем в любом случае, но наличие назначенного ответственного означает, что есть кому написать, когда расхождение обнаружено.
Установите ритуал «смены спецификации» с триггером, а не напоминанием. Когда спецификация меняется существенно (не опечатки – фактические изменения требований), PM обновляет связанные задачи в Linear перед закрытием вкладки Notion. Не позже, не «когда будет возможность» – перед закрытием вкладки. Комментарий к каждой затронутой задаче должен быть в одну строку: что изменилось, ссылка на обновлённый раздел и актуальны ли ещё критерии принятия задачи. Мы обнаружили, что привязка обновления к физическому действию (закрытие вкладки) работает лучше, чем полагаться на чью-то память, потому что именно память и стала причиной образования силоса с самого начала.
Проводите 15-минутную проверку соответствия приоритетов каждую пятницу. Один человек (ротируясь еженедельно) открывает топ-5 приоритетов PM-а в Notion и топ-5 инженерного спринта в Linear рядом друг с другом. Вопрос не «идентичны ли они?» – они не будут, и это нормально. Вопрос: «есть ли среди них активно противоречащие друг другу?» Если приоритет #1 PM-а нигде не фигурирует в спринте, вот разговор для понедельника, а не обновление статуса.
Это ручные процессы, и у них есть срок годности. При пяти инженерах и двух PM-ах они утомительны, но работают. При пятнадцати инженерах, трёх PM-ах и дизайнерской команде, добавляющей Figma в смесь, межинструментальные связи множатся быстрее, чем кто-либо может отслеживать вручную. Но они покажут вам, где на самом деле находятся ваши худшие пробелы в согласованности продукта и инженерии – и эта диагностическая ценность оправдывает усилия, даже если вы в конечном счёте автоматизируете всё.
Будет ли долгосрочным решением Sugarbug или что-то другое (мы очевидно думаем, что строим правильную вещь, но я предвзят), проблема сотрудничества между управлением продуктом и инженерией решается только тогда, когда сами инструменты соединены на семантическом уровне, и люди могут сосредоточиться на принятии решений, а не перемещать контекст между приложениями.
Если ваши ручные перекрёстные ссылки работают, используйте это, пока продолжается. Если вы снова и снова видите одни и те же пункты ретроспективы о коммуникации, проблема не в ваших людях. Это ваша архитектура данных.
Подключите Notion, Linear, GitHub и Slack к единому графу знаний – чтобы изменения спецификаций автоматически доходили до нужных инженеров.
Q: Сколько времени занимает настройка Sugarbug для продуктово-инженерной команды? A: Первоначальное подключение занимает несколько минут на каждый инструмент – вы аутентифицируете Linear, GitHub, Notion, Slack и Figma через OAuth, и Sugarbug сразу начинает строить граф знаний. Граф становится по-настоящему полезным через один-два дня, пока поглощает ваши существующие данные и начинает отображать связи между спецификациями, задачами и разговорами. Мы ещё совершенствуем процесс онбординга, но цель – чтобы вам не нужно было ничего настраивать, кроме подключения аккаунтов.
Q: Заменяет ли Sugarbug Linear, Notion или какие-либо из наших существующих инструментов? A: Нет. Sugarbug работает рядом с вашими существующими инструментами и связывает их – не заменяя ни один из них. Ваши PM-ы продолжают писать спецификации в Notion, ваши инженеры продолжают работать в Linear и GitHub, а Sugarbug поддерживает связи между ними, чтобы контекст не терялся при передаче. Думайте об этом как о связующей ткани между инструментами, которые вы уже используете.
Q: Может ли Sugarbug обнаружить изменение спецификации в Notion и уведомить нужных инженеров? A: Это ключевая часть того, что мы строим. Когда спецификация изменяется в Notion, Sugarbug определяет, какие задачи в Linear с ней связаны, и показывает изменение инженерам, работающим над этими задачами. Мы ещё совершенствуем часть семантического обнаружения (определение, какие изменения существенны, а какие косметичны), но межинструментальное связывание и базовое обнаружение изменений работают.
Q: В чём разница между инструментом синхронизации и графом знаний для этой задачи? A: Инструмент синхронизации копирует изменения статуса между приложениями – когда задача в Linear переходит в «Готово», обновляется флажок в Notion. Граф знаний отслеживает, как данные соотносятся: эта спецификация описывает требования для этих трёх задач, и критерии принятия изменились, что затрагивает две задачи, которые ещё не были выпущены. Разница наиболее важна, когда изменения семантические, а не просто на уровне статуса.
Q: Проблема согласованности продукта и инженерии – это проблема коммуникации или проблема данных? A: По нашему опыту, это почти всегда проблема данных, которую ошибочно диагностируют как проблему коммуникации. Команды общаются – просто через инструменты, которые ничего не знают друг о друге. Исправление потока данных между этими инструментами, как правило, решает проблемы согласованности, которые не могли решить ни ретроспективы, ни sync-встречи.