С чего начать создание своей ракеты

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

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

Компоновочная схема двухступенчатой ракеты-носителя сверхлёгкого класса Falcon-1
Компоновочная схема двухступенчатой ракеты-носителя сверхлёгкого класса Falcon-1

Так с чего же начать? А начать опять-же надо с команды. Вам необходимо собрать команду 3-4 специалистов, которые смогут выполнить небольшую научно-исследовательскую работу (НИР) по той ракете (комплексу), которую вы хотите создать. Этот этап совсем не формальность. Вы должны будете определиться с основными параметрами ракеты, требованиями, которые вы к ней предъявляете, последовательностью действий по её созданию и потребными ресурсами, которые нужны для воплощений ваших идей. По сути это инвестиционная презентация или бизнес-план с картинками, параметрами, деньгами и сроками. Такую презентацию можно и на коленке сварганить без расчётов и раздумий. Но этот вариант я не рассматриваю в качестве цели, так как целью должно являться не облапошивание инвестора или заказчика, а реальное создание и полёт ракеты. Но самый первый шаг придётся делать на коленке, ибо это лучше, чем чистый лист. А дальше уже надо начинать создавать!

Состав работ

Так вот, какие же работы надо на первом этапе сделать? А их примерный список такой:

  • Оценка рынка и его потребностей. Тут должны быть определены целевые орбиты и потребные массы полезного груза, а также цена таких запусков у конкурентов.

  • Формирование облика своей ракеты с комплексом. Сравнение с конкурентами и объяснение почему вы будете на рынке жить, а не умирать.

  • Формирование состава работ по созданию ракеты и комплекса, их увязку в график и назначение стоимости каждому этапу.

  • Определение цены изготовления и запуска ракеты, затрат на содержание инфраструктуры и т.п.

  • Формирование финансовой модели проекта, где показывается схема привлечения средств и окупаемость проекта.

Это достаточно укрупнённый и не полный список, но это база, без которой нельзя. В принципе всё это нужно больше не инвестору или заказчику, а больше вам самим для понимания того, что вы сами хотите сделать. Инвестору и заказчику нужно будет ответить всего на три вопроса:

  • Что вы предлагаете делать?

  • Кто это всё будет делать?

  • Какие для этого нужны ресурсы?

Уверяю вас, что развёрнутые ответы на эти вопросы однозначно определят судьбу проекта.

Какую ракету делать и как определить её технический облик

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

А вот дальше уже идут достаточно сложные технические вопросы. Так вот для техники вам надо увязать облик ракеты и комплекса. Для этого под нишу в рынке (или куда вы ткнули пальцем) надо выполнить проектно-баллистический анализ и определиться с основными параметрами ракеты. Основными проектными параметрами ракеты являются:

  • Количество ступеней ракеты и тип их соединения.

  • Тип применяемого топлива и удельные импульсы тяги двигателей.

  • Тяговооружённости ступеней (тяга двигателей).

  • Распределение масс по ступеням (заправки) или относительные конечные массы ступеней.

  • Диаметр ракеты или нагрузка на мидель.

Дополнительно рекомендуется выбирать:

  • Точка старта (космодром).

  • Дальность полей падения отделяющихся частей.

  • Ограничения на условия сброса головного обтекателя.

  • Максимальные действующие перегрузки в полёте.

  • Тип и схема разделения ракетных блоков.

  • Требования по «захоронению» верхней ступени.

Эти параметры, требования и ограничения не являются полными, но их вполне достаточно для того, чтобы определиться с обликом ракеты. Перебирая основные проектные параметры, вы влияете на всё, в том числе на стоимость и сроки создания, а также на стоимость пусковых услуг. Основные проектные параметры выбираются на основе расчётов баллистики, так что, либо ищите себе в команду проектного баллистика, либо изучайте сами. Также при расчёте баллистики нужны относительные весовые коэффициенты или попросту массы элементов конструкции. Желательно, чтобы у вас был специалист, который умеет эти массы считать с достаточно высокой степенью точности и обосновывать их на основании статистики. Что такое весовые коэффициенты, можете почитать в 15 главе книги «Проектирование средств выведения космических аппаратов», В.К. Сердюк. В принципе баллистику и веса вполне может считать один человек, это даже было бы самым правильным. Но тогда на специалиста может лечь сильно большая нагрузка, что скажется на сроках и качестве. Единственное, стоит учитывать, что при выборе проектных параметров вы должны максимизировать или минимизировать некую функцию. В учебной литературе предлагается обычно улучшать весовое совершенство ракеты. Но скорее всего вам нужно будет минимизировать стоимость пуска или сроки и стоимость разработки (создания). Обычно эти критерии противоречат друг другу, так что придётся выбирать. Но самое сложное в этой работе то, что достоверных моделей (функций) стоимости и сроков нет. Либо формируйте зависимость от основных проектных параметров сами на базе учебной литературы и статей, либо волюнтаристически выбирайте параметры, которые как вам кажется обеспечат вам то, что нужно.

Упаковываем результат и расширяем уровень знания о ракете

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

А как-же выполнить все остальные работы? А для этого необходимо определиться с составом комплекса. Наилучшим образом для этого подходит схема деления.

Примерный вид схемы деления космического ракетного комплекса
Примерный вид схемы деления космического ракетного комплекса

