Итак, начнём с определений. Батхёрт разработческий – особая разновидность батхёрта, которая проявляется в виде полного отрицания возможностей улучшения продукта разработчика без его участия (далее БР). Приводит к различным видам саботажа и деградации самого продукта. Эта статья – попытка осветить проблему и поискать возможности её решения.
Немного контекста. Мы занимается услугами по ускорению сайтов. Обычно это работы над клиентской частью и немного серверного тюнинга. Иногда приходится внедряться в чужой серверный код для решения проблем производительности. В случае наличия команды разработчиков у клиента мы регулярно встречаемся с батхёртом у них.
Для формирования БР нужно три стороны. Далее опишем их вместе с интересами, которые приводят к ситуации батхёрта.
Первая сторона – это команда разработчиков, которая должна иметь достаточную историю взаимодействия с кодом проекта (например, разработка с нуля или долговременная поддержка). Их основные интересы: сохранить собственный авторитет, самооценку и остаться в проекте, доказать свою незаменимость.
Вторая сторона – это другая команда разработки, приглашённая для решения локальных задач: доработка какого-то компонента, аудита проекта, решения проблем производительности, консультации. Их интересы: успешно провести проект, получить кейс, повысить репутацию, дополнительные продажи услуг.
Третья сторона – владелец или менеджер проекта, который и пригласил вторую команду для решения локальной задачи. Его интересы: улучшить качество проекта, решить проблемы для пользователей, увеличить доходы проекта (при этом не потеряв контроля и сохранив все сильные стороны, включая команду разработки).
Природа бархёрта разработчиков различна. Например, это может быть уверенность в собственных силах и правильности решений. В некоторых случаях это страх, что его заменят на более продвинутых разработчиков, которые смогли исправить проблемы в проекте. Иногда – неспособность обучаться и воспринимать новые подходы и технологии. В любом случае, батхёрт приводит к проблемам для всех задействованных сторон.
Сложности возникают при попытке взаимодействия команд разработчиков. Первая команда (старожилы проекта) не заинтересована в успехе работы приглашённой команды (или не хочет в него верить). Результат: саботаж всех действий. Начинается это процесс с затягивания сроков передачи доступов к программному коду проекта и заканчивается на блокировке внедрения изменений. Отказ в доступах легко мотивируется вопросами безопасности, внедрение изменений блокируется на базе оценки изменений кода, которые оказываются «неправильными», «ненужными» и «непрофессиональными».
Далее, руководителю проекта докладывается о полном провале приглашённой команды и необходимости отката всех изменений.
Перед руководителем проекта возникает сложный вопрос доверия: с одной стороны команда, которая погружена в проект, имеет значительный лимит доверия (проект как-никак работает). С другой стороны – приглашённая команда, с которой он работает первый раз, лимит доверия которой заведомо ниже.
Если руководитель обладает достаточной технической подготовкой и сможет разобраться в реальном положении дел – хорошо. Однако, на этом история не закончится. Далее ему придётся продавить свою команду принять изменения и «посыпать голову пеплом». Это может в свою очередь вызвать новые проблемы.
Если руководитель не может самостоятельно разобраться в деталях спора, то скорее всего он выберет путь наименьшего сопротивления – отказаться от проекта с приглашённой командой и принять точку зрения своих разработчиков. Этот вариант наименее конфликтный, но приводит к провалу начальной задачи (доработка проекта, аудит).
Здесь у меня нет однозначного ответа. Могу предложить только несколько методов.
Метод №1 – коммуникации. С самого начала нужно наладить эффективную связь между командами разработки, объяснить всем сторонам цели и задачи проекта. Здесь важна обратная связь и понимание процесса всеми сторонами. Неизвестность порождает страх и недоверие.
Метод №2 – отключаем эмоции. Все мы люди и нам свойственно реагировать эмоционально. Особенно это актуально, когда речь идёт о своём детище (программном коде). Вся аргументация в спорах должна быть основана на объективных данных и логике (если в вашем проекте есть четкие критерии и метрики – отлично). Ни в коем случае нельзя переходить на личности и терять деловой тон общения.
Ну и последний, который метод профилактики, а не лечения – страхуйте риски. Если заранее знать о проблеме батхёрта, можно предусмотреть этот риск в договоре, предупредить заказчика и т. д.
А вы встречались с батхёртом разработчиков в своей практике (с любой стороны)? Как боролись?
Где можно встретить БР?
Немного контекста. Мы занимается услугами по ускорению сайтов. Обычно это работы над клиентской частью и немного серверного тюнинга. Иногда приходится внедряться в чужой серверный код для решения проблем производительности. В случае наличия команды разработчиков у клиента мы регулярно встречаемся с батхёртом у них.
Для формирования БР нужно три стороны. Далее опишем их вместе с интересами, которые приводят к ситуации батхёрта.
Первая сторона – это команда разработчиков, которая должна иметь достаточную историю взаимодействия с кодом проекта (например, разработка с нуля или долговременная поддержка). Их основные интересы: сохранить собственный авторитет, самооценку и остаться в проекте, доказать свою незаменимость.
Вторая сторона – это другая команда разработки, приглашённая для решения локальных задач: доработка какого-то компонента, аудита проекта, решения проблем производительности, консультации. Их интересы: успешно провести проект, получить кейс, повысить репутацию, дополнительные продажи услуг.
Третья сторона – владелец или менеджер проекта, который и пригласил вторую команду для решения локальной задачи. Его интересы: улучшить качество проекта, решить проблемы для пользователей, увеличить доходы проекта (при этом не потеряв контроля и сохранив все сильные стороны, включая команду разработки).
Природа бархёрта разработчиков различна. Например, это может быть уверенность в собственных силах и правильности решений. В некоторых случаях это страх, что его заменят на более продвинутых разработчиков, которые смогли исправить проблемы в проекте. Иногда – неспособность обучаться и воспринимать новые подходы и технологии. В любом случае, батхёрт приводит к проблемам для всех задействованных сторон.
В чём проблема?
Сложности возникают при попытке взаимодействия команд разработчиков. Первая команда (старожилы проекта) не заинтересована в успехе работы приглашённой команды (или не хочет в него верить). Результат: саботаж всех действий. Начинается это процесс с затягивания сроков передачи доступов к программному коду проекта и заканчивается на блокировке внедрения изменений. Отказ в доступах легко мотивируется вопросами безопасности, внедрение изменений блокируется на базе оценки изменений кода, которые оказываются «неправильными», «ненужными» и «непрофессиональными».
Далее, руководителю проекта докладывается о полном провале приглашённой команды и необходимости отката всех изменений.
Перед руководителем проекта возникает сложный вопрос доверия: с одной стороны команда, которая погружена в проект, имеет значительный лимит доверия (проект как-никак работает). С другой стороны – приглашённая команда, с которой он работает первый раз, лимит доверия которой заведомо ниже.
Если руководитель обладает достаточной технической подготовкой и сможет разобраться в реальном положении дел – хорошо. Однако, на этом история не закончится. Далее ему придётся продавить свою команду принять изменения и «посыпать голову пеплом». Это может в свою очередь вызвать новые проблемы.
Если руководитель не может самостоятельно разобраться в деталях спора, то скорее всего он выберет путь наименьшего сопротивления – отказаться от проекта с приглашённой командой и принять точку зрения своих разработчиков. Этот вариант наименее конфликтный, но приводит к провалу начальной задачи (доработка проекта, аудит).
Как лечить?
Здесь у меня нет однозначного ответа. Могу предложить только несколько методов.
Метод №1 – коммуникации. С самого начала нужно наладить эффективную связь между командами разработки, объяснить всем сторонам цели и задачи проекта. Здесь важна обратная связь и понимание процесса всеми сторонами. Неизвестность порождает страх и недоверие.
Метод №2 – отключаем эмоции. Все мы люди и нам свойственно реагировать эмоционально. Особенно это актуально, когда речь идёт о своём детище (программном коде). Вся аргументация в спорах должна быть основана на объективных данных и логике (если в вашем проекте есть четкие критерии и метрики – отлично). Ни в коем случае нельзя переходить на личности и терять деловой тон общения.
Ну и последний, который метод профилактики, а не лечения – страхуйте риски. Если заранее знать о проблеме батхёрта, можно предусмотреть этот риск в договоре, предупредить заказчика и т. д.
А вы встречались с батхёртом разработчиков в своей практике (с любой стороны)? Как боролись?
