0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Батхёрт разработческий - особая разновидность батхёрта, которая проявляется в виде полного отрицания возможностей улучшения продукта разработчика без его участия (далее БР). Приводит к различным видам саботажа и деградации самого продукта. Эта статья - попытка осветить проблему и поискать возможности её решения.</p>
1
<p>Батхёрт разработческий - особая разновидность батхёрта, которая проявляется в виде полного отрицания возможностей улучшения продукта разработчика без его участия (далее БР). Приводит к различным видам саботажа и деградации самого продукта. Эта статья - попытка осветить проблему и поискать возможности её решения.</p>
2
<h2>Где можно встретить БР?</h2>
2
<h2>Где можно встретить БР?</h2>
3
<p>Немного контекста. Мы занимается услугами по ускорению сайтов. Обычно это работы над клиентской частью и немного серверного тюнинга. Иногда приходится внедряться в чужой серверный код для решения проблем производительности. В случае наличия команды разработчиков у клиента мы регулярно встречаемся с батхёртом у них.</p>
3
<p>Немного контекста. Мы занимается услугами по ускорению сайтов. Обычно это работы над клиентской частью и немного серверного тюнинга. Иногда приходится внедряться в чужой серверный код для решения проблем производительности. В случае наличия команды разработчиков у клиента мы регулярно встречаемся с батхёртом у них.</p>
4
<p>Для формирования БР нужно три стороны. Далее опишем их вместе с интересами, которые приводят к ситуации батхёрта.</p>
4
<p>Для формирования БР нужно три стороны. Далее опишем их вместе с интересами, которые приводят к ситуации батхёрта.</p>
5
<p><strong>Первая сторона</strong>- это команда разработчиков, которая должна иметь достаточную историю взаимодействия с кодом проекта (например, разработка с нуля или долговременная поддержка). Их основные интересы: сохранить собственный авторитет, самооценку и остаться в проекте, доказать свою незаменимость.</p>
5
<p><strong>Первая сторона</strong>- это команда разработчиков, которая должна иметь достаточную историю взаимодействия с кодом проекта (например, разработка с нуля или долговременная поддержка). Их основные интересы: сохранить собственный авторитет, самооценку и остаться в проекте, доказать свою незаменимость.</p>
6
<p><strong>Вторая сторона</strong>- это другая команда разработки, приглашённая для решения локальных задач: доработка какого-то компонента, аудита проекта, решения проблем производительности, консультации. Их интересы: успешно провести проект, получить кейс, повысить репутацию, дополнительные продажи услуг.</p>
6
<p><strong>Вторая сторона</strong>- это другая команда разработки, приглашённая для решения локальных задач: доработка какого-то компонента, аудита проекта, решения проблем производительности, консультации. Их интересы: успешно провести проект, получить кейс, повысить репутацию, дополнительные продажи услуг.</p>
7
<p><strong>Третья сторона</strong>- владелец или менеджер проекта, который и пригласил вторую команду для решения локальной задачи. Его интересы: улучшить качество проекта, решить проблемы для пользователей, увеличить доходы проекта (при этом не потеряв контроля и сохранив все сильные стороны, включая команду разработки).</p>
7
<p><strong>Третья сторона</strong>- владелец или менеджер проекта, который и пригласил вторую команду для решения локальной задачи. Его интересы: улучшить качество проекта, решить проблемы для пользователей, увеличить доходы проекта (при этом не потеряв контроля и сохранив все сильные стороны, включая команду разработки).</p>
8
<p>Природа бархёрта разработчиков различна. Например, это может быть уверенность в собственных силах и правильности решений. В некоторых случаях это страх, что его заменят на более продвинутых разработчиков, которые смогли исправить проблемы в проекте. Иногда - неспособность обучаться и воспринимать новые подходы и технологии. В любом случае, батхёрт приводит к проблемам для всех задействованных сторон.</p>
8
<p>Природа бархёрта разработчиков различна. Например, это может быть уверенность в собственных силах и правильности решений. В некоторых случаях это страх, что его заменят на более продвинутых разработчиков, которые смогли исправить проблемы в проекте. Иногда - неспособность обучаться и воспринимать новые подходы и технологии. В любом случае, батхёрт приводит к проблемам для всех задействованных сторон.</p>
9
<h2>В чём проблема?</h2>
9
<h2>В чём проблема?</h2>
10
<p>Сложности возникают при попытке взаимодействия команд разработчиков. Первая команда (старожилы проекта) не заинтересована в успехе работы приглашённой команды (или не хочет в него верить). Результат:<strong>саботаж всех действий</strong>. Начинается этот процесс с затягивания сроков передачи доступов к программному коду проекта и заканчивается на блокировке внедрения изменений. Отказ в доступах легко мотивируется вопросами безопасности, внедрение изменений блокируется на базе оценки изменений кода, которые оказываются "неправильными", "ненужными" и "непрофессиональными".</p>
10
<p>Сложности возникают при попытке взаимодействия команд разработчиков. Первая команда (старожилы проекта) не заинтересована в успехе работы приглашённой команды (или не хочет в него верить). Результат:<strong>саботаж всех действий</strong>. Начинается этот процесс с затягивания сроков передачи доступов к программному коду проекта и заканчивается на блокировке внедрения изменений. Отказ в доступах легко мотивируется вопросами безопасности, внедрение изменений блокируется на базе оценки изменений кода, которые оказываются "неправильными", "ненужными" и "непрофессиональными".</p>
11
<p>Далее, руководителю проекта докладывается о полном провале приглашённой команды и необходимости отката всех изменений.</p>
11
<p>Далее, руководителю проекта докладывается о полном провале приглашённой команды и необходимости отката всех изменений.</p>
12
<p>Перед руководителем проекта возникает сложный вопрос доверия: с одной стороны, команда, которая погружена в проект, имеет значительный лимит доверия (проект как-никак работает). С другой стороны - приглашённая команда, с которой он работает первый раз, лимит доверия которой заведомо ниже.</p>
12
<p>Перед руководителем проекта возникает сложный вопрос доверия: с одной стороны, команда, которая погружена в проект, имеет значительный лимит доверия (проект как-никак работает). С другой стороны - приглашённая команда, с которой он работает первый раз, лимит доверия которой заведомо ниже.</p>
13
<p>Если руководитель обладает достаточной технической подготовкой и сможет разобраться в реальном положении дел - хорошо. Однако, на этом история не закончится. Далее ему придётся продавить свою команду принять изменения и "посыпать голову пеплом". Это может в свою очередь вызвать новые проблемы.</p>
13
<p>Если руководитель обладает достаточной технической подготовкой и сможет разобраться в реальном положении дел - хорошо. Однако, на этом история не закончится. Далее ему придётся продавить свою команду принять изменения и "посыпать голову пеплом". Это может в свою очередь вызвать новые проблемы.</p>
14
<p>Если руководитель не может самостоятельно разобраться в деталях спора, то скорее всего он выберет путь наименьшего сопротивления - отказаться от проекта с приглашённой командой и принять точку зрения своих разработчиков. Этот вариант наименее конфликтный, но приводит к провалу начальной задачи (доработка проекта, аудит).</p>
14
<p>Если руководитель не может самостоятельно разобраться в деталях спора, то скорее всего он выберет путь наименьшего сопротивления - отказаться от проекта с приглашённой командой и принять точку зрения своих разработчиков. Этот вариант наименее конфликтный, но приводит к провалу начальной задачи (доработка проекта, аудит).</p>
15
<h2>Как лечить?</h2>
15
<h2>Как лечить?</h2>
16
<p>Здесь у меня нет однозначного ответа. Могу предложить только несколько методов.</p>
16
<p>Здесь у меня нет однозначного ответа. Могу предложить только несколько методов.</p>
17
<p><strong>Метод №1 - коммуникации</strong>. С самого начала нужно наладить эффективную связь между командами разработки, объяснить всем сторонам цели и задачи проекта. Здесь важна обратная связь и понимание процесса всеми сторонами. Неизвестность порождает страх и недоверие.</p>
17
<p><strong>Метод №1 - коммуникации</strong>. С самого начала нужно наладить эффективную связь между командами разработки, объяснить всем сторонам цели и задачи проекта. Здесь важна обратная связь и понимание процесса всеми сторонами. Неизвестность порождает страх и недоверие.</p>
18
<p><strong>Метод №2 - отключаем эмоции</strong>. Все мы люди и нам свойственно реагировать эмоционально. Особенно это актуально, когда речь идёт о своём детище (программном коде). Вся аргументация в спорах должна быть основана на объективных данных и логике (если в вашем проекте есть четкие критерии и метрики - отлично). Ни в коем случае нельзя переходить на личности и терять деловой тон общения.</p>
18
<p><strong>Метод №2 - отключаем эмоции</strong>. Все мы люди и нам свойственно реагировать эмоционально. Особенно это актуально, когда речь идёт о своём детище (программном коде). Вся аргументация в спорах должна быть основана на объективных данных и логике (если в вашем проекте есть четкие критерии и метрики - отлично). Ни в коем случае нельзя переходить на личности и терять деловой тон общения.</p>
19
<p>Ну и последний, который метод профилактики, а не лечения -<strong>страхуйте риски</strong>. Если заранее знать о проблеме батхёрта, можно предусмотреть этот риск в договоре, предупредить заказчика и т. д.</p>
19
<p>Ну и последний, который метод профилактики, а не лечения -<strong>страхуйте риски</strong>. Если заранее знать о проблеме батхёрта, можно предусмотреть этот риск в договоре, предупредить заказчика и т. д.</p>
20
<p>А вы встречались с батхёртом разработчиков в своей практике (с любой стороны)? Как боролись? Пишите в комментариях!</p>
20
<p>А вы встречались с батхёртом разработчиков в своей практике (с любой стороны)? Как боролись? Пишите в комментариях!</p>
21
21