Как синхронизировать работу отдела разработки с бизнесом

Бизнес и разработка существуют в параллельных реальностях — говорят на разных языках, преследуют разные цели, по-разному оценивают риски и качество. В этой статье разберу причины, почему так происходит и к каким последствиям это приводит, а также покажу на примере нашего продукта SimpleOne SDLC, как мы решили похожую проблему.

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

Бизнес оперирует строгими сущностями — контрактами, KPI, сроками, штрафными санкциями. Они понимают, что происходит во внешнем мире, взаимодействуют с клиентами и партнерами. Разработка фокусируется на конкретных задачах в трекере и техническом долге. Каждый отдел живет в собственном мире со своим языком и приоритетами.

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

Бизнес обещает одно, а разработка делает другое

Бизнес-задачи, преобразованные в список фич, теряют изначальную цель. Разработка создает «еще одну кнопку», не понимая, какую проблему клиента решает эта кнопка и какую ценность создает для бизнеса.

Бизнес ставит целью продать продукт, разработка — разработать. У компании, казалось бы, общая цель — выпустить хороший продаваемый продукт, но в итоге — одни делают, другие продают, и эти процессы не всегда совместимы.

Бывает, что представители бизнеса обещают функциональность, которой нет в продукте, уверяя клиента, что все будет готово через две недели, а разработчики говорят: «Это будет сделано только через год». Рушатся обещания, страдают отношения с клиентами, начинаются внутренние конфликты. 

Почему бизнес и разработка по-разному понимают риски и сроки

Есть разграничение между рисками бизнеса и рисками разработки. Бизнес боится не выпустить продукт вовремя, не выполнить обещания, потерять доверие клиента. Риски для бизнеса проходят на коммуникационном уровне — в договоренностях и обещаниях.

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

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

Почему в компании появляется технический долг

Бизнес хочет выпустить продукт быстрее. Для бизнеса важнее скорость, и разработка идет на компромисс. Когда бизнес ставит скорость в приоритет и делает функциональность кое-как — возникает технический долг. В понятие «кое-как» закладывается, что продукт потом придется переделывать или дорабатывать. 

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

Конфликт в определении критериев качества

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

Проблема связана с целями и KPI. Цель бизнеса — продать, и главное, чтобы продукт хоть как-то работал. Качество для них — количество продаж и вернувшиеся клиенты, поэтому они готовы допускать увеличение технического долга. Для разработки качество — возможность удобно и быстро поддерживать продукт. Продается продукт или нет — для них второстепенно.

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

Как решить противоречия между бизнесом и отделом разработки 

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

1. Постройте мост, а не нанимайте переводчика

Есть два пути:

• Краткосрочное решение — ввести роль delivery-менеджера, который будет переводчиком между двумя мирами. Стоит помнить, что delivery-менеджер, или медиатор — это промежуточный этап в решении проблемы. Он всегда создает риск. Если с ним что-то случится, вся коммуникация разрушится. Медиатор устраняет симптомы, но не искореняет проблему — дискоммуникацию. Нужно исправить базовую структуру, а не закрывать проблему дополнительной ролью.
• Долгосрочное решение — выстроить организационную структуру, где бизнес и разработка работают вместе под одним крылом, понимая, кто что делает. Важно не просто сказать отделам «живите дружно», нужно дать им условия для совместной работы.

2. Учитывайте техдолг наравне с бизнес-рисками

Устранение технического долга должно стать не только проблемой разработки, но и частью культуры всей компании. Разработчики должны учтивее относиться к бизнес-рискам в виде сроков. Бизнес в свою очередь должен понимать, что такое технический долг и почему для них он важен так же, как для разработки. Кроме того, бизнесу стоит сделать цели и риски общими и одинаково значимыми для всех подразделений.

3. Создайте систему сквозных метрик

Для правильной постановки цели нужны метрики, определяющие эти цели. Метрики должны быть сквозными — у компании должны быть общие метрики по продажам, и разработка должна понимать, как влияет на эти продажи.

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

4. Закрепите зоны ответственности для каждого вопроса разработки

В разработке используют разные подходы, например, Agile учит нескольким практикам по организации работы. Первое — общее планирование. Должны быть общие точки соприкосновения бизнеса и разработки, общие цели. Второе — разработка должна понимать, к кому из представителей бизнеса прийти с вопросом. Часто бывает, что бизнес представляют 20 человек. Это, конечно, хорошо, но разработка должна понимать, к кому именно прийти по тому или иному вопросу.  

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

Сделать хорошо работающую компанию не сложно — для этого всего лишь нужно понимать, что мы делаем, для кого и как. Чаще всего это упускается на старте. Команды редко делают полноценное описание бизнес-моделей, с детализацией всех процессов – все ограничивается устной договоренностью. Когда так происходит, возникает дискоммуникация между отделами.

Как выстроить диалог с разработкой: кейс SimpleOne

Год назад в нашей команде, которая создает продукт SimpleOne SDLC, у разработки и бизнеса были совсем разные цели. Разработчики ставили перед собой задачу выпускать релизы каждый месяц, а бизнес-подразделения — увеличивать количество проданных лицензий и общий оборот по продукту, на фоне чего возникали недопонимания.

Кликните по картинке, чтобы открыть в полном размере

За год мы привели все в порядок, пришли к общему пониманию того, что мы продаем и кому, выстроили описание продуктов, сделали сегментацию клиентов. Мы построили правильную коммуникацию между отделами за счет общих планирований. У нас появилось дополнительные квартальное и годовое планирования, что позволило собирать обратную связь от разных представителей бизнеса и передавать ее разработке. Кроме того, мы усилили связь между владельцем продукта и разработкой.

Оптимазация работы компании показала хорошие результаты:

• ускорили time-to-market на 40%;
• уменьшили текучку кадров на 20%;
• выстроили более тесные отношения внутри команды — появилось понимание, что мы делаем и для чего мы это делаем;
• скорость принятия решений увеличилась на 50%, потому что каждый член команды может самостоятельно принимать решения и не тратить время на излишнее согласование.

Вывод

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

Мой главный совет — создайте общие цели, общие метрики и общую ответственность. Дайте отделам возможность работать вместе — не через посредников, а напрямую. Сделайте технический долг видимым для бизнеса, а бизнесовые риски понятными для разработки. Превратите конфликт в диалог. Ваш продукт и клиенты скажут «спасибо».

Партнерский материал

Реклама. Рекламодатель ООО «СИМПЛ 1» ИНН 9725013892 Erid 2SDnjdrY9sm

Читайте также: