Современная разработка программных продуктов сталкивается с парадоксом: компании инвестируют в новейшие инструменты и методологии, но продолжают терять время и деньги из-за разобщенности команд.
Проблема не в технологиях — проблема в культуре взаимодействия.
Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. Сегодня я расскажу вам, как единая продуктовая культура влияет на производительность компании.
Почему модель «заказчик-исполнитель» больше не работает
Модель «заказчик-исполнитель», где задачи передаются между отделами как по конвейеру, теряет эффективность в современных реалиях. Причина проста: рынок требует скорости и качества одновременно, а «бункерная культура» создает множество точек передачи, где теряется контекст, время и деньги. Разберем, почему это происходит и во что это обходится бизнесу.
Бункерная культура
В большинстве компаний я наблюдаю одну и ту же картину: каждый отдел живет в своем «бункере». Разработка получает ТЗ «через стену», поддержка узнает о релизах постфактум, продакт не понимает технические ограничения.
«Бункерная культура — это когда каждый отдел работает внутри своего «силоса», информационно закрытого формирования. Отдел продаж, бизнес-аналитики, разработка — все они есть, но друг с другом почти не общаются: живут своими жизнями, сфокусированы на локальных целях, а не на общей ценности для клиента. Сотрудники не видят сквозной поток целиком, между отделами высокие стены, задачи перебрасываются через них. Результат предсказуем — падает качество продуктов, внешний заказчик отходит на второй план».
Андрей Вишняков
Директор по бизнес-продуктам компании SimpleOne, корпорация ITG, ITIL® 4 Strategic Leader, Managing Professional, ITIL® Expert, ITIL® Practitioner, VeriSM™ Foundation.
Типичная схема выглядит так: есть отдел продаж или бизнес-заказчик, который формирует требования клиента в ТЗ, самостоятельно их обрабатывает, и только потом эти требования попадают в разработку. Получается, что комментарий клиента проходит несколько этапов трансформации, прежде чем дойти до того, кто будет его реализовывать.
При этом менеджер по продажам часто не знает, как работает разработка, какие нюансы нужно учитывать в требованиях. А отдел продаж не обладает технической компетенцией для обсуждения сложных моментов с клиентом.
Цена разобщенности
Разобщенность команд — это не абстрактная проблема процессов, а конкретные финансовые потери и упущенные возможности. Рассмотрим четыре основных сценария, где бункерная культура бьет по результатам компании.
1. Срывы сроков
Главная проблема здесь — невыполнение обещаний клиентам. Как это обычно бывает: бизнес обещает клиенту сроки, не оговаривая их с разработкой.
Приведу пример: бизнес-аналитик популярного маркетплейса понимает, что к распродаже 11.11 нужна новая функциональность, но не обсуждает с командой разработки реальность сроков. Результат: либо функциональность не выпущена — и это потери в продажах, либо, что еще страшнее, функциональность выпущена в спешке и кладет весь продакшен во время распродажи. Это уже огромная потеря денег.
2. Переделки
Представьте: мы решили выпустить AI-агента для код-ревью. Выпустили. А потом оказалось, что клиенту важно иметь какую-то конкретную кнопку не в нашей системе управления задачами, а прямо в среде разработки. Вроде бы задачу выполнили, но заказчику это неудобно, и он хотел по-другому.
Такие вещи решаются вовремя проведенным демо с заказчиком. Если бы мы обсудили напрямую и поняли его проблему, скорее всего, сделали бы правильно с первого раза.
3. Потеря контекста
В чем минус проектного подхода с большим ТЗ? Очень тяжело понять, где мы в нем ошиблись. Реализуем все, а оказывается, что ТЗ просто изначально составлено неправильно.
Поэтому важно, чтобы внутри команды был человек, который может общаться с заказчиком напрямую. Который в любой момент может уточнить, провести кастдев или показать демо прототипа и на этом этапе получить обратную связь.
Сквозные метрики страдают
Разобщенность команд отражается не только на отдельных проектах, но и на ключевых показателях всей компании. Две критические метрики особенно чувствительны к бункерной культуре.
1. Увеличивается time-to-market
Время от идеи до реализации растет, потому что путь задачи слишком длинный. Идея какое-то время живет в одном отделе, потом тратится время на передачу в разработку, на погружение разработчиков в задачу.
Еще хуже, когда появляются буферы: отдел тестирования занят, задачи скапливаются. Работа на них не ведется — time-to-market увеличивается.
2. Падает вовлеченность разработчиков
Когда разработчик становится просто «станком», в который входят требования, а выходит функциональность, его вовлеченность в работу падает, инициативность снижается, а это — самый простой путь к выгоранию.
Для кого-то это норма — просто выполнять работу, но многим важно понимать, что и для чего они делают, как это влияет на пользователя. Когда разработчик лучше погружен в контекст — пользы больше. Да, он меньше пишет кода, но код становится качественнее и лучше реализует то, что хотел пользователь.
Современный рынок требует скорости и качества одновременно, а это возможно только через коллаборацию. Модель «отдать в разработку» создает множество точек передачи, где теряется контекст и время. Современная разработка требует другого подхода.
Принципы культуры совместной работы
Культура коллаборации строится на четырех фундаментальных принципах, которые меняют саму философию работы команд. Эти принципы взаимосвязаны и работают только в комплексе.
Принцип 1: единая ответственность за результат
Не «я сделал свою часть», а «мы вместе доставили ценность пользователю».
Проблема в том, что у всех обычно свой KPI, за которым они гонятся. У отдела продаж — KPI по продажам. У разработки — метрика time-to-market на время выпуска функциональности.
По итогу начинается перетягивание каната. Команда разработки тянет одеяло в сторону: «Мы хотим выпускать маленькие задачи, потому что нам нужно поддерживать метрику time-to-market». А отдел продаж в ответ: «Нам нужна полноценная функциональность, а вы выпускаете мелкими кусками».
В идеальном мире, конечно, у команды должна быть единая цель. Например, продать продукт. А дальше каждый вкладывается по-своему: отдел продаж помогает собрать лиды, разработка выпускает функциональность вовремя.
Принцип 2: прозрачность и общий контекст
Все в команде должны видеть цели продукта, метрики успеха, обратную связь от пользователей.
Когда изначально нет «сломанного телефона» в постановке задачи, все общаются напрямую, все всё понимают, могут уточнить непонятное — это снимает огромный пласт проблем.
Принцип 3: ранняя вовлеченность
Дизайн, разработка, QA, поддержка — все должны участвовать на этапе формирования идеи, а не получать готовое ТЗ.
Например, Scrum специально выделяет только три роли: владелец продукта, Scrum Master и команда разработки. Он не делит команду разработки на дизайнера, QA, разработчика. Подход в том, что все внутри команды — разработчики (developers), неважно — аналитик это, дизайнер или кто-то еще.
Вся команда должна работать на всех этапах. Это позволяет:
не тратить время на погружение — вся команда в одном контексте с самого начала;
сделать более глубокую проработку задачи: разные компетенции дают более качественную оценку и продукт.
Возьмем покер-планнинг для оценки сложности задач: некоторые компании проводят его только для разработчиков, но, по-хорошему, участвовать в оценке должны все — от бэклога до релиза.
Важно, чтобы и дизайнер мог сказать свое слово, и разработчик, и QA. Пока команда обсуждает задачу и оценивает Story Points, идет проработка с разных сторон: «Здесь может возникнуть проблема», «А мы правильно поняли требования?», «Может, уточнить у заказчика?». Эта возможность вести дискуссию позволяет более четко проработать задачу. Поэтому важно не разделять команду на подразделения, чтобы она всегда была в одном контексте.
Принцип 4: сквозные метрики вместо локальных KPI
Измеряем не количество закрытых задач, а влияние на пользовательский опыт и бизнес-результат.
Из единой цели должны рождаться общие метрики, которые понятны всем — и разработке, и бизнесу. Это принципиально меняет подход к работе: команды перестают гнаться за локальными показателями в ущерб общему результату.
Возьмем NPS — готовность клиента рекомендовать продукт другу. Это не самая объективная метрика, но она хорошо показывает настрой клиентов и общее восприятие продукта. Если клиенты не готовы рекомендовать ваше решение — значит, что-то работает не так, как должно.
Когда NPS становится общей метрикой для всех отделов, происходит интересная трансформация. Отдел продаж может предлагать новую функциональность, которая теоретически принесет деньги бизнесу. Но команда разработки, видя ту же метрику, понимает: сначала нужно исправить критические проблемы в существующей функциональности, которые раздражают пользователей.
При общей метрике разработка может обоснованно сказать: «Мы можем повлиять на наш общий показатель, если решим проблему со стабильностью основного функционала. Это важнее новой фичи». И это будет не конфликт отделов, а совместное решение на основе общих данных.
Рассмотрим другой пример — метрики выручки и прибыли часто считаются прерогативой бизнеса и продаж. Но когда вся команда понимает, как её работа влияет на финансовые показатели, мотивация и осознанность решений возрастают. Разработчик видит не просто задачу «добавить кнопку», а понимает, что эта кнопка закрывает потребность сегмента клиентов, который приносит определенную долю выручки.
Прозрачность финансовых метрик помогает всем отделам лучше приоритизировать работу, понимать, какие решения действительно важны для бизнеса, а какие можно отложить.
Ключевой момент: важно объединять метрики успеха не только со стороны разработки (lead time, cycle time, deployment frequency), но и бизнесовые показатели (NPS, выручка, retention). Когда они становятся общими для всех отделов и все их отслеживают вместе, рождается единое понимание того, что такое успех. Исчезает ситуация, когда разработка празднует релиз, а бизнес недоволен результатом, или наоборот. Общие метрики синхронизируют восприятие успеха и формируют культуру совместной ответственности за результат.
Практики коллаборации: как это работает на деле
Принципы работают только тогда, когда они воплощаются в конкретных практиках. Рассмотрим пять ключевых механик, которые превращают культуру коллаборации из декларации в реальность.
1. Триады (Product-Design-Tech)
Треугольник Product-Design-Tech — это модель командной работы, где продакт-менеджер, дизайнер и технический лидер работают как единая команда на всех этапах создания продукта.
Каждая из трех ролей отвечает за свою область экспертизы:
Product — за видение, цели и бизнес-ценность продукта;
Design — за пользовательский опыт и качество интерфейсов;
Tech — за архитектуру, реализацию и технологическую устойчивость.
В традиционной модели роли работают последовательно: «PM написал требования → дизайнер нарисовал → разработчик реализовал». В триаде решения формируются совместно, а не передаются по цепочке. Это сокращает время и уменьшает количество переделок.
Стоит собираться определенными группами, которые будут реализовывать функциональность, и совместно делать kick-off. Вместе участвовать в приоритизации — это снимает коммуникационные проблемы.
Обсуждение задач в формате тройки помогает выявить риски на раннем этапе. Команда обсуждает крупный релиз и сразу понимает, какую часть можно сделать MVP, какую стоит отложить, а где потребуется компромисс между внешним видом, сроками и качеством.
Помню, когда работал в крупной страховой компании, мы создавали для каждой задачи свой чат. С одной стороны, раздражало — чатов очень много. Но с другой стороны, это позволяло всем оставаться в контексте и подключать заинтересованных лиц из разных отделов в рамках одной задачи.
2. Discovery-воркшопы
По Kanban-методологии можно разделить работу на Discovery и Delivery. Discovery — это исследование, генерация идей и их фильтрация. Кастдевы, пользовательские тестирования, прототипы.
Delivery — самый дорогой процесс в компании: аналитики, разработчики, тестировщики, релиз-менеджеры. Поэтому результативно, если отдел Discovery проводит воркшопы, где рассказывает, что узнали от пользователей. Команда Delivery тоже узнает, что исследуют.
Полезно, когда Discovery может подключать к своей работе заинтересованных людей. Например, разработчика — чтобы он сделал прототип для проверки гипотезы. Не обязательно, но на добровольной основе. Даже это «кто хочет» повышает мотивацию — разработчики становятся не заводом, а участниками: «Мы хотим попробовать, давайте попробуем».
3. Сквозной бэклог и единая доска
Видимость всего потока — от идеи до поддержки в продакшене.
Когда бэклог не разбит на множество маленьких частей, а собран в одном месте — это позволяет понимать, что происходит.
Единая доска показывает, какие этапы мы проходим. Здесь работает каскадный подход: можно сделать единую доску с объединенными статусами: Discovery — в работе — выполнено, Delivery — в работе — выполнено, Релиз. Каскадная доска позволяет анализировать процессы на разных уровнях детализации. Она объединяет команды и при этом не мешает работе.
4. Ретроспективы с участием всех отделов
Анализ не только «что сделали», но и «какую ценность доставили».
Важно, чтобы это была не просто встреча, где мы отчитываемся, что сделали за итерацию — это должно быть обсуждение того, как мы повлияли на пользователя.
Важно обсуждать:
что было хорошего — поднять мотивацию, похвалить друг друга, провести некий внутренний тимбилдинг;
какие были сложности и проблемы и как их устранить.
На практике я проводил ретроспективы в несколько этапов:
Собираем общую обратную связь, проблемы и сложности
Разбиваемся на маленькие команды, обсуждаем, как решить проблемы
Объединяемся, обсуждаем варианты решений от разных команд
Снова делимся на команды, обсуждаем, как реализовать решения
Формируем итоговый план, чек-лист действий
Это позволяет мотивировать команды общаться. Не общая встреча на 20 человек, где говорят только 3 активных, а формат, где участвуют все.
При правильном построении мини-команд и понимании, кто может мотивировать других говорить, получается качественная коммуникация. Это повышает мотивацию и позволяет команде самой решать проблемы, а не передавать менеджеру, который думает: «Я не знаю ваш контекст, поэтому сделаю как считаю нужным».
Как SimpleOne помогает построить культуру совместного создания
Культурные изменения невозможны без правильной технологической основы. Инструменты либо помогают командам работать вместе, либо цементируют разобщенность — третьего не дано.
Мы создаем SimpleOne SDLC как продукт для управления продуктовой разработкой, который изначально проектировался с фокусом на коллаборацию.
Интервью Артема Герасимова на Tadviser
Мы создали SDLC-платформу, которая синхронизирует бизнес и разработку
Наша задача — сделать так, чтобы все принципы и практики эффективной совместной работы можно было реализовать естественно, без костылей и обходных путей, чтобы команды могли сосредоточиться на создании продукта, а не на борьбе с инструментами.
Рассмотрим, как это реализовано на практике.
Устраняем разрыв между разработкой и поддержкой
Одна из главных проблем бункерной культуры — разрыв между разработкой и поддержкой. Разработчики не знают, какие проблемы возникают у пользователей, служба поддержки не понимает, что планируется в следующих релизах.
SimpleOne объединяет SDLC и ITSM-процессы (Service Desk) в едином пространстве. Разработка и поддержка работают в общем контексте, видят информацию друг друга. Это устраняет «бункеры» между отделами и создает единый поток работы. Проблема, обнаруженная службой поддержки, может автоматически трансформироваться в задачу для разработки. Запрос пользователя становится частью продуктового бэклога.
Это создает непрерывный цикл обратной связи, где каждый отдел видит результаты своей работы и вклад других команд.
Продукт как точка объединения
В большинстве систем управления разработкой фокус сделан на задачах — команда работает с бэклогом, не всегда понимая общую картину. SimpleOne использует другой подход: центральной сущностью становится продукт.
Единый продукт — это точка входа для всех команд. Все понимают общую цель, общую задачу, общий бэклог именно за счет этой сущности. Это объединяет команды (их может быть несколько на один продукт) вокруг общего видения.
Процессы важнее ролей
Традиционный подход делит команду на жесткие роли: аналитик, разработчик, тестировщик, дизайнер. Каждый в своем бункере, каждый со своей зоной ответственности.
В SimpleOne SDLC внутри команды не выделяются жесткие роли. Есть руководитель команды для административных задач (Team Lead или Scrum Master), но вся остальная команда работает как единое целое.
Фокус — на процессах, а не на ролях. Это позволяет всем участникам быть в едином контексте с самого начала работы над задачей, без необходимости «передачи» между этапами.
Каскадная декомпозиция целей
Единая сущность «продукт» позволяет выстроить прозрачную систему целей от верхнего уровня до конкретных команд:
На уровне продукта прописываются все цели, которые хотим реализовать.
Продукт делится на команды — можно настроить мини-OKR для каждой.
Цели каскадно декомпозируются на команды.
Внутри команды каждый видит, как его работа связана с целями продукта.
Такая прозрачность целей решает проблему рассинхронизации: когда продажи обещают одно, разработка делает другое, а поддержка не знает ни того, ни другого. Все работают в едином контексте с общим пониманием приоритетов.
Продуктовая аналитика и дашборды
Сквозные метрики доступны всем участникам потока. Это обеспечивает прозрачность и общее понимание результатов работы команд, влияния на пользователей и достижения бизнес-целей.
Переход от модели «заказчик-исполнитель» к культуре совместного создания — это не просто изменение процессов. Это культурный сдвиг, который требует пересмотра принципов работы, метрик успеха и самой философии разработки.
Резюме
Переход от модели «заказчик-исполнитель» к культуре единого рабочего пространства — это не просто изменение процессов, а культурный сдвиг в самой философии разработки.
Ключевые принципы этого подхода:
единая цель вместо локальных KPI;
прозрачность вместо передачи задач «через стену»;
ранняя вовлеченность всех ролей вместо последовательной работы;
сквозные метрики вместо изолированных показателей отделов.
Практики коллаборации — триады, Discovery-воркшопы, единые доски, совместные ретроспективы — превращают эти принципы в реальность, а правильные инструменты делают коллаборацию естественной частью работы, а не дополнительным усилием.
Компании, которые смогут построить такую культуру, получат конкурентное преимущество в скорости разработки, качестве продукта и вовлеченности команд.
Сталкивались ли вы с «бункерной культурой» и что помогло (или не помогло) её преодолеть?
