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

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

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

Биография автора приведена ранее.

Мы СОЗДАЕМ ИНСТРУМЕНТЫ. Создаваемые нами системы служат единственной цели (не считая того, что нам за них платят) — помогать кому-то (обычно кому-то другому) что-либо делать.

Мартин Хайдеггер (Martin Heidegger), известный немецкий философ XX века, исследовал, как люди воспринимают инструменты (и вообще «оборудование»). Человек использует инструмент для достижения определенной цели, причем сам инструмент является всего лишь вспомогательным средством.

Для успешного применения инструмент должен быть zuhanden («подручным», то есть «ложащимся в руку»). Иначе говоря, такой инструмент воспринимается непосредственно, он используется инстинктивно, без размышлений и полемики. Мы просто берем инструмент и используем его для достижения нашей цели. В ходе такого использования инструмент исчезает, он фактически становится продолжением нашего тела и не воспринимается как нечто отдельное. Одним из признаков zuhanden-инструмента является то, что он становится как бы невидимым, неосязаемым, незаметным.

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

Возможна и другая ситуация (обычно она свидетельствует о возникших проблемах): пользователь воспринимает инструмент как vorhanden («наличествующий», то есть «находящийся в руке»). Инструмент отделяется от цели; он находится перед вами, требуя вашего внимания. Он становится объектом отдельного исследования. Пользователь уже не может двигаться к цели; он должен разобраться с инструментом, прежде чем тот сможет хоть как-то приблизить его к ней. Нам как техническим специалистам свойственно воспринимать создаваемые нами для пользователей системы как vorhanden-инструменты — и в ходе работы над ними, и позднее, когда мы получаем сообщения о дефектах. Инструмент вполне закономерно является для нас объектом рассмотрения, предметом размышлений, исследовательской задачей. Это нечто требующее изучения.

Однако (и это очень важно!) пользователи смогут добиться успеха, применяя наш продукт, только в том случае, если для них это zuhanden-инструмент. Спроектированы ли ваши системы так, чтобы становиться «невидимыми» при использовании? Насколько естественно «ложится в руку» пользовательский интерфейс? Или же ваша система постоянно требует внимания, отвлекая пользователя от его цели?

Биография автора приведена ранее.

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

Вероятно, большинство читателей согласится с тем, что поиск первоклассных разработчиков требует проведения основательного технического собеседования. Но что следует понимать под «основательным»? Это вовсе не означает, что кандидат должен ответить на трудные вопросы о малоизвестных технических нюансах. Разумеется, проверка конкретных технических навыков является частью процесса, но превращение собеседования в сертификационный экзамен не гарантирует успеха. Вам нужны разработчики-энтузиасты, обладающие навыком поиска решений. Инструменты, которые вы используете сейчас, наверняка изменятся; вам нужны люди, способные успешно пойти на штурм задачи независимо от доступных технологий. Даже если человек может наизусть перечислить все методы API, это практически ничего не скажет вам о его склонностях и о его стремлении решать задачи.

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

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

Будьте осторожны с порицанием. Избыток негатива подавляет творческое мышление, снижает производительность и, что еще хуже, разобщает команду. Хорошие разработчики умны и знают, что не могут все время ошибаться. Постоянно выискивая в их работе мелкие огрехи, вы потеряете их уважение. Ограничивайтесь конструктивной критикой и не требуйте, чтобы каждое решение выглядело так, будто вышло из ваших рук.

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

Биография автора приведена ранее.

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