Рэнди Стаффорд (Randy Stafford) — профессионал, в области создания программного обеспечения, обладающий 20-летним опытом работы в качестве разработчика, аналитика, архитектора, менеджера, консультанта и автора/лектора. В настоящее время занимается разработкой промежуточного (middleware) программного обеспечения в составе группы А-Team фирмы Oracle, а также участвует в концептуальных проектах, занимается оценкой архитектуры и помогает устранять кризисы производства различным организациям во всем мире. Основные области его специализации — сервис-ориентированные архитектуры, производительность, высокая доступность и JEE/ORM.

Заказчики и конечные пользователи часто под видом требования выдвигают то, что им кажется эффективным решением некоторой задачи. Классический пример такого рода приводит Гарри Хиллейкер (Harry Hillaker), ведущий конструктор истребителя F-16 Falcon. Перед его группой была поставлена цель спроектировать самолет, развивающий скорость М2-2,5, что было (и вероятно, остается) весьма нетривиальной задачей, особенно если сопутствующая цель состоит в создании «дешевого» легкого самолета. Учтите, что сила, необходимая для преодоления сопротивления воздуха, при удвоении скорости полета возрастает вчетверо, и представьте себе, как это обстоятельство влияет на вес самолета.

Когда конструкторская группа спросила заказчиков из ВВС, зачем им нужна скорость М2-2,5, те ответили: «Чтобы самолет мог при необходимости выйти из боя». Когда настоящая потребность стала очевидной, конструкторы смогли решить главную проблему и представить работоспособное решение: подвижный самолет с высокой тяговооруженностью, обеспечивающей хорошее ускорение и маневренность вместо высокой максимальной скорости.

Выводы из этого урока в равной степени справедливы и в области разработки программного обеспечения. Узнав у заказчика истинный смысл запрашиваемой возможности или требования, архитектор сможет проникнуть в суть проблемы и, если повезет, предложить решение более качественное и экономичное по сравнению с тем, на котором настаивает клиент. Повышенное внимание к сути требований упрощает и расстановку приоритетов: самые значимые для заказчика требования становятся определяющими.

Как же следует действовать? В манифесте гибкой (agile) разработки есть принцип, который ко многим случаям подходит очень хорошо: «Сотрудничество важнее контракта». С практической точки зрения это подразумевает проведение семинаров и встреч, на которых архитекторы анализируют потребности заказчика, помогая ему ответить на вопрос «Почему?». Учтите, что поиск ответа на этот вопрос может оказаться весьма непростой задачей, потому что в процессе анализа требований речь зачастую идет о неявных допущениях и подразумеваемых знаниях. На таких встречах следует избегать дискуссий по поводу технических решений, потому что они переводят обсуждение из предметной области заказчика в область программирования.

Эйнар Ландре (Einar Landre) — профессионал в области программного обеспечения с 25-летним опытом работы в качестве разработчика, архитектора, менеджера, консультанта и автора/лектора. В настоящее время работает в группе коммерческих приложений фирмы StatoilHydro, где занимается разработкой приложений, критических для бизнеса, оценкой архитектуры и оптимизацией процессов разработки. Основные сферы его интересов — сервис-ориентированные архитектуры, проектирование на основе предметной области (domain-driven design), применение мультиагентов и проектирование интенсивно используемых крупномасштабных сетевых систем.

Для многих из нас карьера архитектора начиналась с какой-либо чисто технической должности, где успех определялся в основном способностью общаться с компьютерами. Однако в роли архитектора нам приходится общаться главным образом с другими людьми. Обсуждаете ли вы с разработчиками преимущества того или иного шаблона или объясняете руководству плюсы и минусы покупки промежуточного программного обеспечения, залогом успеха являются ваши навыки общения.

Объективно измерить степень влияния архитектора на проект довольно сложно, но одно совершенно ясно: если разработчики постоянно игнорируют указания архитектора, а руководство не придает значения его рекомендациям, «правильность» действий архитектора никак не повлияет на развитие его карьеры. Опытные архитекторы понимают, что они должны «продвигать» свои идеи, а эта задача требует умения эффективно общаться.

На тему межличностного общения написано множество книг, но я хотел бы предложить вашему вниманию один простой и практичный прием, который радикально повысит эффективность вашего общения и соответственно упрочит ваш успех в роли архитектора. В какой бы ситуации вам ни приходилось объяснять свою позицию сразу нескольким слушателям, встаньте. Неважно, где вы при этом находитесь — на официальном анализе проекта системы или неформальном обсуждении пары диаграмм. Встаньте — особенно если все остальные сидят.

Когда вы встаете, окружающие автоматически начинают воспринимать вас как авторитетного и уверенного в себе человека. Вы становитесь центром внимания. Вас будут реже перебивать. Все это окажет существенное влияние на обсуждение независимо от того, будут приняты ваши рекомендации или нет.

Также следует отметить, что стоящий человек более интенсивно использует жестикуляцию и мимику. Если вы общаетесь с группой из 10 и более человек, вставание поможет установить зрительный контакт со всей аудиторией. Зрительный контакт, жестикуляция, мимика и другие визуальные элементы играют важную роль в общении. Кроме того, положение стоя изменяет тональность и громкость голоса, а также темп речи: вы начинаете говорить так, чтобы вас было слышно в большом помещении, делая паузы для выделения важных моментов. Все эти элементы вносят существенный вклад в эффективность общения.

Хотите повысить эффективность передачи своих идей в процессе общения более чем вдвое? Это очень просто: встаньте.

Уди Дахан (Udi Dahan) — Шаман от Программирования; его заслуги были признаны корпорацией Microsoft и в течение трех лет оценивались престижным званием «Наиболее ценного специалиста» (Most Valuable Professional) в области архитектуры решений. В качестве советника по коммуникационным технологиям Уди работает с компанией Microsoft над WCF, WF и Oslo. Он также участвует в работе консультативных комитетов Microsoft Software Factories Initiative и проекта Prism группы Patterns & Practices. Он оказывает консультации в области современных архитектур и обучает клиентов по всему миру. Его основной специальностью является проектирование сервис-ориентированных, масштабируемых и безопасных архитектур на базе платформы. NET.

Оборудование подвержено сбоям, поэтому мы вводим в наши системы избыточность. Она позволяет пережить отдельные сбои оборудования, но повышает вероятность того, что в любой момент времени в системе будет присутствовать хотя бы одна неисправность.

Программный код тоже подвержен сбоям. Наши приложения строятся на основе программного кода, а значит, они тоже уязвимы. Мы реализуем средства мониторинга, сообщающие о сбоях приложения, однако в основе этих средств тоже лежит программный код, а значит, они сами подвержены сбоям. Люди тоже совершают ошибки, поэтому мы стараемся автоматизировать наши действия, диагностику и рабочие процессы. Автоматизация снижает вероятность ошибок, обусловленных нарушениями правил, но повышает вероятность ошибок, возникающих из-за отсутствия правил. Ни одна автоматизированная система не способна реагировать на такой спектр ситуаций, как человек.