Закон Конвея
Мелвин Конвей в 1968 году (48 лет назад!) опубликовал свою работу, в которой сформулировал следующую идею: «Организация, которая создает систему, ограничена дизайном, который копирует структуру коммуникации в этой организации». Более просто эту идею перефразировал Эрик Реймонд: «Если над компилятором работает четыре группы разработчиков, вы получите четырехпроходный компилятор». Желающие могут прочитать оригинал статьи здесь.
Так вот сформулированная выше идея называется законом Конвея, причем она получила подтверждение в дальнейших исследованиях (можно посмотреть на википедии). Из этого закона есть логичный вывод, а что если нам не „натягивать“ новый продукт на существующую организацию, а создавать организацию под новый продукт. Такая простая мысль, а так сложно ее реализовать. Ведь в любой организации, особенно крупной, все роли поделены и любая попытка рыпнуться вызывает политическое сопротивление, ведь у кого-то после этого власти станет меньше, а у кого-то и больше. И чтобы не тратить силы на политическую войну, люди договариваются делать что-то новое по-старинке, в рамках существующей оргструктуры.
И тут я прямо вижу связку с DevOps, командой двух пицц и всем этим современным шумом. Если не получается собрать всю команду поставки продукта в одну группу, то получается как раз перебрасывания релиза через стену, куча совещаний по любому поводу (15 минут на каждом из которых занимает подключения удаленных участников и настройка этого дурацкого телевизора), эскалация всех проблем наверх, потому что локально решить их не получается, письма с обвинениями друг друга и двадцатью людьми в копии. Этакое нарезание багета вдоль, а не поперек.
Но даже те, кто преодолел политический и организационный барьеры, оказываются не сильно в лучшем положении. Команда продукта хочет себе новое окружение: серверов, мониторинга, очереди сообщений и немножко БД. И снова совещания (правда, на этот раз все приходят с хорошим настроением и искренне хотят друг другу помочь), переписка, ожидание. Команды инфраструктуры (а их минимум две: одна для тестовых сред, а вторая — для боя, и это в лучшем случае) перегружены, потому что продуктовых команд, которые они обслуживают, далеко не одна. Дальше все ждут команду поддержки приложений, потом команду мониторинга, которая настраивает мониторинг на новой машине, потом парни из БД отдела делают копию БД для нового окружения и настраивает очереди сообщений. И это я еще промолчал про службу безопасности, основная задача которой мешать любой организации сделать хоть что-нибудь. Короче, позитивные и классные ребята, режут уже не багет, а обычный нарезной батон, но тоже вдоль.
Я считаю, что людей надо заменить на API или, на худой конец, кнопочки в веб-интерфейсе. Как только продуктовая команда сможет делать свои дела, ни с кем не особо не договариваясь и никого не ожидая, дело пойдет совсем с другой скоростью. Фактически, все, что спрятано за API, перестает попадать под действие закона Конвея. Хочешь себе мониторинг — нажал кнопочку, вот тебе эндпоинты для агентов и веб-интерфейс для людей, хочешь себе серверов — сделал запрос по API, и вот у тебя уже небольшая ферма, хочешь БД — вбил количество IOPS и необходимый размер, получил доступы. Короче, полный фигак, фигак и в продакшен. В естественной среде обитания я постоянно наблюдаю все эти типы организации (а иногда даже тех, кто не „оцифровал“ свой бизнес), но всем сердцем симпатизирую только последним.
И совсем забавно то, что за 50 лет не так уж много в мире изменилось.