Bikeshedding
Оригинальное название: bikeshed
Коротко
Затяжной спор о простой и малозначимой детали, в то время как сложные и действительно важные вопросы проекта остаются без внимания.
Что такое «Bikeshedding»
Слово переводится как «обсуждение велосипедного сарая». Метафора восходит к британскому историку Сирилу Норткоту Паркинсону, автору «Законов Паркинсона». Он описал комитет, который за минуты утверждает проект атомного реактора — в нём никто толком не разбирается, — и долго спорит о навесе для велосипедов, потому что про сарай мнение есть у каждого. Это наблюдение называют законом тривиальности.
В программистский жаргон слово «bikeshed» попало из рассылки разработчиков FreeBSD: Пол-Хеннинг Камп использовал эту притчу, чтобы остановить бесконечную ветку обсуждения мелкого изменения. С тех пор термином обозначают любую ситуацию, когда энергия команды уходит на то, в чём легко высказаться, а не на то, что важно.
Пример из практики
Созвон по интернет-магазину. Нерешёнными висят обмен остатками с 1С и выбор платёжного шлюза. Но сорок минут уходит на оттенок кнопки «В корзину» и на то, называть её «Купить» или «Заказать». Решение по обмену откладывается на следующую неделю, а сроки едут. В коде то же самое выглядит как длинная ветка комментариев в ревью о табах и пробелах или об имени переменной, хотя в соседнем файле не обработана ошибка оплаты.
Как не утонуть в мелочах
- Автоматизировать вкусовые вопросы. Форматирование, отступы и порядок импортов отдают линтеру и форматтеру с общим конфигом — спорить становится не о чем.
- Зафиксировать договорённости. Единое руководство по стилю закрывает вопросы о цветах, названиях и оформлении раз и навсегда.
- Назначить владельца решения. Мелкий вопрос решает один человек, остальные могут высказаться, но не блокировать.
- Ограничить время. На обсуждение детали — пять минут, дальше берётся любой разумный вариант.
- Начинать с рискованного. Сложные пункты ставить в начало встречи, пока у всех есть силы.
Многие споры снимаются ещё до старта, если интеграции, роли и ограничения описаны в техническом задании на сайт. Тогда обсуждать приходится только то, что действительно открыто. В гибких методологиях вроде Agile этому помогают короткие встречи с жёсткой повесткой.

