97 этюдов для архитекторов программных систем

Конечно, дело этим отнюдь не исчерпывается, но несколько простых советов существенно повысят эффективность вашего общения с подчиненными:
• Смотрите на обсуждение проблем как на конструктивный диалог, а не как на конфликтную ситуацию.
Исходите из позитивных предположений о людях и рассматривайте общение как возможность задать интересующие вас вопросы; так вы определенно сможете получить больше полезной информации, а ваши собеседники не займут оборонительную позицию.
• Приступайте к беседе только в подходящем для общения настроении.
Если вы рассержены, раздражены, расстроены и вообще выведены из душевного равновесия, ваш собеседник, скорее всего, истолкует ваши невербальные проявления как признак нападения.
• Используйте такие ситуации как возможность достичь взаимной выгоды. Не говорите разработчику, чтобы он вел себя потише на собраниях, поскольку не дает никому говорить; лучше спросите, не поможет ли он вам вовлечь в обсуждение других людей. Объясните, что интровертам необходима более длинная пауза для вступления в разговор, и если он выдержит паузу в пять секунд перед произнесением первых слов, то тем самым очень поможет вам.
Если вы сосредоточены на общей цели, рассматриваете «проблемы» своих собеседников как возможность чему-то научиться, управляете своими эмоциями, то вы не только повысите свою эффективность, но и будете каждый раз узнавать что-то новое.
Марк Рэмм (Mark Ramm) — «великодушный пожизненный диктатор» [4] для TurboGears 2, страстный поклонник Python и, вообще говоря, совершенно сумасбродный парень. Он перепробовал все мыслимые и немыслимые виды деятельности — от архитектора программного обеспечения и сетевого администратора до ловца лобстеров и уборщика в баре для байкеров. Его основное увлечение — разработка инструментов, повышающих производительность труда программистов (как профессионалов, так и любителей).
  
Общение — король, ясность и лидерство — его верные слуги
 
Марк Ричардс
 
Слишком часто архитекторы программного обеспечения обитают в башнях из слоновой кости, спуская оттуда разработчикам спецификации и навязывая им технологии и направления. Сплошь и рядом это приводит к раздорам, за которыми быстро следует «народное восстание». В итоге появляется программный продукт, который не имеет ничего общего с исходными требованиями. Каждый архитектор программного обеспечения должен уметь объяснять своим коллегам цели и задачи программного проекта. Ключами к эффективному общению являются ясность и лидерство.
Ясность характеризует процесс общения. Никто в вашей группе не станет читать 100-страничный документ с обоснованием ваших архитектурных решений. Умение четко и ясно выражать свои мысли жизненно важно для успеха любого программного проекта. С самого начала работы над проектом придерживайтесь простых объяснений и ни в коем случае не начинайте составлять длинные описания в Word. Используйте такие инструменты, как Visio, для создания простых диаграмм, поясняющих ваши идеи. Диаграммы должны быть простыми, потому что они почти наверняка будут часто изменяться. Еще одним эффективным средством распространения информации являются неформальные встречи. Лучший способ донести вашу мысль до участников проекта — собрать группу разработчиков (или других архитекторов) в одной комнате и изобразить свои идеи на доске. Обязательно захватите с собой цифровой фотоаппарат (ничто так не раздражает, как требование освободить конференц-зал, когда вы только что закончили рисовать). После собрания сделайте снимок, размножьте его и распространите среди остальных участников через вики. Отложите создание пространных документов и направьте усилия на то, чтобы донести свои идеи до коллег, а уже потом можно будет подумать и о более подробном изложении ваших архитектурных решений.
 
Большинству архитекторов программного обеспечения не приходит в голову, что они должны быть еще и лидерами. Чтобы работать в здоровой и продуктивной атмосфере, вы как лидер должны завоевать уважение своих коллег. Держать разработчиков в неведении относительно того, как выглядит общая картина и почему приняты те или иные конкретные решения, — верный путь к катастрофе. Напротив, привлекая разработчиков на свою сторону, вы формируете среду коллективной работы, в которой проверяется правильность ваших архитектурных решений. В свою очередь, подключение разработчиков к процессу создания архитектуры обеспечивает их приверженность и заинтересованность.
Действуйте совместно с разработчиками, а не против них. Учитывайте, что ясность и лидерство важны для взаимодействия со всеми участниками команды (не только с разработчиками, но и с группой тестирования, бизнес-аналитиками и руководителями проектов). Ясность в передаче информации и эффективное проявление лидерства улучшают качество коммуникации, формируют сильную и здоровую рабочую среду.
Если «общение — король», то ясность и лидерство — его верные слуги.
Марк Ричардс (Mark Richards) — директор и ведущий архитектор в фирме Collaborative Consulting, LLC, где он занимается разработкой архитектуры и проектированием крупномасштабных сервис-ориентированных решений на базе J2EE и других технологий главным образом в области финансовых операций. Работает в программной отрасли с 1984 года, обладает значительным опытом проектирования и разработки на J2EE, объектно-ориентированного проектирования и разработки, а также опытом системной интеграции.
  
Производительность приложения определяется его архитектурой
 
Рэнди Стаффорд
 
Производительность приложения определяется его архитектурой. На первый взгляд кажется, что это утверждение должно быть очевидным, но опыт реальной работы показывает обратное. Например, архитекторы программного обеспечения нередко полагают, что проблемы с производительностью приложения можно решить простым переходом на программную инфраструктуру от другого производителя. Источником этой веры может быть рекламная шумиха вокруг результатов тестирования — например, заявляется, что продукт фирмы-лидера на 25 % превосходит по производительности ближайшего конкурента. Однако если продукт-лидер выполняет операцию за 3 миллисекунды, а конкурирующий продукт — за 4 миллисекунды, заявленные 25 % (одна миллисекунда) значат очень мало на фоне общей низкой производительности, уходящей корнями в неэффективность архитектуры.
Помимо ИТ-менеджеров и команд тестирования производительности есть и другие группы людей, например служба поддержки фирмы-разработчика и авторы книг по управлению производительностью приложений, которые рекомендуют заняться тонкой настройкой инфраструктуры приложения: поиграть с операциями выделения памяти, размерами пулов подключений, размерами пулов потоков и так далее. Но если приложение спроектировано недостаточно эффективно для ожидаемой нагрузки или его функциональная архитектура нерационально использует вычислительные ресурсы, то никакая тонкая настройка не обеспечит желаемого быстродействия и масштабируемости. Потребуется полное перепроектирование внутренней логики и/или стратегии развертывания.
В конечном счете за фасадом продукта любого производителя и архитектуры любого приложения действуют одни и те же фундаментальные принципы распределенной обработки данных и физические закономерности: приложения и используемые ими продукты выполняются как процессы на компьютерах ограниченной мощности, взаимодействуя друг с другом через стеки протоколов и каналы связи с ненулевыми задержками. А значит, людям следует понять и принять мысль о том, что архитектура приложения является главным фактором, определяющим его производительность и масштабируемость. Эти качественные характеристики невозможно улучшить как по волшебству — чудодейственной сменой технологий или тонкой настройкой инфраструктуры. Любые усовершенствования в этих областях требуют упорного труда по тщательной проработке архитектуры.