🤖4 закона роботехники

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

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

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

Работа заполняет все отведенное на нее время.

Если вы рассчитали, что выполнение задачи займет месяц, то скорее всего так и будет. Но если другой человек рассчитает, что на ту же задачу потребуется два месяца, то он тоже окажется прав. Как же так?

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

Ставим все дедлайны на 1 день -> Profit.

Закон Конвея

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

Другими словами, то как мы общаемся, также мы и организовываем наш код.

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

И наоборот, если фронтенд и бэкенд являются частью кроссфункциональных команд, то и код, и инфраструктура будут более тесно связаны друг с другом.

Сдружитесь с фронтендами, и вы сами не заметите, как перепишите бэкенд на Node.js.

Закон Брукса

Добавление рабочей силы на запаздывающий проект задерживает его еще больше.

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

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

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

Закон Мерфи

Если что-то может пойти не так, это обязательно пойдёт не так в самый неподходящий момент.

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

Не путать с “У меня локально все работало”.

🙂 Еще вспомнился закон из "силиконовой долине", все айтишники тусуются по 5 человек и среди них обязательно есть индус, азиат, кто-то с бородой, полный с длинными волосами и просто худой белый парень.