Некоторые из них хорошо известны, другие — достаточно нишевые. Но все они очень полезны разработчикам и менеджерам. Любопытно, какие из них вам известны:

1. Закон Паркинсона.
2. Закон Хофштадтера.
3. Закон Брукса.
4. Закон Конвея (и обратный закон Конвея).
5. Закон Каннингема.
6. Закон Старджона.
7. Закон Завински.
8. Закон Хайрама.
9. Закон Прайса.
10. Эффект Рингельмана.
11. Закон Гудхарта.
12. Закон Гилба.
13. Закон Мёрфи.

Поехали.

1. Закон Паркинсона

Работа заполняет время, отпущенное на неё.

Это знаменитый закон, используемый для оправдания ложных (а иногда неразумных) дедлайнов.

— Асок, это важная задача, у тебя есть месяц на её выполнение.
— Немедленно приступаю.
— Умнее будет подождать до последней минуты, а потом устроить шоу, как упорно тебе пришлось работать, чтобы уложиться в такой неразумный дедлайн.
— Он же тебя слышит.
— Всё равно сработает, в этом-то и прелесть.

▍ Почему он важен

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

Как и любой закон, его можно использовать во зло. Отличный противовес ему — закон Хофштадтера:

2. Закон Хофштадтера

Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.

Проекты по разработке ПО почти всегда завершаются с опозданием, даже если время берётся с запасом. Так что если вы используете закон Паркинсона для оправдания коротких дедлайнов, то это приведёт к следующему:

• Или ваша команда полностью выгорит.
• Или вы всегда будете опаздывать.

— Я так плохо умею оценивать время, необходимое для завершения проектов.
— Не паникуй, для этого есть хорошее правило: возьми самую реалистичную оценку и удвой её.
— А теперь прибавь пять минут. Снова удвой. И удвой ещё раз.
— Ты потратила тридцать секунд на перемножение несуществующих чисел! Ты не двигаешься вперёд, а значит, никогда не закончишь! Паникуй!
— А-А-А-А-А-А-А!!!

▍ Почему он важен

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

Простых способов решения этой проблемы нет, лишь куча практики и общения (и наличие обсуждаемого масштаба проекта).

3. Закон Брукса

Добавление людей в проект на поздних этапах замедляет его выполнение.

Есть известная поговорка: «Девять женщин не могут родить ребёнка за месяц».

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

Любому менеджеру по разработке знакомо чувство, когда начальство говорит: «Это сверхважно, ты можешь взять любых людей из других отделов». Ага… Или просто хватит вставлять нам палки в колёса и дайте работать.

▍ Почему он важен

Невозможно быть менеджером по разработке, ни разу не поучаствовав в проекте с прошедшими сроками (см. два предыдущих правила).

Большинство менеджеров не осознаёт полностью этот закон. Они считают, что реальность ближе к эффекту Рингельмана (о котором я скажу чуть ниже).

Допустим, у вас есть четыре человека в не укладывающемся в дедлайн проекте, и вам предложили добавить в него ещё двух сеньоров. Вы знаете, что это не повысит продуктивность на 50%, но уверены, что будете работать хотя бы на 5-10% быстрее.

Но очень часто оказывается так, что вы будете работать МЕДЛЕННЕЕ!

(Разумеется, это зависит от множества переменных. Этот закон, как и любые другие, имеет свои ограничения.)

4. Закон Конвея

Организации проектируют системы, которые копируют структуру коммуникаций в этой организации.

Например, в SaaS-компании есть команды фронтенда и бэкенда. Так как эти команды работают по отдельности, структура коммуникаций влияет на архитектуру проекта:

• Команда фронтенда создаёт UI, ожидающий получения данных в определённом формате.
• Команда бэкенда создаёт API, исходя из своих собственных допущений.
• Ответы API не совпадают с тем, что ожидает фронтенд, требуя дополнительных преобразований.
• Постепенно в SaaS-приложении возникают дополнительные слои соединительного кода и неэффективности, потому что у команд нет тесного сотрудничества.

Если закон Конвея правдив, а руководство определяет структурирование организаций, тогда руководство проектирует архитектуру ПО. Теперь всё понятно.

▍ Почему это важно

Можно использовать в свою пользу обратный закон Конвея.

Отличным примером стало то, что сделала компания Flo: у них возникали проблемы с трёхнедельными циклами релизов мобильного приложения в магазине приложений. Поэтому они перевели в каждую команду по одному разработчику для iOS и для Android и 2-4 бэкенд-разработчика. Перенеся больше функциональности в бэкенд, они смогли выпускать релизы по 20-30 раз на дню, а не раз в несколько недель.

5. Закон Каннингема

Лучший способ найти правильный ответ в интернете — не задать вопрос, а разместить заведомо неправильное утверждение.

Люди любят поправлять других:

▍ Почему он важен

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

Так вы решите множество проблем:

1. Команда DevOps увидит ваш PR и спросит: «Что это за чушь?»
2. Она быстро ответит на PR, сообщив, что нужно исправить.
3. Вы будете лучше понимать, что делать в следующий раз.
4. Команда DevOps постепенно стандартизирует этот процесс при помощи автоматизации и политик.

6. Закон Старджона

90 процентов чего угодно — ерунда.

Это как соотношение 80/20 Парето, только ещё радикальнее. Большинство кода, идей и фич — это чушь.

Стоит делать/чушь

▍ Почему он важен

Большинство выпускаемых вами фич будет бесполезно, а основным продуктом вашей компании окажется их малая доля.

Когда люди говорят о 10x- (или 100x-) инженерах, то речь идёт не об инженерах, которые пишут в десять раз больше кода, а о тех, кто приносит в десять раз больше пользы компании.

Если просто согласиться на план, который «вручит» вам менеджер по проекту, то вы рискуете работать над 90% чуши, над фичами, не приносящими никакой пользы компании.

Просто соглашаться делать то, что сказано, особенно опасно из-за следующего закона:

7. Закон Завински

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

Особенно справедливо это в эпоху ИИ! Теперь стало так просто добавлять чат-ботов (или другие фичи), превращающих продукт в огромного монстра. Наверно, всё-таки стоит смириться, что ваши клиенты всё ещё ведут электронные таблицы не в вашем продукте…

Любое ПО продолжает добавлять фичи, пока не становится раздражающе сложным. Потом его заменяет более «простое» решение, в которое будут добавлять фичи, пока оно не станет таким же сложным.

▍ Почему он важен

Именно так происходит разрастание фич — добавление фич продолжается до того момента, когда они начинают саботировать ценность продукта. Пользователи начинают жаловаться, что продукт становится слишком сложным или запутанным, или что они не могут найти нужную им функциональность. Особенно это касается новичков!

8. Закон Хайрама

При достаточно большом количестве пользователей API становится неважно, что вы обещали в контракте: кто-нибудь обязательно будет зависеть от всего наблюдаемого поведения вашей системы.

Этот закон крайне забавен:

Изменения в версии 10.17: процессор больше не перегревается при удерживании пробела.

ДАВНИЙПОЛЬЗОВАТЕЛЬ4: Обновление поломало мой рабочий процесс. Мне лень тянуться к клавише Control, поэтому я удерживал пробел и настроил Emacs так, чтобы резкое повышение температуры интерпретировалось, как нажатие на Control.

АДМИН: Это ужасающе.

ДАВНИЙПОЛЬЗОВАТЕЛЬ4: Лично меня это устраивает. Просто добавьте опцию перегрева по пробелу.

▍ Почему он важен

В законе говорится об API, но я считаю, что он актуален и для фич. Как мы поняли из закона Старджона, 90% всего — это чушь.

НО вам всё равно придётся тратить кучу времени на поддержку 100% ваших фич, потому что как только вы что-то выпустите, будет хотя бы один клиент, пользующийся этим. А если вы попробуете удалить эту функциональность, то он, разумеется, начнёт жаловаться… И какие-нибудь стейкхолдеры бизнеса заставят вас поддерживать эту фичу.

Я говорил об этой проблеме в статье Feature flags are ruining your codebase. Feature flags — отличный инструмент, но их можно использовать как оправдание для менеджеров проектов, не желающих принимать жёстких решений, например, полностью удалять фичу из кодовой базы.

9. Закон Прайса

В любой группе 50% работы выполняется квадратным корнем от количества людей.

Например:

Если у вас есть десять инженеров, то половину результатов создадут трое из них.