На схеме деления вы определяете структуру и состав комплекса и его составных частей. Вы должны всё расписать на такую глубину, чтобы у каждого кубика был определён исполнитель по проектированию, изготовлению и испытаниям. Это может быть кооперация, а можете туда вписать свою компанию. Каждому кубику вы расписываете этапы их создания, не забывая вопросы организации производства и испытаний. Для чего это делается?

Каждому этапу и кубику вы можете присвоить значение сроков и стоимости создания. Лучше всего на основании статистики и переговоров с кооперацией и специалистами. Можно и из головы взять, это всё равно будет точнее, чем ничего. Все сроки (этапы) вы увязываете в последовательность с отслеживанием их зависимости друг от друга. При этом следует учесть, что без неких выполненных этапов одного кубика нельзя начать выполнение этапов других кубиков. Кажется довольно сложным, но голова у нас всегда боится, а руки делают. Как только вы начнёте это прорисовывать, то увидите, что это всё надо просто прорисовать. Хотя всё это отнимает много времени и сил. В итоге вы получаете возможность сформировать взаимоувязанный план-график работ, график затрат, перечень кооперации и даже потребность в специалистах. Поставив каждому кубику цену изготовления и услуги при подготовке и проведению пуска, вы сможете сформировать цену пуска. На выходе вы будете знать всё о своём проекте. Не выполнив эту работу, вы будете знать — ничего! Ну а если вы постараетесь и всё сделаете правильно, то финансовый план у вас получится сам. Также к данным кубикам и их этапам вы можете приписывать количество людей, их квалификацию, площади помещений, оборудование и всё, что потребуется.

Заключение

Вот с чего необходимо начинать создание своей ракеты. Если вы хотите сэкономить силы и этого не делать, то вы просто начнёте начинать создание позже, а до этого вы будете готовиться к первому этапу. Сама же глубина и точность проработки на первом этапе (НИР) может быть относительно небольшая, но сформированная модель, структура и состав позволят вам достаточно уверенно идти вперёд и решать новые совершенно непонятно откуда взявшиеся задачи.

Данная статья написана на базе моего личного опыта и надеюсь будет особо полезна студентам, которые только начинают изучать проектирование ракет-носителей. Статья носит обзорный и вводный характер и написана общедоступным языком (по крайней мере старался). Если вам будет интересно, то могу попробовать написать статью про проектно-баллистический анализ с формулами и расчётами.

ссылка на оригинал статьи https://habr.com/ru/post/517218/

Киберграмотность сотрудников: флаеры и шаблоны писем, которые они захотят прочитать

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

Информационные памятки по кибербезопасности

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

Флаер по фишингу

Согласно статистике киберпреступлений за последние годы 71 % хакерских группировок, совершивших атаки в 2017 году, использовали целевой фишинг электронной почты (по данным компании Symantec), что делает этот способ взлома самым популярным среди злоумышленников. Эта информационная листовка поможет привлечь внимание ваших коллег и сотрудников к таким угрозам, как фишинг и whailing.

Флаер по безопасным паролям

У нас и в далеких-далеких галактиках есть хакеры, взламывающие ненадежные пароли. Этот флаер «Компьютерные войны» поможет привлечь внимание к безопасности паролей и учетных записей и рассказать о двух эффективных способах защиты: диспетчерах паролей и многофакторной аутентификации.

Флаер по поддельным счетам

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

Базовые шаблоны памяток по кибербезопасности

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

Памятки по кибербезопасности для новых сотрудников

Как показывает опыт, знакомство с корпоративными политиками и мерами кибербезопасности должно входить в обучение всех новых сотрудников. Эти шаблоны помогут новым сотрудникам начать работу в компании с верной ноты.
Важные темы:

Шаблон письма

Здравствуйте, [ИМЯ].

Мы рады приветствовать Вас в наших рядах. Я понимаю, что Вам предстоит ознакомиться с большим количеством документов во время обучения. Тем не менее я хочу привлечь Ваше внимание к политикам кибербезопасности, принятым в нашей компании.

Мы придаем большое значение безопасности и целостности данных. Это отражено в приложенной политике безопасности. Ниже перечислены некоторые важные темы. Если у Вас возникнут вопросы по мерам безопасности, обращайтесь ко мне.

  • Политика безопасности [ССЫЛКА или ВЛОЖЕНИЕ]

Важные темы, затрагиваемые в политике:

  • нормативные требования к безопасности и конфиденциальности в [ОТРАСЛЬ]
  • работа с конфиденциальными и персональными данными
  • безопасность паролей и учетный записей
  • [ДРУГИЕ ВАЖНЫЕ ТЕМЫ]

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

С благодарностью,
[ПОДПИСЬ]

Памятки по кибербезопасности для удаленных сотрудников

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

Важные темы:

Шаблон письма

Здравствуйте, [ИМЯ].

Хотим ознакомить Вас с последними нововведениями в области безопасности.

Используя общедоступные и бесплатные сети Wi-Fi, Вы подвергаете себя угрозе взлома, а [КОМПАНИЯ] — угрозе нарушения безопасности данных и их кражи.

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

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

Измененная политика вступает в силу [ДАТА]. Чтобы избежать накладок, выполните настройку устройства к [ДАТА].

С благодарностью,
[ПОДПИСЬ]

Памятки по кибербезопасности для всех сотрудников

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

Важные темы:

  • безопасность паролей
  • фишинг, спуфинг и другие типы мошенничества с использованием электронной почты
  • поддельные счета

Шаблон письма

Здравствуйте, [ИМЯ].

Ввиду [ПРИЧИНА] мы хотим привлечь Ваше внимание к [ТЕМА].
[ТЕМА] — это [ОПРЕДЕЛЕНИЕ]. Чтобы обеспечить целостность и безопасность данных [КОМПАНИЯ], необходимо [ДЕЙСТВИЕ].
[ДОПОЛНИТЕЛЬНЫЕ СВЕДЕНИЯ И ПЕРЕЧНИ]

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

С уважением,
[ПОДПИСЬ]

Шаблон памятки по фишингу

Здравствуйте, коллеги

В свете растущего числа фишинговых атак мы хотим поделиться некоторыми советами, которые помогут вам защитить данные ваших учетных записей.

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

Разновидности фишинга:

  • целевой фишинг — фишинговая атака, направленная на конкретное лицо; например, хакер может выдавать себя за вашего знакомого, чтобы втереться к вам в доверие
  • whailing (уэйлинг) — фишинговая атака, направленная на лиц с широкими правами доступа к данным, средствам и информации (например, на владельцев компаний, финансовых директоров и т. д.)

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

Признаки мошенничества:

  • опечатки в словах
  • необычные или масштабные запросы
  • странный пустой веб-сайт
  • небезопасный веб-сайт
  • отсутствие подвала сайта и навигации
  • опечатки в словах
  • отсутствие контактной информации

Как защитить себя от таких атак:

  • Главное, что вы должны усвоить: не переходите по ссылке
  • не будьте доверчивы и беспечны, задавайте уточняющие вопросы
  • прежде чем опубликовать что-либо в социальных сетях, подумайте, не сделает ли это вас легкой мишенью для злоумышленников
  • регулярно обновляйте программное обеспечение
  • убедитесь, что все пароли соответствуют корпоративным стандартам (комбинация букв и цифр, минимум 16 символов) и хранятся только в одобренном компанией диспетчере паролей

Благодарим вас за все, что вы делаете для безопасности своих коллег, а также для защиты наших данных и данных клиентов. Спасибо за внимание.

С уважением,
[ПОДПИСЬ]

Памятки по кибербезопасности для руководителей

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

Важные темы:

Шаблон письма

Здравствуйте, [ИМЯ].

В рамках мероприятий по улучшению безопасности и обеспечению соответствия [НАЗВАНИЕ НОРМАТИВНОГО АКТА] просим Вас уделить особое внимание [ТЕМА].
Чтобы эффективно внедрить и оптимизировать [ТЕМА], воспользуйтесь приведенными ниже [советы/шаги].

• [СОВЕТ/ШАГ]
• [СОВЕТ/ШАГ]
• [СОВЕТ/ШАГ]
Мы ожидаем, что Вы подадите достойный пример своим подчиненным и они вслед за Вами также станут уделять повышенное внимание вопросам безопасности.
Заранее благодарим Вас за все, что Вы делаете для защиты данных наших сотрудников и пользователей. Ваш вклад очень важен.

С уважением,
[ПОДПИСЬ]

Шутливые шаблоны для последующих напоминаний о кибербезопасности

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

Шутливые темы для рассылок:

  • Несмешной смишинг: как не стать жертвой мошенников
  • Напоминание: станьте мастером экстра-класса в создании и хранении паролей
  • Совет по выявлению мошенничества: поддельные счета вместо писем от нигерийского принца

Шаблон письма
Всем привет!
Мы бы хотели ненадолго отвлечь вас от дел, чтобы напомнить о правилах безопасности паролей [И (ИЛИ) ДРУГАЯ ТЕМА].

Пароли должны:

  • содержать буквы и цифры
  • содержать минимум 16 символов
  • храниться в одобренном компанией диспетчере паролей ([ССЫЛКА НА ДИСПЕТЧЕР ПАРОЛЕЙ])
  • [ДРУГИЕ СОВЕТЫ]

Заранее благодарим вас за вклад в общее дело. Держим ухо востро, друзья!
[ПОДПИСЬ]

Восемь оригинальных идей для мероприятий по информированию о кибербезопасности

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

  1. Базовый опрос. Попросите сотрудников ответить на пару вопросов по кибербезопасности и методам ее обеспечения, чтобы определить уровень осведомленности в масштабах всего коллектива и разных отделов. После этого вы сможете адаптировать остальные мероприятия, чтобы повысить их эффективность.
  2. Проверка с помощью фишингового письма. Отправьте всем сотрудникам убедительное фишинговое письмо, чтобы на практике проверить их знания о фишинге. Используйте поддельный электронный адрес компании и вставьте в письмо корпоративную символику, чтобы замаскировать его под обычную внутреннюю рассылку. Письмо должно содержать запрос на предоставление доступа или конфиденциальных данных. Заметив это, внимательные сотрудники смогут сообщить о попытке взлома. Выявив тех сотрудников, которые ничего не заподозрили, вы сможете провести для них дополнительное обучение, чтобы подготовить их к реальным угрозам.
  3. Имитация атаки, направленной на конкретное лицо. Здесь мы снова предлагаем вам использовать поддельное фишинговое письмо, но на этот раз его нужно адаптировать в соответствии с должностью адресата или его отделом. Чем реалистичнее будет ваша имитация, тем больше полезного опыта получат сотрудники
  4. Викторина или «Своя игра» для команды. Перерыв на обед или на неформальное общение — отличное время для того, чтобы провести веселое и познавательное мероприятие для команды. Подготовьте для них вопросы по кибербезопасности и мерах ее обеспечения. Чтобы стимулировать активное участие, предложите победителям официальное звание знатока и возможность сделать пожертвование в благотворительный фонд от лица компании.
  5. Соревнование по выявлению уязвимостей (для ИТ-специалистов). Не забывайте об ИТ-персонале и других специалистах по безопасности: для них можно провести соревнование по выявлению уязвимостей с призами для тех, кто найдет самые серьезные уязвимости. В ходе соревнования участники смогут выявлять расставленные вами (а также реальные) уязвимости и баги в системах или сети. Используйте для этого мероприятия тестовую среду, чтобы не нарушать производственные процессы и не перегружать узлы трафиком
  6. Цели и важные этапы. Составьте список утвержденных мероприятий, викторин, онлайн-тестов и сертификационных курсов, которые сотрудники смогут проходить в своем темпе в определенный период. За каждое выполненное задание сотрудники будут получать баллы, а в конце периода по сумме баллов вы сможете определить победителей, которые получат призы (отгул, подарочный сертификат, пожертвование в фонд и т. д.).
  7. Использование визуальных материалов и видео. Используйте разные методы представления информации, чтобы вовлечь сотрудников и помочь им усвоить важность затрагиваемых тем. Если у вас есть возможность, снимите видеоролик, посвященный наиболее важным вопросам. Либо просто включите в вашу рассылку один из флаеров по кибербезопасности, приведенных выше.
  8. Приглашенный эксперт. Существует множество специалистов и компаний, которые занимаются организацией увлекательных и познавательных мероприятий. Вы всегда можете обратиться к профессионалам, которые организуют для вашей команды мероприятие, презентацию или познавательный семинар с закусками.

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

ссылка на оригинал статьи https://habr.com/ru/company/varonis/blog/517232/

Как мы распилили монолит. Часть 1

Привет, меня зовут Ваня. Я решаю архитектурные задачи на фронтенде в Тинькофф Бизнесе и сейчас расскажу вам про одну из них.

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

Синхронизация

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

Как было

Долгое время в компании был репозиторий с проектом РКО (расчетно-кассовое обслуживание), в котором находилась почти вся функциональность данной аббревиатуры. На картинке показано примерное количество разных блоков, которые пытались жить своими релизными циклами и фича-командами.

Примерная схема монолитного фронтенд-приложения
Примерная схема монолитного фронтенд-приложения

Одна из мыслей, которая приходит при просмотре картинки: «А давайте-ка мы все это распилим на независимые части!». На эту тему я предлагаю порефлексировать.

Нужно ли?

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

Тезис

Почему это хорошо

Почему это плохо

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

Если вы разделите приложение на несколько, то разработчики физически не смогут друг друга заблокировать. В рамках одного монорепозитория можно настроить линтинг на запрет импортов из соседних проектов

Этот пункт можно относительно спокойно решить с помощью TBD и фича-флагов

Уменьшение связности кода

Грамотная организация кода позволит вынести общую функциональность в библиотеки и назначить ответственных, а настроенные процессы — как в команде, так и технические — закрепят разделение

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

Выделение логических частей продукта в проекты с целью повышения ответственности (ownership) за кодовую базу. Этот пункт актуален для больших команд, которые работают в одном репозитории. Часто в мастер-ветке бывает 5, 10, а то и больше пулл-реквестов (ПР), которые могут конфликтовать друг с другом

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

В монолите можно организовать код по библиотекам или разделам, на которых также появятся ответственные. Дополнительно можно создать и соблюдать определенные договоренности по работе с git flow

Возможность менять стек отдельной части

Команда как владелец приложения определяет свой стек — например, может поменять state-менеджер, обновить библиотеку до последней версии или, наоборот, зафиксировать ее. Отмазки «так исторически сложилось» со временем пропадут

Возможность ротации специалистов между командами усложняется с увеличением разницы в стеке технологий между проектами

Возможность заморозить часть приложения

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

— Кто сломал такую-то функциональность на этом релизе?

— Это соседняя команда. Они сказали, что ревью прошло, все протестировано и доехало до прода.

Правда знакомо? 🙂

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

Рефакторинг маленьких приложений происходит быстрее

У вас есть некоторое ломающее изменение, и нужно мигрировать со старой версии на новую. Например, повысить версию Ангуляра (хотя со схематиками это одна радость). У вас варианты: 

  1. Засесть на большой срок за миграцию одного монолита, по дороге что-то потерять или сломать, потому что ПР будет очень большим

  2. Мигрировать по проекту: ПРы и вероятность что-то потерять ниже — за счет меньшей кодовой базы

Рефакторинг монолита можно проводить частями, для больших миграций могут помочь скрипты, codemod и схематики. В таком случае весь проект будет 100% переведен и технического долга не останется

Сокращение времени выполнения тестов, линтов и так далее — за счет уменьшения кодовой базы

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

Все же такие тест-раннеры существуют и в монолите можно распараллелить выполнение задач

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

Что дальше?

