company_banner

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

    Что посеешь, то и пожнешь
    Из желудя вырастет дуб,
    Из семени репейника — только репейник
    Профессиональное образование —
    это семена, которые мы сеем...


    Поиск высококлассных специалистов — один из самых сложных вопросов в бизнесе, связанном с разработкой ПО. Несмотря на все сложности мировой и отечественной экономики, квалифицированных кадров не хватает катастрофически. Количество проектов, требующих высокой квалификации, растет значительно быстрее, чем “зреют” специалисты (разработчик — 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. Майкл Ротер, Джон Шук Учитесь видеть бизнес-процессы. Практика построения карт потоков создания ценности
    Mail.ru Group
    1814,00
    Строим Интернет
    Поделиться публикацией

    Комментарии 10

      +11
      «только половина студентов IT-специальностей»
      Это очень оптимистично т.к. обычно в группе таких человек отсилы 3-5
        +2
        В хороших ВУЗах на целевых специальнотях даже больше. На мой взгляд в ВШЭ на Програмной инженерии доходит до 3/4 :-) ( по крайней мере из тех кто доживает до магистров)
        p.s.Но и в ВУЗах попроще тоже много хороших ребят
        0
        Странно видеть такой курс в двухгодичной программе обучения, учитывая что в первом семестре рассказывали про то, что такое реляционные субд и как сделать select, и прочие основы основ. То есть этапы технических навыков, выстраивания взаимосвязей и личныех навыков успешно пройдены?
          0
          Понимание потребностей бизнеса и умение анализировать не базируется на технических навыках. Более того может способствовать более эффективному их развитию. Хотя конечно побольше практического опыта для второй части не помешало бы.
          p.s. Статью внимательно читали?
            +1
            Однако вы их изобразили наверху пирамиды, а технические навыки внизу. Или у пирамиды какой-то другой смысл?
              +1
              Хороший вопрос :-) Рисунок с пирамидой это классическое представление и последовательность приобретения навыков ведущее к длинному, длинному пути. По сути один из основных тезисов статьи в том, что за счет изменения последовательности обладения знаниями можно путь сократить.
                0
                Собственно, этот тезис и хотелось бы покритиковать (слегка). Все таки в начале такая оценка дается:

                разработчик — 2-3 года,
                ведущий разработчик — плюс 2 года,
                архитектор решения — плюс 3–5 лет


                А тут получается вместо 10 лет 2. Не слишком ли круто?

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

                Может, конечно, что-то изменилось, но когда я учился в технопарке (1ый семестр), там было всего два предмета в семестр. Это очень мало, на мой взгляд, чтобы отходить от технических тематик.

                P. S. За литературу — спасибо
                  +2
                  По поводу критики
                  1) Два года это на то чтобы посеять правильные семена :-) Практический опыт никто не отменял.
                  Суть этого курса в том чтобы сделать полученный опыт более эффективным.
                  2) В идеале если из всего потока 2-3 человека станет архитекторами через 3-4 года после окончания «технопарка» — очень хороший результат. Да и разработчики из ребят получатся гораздо более эффективные

                  По поводу технической тематики:
                  Какой технической дисциплины на Ваш взгляд не хвататет в программе технопрака?

                  p.s. Честно говоря, мне как преподавателю и инженеру со стажем ( когда то насчитал 26 инструметов разарботки в своем резюме ) не совсем понятно «преподавание» языков программирования. Первый язык еще куда ни шло, но следующие лучше и эффективнее учить с книжкой, компилятором и реальной задачей.
                  Чего не скажешь о бизнес и системном анализе. Хотя конечно есть ребята которые верят что Вигерс им открывает все тайны :-)
          0
          ИМХО, высококлассные специалисты есть. Дешёвых нет, но это уже другая проблема.

          Пожалуй самое ценное в этом курсе — практика. Хотя было бы реалистичнее если бы также участвовали не технические специалисты (например с эконом. факультетов), которые делали бы постановку задачи, а команда пыталась их решить.
            0
            Тезис в том что их мало, по сравнению с колличеством проектов, в которых они необходимы.

            Такая практика была бы дейтсвительно хороша. Но тогда проект будет один на всех. У нас стоит задача охватить несколько предметных областей. Т.к. при разборе кейса минигруппы участвует вся группа.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое