А сегодня вам от меня статейка на тему bikeshedding, или почему команды тратят время на не важное, когда есть реально острые задачи.
Статья в 4х частях, и это первая, а остальные ниже. Если вам не актуально, смело скипайте все 4 поста, хотя, как по мне, тема "живая"!

Тема остро встала сразу в нескольких моих контекстах:
1 Я часто на совещаниях (всяких уровней) вижу, как коллегия уважаемых специалистов спорит на тему... ну вообще не важную, и уделяет этому большую часть времени встречи, когда на важное времени уже не остается.
2 Команды разработки тратят время на бесконечные технические документы и всякие "а если ..., то что будем делать?", причем весьма в странных кейсах, типа "у нас RPS 100, а вот если будет 1000000 что будем делать?" (а не будет, такого трафика нет просто)
3 Команда продукта бесконечно обсуджает дизайн, а УТП доказанного у продукта нет (один из примеров)
4 Мой друг из крупного бигтеха пожаловался мне на это, с хорошими примерами, когда тех менеджмент просто до смерти долбит "рядовых" по каким то тех докам, вместо реально реализации, до которой еще и не доходит часто. А команда выгорает и демотивируется

От чего так выходит? Давайте разбираться в моей мини статье, которую я готовил давно для выступления, и обновил для вас сейчас.

Начнем со скучного: с теории. Так откуда взялся термин и причем тут велосипеды?

В 1957 году британский историк и теоретик организационного управления Сирил Норткот Паркинсон описал закономерность, которую он назвал законом тривиальности (Law of Triviality). Суть его проста: в организациях непропорционально много времени уделяется вопросам, которые легко понять, и непропорционально мало – тем, которые действительно важны.

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

Термин bikeshedding популяризовал разработчик Поул-Хеннинг Камп в своём письме в рассылку проекта FreeBSD в 1999 году. Он применил его к разработке программного обеспечения, наблюдая, как сообщество часами спорило о незначительных деталях, игнорируя архитектурные решения с долгосрочными последствиями.

Важно понимать, что bikeshedding – не проявление некомпетентности. Напротив, он часто поражает именно умные и вовлечённые команды, а причины не совсем тривиальны. Разбираемся!

(часть 2 следует далее)