The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
У вас есть архитектор программного обеспечения в вашем проекте? Вам нужен такой человек? В большинстве гибких команд такая роль явно не определена, и работают они в демократическом режиме. Каждое важное техническое решение обсуждается с всей командой, и побеждает решение, за которое проголосовало большинство. Когда такая команда наконец решает надеть значок “архитектор программного обеспечения” на футболку кого-то, его получает самый авторитетный программист.
Значок редко меняет его обязанности. В конце концов, команда остается той же и наслаждается общением на технические темы вместе, вовлекая всех. В конце концов, архитектор программного обеспечения - это скорее статус, чем роль с явно определенными обязанностями. Это знак уважения, который другие участники команды проявляют к самому старшему и авторитетному из них. Правильно?
Очевидно, архитектор обычно является человеком с самыми большими знаниями, навыками, опытом и полномочиями. Конечно, архитектор обычно знает больше остальных и может передавать свои знания с дипломатией и педагогикой, когда это необходимо. Архитектор обычно является одним из самых умных парней в команде.
Однако это не то, что делает его/ее архитектором.
И этого не нужно команде. Моя определение программного архитектора такое:
Архитектор - это тот, кто берет на себя ответственность за качество.
Вы можете заменить “ответственность” на обязанность или ответственность. Хотя я предпочитаю использовать “ответственность”, потому что это гораздо лучше подчеркивает тот факт, что каждая проблема с качеством в разрабатываемом продукте является личной ошибкой архитектора. Конечно, вместе с ответственностью он также получает все похвалы от довольных клиентов, когда качество хорошее.
Это то, что команде нужно - кто-то лично ответственный за качество разрабатываемого программного обеспечения.
Как этот человек будет делегировать эту ответственность другим - это его работа. Будь то использование его знаний и навыков, или инструментов контроля качества, или фреймворков для модульного тестирования, или полномочий, или коучинга, или физического наказания - это его дело. Менеджер проекта делегирует контроль качества архитектору программного обеспечения, и архитектору программного обеспечения зависит, как он будет делегировать это дальше.
Роль архитектора программного обеспечения критическая для каждого проекта, даже если за одним столом работают всего две разработчика. Один из них должен быть архитектором.
Идеальный архитектор обладает всеми упомянутыми достоинствами. Он слушает каждого и принимает их мнения во внимание. Он хороший коуч и учитель, обладающий терпением. Он эффективный коммуникатор и переговорщик. Он дипломат. И он эксперт в технической области.
Но даже если у него нет всех этих достоинств, его решение всегда окончательное.
И это работа менеджера проекта - убедиться, что каждое техническое решение, принятое архитектором, не вызывает сомнений у кого-либо. В этом и заключается делегирование - ответственность всегда должна сопровождаться властью.
В качестве менеджера проекта вы должны регулярно оценивать результаты своего архитектора. Помните, что качество продукта, над которым работает ваша команда, является его личной (!) ответственностью. Любые проблемы, которые вы видите, - его проблемы. Не бойтесь винить его и наказывать. Но всегда помните, что для того, чтобы ваши наказания были продуктивными, вы должны дать своему архитектору полную власть в его действиях. Позвольте мне повторить: его решения должны быть окончательными.
Если вы, как менеджер проекта, не довольны качеством продукта и архитектор не улучшает ситуацию, замените его. Понизьте его до программиста и повысьте одного из программистов до архитектора. Но всегда помните, что в команде может быть только один архитектор, и его решения окончательны.
Именно таким образом у вас есть шанс создать идеальный продукт.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:40