Если вы все-таки решили распиливать монолит, теперь у вас на одну проблему больше 🙂 Обсудим первоочередные затруднения, с которыми мы столкнулись:

  • Каким образом будет происходить оркестрация приложениями. Теперь вам понадобится дополнительная обвязка-приложение, которое будет определять активное приложение на экране пользователя. У нас это Frame Manager, познакомиться с которым можно в докладе или в следующей статье.

  • Глобальные стили и зависимости больше не могут быть глобальными в абсолюте. Вам придется думать, как правильно развести глобальное состояние приложений, будь то window.myVar или глобальный стиль .my-bar. Теперь вам необходимо учитывать, что соседнее приложение может обратиться к вашему состоянию и произойдет что-то неожиданное. Данный пункт применим только к случаям, когда на странице более одного микрофронтенда.

  • Зависимости приложения теперь дублируются. Поясняю: все пакеты ваших приложений находятся в каждом из ваших приложений. Если раньше пользователь загружал vendor.js один раз и пользовался монолитом, то теперь это будут vendor1.js, vendor2.js и т. д. Если сойдутся звезды, то у вас будет полное совпадение всех версий и хэш в названии файла будет одинаковым — тогда браузер достанет файл из кеша. Однако такое совпадение полностью убивает преимущество № 4, да и, скорее всего, эти приложения будут находиться по разным url’ам и файл все равно будет загружен.

Разделение

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

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

  1. На каждую из логических частей создаем новое полноценное приложение. Если встречаются переиспользуемые сущности, то копируем их в новый проект. Звучит абсурдно, но никто не будет спорить, что это самый быстрый вариант. Однако копировать общий код из репозитория в репозиторий совсем не круто, поэтому чуть прокачаем метод.

  2. На каждую из логических частей создаем новое полноценное приложение и отдельно выносим общую кодовую базу в некий foundation. Это может быть отдельный (моно)репозиторий или директория libs у вас в проекте. И вот здесь возникает еще один нюанс: вынести-то мы вынесли, а как теперь обратно в проект подключить?

    • Самый простой вариант — положить библиотеки в репозиторий вашего проекта. Способ применим, если вы распиливали монолит в одну монорепу. Например, по такому алгоритму работает Nx Workspace. Таким образом вы можете работать со своими библиотеками, не переключаясь с проекта. Однако минусом будет тот факт, что конкретно в этот момент вы можете использовать только текущую версию библиотеки. Вы не можете ее зафиксировать, повысить или понизить, а любое изменение библиотеки соседними разработчиками автоматически применится на ваш проект.

    • Чуть посложнее: на каждый релиз вашего приложения можно создавать отдельную ветку в foundation и указывать ее название в package.json. В принципе готово. Теперь после установки зависимостей у вас будет загружена именно та версия общего кода, которую вы указали, а все дополнительные настройки можно сделать через tsconfig.json.

    • git submodule / subtree — вариант чуть посложнее, так как, кроме простого указания ссылки на репозиторий, придется еще чуть-чуть отладить его работу. У этого варианта есть огромный плюс перед предыдущим: можно прямо в своем проекте изменять исходники библиотек и пушить их в репозиторий. Еще плюс по сравнению с первым пунктом — всегда можно зафиксироваться на определенном коммите и изменение общего кода не затронет ваш проект.

    • Сложный вариант — настроить публикацию вашего общего кода как npm-библиотек, при этом заранее разбив его на пакеты. Декомпозиция нужна, чтобы изменение функциональности проходило дозированно. Вот что я имею в виду: если разработчик меняет работу с авторизацией обратно несовместимо в пакете auth и повышает версию с 1.0.0 до 2.0.0, а второй разработчик хочет поменять название в баннере для платежной системы, который каким-то чудом оказался в этом же пакете, то он выпустит уже 2.0.1, но применить его не сможет, пока не обновит в своем проекте авторизацию, которая ему в общем-то и не нужна. Здесь же можно придумать различные релиз-кандидаты, альфа-/бетаверсии и т. д. Если вас это заинтересовало — рекомендую посмотреть Lerna.

  3. Заново построить SPA. Если у вас ранее был SPA, вы, скорее всего, хотите его вернуть, чтобы у пользователя не было перезагрузки страницы, одно состояние и тому подобные плюсы одностраничного приложения. Вам придется разработать обертку над своими приложениями, которая будет всем этим заниматься. Напомню, что у нас этим занимается Frame Manager, о котором в скором времени тоже расскажем. Если очень упрощать, то вам понадобится функциональность, которая будет сопоставлять массив продуктов с массивом путей и изменять состояние страницы в зависимости от пути. В качестве шины для передачи состояния можно придумать массу решений: window.myVar, localStorage, sessionStorage, CustomEvent, postMessage и так далее.

  4. Если ваш проект использует технологию серверного рендеринга (SSR), вам также стоит продумать изменения архитектуры. Будьте готовы запрашивать разные части с разных серверов и склеивать их в единое приложение для пользователя. Минусом такого подхода может быть возросшая нагрузка на серверы вашей компании. Также стоит отметить, что, если части вашего приложения будут собираться воедино с помощью iframe, это может вызвать проблемы с SSR.

Тинькофф Бизнес

Мы в Тинькофф выбрали несколько вариантов.

Исторически первым распилом был вынос части Тарифов в отдельный репозиторий. На тот момент ключевой целью было обкатать процесс безболезненного разделения функциональности от монолита и дальнейший релиз на продакшен без проблем для пользователя. При этом общий код был в отдельном репозитории, который публиковался в виде npm-пакетов. 

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

  • Новые приложения стали самостоятельными продуктами с большим числом наработок. Делать по прошлому процессу означало перенести общий код в базовый монорепозиторий, но стоило ли оно того? Этот код использовал только этот проект и проект, который будет отрезан от него. Нужна ли такая библиотека в общем пространстве?

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

  • Для продуктов уже был настроен ci pipeline, а заведение нового продукта требовало дополнительных манипуляций.

В итоге подход был пересмотрен на пилотном проекте: мы стали использовать Nx. Теперь части приложения выносились в apps/, а их пересекающийся код обобщался в libs/. Это позволило решить первые две потребности команд, но только усилило третью. В итоге ci pipeline был полностью переписан и теперь добавление к новому продукту pipeline занимает считаные минуты, так как мы придерживаемся подхода IaC.

tl;dr

От монолита в одном репозитории мы смасштабировались до десятков монорепозиториев с микрофронтендом, которым для клиента управляет Frame Manager.

Схема взаимодействия клиента с микрофронтендом
Схема взаимодействия клиента с микрофронтендом

Советы

Вот мы и прошли весь тернистый путь от принятия решения до его реализации. Мы приняли недостатки каждого метода и получили преимущества от реализации, описанные выше. Пробежимся быстренько по tips&tricks, которые помогли нам в работе:

  1. Подумайте несколько раз, действительно ли вам будет полезен микрофронтенд? Пока мы общаемся с вами в рамках этой статьи, вы, скорее всего, еще не начали распил, а значит, есть время одуматься 🙂

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

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

  4. Если ваша цель — декомпозировать проект более одного раза, то задокументируйте все процессы настройки, чтобы другая команда пошла уже по проторенной дороге, а не набивала шишки заново. В худшем случае вы можете получить несколько решений микрофронтенда в одной компании/продукте.

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

P. S.

Делитесь своими вариантами реализации микрофронтенда, подводными камнями, на которые наступили, плюсами, которые получили при реализации, или почему передумали и остались в монолите.

ссылка на оригинал статьи https://habr.com/ru/company/tinkoff/blog/517230/

Заработай, сидя дома

image

Заходишь в знакомый слегка пыльный офисный воздух, а на душе радостно, как будто вернулся в старые места, забрался на знакомую вершину с прекрасным видом. Стоишь, наслаждаешься красотой заброшенного опенспейса и готовишь кофе в гордом одиночестве. Вкус совсем не изменился, но первая чашка кажется чуть приятнее, чем помнится. Пьёшь, привычно проверяешь почту и понимаешь, что на некоторые горы люди забираются исключительно ради красивого вида, а затем спешат спуститься вниз к себе на равнину. Фотка пустых кубиков на прощание и путь в сторону дома!

Кто любит работать из офиса, общаться с коллегами, есть печеньки и болтать на кухне – это я. Сказали бы мне, что мне будет лучше работаться из дома, я бы не поверил и привел 100 причин, почему дома работать не эффективно, неудобно и вообще лень. Десять лет в разных конторах я работаю в техподдержке и где-то офис – это скромно и для работы, где-то чуть приятнее и для души, но везде это в меру удобное место для работы с различными бонусами в виде печенек, коллег и других приятностей по вкусу.

Последние пару лет я живу в Брисбене Австралия и у меня была возможность работать из дома, но пользовался я ей крайне редко. Всё неожиданно изменилось, когда в марте все вокруг перешли на удалёнку. Я успел прихватить пару мониторов и пожелав коллегам счастливого рождества (да, уже в марте, было ощущение, что увидимся мы не скоро) отправился открывать свой маленький офис к себе домой.

ЧТО НЕ ТАК ПРИ РАБОТЕ ИЗ ДОМА

  • Дом, это то место где отдыхаешь, тут работать во-об-ще не хочется. Хочется сделать видимость постоянного присутствия онлайн и раз в полчаса ходить на кухню за печенькой. Потом плюнуть и принести печеньки к компу и смотреть YouTube, время от времени проверяя рабочий чат и почту.
  • Все остальные недостатки, они конечно от начальной лени и внутренней неустроенности. Перечислять их можно долго, было бы кому слушать.
  • Дополнительные расходы на кофе и печеньки. Если для вас кофе это ещё и ритуал, то будьте готовы потратиться, ещё и на кофемашину. Должен же в доме хоть кто-то работать пока вы отдыхаете.
  • Рано или поздно ощущается покалывание от дефицита общения. Тот же кофе оказывается не такой вкусный, когда делаешь его на кухне в одиночестве. При этом, как кофеин не стоит пытаться заменить на что-то более безобидное, так и с живым общением – суррогаты опасны для здоровья. Даже не думайте делать Zoom и все эти групповые звонки – пустая трата времени. Лучше чатится или уже письмо написать, так реально проще и от видосиков меньше отвлекаешься.
  • Будьте готовы, что дома нет удобной мебели и хорошего освещения. Журнальный столик для работы сидя на полу или походный стол из гладильной доски вызывают радость только первое время. Первые 15 минут.
  • Работа дома с детьми – это новая реальность и ещё один оксюморон в копилку: горячий лёд, страшно красива, отдых с детьми.
  • Буду работать из дома, появится больше свободного времени. Ложь и обман! С общим недовольством собственной эффективностью и невыполненными планами оказывается, что нужно задержаться ещё и ещё. После 12 часовых заседаний и звонков, все домашние хотят отправить вас в офис на 8 часовой рабочий день.

