Большинство программных проектов начинаются с одного разработчика, которого мы будем называть архитектором. Этот человек обдумывает проблему, которую пытается решить, и разрабатывает решение. Из ничего возникает кодовая база.
В какой-то момент архитектор отказывается от своего кода. Это может произойти по разным причинам:
- Она довольна своим решением проблемы и хочет перейти к другим задачам.
- Команда растет, и ее код больше не кажется ей знакомым.
- Внешнее давление меняет характер проекта, делая его менее привлекательным.
Если проекту повезло, появляется преемник, который становится новым архитектором, и с миром все в порядке.
Если проекту не повезло, то, что произойдет дальше, зависит от того, насколько проект успешен. У успешной программы будут пользователи, и она будет рассматриваться как важная для бизнеса. Неиспользуемая или малоизвестная программа, скорее всего, будет лишена финансирования и закрыта. В любом случае, проект будет продолжаться без архитектора.
Почему важно иметь архитектора? У нее есть три сверхспособности:
- Она может уместить всю программу в своей голове.
- Она может изменить все, что захочет.
- Она не менеджер.
Проекты, которые слишком велики для № 1, становятся неуправляемыми комками грязи. Это связано с тем, что для ее составных частей появляются более мелкие собственники, которые проводят локальные оптимизации, не рассматривая систему в целом.
Например, владелец уровня данных потратил три месяца на оптимизацию производительности запросов, в то время как внешний интерфейс был локализован на дополнительные рынки. Во время интеграционного тестирования команда обнаруживает, что их локализованный продукт не может правильно сохранять или извлекать данные с неанглийскими символами. Упс.
Руководители программ (PM) возражают сейчас. «Джефф, — кричат они, — ты ошибаешься, продакт-менеджер будет устанавливать требования и управлять сроками, чтобы предотвратить подобные вещи».
Возможно, они правы, и лучшее общение предотвратило бы эти недоразумения. Однако наличие чрезвычайно сложного продукта (все, что не может уместиться в голове одного человека, по определению чрезвычайно сложно) означает, что никто не понимает, что база данных не может обрабатывать неанглийские символы. А может БД поддерживает, но текст испорчен где-то посередине. Технологии прекрасно умеют удивлять вас проблемами, которые задним числом кажутся очевидными.
Вернемся ко второй сверхспособности архитектора: она может изменить все, что захочет. Проекты без архитектора имеют неясную принадлежность к общей картине. Владельцы небольших компонентов могут захотеть внести изменения, затрагивающие всех членов команды, но они могут не согласиться со стилем или характером этих изменений.
Как разрешаются конфликты в командах? В отсутствие технического владельца владение по умолчанию переходит к управленческой иерархии из-за их ролевой власти, которая проистекает из того факта, что менеджеры могут влиять на вашу зарплату, поэтому большинство людей склонны подчиняться им.
Разрешение конфликта происходит по-разному в зависимости от того, кто не согласен. Если это два относительно младших разработчика, которые находятся под одним и тем же руководителем, вероятно, лидер может смягчить их спор и обеспечить решение. Есть надежда, что, поскольку руководитель является линейным менеджером, он «достаточно близок» к кодовой базе, чтобы понимать технические компромиссы. Иногда это ошибочно и, как правило, несправедливо по отношению к руководителю, если он на самом деле является менеджером по персоналу.
Но что, если у младших разработчиков полностью отдельные цепочки управления вплоть до вице-президента? Что, если менеджеры среднего звена в этом сценарии имеют разные бизнес-цели и расходятся во мнениях? Или что, если рассматриваемые разработчики на самом деле очень старшие и подчиняются непосредственно вице-президенту?
В каждом из этих случаев мы заканчиваем обращением к руководителям высокого уровня для принятия технических решений. Это ужасный результат, потому что:
- Менеджеры высокого уровня обычно не обладают техническими знаниями или практическим опытом решения проблемы, чтобы сделать правильный выбор.
- Откладывание решения на потом в ожидании встречи с высокопоставленным менеджером приводит к напрасным усилиям.
- Доведение проблемы до сведения руководителя высокого уровня может иметь непредвиденные последствия.
Что я имею в виду под номером 3? Представьте, что перед вице-президентом стоит следующая проблема: два старших разработчика принципиально расходятся во мнениях относительно того, как реализовать важную систему. Их команды работали по-разному (каждая исходила из своей правоты), и проект сильно отстает от графика. Выслушав, как разработчики клеймят дизайн друг друга, вице-президент решает, что этот проект не стоит хлопот, и просто отказывается от него.
Как насчет проектов, в которых архитектор является менеджером либо изначально, либо после повышения по службе? Почему третьей сверхсилой архитектора не является менеджер? Проще говоря, управление людьми и написание кода — это разные наборы навыков.
Это не означает, что отличный программист не может быть отличным менеджером. Есть волшебные личности, которые отлично справляются с обеими ролями. Однако никто не должен носить обе шляпы одновременно. Если вы отличный менеджер, то вам следует расширять свою команду и делегировать технические задачи своим отчетам, а не принимать решения самостоятельно. Менеджер для программиста то же, что редактор для автора: он должен давать указания и советы, а не заниматься настоящей творческой работой.
Аналогия с автором помогает нам понять, почему архитекторы так важны. Программа без архитектора — это книга без автора. Наверное, это не очень хорошо, скорее всего, у него нет единого стиля и уж точно не будет души.
Если вы ничего не вынесете из этой статьи: Никогда не позволяйте владеть кодом менеджерам. Они не будут знать, что с этим делать. Выберите разработчика в команду, рисуйте соломинки, боритесь на руках, играйте в ножницы-бумага-камень. Неважно как, но убедитесь, что кто-то владеет кодом и имеет над ним полную власть, не спрашивая разрешения ни у кого.
