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

Поиск высококлассных специалистов — один из самых сложных вопросов в бизнесе, связанном с разработкой ПО. Несмотря на все сложности мировой и отечественной экономики, квалифицированных кадров не хватает катастрофически. Количество проектов, требующих высокой квалификации, растет значительно быстрее, чем “зреют” специалисты (разработчик — 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
• Яндекс.Директ
• и т.д.

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

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

Суммируя

Курс «Бизнес- и системный анализ для архитекторов» позволяет:

1. Улучшить качество принимаемых архитектурных решений, связать техническое совершенство с реальными проблемами пользователей и задачами бизнеса
2. Внести систему в получаемый в рамках текущей и будущей работы опыт
3. Получить навык анализа архитектуры и коммуникации результатов анализа своим коллегам
4. С учетом полученного опыта проведения курса в будущем году мы планируем расширить часть курса, позволяющую студентам более эффективно выполнять домашние задания, связанные с пониманием потребностей бизнеса и пользователей системы.

Безуглый Дмитрий
cless75
http://www.facebook.com/dmitry.bezuglyy

Литература, использованная при подготовке курса:

1. Александр Остервальдер и Ив Пинье Построение бизнес-моделей. Настольная книга стратега и новатора
2. Дин Леффингуэлл, Дон Уидриг Принципы работы с требованиями к программному обеспечению. Унифицированный подход Вильямс 2002 Гл 8-13
3. Крэг Ларман, Применение UML 2.0 и шаблонов проектирования (3-е издание) Вильямс 2006.
4. Клейтон М. Кристенсен Дилемма инноватора. Как из-за новых технологий погибают сильные компании2012
5. Мартин Фаулер, Дейвид Райс, Мэттью Фоммел, Эдвард Хайет, Роберт Ми, Рэнди Стаффорд. Шаблоны корпоративных приложений
6. Martin Fowler Analysis Patterns: Reusable Object Models
7. Nick Rozanski, Eóin Woods, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition) 2011
8. www.viewpoints-and-perspectives.info/
9. Л. Басс, П. Клементс, Р. Кацман Архитектура программного обеспечения на практике (NFR)
10. Мартин Фаулер UML. Основы. Краткое руководство по стандартному языку объектного моделирования
11. Алистер Коберн Современные методы описания функциональных требований к системам
12. Алан Купер Психбольница в руках пациентов
13. Барбара Минто. Принцип пирамиды Минто Золотые правила мышления, делового письма и устных выступлений
14. Майкл Ротер, Джон Шук Учитесь видеть бизнес-процессы. Практика построения карт потоков создания ценности