Некоторые из них известны, некоторые - довольно узкоспециальные, но ВСЕ они очень полезны инженерам-разработчикам и проектным менеджерам.
Интересно, сколько из этих законов будут для вас новыми?
Закон Паркинсона
Закон Хофштедтера
Закон Брукса
Закон Конвея (и обратный закон Конвея)
Закон Каннингема
Закон Стерджена
Закон Завински
Закон Хайрума
Закон Прайса
Эффект Рингельмана
Закон Гудхарта
Закон Гилба
Закон Мерфи
Для каждого закона в статье приводится:
Сам закон
Соответствующий комикс (если найден)
Почему это важно для управления разработкой ПО
1. Закон Паркинсона
Объем работы расширяется до заполнения всего доступного времени.
Это известный закон, который используется, чтобы оправдать фиктивные (а иногда и неразумные) дедлайны.
Почему это важно
Ранее мы рассмотрели подробно этот закон в другом гостевом посте. Установка дедлайнов часто даёт лучшие результаты, так как влияет на «железный треугольник» объёма, ресурсов и времени. Как и любой закон, его можно использовать с плохими намерениями. Закон Хофштедтера является его контрбалансом.
2. Закон Хофштедтера
Реализация всегда займет больше времени, чем ожидается, даже если вы предусмотрите поправку на закон Хофштедтера.
Проекты по созданию ПО почти всегда выходят за рамки дедлайнов, даже если вы предусмотрите небольшой буферный срок в конце этапа планирования. Таким образом, если вы будете использовать закон Паркинсона (см. выше) для сокращения времени реализации проекта (дедлайнов), то вы:
приведете команду к полному выгоранию, или
всегда будете опаздывать.
Почему это важно
Эти два закона определяют все, что вам надо знать о том, почему оценка выполнения проектов в области ПО - тяжелое занятие. Предусмотрите большие подстраховочные временные буферы - и вы заполните их бесполезной работой. Если такие буферы будут слишком маленькими - вы сорвете сроки.
Рецепта решения проблемы нет - вам поможет только большой и горький опыт в области управления проектами (ну и постоянное общение с командой и заказчиком). Также постарайтесь предусмотреть возможность хоть частичной адаптации объема работ под реальность.
3. Закон Брукса
Добавление разработчиков к проекту на поздней стадии выполнения только отдалит срок его завершения.
Согласно народной мудрости, "девять женщин не смогут родить ребенка за месяц".
Каждый менеджер проекта знает это чувство, когда вышестоящее начальство говорит: "Это крайне срочно, вы можете затребовать любые человеческие ресурсы от других команд". Да уж.. Или просто не отвлекайте нас и дайте нам спокойно поработать.
Почему это важно
Вы не можете быть руководителем проекта и не испытать все прелести поздних стадий проекта (см. оба предыдущих закона).
Большинство неопытных менеджеров неправильно понимают этот закон. Они думают, что реальность больше соответствует эффекту Рингельмана (о котором поговорим чуть ниже). Допустим, что на поздней стадии проекта у вас есть команда из четырех разработчиков и вам предложили еще двух сеньоров. Вы, конечно, понимаете, что это не увеличит продуктивность команды на 50 процентов, но вы можете надеяться, что вы закончите проект на 5-10 процентов быстрее.
Чаще, чем хотелось бы, реальность будет такова, что выполнение проекта ЗАМЕДЛИТСЯ!
(Конечно, реальный результат зависит от слишком многих переменных. У этого закона (как и всех здесь упомянутых) есть свои ограничения применимости).
4. Закон Конвея
Организации создают системы, которые отражают их внутренние коммуникационные структуры.
Например, компания, продающая «программное обеспечение как услугу» зачастую разделяется на две команды: фронтенда и бекенда. Так как обе команды работают как отдельные организационные единицы, коммуникации между ними отражаются в архитектуре продукта:
Команда фронтенда создает пользовательский интерфейс, ожидая данные в определенном формате.
Команда бекенда создает API на основе собственных предположений.
Ответы API не соответствуют точно том, что ожидает фронтенд, поэтому требуется промежуточный трансформирующий слой.
Со временем, приложение обрастает слоями склеивающего и трансформирующего кода из-за того, что команды не работали плотно между собой.
Почему это важно
Вы можете использовать обратный закон Конвея для повышения шансов на успех.
Прекрасный пример команды разработчиков в Flo: они находились под сильным давлением из-за трехнедельного цикла релизов своего мобильного приложения. Поэтому они использовали только одного iOS разработчика и одного Android разработчика в каждой команде, и 2-4 общих бекенд-разработчиков. Сдвигая фокус разработки на бекенд, они смогли пушить обновления в прод 20-30 раз в день и отойти от недельного релизного цикла.
5. Закон Каннингема
Самый лучший способ получить полезный и правильный ответ в интернете - не спрашивать, как правильно, а запостить неправильный ответ.
Люди обожают поправлять других людей:
Почему это важно
В статье 6 секретов, как не быть заблокированным снова, мы обсудили способ, как использовать этот закон, чтобы продвинутся в реализации проекта:
Вместо того, чтобы закинуть запрос в ДевОпс команду, ожидая, когда же они определят ее как приоритетную с последующей реализацией, просто откройте пулл-реквест и определите себя как ответственного за реализацию. Даже, если вы понятия не имеете, как подходить к решению проблемы! Просто найдите похожую задачу и попробуйте аналогично решить свою.
Это будет иметь ряд последствий:
Команда ДевОпс увидит ваш пулл-реквест и скажет: "Какого черта?!"
Они быстро просмотрят ваш пулл-реквест, определят в чем проблема, и сами устранят проблему, чтобы не загрязнять свою территорию вашим дилетантским решением.
Вы теперь лучше знаете, как работать с аналогичными проблемами, чтобы вас услышали.
Команда ДевОпс зарегламентирует постепенно весь процесс автоматизацией и правилами во избежания повторения такой ситуации в будущем.
6. Закон Стерджена
90% всего - мусор.
Это тот же закон Парето (80/20), но на стероидах. Код ли, идеи ли, или новые функции - большинство из этого полный отстой.
Почему это важно
Большинство функционала, который вы реализуете, - бесполезен. Его совсем небольшая часть будет важной (и нужной) частью вашего программного обеспечения или API. Когда люди говорят о разработчике с десятикратной силой (10x engineer), то это не те инженеры, которые создают десятикратное увеличение кодовой базы - а те, кто понимают и убирают ненужные 90% функционала.
Если мы просто примем пошаговый план реализации, который проектный менеджер даст нам в руки, мы гарантированно будем работать 90 процентов времени над бесполезными функциями - теми, которые не нужны ни компании, ни потребителям.
Просто работая по принципу "Делаю то, что мне сказали" особенно опасно в связи со следующим законом.
7. Закон Завински
Функционал любой программы расширяется до тех объемов, когда она сможет получать и обрабатывать электронную почту. Программы, которые не смогут расширить свой функционал до таких пределов, будут замещены теми программами, которые смогут.
И этот закон особенно актуален в нашу эру ИИ! Ведь так просто добавить функционал ИИ-чатбота, превращая продукт в гигантский монстр-комбайн. Все-таки может это нормально, если в вашем продукте не будет встроенного функционала, например, электронных таблиц, и клиенты будут использовать другую программу для этого?
Почему это важно
Так происходит функциональное уродование продукта (feature creep) - путем добавления функций до тех пор, пока они полностью не уничтожают его ценность для пользователей. Пользователи будут жаловаться, что продукт стал слишком сложным, или непонятным, или они не могут быстро найти функционал, который им нужен. В частности, новые пользователи ПО даже не смогут понять, как начать работу с продуктом!
8. Закон Хайрума
Когда число пользователей вашего API достигнет определенного числа, неважно, о чем вы договаривались с ними в рамках документации, - всегда найдется пользователь, который будет зависеть от всего поведения вашей системы - даже незадокументированного.
Вот прекрасная иллюстрация:
Почему это важно
Закон говорит об API, но я верю, что он также описывает и ПО. Как мы видели в законе Стерджена, 90% всего - мусор.
Но вы все равно будете поддерживать все 100% функций вашего ПО, так как, как только вы попробуете удалить часть казалось бы ненужного функционала, то в тот же момент появится пользователь, который использовал его. Конечно, он будет громко жаловаться про удаление нужной ему функции… И кто-то из руководства скажет вам,чтобы вы продолжали ее поддержку.
Я обсуждал эту проблему в статье Функциональные флаги разрушают ваш код. Такие флаги - прекрасный ин��трумент, но они могут легко быть использованы не по назначению путем избавления проектного менеджера от тяжкого решения по удалению какого-то функционала из кодовой базы.
9. Закон Прайса
В любой группе, 50% работы выполняется {квадратный корень от числа всех работников} работниками.
Например:
Если у вас десять разработчиков, половина работы может быть отслежена до трех из них.
Из ста инженеров, десять будут делать объем работы, как и остальные девяносто.
Я узнал об этом законе из поста Итци Сабо в LinkedIn, где он объясняет, почему Twitter не развалился после массовых увольнений:
Элон Маск уволил 50% персонала Twitter в ноябре 2022.
Закон квадратного корня Прайса объясняет, почему Twitter не развалился, даже когда еще 30% были уволены.Квадратный корень изначального числа работников (8000) - это приблизительно 90!
Почему это важно
Масштабирование команд разработчиков - сложная задача. Если вам нужно двукратное увеличение производительности, то закон Прайса показывает, что вам нужно будет четырехкратное увеличение персонала. Одно из объяснений этого закона состоит в эффекте Рингельмана.
10. Эффект Рингельмана
Существует стабильная тенденция для отдельных членов групп разработчиков к менее продуктивному состоянию по мере того, как группа растет в числе.
Я был в шоке, что этот эффект был обнаружен и исследован более ста лет назад (в 1913 году) на примере соревнований по перетягиванию каната. Чем больше людей участвовало в группе с каждой стороны, тем меньше усилий прикладывал каждый член группы:
Рингельман определил две причины:
Потеря мотивации (социальное расслабление).
Проблемы координирования.
Почему это важно
Да, это не только про грубую физическую силу.
PostHog написал о Магии небольших команд разработчиков (у них 47 разработчиков организованы в 15 команд).
Особенно в небольших компаниях-стартапах, с новыми продуктами, не бойтесь создавать небольшие команды с четким зонами ответственности.
11. Закон Гудхарта
Когда показатель становится целью, он перестает быть хорошим показателем.
Это достаточно знаменитый закон. Его упоминают тут и там в нашей отрасли, например, говоря о том, что вам не следует использовать число строчек кода как показатель производительности, так как люди найдут (и правильно сделают) способ абьюзить такой показатель.
Почему это важно
Каждый KPI, который ваша команда или компания использует, может мотивировать к нежелательному поведению.
Объем продаж? → Огромные скидки.
Процент ухода потребителей? → Сделать отмену подписки невероятно сложной.
Число новых пользователей? → Агрессивные рекламные компании, которые привлекут низкокачественные лиды.
Скорость закрытия тикетов? → Закрывать тикеты без реального решения проблемы клиентов (Сколько раз я видел такое поведение…)
Любая метрика, становящейся самоцелью вне контекста ее возникновения, быстро может стать бесполезной.
Даже несмотря на это, правильный ответ не в том, чтобы не измерять. Если мы пойдем по этому пути, то попадем в ловушку Гилба.
12. Закон Гилба
Все, что вам надо охарактеризовать, может быть измерено таким образом, что это будет лучше той ситуации, когда вы вообще ничего не измеряете.
Фактически, этот закон говорит о том, что измерения могут быть трудными и не 100% аккуратными, но это в любом случае будет лучше, чем вообще ничего не измерять.
Почему это важно
Это хороший противовес закону Гудхарта. Вместо того, чтобы совсем отказываться от измерения и метрик, мы должны начать с измерения чего-нибудь простого и постепенно улучшать эту метрику.
Мы уже видели, как это происходит в области измерения производительности разработчиков. DORA, SpaceX, DevEx - различные подходы с различными преимуществами.
Мне нравится недавно опубликованный документ DX Core 4, который совпадает с моим пониманием проблемы.
13. Закон Мерфи
Все, что может пойти не так, идет не так.
Ни один список не будет полным без закона Мерфи
Почему это важно
Да, мы часто смеемся при упоминании этого закона, но я уверен, вы уже испытывали что-то подобное:
Вы находитесь под сильным давлением проектного менеджера, который требует выпустить определенный функционал программы как можно быстрее. Осталось протестировать последний пограничный случай, который настолько сложен, что вы полны уверенности - он просто не реализуем. Поэтому вы решили пропустить его воссоздание и обработку.
Догадаетесь, что сломает прод в следующее воскресенье?
После того, как это произошло со мной четыре или пять раз (да-да, я знаю..), я сразу распознаю этот шаблон своего мышления. Каждый раз, когда я оцениваю событие как маловероятное, я делаю дополнительную тщательную проверку и тестирование этого сценария.
Заключительные слова
Конечно, ни один из этих законов - реальный закон в прямом смысле, они просто хорошие ментальные модели. Я надеюсь, что, держа их в уме, вы сможете избежать некоторых болезненных ситуаций в вашем ежедневном труде разработчика или проектного менеджера.
Если вам интересны другие аналогичные законы и принципы, то можете посмотреть их в этом репозитарии!