В 1967 году журнал Harward Business Review (HBR) отклонил статью, предложенную Мелом Конвеем (Mel Convey), но в конечном счете, всего год спустя, его тезисы стали называть «законом Конвея». Мел Конвей окончил Калифорнийский технологический институт со степенью магистра в области физики и получил звание доктора математических наук в Университете Кейс Вестерн Резерв. Он работал над компилятором Pascal’я, а также над многими другими известными программными проектами. На протяжении всей своей карьеры Конвей наблюдал любопытный феномен: продукты, разрабатываемые софтверными командами, отражали организационную структуру их компаний.
Для начала немного проясним эту концепцию. Эксперт по юзабилити, Найджел Беван (Nigel Bevan), писал: «Организации часто снабжают свои сайты контентом и структурой, которые опираются на внутренние проблемы компании, а не на потребности клиентов». Иными словами, вместо того чтобы отражать реалии покупательского путешествия, внутренняя структура компании влияет на архитектуру продукта.
Закон Конвея
Закон Конвея всплывает в проектах по разработке программного обеспечения. Поручите трем ведущим инженерам работу над одним и тем же проектом, и вы получите три различных способа выполнения каждой задачи: point-and-click («укажи и щелкни»), комбинацию клавиш и пункт меню. Если в вашей команде присутствуют два проектных руководителя, то у вас наверняка появятся две разные исходные системы управления, две разные методики проверки кода, две разные архитектуры и так далее.
В 2008 году Алан МакКормак (Alan MacCormack) и его соавторы исследовали и подтвердили Закон Конвея в журнале HBR, изучая софт, разрабатываемый компаниями, и сопоставляя его c открытым программным обеспечением (open source software), которое создавалось сообществами.
Возможно, этот закон и не является универсальной истиной, но все же он поднимает вопрос о том, правильно ли структурирована команда стартапа. К примеру, большинство быстрорастущих компаний начинают с разработки монолитного приложения (один сервер для приложения, одна база данных, один логический уровень) и в конечном счете переключаются на микросервисную архитектуру, где функции, которые обычно инкапсулируются в одной кодовой базе (code base), фрагментированы на десятки или даже сотни различных сервисов.
Можно предположить, что это является следствием двух сил: растущего размера команды и развития DevOps — методологии разработки ПО, в рамках которой разработчики ответственны не только за кодинг, но и за контроль качества и операции. Таким образом, небольшие группы девелоперов могут стать практически независимыми от более крупной инженерной организации. Отсюда и микросервисы.
К сожалению, Закон Конвея не предусматривает диагностический инструмент, который бы помог исполнительным командам определить правильность структуризации их компаний или понять, когда пришло время для реорганизации стартапа. Он всего лишь порождает один простой вопрос: позволяет ли ваша организационная структура разработать наилучший продукт для ваших клиентов?
Это очень хороший вопрос, и вам несомненно стоит задаваться им время от времени.
Высоких вам конверсий!
По материалам: tomtunguz.com
