Бизнес и разработка существуют в параллельных реальностях — говорят на разных языках, преследуют разные цели, по-разному оценивают риски и качество. В этой статье разберу причины, почему так происходит и к каким последствиям это приводит, а также покажу на примере нашего продукта 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
Читайте также:
Термины "бизнес" и "разработка" использованы неочевидным образом, видимо - внутренний сленг компании.
"Продажи" и "производство" звучали бы лучше.
Все-таки "бизнес" ассоциируется с "менеджментом/управлением", а управлять и производством и продажами одинаково важно.