Вероятно, большинство читателей согласится с тем, что поиск первоклассных разработчиков требует проведения основательного технического собеседования. Но что следует понимать под «основательным»? Это вовсе не означает, что кандидат должен ответить на трудные вопросы о малоизвестных технических нюансах. Разумеется, проверка конкретных технических навыков является частью процесса, но превращение собеседования в сертификационный экзамен не гарантирует успеха. Вам нужны разработчики-энтузиасты, обладающие навыком поиска решений. Инструменты, которые вы используете сейчас, наверняка изменятся; вам нужны люди, способные успешно пойти на штурм задачи независимо от доступных технологий. Даже если человек может наизусть перечислить все методы API, это практически ничего не скажет вам о его склонностях и о его стремлении решать задачи.
С другой стороны, если вы попросите человека объяснить свой подход к диагностике проблем быстродействия, вы получите ясное представление о его методах решения задач. Хотите узнать, умеет ли разработчик извлекать опыт из полученных уроков? Спросите, что он изменил бы в своем последнем проекте, если бы получил возможность начать его заново. Хорошие разработчики относятся к своей работе с энтузиазмом. Этот энтузиазм непременно проявится, когда они будут рассказывать о своих прошлых проектах, — и вы получите такую информацию, которую невозможно извлечь из правильных ответов на технические вопросы.
Потратив немало сил на формирование сильной команды, сделайте все, что в ваших силах, для ее сохранения. Возможно, некоторые удерживающие факторы (например, оплата) вам неподвластны, но позаботьтесь по крайней мере о тех мелочах, которые помогают сохранить здоровую рабочую среду. Хороших разработчиков часто стимулирует признание их заслуг. Используйте это обстоятельство и отмечайте выдающиеся достижения. Найти хорошего разработчика трудно; показать человеку, что его ценят, легко. Не упускайте простые возможности поднять дух и повысить производительность команды.
Будьте осторожны с порицанием. Избыток негатива подавляет творческое мышление, снижает производительность и, что еще хуже, разобщает команду. Хорошие разработчики умны и знают, что не могут все время ошибаться. Постоянно выискивая в их работе мелкие огрехи, вы потеряете их уважение. Ограничивайтесь конструктивной критикой и не требуйте, чтобы каждое решение выглядело так, будто вышло из ваших рук.
Важность правильного подбора команды разработчиков трудно переоценить. В любой команде есть «тяжеловесы», которым поручаются самые трудные задачи, но, когда дело доходит до оценок, все участники рассматриваются на равных. Позаботьтесь о сплоченности стартового состава, а когда вы успешно сформируете команду победителей, не пожалейте усилий на то, чтобы сохранить ее.
Биография автора приведена ранее.
Программы на самом деле не существуютЧед Лавинь
Разработку программного обеспечения часто сравнивают с такими устоявшимися дисциплинами, как гражданское строительство. Однако у подобных аналогий имеется серьезный недостаток: в отличие от материальных продуктов, создаваемых в ходе строительства, программы в реальности не существуют — по крайней мере, в традиционном смысле слова. Обитатели мира нулей и единиц не связаны физическими законами, которые накладывают ограничения на классические инженерные парадигмы. Хотя в фазе проектирования ПО применение инженерных принципов дает достаточно хороший результат, предположение о том, что вы сможете воплотить созданный дизайн таким же образом, как это делается в традиционных инженерных подходах, выглядит малореалистичным.
Как бизнес, так и программное обеспечение — живые, динамичные сущности. Бизнес-требования быстро меняются под влиянием таких факторов, как появление новых деловых партнеров и маркетинговых стратегий. По этой причине очень сложно использовать в программном проекте те же подходы, что и в традиционном конструировании (например, строительстве мостов). Вряд ли вас попросят изменить местоположение моста в разгар строительства. В то же время с появлением нового делового партнера вполне может оказаться, что в приложение придется включить поддержку управления контентом на уровне организации. Мы часто говорим, что программные архитектурные решения трудно изменять, но все же это намного проще, чем изменять объекты, воплощенные в камне (как в буквальном, так и в переносном смысле).
Если вы изначально знаете, что создаваемые вами продукты пластичны, а предъявляемые к ним требования могут измениться, вы находитесь в совершенно ином положении, чем инженер, создающий статичный объект.
В инженерных проектах физического характера гораздо проще реализовать принцип «сначала план работ, потом работы по плану». К построению программных продуктов обычно приходится подходить по принципу «сначала план работ, потом подгонки плана».
Эти различия не обязательно ставят нас в невыгодное положение — иногда из них можно извлечь пользу. Например, вы не связаны требованием строить компоненты программных систем в определенном порядке, а значит, можете начать работу с самых рискованных вопросов. Это радикально отличает программный проект от строительства моста, где порядок выполнения задач обусловлен множеством жестких физических ограничений.
Тем не менее гибкость процесса разработки ПО сопровождается также рядом специфических проблем, источником которых часто являются они же сами. Мы, архитекторы, очень хорошо сознаем изменчивую природу своей профессии и любим решать задачи. Ситуацию усугубляет то, что владельцы бизнеса тоже что-то слышали об этом и без особых сомнений инициируют большие изменения. Не торопитесь соглашаться с крупными архитектурными изменениями только потому, что вас подталкивает к этому ваша природа «решателя задач». Подобные решения могут разрушить в целом жизнеспособный проект.
Помните, что формулировка требований — не технический чертеж, а программы не существуют в реальности. Создаваемые нами виртуальные объекты изменять проще, чем их физические аналоги, и это хорошо, потому что такая необходимость возникает довольно часто. Совершенно нормально планировать работу так, будто вы строите объект недвижимости, — просто не удивляйтесь, когда кто-либо потребует его передвинуть.
Биография автора приведена ранее.
Освойте новый языкБеркхардт Хафнагель
Чтобы добиться успеха в роли архитектора, вы должны говорить понятно для людей, не владеющих вашим родным языком. Нет, я не предлагаю изучать эсперанто или клингонский язык, но вы, по крайней мере, должны говорить на простейших диалектах делового языка и языка тестирования. А если вы не владеете свободно программистским языком, его освоение должно стать для вас делом первостепенной важности.
Если вы не видите особого смысла в изучении других языков, взгляните на такой сценарий развития событий: у владельцев бизнеса есть желание внести изменения в существующую систему, и они организуют встречу с архитектором и программистами для обсуждения этих изменений. К сожалению, никто в технической группе не говорит на языке бизнесменов, а никто из бизнесменов не владеет языком программистов. Скорее всего, встреча будет проходить примерно так:
• Бизнесмен около минуты говорит о необходимости относительно простого усовершенствования существующего продукта. Он объясняет, каким образом эти изменения позволят отделу продаж увеличить долю рынка и повысить популярность продукта.
• Пока он говорит, архитектор начинает рисовать в блокноте какие-то мистические символы и вступает в тихий спор с одним из программистов на таинственном, понятном только им языке.
• Наконец бизнесмен завершает свою речь и выжидательно смотрит на архитектора.
• Архитектор заканчивает перешептываться, выходит к доске и принимается рисовать сложные диаграммы с несколькими представлениями существующей системы, попутно объясняя (в сложных технических терминах), почему требуемое усовершенствование практически невозможно реализовать без радикальных изменений в системе и почему оно требует полного перепроектирования и переписывания всей системы.
• Бизнесмены (которые мало что поняли в диаграммах и еще меньше в объяснениях) явно озадачены. Им трудно поверить, что такой пустяк требует столь серьезных изменений. Они пытаются понять, говорит ли архитектор серьезно или просто придумывает отговорки, чтобы вообще избежать изменений.
• Тем временем архитектор и программисты в свою очередь поражаются, почему до бизнесменов не доходит, что их «мелкая задачка» требует принципиального изменения базовой функциональности системы.
В этом и состоит суть проблемы. Ни одна из сторон не понимает, что думает другая и что означает добрая половина используемых ею слов. Все это порождает непонимание и недоверие. Срабатывает простейший психологический принцип: люди более комфортно чувствуют себя в общении с теми, кто похож на них, а не с теми, кто от них отличается.
Представьте себе, как изменится описанная ситуация, если архитектор сможет объяснить бизнесменам возникающие проблемы на понятном им деловом языке, а потом переведет суть проблем бизнеса на язык, понятный программистам. Вместо удивления и взаимного недоверия они придут к согласию и компромиссу.
Я не утверждаю, что изучение нескольких языков решит все ваши проблемы. И все же оно поможет предотвратить недопонимание, порождающее проблемы.
Тем читателям, кто находит эту точку зрения разумной, я желаю успеха на их пути. Или, как говорят клингоны, — Qapla![40]
Биография автора приведена ранее.
Не создавайте решения «на перспективу»Ричард Монсон-Хейфел
Сегодняшнее решение становится завтрашней проблемой
Никто не может предсказать будущее. Если вы согласны с этой всеобщей истиной, возникает вопрос: что следует считать будущим? Десятилетие? Два года? Двадцать минут? Если будущее невозможно предсказать, значит, вы не можете прогнозировать вообще ничего. Текущий момент и то, что ему предшествовало, — вот и все, что вы знаете, пока не наступит следующий момент. Собственно, из-за этого происходят автомобильные аварии: если бы вы знали, что во вторник попадете в катастрофу, то, скорее всего, остались бы дома.