ЧТО ТАК ПРИ РАБОТЕ ИЗ ДОМА

  • После начальной ломки оказывается, что и с небольшим монитором можно успевать следить за всем что раньше на 3х не помещалось. Главное желание.
  • Короткие перерывы каждые час-полтора – это гениально. Важно оторваться от монитора и заняться любым другим делом, желательно не доходя до кухни. За день с таким графиком и домашние дела можно успеть поделать, и к концу дня голова не гудит от постоянного смотрения в монитор. Главное, чтобы через 20 минут любого такого отдыха ваш внутренний Штирлиц был готов проснуться и поехать в Берлин.

  • Работа из дома – это отличный повод разобраться с рабочим местом и вещами, которые используются для работы ежедневно. Удобная мебель и правильное освещение помогут оставаться продуктивным и создадут приятную атмосферу для работы. Добавим к этому удобные клавиатуру, мышку и вам никогда не захочется сидеть за “агрономическим” офисным стулом и пользоваться стоковой мышкой.
  • Наконец, появилось время для тайм менеджмента. Да, теперь реально сконцентрироваться на работе и сделать до обеда то, на что ранее дня не хватало.
  • Работай, как будто никто не смотрит! Но веб-камеру, на всякий случай, заклей.

После шести месяцев #WorkFromHome (#WFH, не путать с WTF), у меня появился шанс вернуться в офис. Пару дней я просидел в полупустом здании и вместо радости и безудержной работы у меня родилась вторая часть списка для этой статьи. Я всё ещё люблю свою работу и офис у меня очень даже не плохой, но дома лучше!

ссылка на оригинал статьи https://habr.com/ru/post/517242/

Новое поколение разработчиков. Чем они отличаются и почему это нормально

image

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

Именно эту реальность мы учли в «Школе 21», где обучение построено на способностях человека находить информацию. Здесь используются методики без учителей, лекций и оценок, и это работает. Среди участников и те, кто никогда не программировал, и те, у кого есть какой-то опыт и техническое образование.

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

Мы решили обсудить плюсы и минусы такого положения дел с руководителем IT-департамента, тимлидом и двумя участниками «Школы 21».

Андрей Карлов, руководитель IT-департамента блока Сервисы и безопасность

image

В культуре, к которой я привык, разработчик — это творец. Ты чувствуешь, что создаёшь что-то новое, уникальное, то, чего ещё нет. Придумываешь, проектируешь. В той культуре, если в твоём коде находили ошибки, ты не считался квалифицированным разработчиком. Сейчас человек пишет тонны строк кода, рассчитывая на то, что кто-то другой их после него тестирует и проверяет, — он об этом может не думать. Когда ты считаешь, что твоя работа только писать код, а проверять его — дело тестировщика, теряется ответственность за качество твоей работы.

Это, на мой взгляд, очень сильно девальвирует профессию. Из разработчиков мы превращаемся в кодеров, которым сказали что-то написать, вот они и пишут. Я переживаю на эту тему, но вижу, что сейчас это распространённая тенденция. С другой стороны, я задумался, а почему это обязательно что-то плохое? Изменилось время, задачи, возможности. В департаменте, где я работаю, проходили стажировку 40 участников «Школы 21», и 80 % из них получили офферы.

Я приверженец классической системы образования и считаю его очень важным.
При этом не из всех вузов выходят ребята с любовью к профессии, многие из нас ненавидят половину предметов, которые изучали. И многие считают, что им не повезло с преподавателями. Это не предмет плохой, это у тебя был плохой наставник. Но полюбил бы ты какой-то предмет, если бы у тебя не было вообще наставника, — тоже большой вопрос. Наставник сформировал у тебя какое-то к нему отношение: либо положительное, либо отрицательное. А когда ты механически учишься, у тебя, скорее всего, никакого отношения к этому не будет. Это набор каких-то алгоритмов, действий, подходов. Айтишники всё больше стали нужны не только классическим IT-компаниям, а всему большому бизнесу. Их постоянно не хватает, рынок давно перегрет.

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

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

Всё циклично, это изменится, и я думаю, что мы снова начнём воспринимать профессию разработчика как человека, который создаёт что-то новое, уникальное, качественное и классное, а не просто выполняет задачу.

Никита Полежаев, руководитель группы разработки

image

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

  • Ресурсы, откуда можно черпать знания.
  • Учебное задание. Обычно это какой-то самостоятельный проект, который он должен написать сам. Тимлид в процессе разработки продукта проверяет код, рассказывает лучшие практики. Таким путём мы оттачиваем правильный подход к разработке и даём фундаментальные знания по работе с промышленными фреймворками.

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

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

На мой взгляд, самое сложное — это понять, что промышленная разработка, это не просто написать маленький учебный проект. Есть релизный цикл, тестирование, DevOps и реальные пользователи. Стажёры понимают, что работа разработчика — это не всегда занятие прикольными, интересными и инновационными вещами. Порой мы сталкиваемся с муторной работой, но это обязательная часть работы любого разработчика.

Камиль Алиев, участник «Школы 21»

image

