Давно, я не рекомендовал статьи, а сегодня принес «Иногда лучше делать, а не планировать».

Там описывается одна простая мысль: за последние десятилетия реализация проектов погрязла в бесконечных совещаниях и согласованиях.

Несколько примеров:

• Эмпайр-стейт-билдинг построили за 410 дней: с 22.01.1930 по 01.05.1931.
• Космическая программа «Аполлон» — от формулирования задачи 12.09.1962 до высадки на Луну 20.07.1969 — заняла менее 7 лет.

В наши дни только получение разрешения на строительство может занять несколько лет или десятилетий. Потом ещё несколько лет уйдёт на документацию, подготовку инфраструктуры и т. д.

Например, строительство высокоскоростного поезда между Сан-Франциско и Лос-Анджелесом началось в 2015 году и не окончено до сих пор.

Самая классная фраза из статьи:

«Время, потраченное на обсуждение пункта, обратно пропорционально рассматриваемой сумме».

Это правило называется законом Паркинсона.

Думаю, все замечали, как на каком-нибудь митинге чрезмерное внимание уделяется мелочам. Например, можно 20 минут обсуждать название кнопки или порядок полей в форме, хотя всем примерно понятно, что надо сделать. Каждый считает, что важно сделать именно так, как хочет он.

При этом сложные моменты, где нужно приложить усилие и реально подумать, люди часто пропускают.

То же самое часто происходит и во время код-ревью. Все мастера указать на неправильное именование переменной, но чтобы разобраться в архитектуре, многие не хотят тратить силы.

Это ещё называется bike-shed effect или «эффект велосипедного сарая».

Год назад у нас произошла большая реструктуризация, и появился скрам со своими планированиями и грумингами. На груминге можно долго обсуждать, как лучше что-то сделать, где могут появиться подводные камни, что ещё нужно учесть и прочее.

Но я вижу, как все терпеть не могут эти митинги. Все хотят просто сидеть и заниматься своим делом.

Для некоторых важных задач, конечно, нужно обсудить подход и понять, как мы будем это решать. Но, кажется, что гораздо важнее полностью понять требования, а что до реализации  — для некритичных задач проще спросить у Клода или Кодекса: «что сломается, если я внесу это изменение?» или «как лучше реализовать это?», а не тратить время всей команды на обсуждение.

Да и иногда проще быстро спрототипировать — спасибо тому же Клоду — и спросить у команды: «вот так нормально?», чем снова собирать всех на обсуждение.

Раньше что-то переписать могло занять дни, а теперь — часы. Поэтому мне кажется, что это не такая уж плохая идея.

Ещё один интересный момент из статьи:

В 1944 году ЦРУ выпустило инструкцию по саботажу работы компаний для своих диверсантов. Среди советов: всё прогонять через формальные каналы, чаще делать длинные доклады, спорить о формулировках, поднимать несущественные вопросы и возвращаться к уже принятым решениям.

Задача — снижать продуктивность, но выглядеть так, будто ты просто соблюдаешь правила.

Иногда кажется, что многие современные менеджеры отлично с этим справляются.

Ставьте:

• 🔥 — если митинги заколебали
• 👍 — если вы везунчик и у вас минимум митингов