Секретный ингредиент хорошего архитектора

Поиск высококлассных специалистов — один из самых сложных вопросов в бизнесе, связанном с разработкой ПО. Несмотря на все сложности мировой и отечественной экономики, квалифицированных кадров не хватает катастрофически. Количество проектов, требующих высокой квалификации, растет значительно быстрее, чем “зреют” специалисты (разработчик — 2-3 года, ведущий разработчик — плюс 2 года, архитектор решения — плюс 3–5 лет . ).

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

Поэтому, когда в мае 2012 года я получил предложение Технопарка Mail.Ru принять участие в проекте подготовки архитекторов в вузе ( пусть даже таком именитом как “Бауманка”) я был, мягко говоря, озадачен и заинтригован.

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

1. Докопались до сути проблемы: — Можно ли подготовить архитектора в вузе?Правильный ответ — «НЕТ»— Может ли обучение в вузе максимально ускорить развитие и повысить качество подготовки архитектора?Наш ответ — «ДА»
2. Сформировали правила создания курса: a) Обеспечить базовый отбор и исходное качество «материала» (подробнее об этом см. здесь: Технопарк Mail.Ru. Начало); b) Максимально повысить «эффективность» опыта, который получает студент вне обучения. В линейной ситуации сначала опыт «доводит» студента до ведущего разработчика, а затем другой опыт позволяет «переучиться» до уровня архитектора. Исключение переучивания позволяет сократить путь в 1,5-2 раза; для этого необходимо умение анализировать и систематизировать опыт; c) Дать учебную практику, чтобы закрепить базу знаний
3. Определили способы обеспечения качества: a) Прочный фундамент знаний для того, чтобы опыт не проходил мимо (820 часов + мастер-классы там же); b) Самый передовой опыт из первых рук (все курсы разработаны и проводятся с практиками).

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

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

1. Бизнес и системный анализ в продуктовой и сервисной разработке. В этой лекции закладывается основа понимания контекста различных видов бизнеса, основу которых составляет разработка ПО. С использованием прикладной теории систем и сложности вводится представление о ключевых проблемах и движущих силах в области разработки ПО. Корректируется механистическое представление о сложных системах, включая такие системы как бизнес, в основе которого лежит создание сложных технологических решений. (+2 к скорости развития, +2 к качеству принимаемых решений)
2. ЖЦ технологий их взаимосвязь с архитектурой ПО. На этом занятии рассматривается еще более широкий контекст, оказывающий влияние на бизнес и создаваемое техническое решение, связанное с инновационными процессами и эволюцией технологий. Рассматривается концепция подрывных и поддерживающих технологий, Gartner Hype Curve. Эти знания дают возможность осознанно наблюдать за изменениями в мире технологий и за кажущимся хаосом инновационного процесса, видеть управляющие им закономерности. (+1 к скорости развития, +2 к качеству принимаемых решений)
3. Бизнес-модель. Поток создания ценности. От внешних сил и законов, определяющих развитие отрасли целиком, мы переходим к конкретным вопросам достижения успеха продукта и компании. Рассматриваем способы коммуницирования и понимания бизнес-модели компании. (+2 к качеству принимаемых решений) На основе полученного опыта в следующий курс будет добавлен аспект потока создания ценности для сервисной модели разработки.
4. Моделирование использования. Анализ проблемы. Роль архитектора в работе над требованиями к системе. Определение заинтересованных лиц для продукта, проекта и архитектур. Работа с заинтересованными лицами. Моделирование пользователей. (+1 к скорости развития, +3 к качеству принимаемых решений)
5. Концептуальная модель, введение в аналитические паттерны. Этот модуль завершает первую часть курса. В нем происходит обобщение механизмов объектно-ориентированного проектирования и перевод их в плоскость инструмента работы с предметной областью ее изучения, а также использования уже накопленного опыта и создания собственных паттернов (шаблонов) решений. (+2 к скорости развития)

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

1. Атрибуты качества. Своего рода понятийный мостик между качественным продуктом и характеристиками архитектуры ПО. В этом модуле мы рассматриваем влияние нефункциональных требований на архитектуру программного обеспечения, а также модели качества ПО и сценарии атрибутов качества. (+1 к скорости развития, +2 к качеству принимаемых решений)
2. Ключевые концепции архитектуры программного обеспечения. View points. В продолжение проработки темы сложности в области разработки ПО в рамках этой лекции вводится терминологическая основа, инструменты работы и обеспечения целостности создаваемого продукта/решения c точки зрения заинтересованных лиц. (+2 к скорости развития, +1 к качеству принимаемых решений)
3. Ключевые концепции архитектуры программного обеспечения. Перспективы. В этой лекции обзорно рассматривается разработка архитектуры как процесс и как документ. (+1 к скорости развития, +1 к качеству принимаемых решений)
4. Процесс формирования архитектуры. Эта заключительная лекция связывает воедино и позволяет повторить все ключевые аспекты создания архитектуры высокого качества, включая процесс согласования и принятия архитектуры, процесс коммуницирования архитектуры не техническим специалистам. (+2 к успеху)

Практика была одним из самых сложных аспектов. Учить архитектора на примерах “Hello world” или очередного сайта интернет-магазина, мягко говоря, некорректно — это ведет напрямую к «карго культу». Создать в рамках относительно небольшого курса продукт, на котором можно почувствовать архитектуру и ее взаимодействие с бизнес-контекстом, тоже мало реально. Решение созрело быстро. Так же как и врачи, прежде чем стать хирургами, начинают со вскрытия — так и мы решили, что вначале студенты должны будут препарировать однозначно успешный продукт и постараются выявить те взаимосвязи, которые позволили продукту занять свое место. Только в отличие от врачей, для успешного бизнес- и системного анализа, совершенно необязательно анализировать мертвый продукт, живые тоже подходят. :-)

В рамках курса студенты в мини-группах работают над восстановлением бизнес-контекста и его взаимосвязи с архитектурой публичного продукта.

В этом семестре студенты выбрали следующие продукты:

• Поиск Mail.Ru
• Twitter
• Dropbox
• Яндекс.Директ
• и т.д.

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

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