Моё основное образование — бизнес-менеджмент, которому я учился даже не в России, а в штате Вирджиния. Сейчас я уже окончил стажировку и успел попробовать как разработку игр на Unity, так и DevOps. Работаю над сборкой, тестированием и хранением артефактов по коммиту. В банке существуют свои требования по безопасности и качеству кода, и до моего прихода такими вещами занимались сами разработчики. Эту часть работы сейчас выполняет наша небольшая команда. В основном я помогаю iOS и macOS проектам, однако в последние пару месяцев мною решалась задача деплоя системы с нуля, которая включала в себя полноценный фронт и бэк. Стек — Jenkins, Docker, Ansible, Fastlane, Xcode, Nginx, SonarQube, Python.

Ещё до «Школы 21» я решил попробовать сферу IT, но думаю, без неё не удалось бы совершить этот «переход» так быстро. «Школа 21» дала мощный толчок в начале, который я лично считаю очень важным. В этом заслуга программы обучения в виде «бассейна» с множеством заданий разного уровня, которые не дают тебе прийти в себя и осознать, что происходит, однако по прохождению ты наконец осознаёшь объём материала, который удалось перелопатить.

«Школа 21» больше про прокачку навыка поиска нужной информации, про работу в команде и про правильную оценку результатов. Главное — преодоление страха в отсутствии хард скилов. Мне несколько раз приходилось изучать что-то с нуля, и при должном отношении к этой «проблеме» она становится обыденной.

Андрей Карлов, руководитель IT-департамента блока Сервисы и безопасность

Наше подразделение отвечает за технологическую поддержку работы всех зданий и связанных процессов. И мы были первым департаментом, который вошёл в эксперимент со «Школой 21».

Как это выглядело для меня? Много людей, которые раньше не имели никакого отношения к IT, бросили всё и сделали ставку на развитие в этой области. У нас было скептическое отношение, мы как-то привыкли, что айтишники — это своего рода отдельная каста. Вход только для своих — людей с классическим математическим или техническим образованием. Чтобы с пелёнок разбирал-собирал компьютер, в девять лет уже написал три разные программы, поиграл с друзьями по сети.

Как мы думали до встречи со стажёрами «Школы 21», основной риск был в том, что с участниками нужно будет нянчиться. Участники, которые пришли к нам на стажировку, по методологии «Школы 21» были на седьмом уровне. И это, мягко говоря, не сильно применимо к нашим реалиям. Мы ожидали, что ребят нужно переучивать. Дальше был вопрос — насколько это будет трудоёмко.

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

Действительно, все очень скептически к этому относились, но всё получилось, на наш взгляд, очень хорошо. Именно идейность и целеустремлённость помогает ребятам очень быстро обучаться, получать удовольствие от новой работы и двигаться вперёд.
В целом работа со стажёрами «Школы 21» в команде почти не отличается от того, как наша команда адаптирует обычных джунов с небольшим опытом работы и техническим образованием.

Участники включаются в команду, в которой есть тимлид, эксперты и которой поставлены общие задачи. Сначала им даются задачи попроще, ребятам подсказывают, с чего начать, что почитать, что изучить. Они знают, к кому обратиться, если что-то непонятно. Стажёры — такие же полноценные участники команды, и, как и у всех, у них могут быть какие-то затыки, сложности и проблемы. Они у всех разные, но всегда известно к кому обратиться, с кем пообщаться. Начинают стажёры, когда у них есть простые тестовые задачи, когда они занимаются какими-то исследованиями.

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

Ирина Дровянникова, участница «Школы 21»

image

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

Мне нравится, что в «Школе 21» нет никакой конкуренции, все учатся в своём темпе и всегда готовы прийти на помощь, если ты в ней нуждаешься. Я проходила самый первый «бассейн» самого первого набора, о «Школе 21» не было практически никакой информации. Многое казалось неправдой: непонятно было, зачем Сберу открывать это, почему бесплатно, как это без учителей? Казалось, что в этом есть какой-то подвох. Поэтому особо не строила ожиданий.

Я из тех участников, кто впервые увидел терминал во время «бассейна». Сейчас работаю в Сбербанке, получив оффер через пять месяцев стажировки. За это время работала над разными проектами. Например, в лаборатории робототехники Сбербанка разрабатывала интерфейсы для роботов, у которых есть экраны. Сейчас работаю над двумя проектами. Первый — это приложение, которое поможет рассчитать более выгодный тариф при расходовании электроэнергии для разных объектов банка и его экосистемы. А второй — приложение, в котором команды разработки смогут грамотно управлять доступными им серверами или арендовать новые без кучи заявок или отдельных специальных людей, отвечающих за это. Здесь постоянно идёт упрощение процессов, с которыми сталкиваются разработчики, и мне нравится участвовать в этом.

Итог

Это только часть историй участников «Школы 21». Например, ещё есть востоковед, ставший Java-разработчиком, архитектор — iOS-разработчик, стоматолог — data scientist, специалист управления ж/д перевозками сегодня ведущий инженер по разработке в одном из блоков IТ-департамента. Все они доказывают, что желание стать айтишником может появиться в абсолютно любой момент и у совершенно разных людей.

Очень круто, что наш проект даёт возможность начинающим специалистам осваивать IТ-сферу. Даже если у них нет технического бэкграунда, участники «Школы 21» на равных конкурируют с теми, кто получал профильное образование. В течение обучения в «Школе 21» участники учатся получать информацию разными способами, работать над командными проектами. Результат такого опыта — эффективное использование полученных знаний на стажировке и во время полноценной работы в компании.

ссылка на оригинал статьи https://habr.com/ru/company/sberbank/blog/516698/