Из сотни инженеров десятеро сгенерируют результаты, по качеству и объёму близкие к результатам остальных девяноста.

Я узнал об этом законе из поста Итци Сабо в LinkedIn; в нём этот закон использовался для того, чтобы объяснить, почему не развалился Twitter:

В ноябре 2022 года Илон Маск уволил 50% персонала Twitter.

Квадратный корень закона Прайса объясняет, почему Twitter не развалился даже после увольнения ещё 30% сотрудников.

Квадратный корень от исходных восьми тысяч сотрудников — это всего девяносто!

▍ Почему он важен

Масштабировать команды сложно. Если вы хотите улучшить результаты вдвое, то из закона Прайса следует, что вам нужно нанять в четыре раза больше людей. Одно из объяснений этого закона — эффект Рингельмана.

10. Эффект Рингельмана

Тенденция к снижению личной продуктивности отдельных членов группы по мере роста её численности.

Меня потрясло, что это явление было обнаружено и проанализировано более ста лет назад (в 1913 году!) в соревнованиях по перетягиванию каната. Чем больше людей участвовало в каждой группе, тем меньше усилий прилагал каждый из участников:

Рингельман выявил две причины этого:

1. Утерю мотивации (социальную леность).
2. Проблемы координации.

▍ Почему он важен

Да, эффект применим не только к физической силе.

PostHog писал о магии маленьких команд разработки (компания организовала 47 людей в 15 команд).

Не стоит бояться разбиваться на меньшие команды с более чёткими сферами ответственности, особенно в маленьких стартапах с «новыми» продуктами.

11. Закон Гудхарта

Когда мера становится целью, она перестаёт быть хорошей мерой.

Этот закон достаточно известен. Его постоянно упоминают в технологической сфере, говоря, что не стоит мерить производительность по количеству строк или PR, потому что люди будут манипулировать этим (и имеют на это право).

— Когда метрика становится целью, она перестаёт быть хорошей метрикой.
— Это плохо. Давай установим премию каждому, кто сможет выявить метрику, которая стала целью.

▍ Почему он важен

Любой KPI, используемый в вашей команде или компании, можно обойти.

• Выручка? → Огромные скидки.
• Текучка пользователей? → Сделать отмену подписки очень сложной.
• Новые пользователи? → Агрессивные рекламные кампании, приводящие низкокачественные лиды.
• Время разрешения тикетов службой поддержки? → Быстрое закрытие тикетов без реального решения проблем (я сталкивался с этим, как пользователь…).

То же самое справедливо по отношению к velocity, разнице реализованного и запланированного, и так далее — любая метрика сама по себе достаточно быстро становится бесполезной.

Однако «мы не должны использовать метрики» — это не решение. Если мы выберем такой подход, то попадём в ловушку Гилба:

12. Закон Гилба

Если нужно представить что-либо в количественной форме, это можно измерить каким-то способом, который даст лучшие результаты, чем в случае, если не проводить измерений вовсе.

По сути, он гласит, что измерения могут быть затруднены и результаты точны не на 100%, но любые измерения — это лучше, чем ничего.

▍ Почему он важен

Это хороший противовес закону Гудхарта. Надо не отказываться от измерений, а начать с каких-то метрик и совершенствовать их.

Это происходит и с измерениями продуктивности разработчиков. DORA, SpaceX, DevEx — разные способы, каждый из которых имеет свои преимущества.

Мне нравится недавно выпущенный DX Core 4, он кажется мне очень разумным.

13. Закон Мёрфи

Если что-нибудь может пойти не так, оно пойдёт не так.

Разумеется, ни один список законов не может обойтись без закона Мёрфи.

▍ Почему он важен

Мы часто смеёмся над ним, но я уверен, что вы наверняка сталкивались с подобными ситуациями:

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

Этот случай тестировать слишком сложно, он точно не возникнет…

Угадайте, что же поломает продакшен в следующее воскресенье?

После того, как это произошло со мной 4-5 раз (да знаю, знаю…), я научился отлавливать такие мысли. Каждый раз, когда я считаю, что ситуация невероятна, я трачу дополнительные усилия для того, чтобы учесть её.

В заключение

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

Другие законы и принципы можно изучить в репозитории на Github.

Telegram-канал со скидками, розыгрышами призов и новостями IT