Меня одного смущает отсутствие корреляции между виртуальным образом джуна и обсуждение базовых постулатов взаимодействия с хорошо выстроенной подачей материала и стратегией поддержания огня в комментах?
Есть четкое ощущение, что автор профессионально набирает карму.
Статья наполнена болью от несоответствия реальности ожиданиям автора.
Сложно не согласиться со всеми описанными проблемами, но отношение автора к ним именно такое, какое может быть у молодого человека, который рассчитывал что работа программистом это лежание в гамаке на райском острове с макбуком и написание кода по четкому ТЗ. К сожалению, текущий уровень ожиданий молодежи от работы и мира в целом слишком завышен сверхпозитивными рекламами, лекциями и лозунгами от Яндекса, Сбера и прочих передовых компаний.
Сам начинал работу эникеем в небольшой организации, вижу несколько сценариев дальнейшего развития событий, при условии желания остаться в айти:
Сидеть страдать и дальше ныть на хабре как все вокруг плохо и какие все тупые и алчные, но ничего с этим не делать;
Если совсем нет другой работы, пытаться развиваться и поднимать свои компетенции на текущем месте работы, чтобы в дальнейшем ее сменить;
Сменить место работы на похожую небольшую или незрелую с точки зрения айти организацию, радоваться три месяца, затем дальше страдать там;
Сразу пойти работать в БОЛЬШУЮ айти компанию типа Сбера или Яндекса на любую предлагаемую должность, хоть помощником джуна и развиваться там. В дальнейшем тут тоже будут свои ограничения и компромиссы, но для старта карьеры это не плохой путь.
Увы, правильного выбора из предложенных сценариев не существует и каждый должен сам определиться.
Желаю автору найти в себе силы победить депрессию, спланировать, хотя бы верхнеуровнево, задачи по личностному и карьерному развитию и приступить к работе.
Вы все правильно пишите про материнскую плату на сервере, но когда у вас несколько десятков ЦОДи тысячи ИС - стандартизация, унификация и типовые решения начинают работать наоборот, на сокращение расходов.
Компания заключает рамочные договоры и не тратит время и другие ресурсы на торги каждый раз, плюс получает скидку за объем у одного вендора. Эксплуатацию не нужно учить работать с зоопарком оборудования и систем, достаточно научить работать с парой используемых вендоров, а дальше старшие инженеры бесплатно обучают младших, вместо постоянных вендорских платных обучений с полным отрывом сотрудников от работы.
Если есть стандарты для внедряемых систем, вы точно знаете каким требованиям они будут удовлетворять и вам не придется делать нетиповые интегарции, нетиповые авторизациии прочие доработки, которые стоят времени и денег, а также увеличивают гетерогенность вашего ИТ ландшафта.
Вы разработали типовое решение для разворачивания ЦОД в поле, написали требования по каналам связи, питанию, охлаждению, инженерной подготовке здания, запасли на складе типовых компонентов ЗИП, а все ваши системы своими нефункциональными требованиями вписываются в ваш типовой ЦОД. Больше эту работу по проектированию не нужно делать и оплачивать, строй по типовому проекту, это дешево.
На каждую позицию необходим свой бекграунд компетенций. В интернете полно статей об этом.
Нужно учитывать также, что не все организации живут по классическому Togaf и выделяют такие роли как Solution архитектор (архитектор конкретного решения, тут будет нужен бекграунд разработчика или лида разработки, а также аналитика, чтобы перерабатывать потребности заказчика в конкретные программные решения), архитектор сервиса (функционал похож на Solution, но могут быть нюансы). Некоторые компании декомпозируют роли на более мелкие, например в Ростелекоме в отделе технической архитектуры работают технические и сетевые архитекторы, а вот роль архитектора предприятия, архитектора данных и бизнес архитектора схлопнута в позицию под названием корпоративный архитектор.
В любом случае, необходимы прокачанные коммуникативные навыки, так как постановка задачи и требования это половина успеха проектирования. Придется много общаться с заказчиками, продуктовыми и техническими командами. Предполагается, что архитектор лидирует встречи, задает правильные вопросы и прорабатывает с коллегами сценарии. Зачастую, заказчик либо вообще не знает чего хочет, либо приходит с готовым решением, которое, по его мнению, удовлетворит его потребности, но ошибается.
Третье, необходимо в любом случае уметь визуализировать и структурировать информацию и работать с диаграммами и документацией. Неплохо было бы посмотреть в сторону актуальных нотаций описания процессов, сценариев, систем и их компонентов. Тут нужно гуглить BPMN, IDEF0, UML, C4.
Во время написания статьи у меня родилась мысль о том, что на текущем месте работы я, по сути, собираюсь сделать то же самое, просто масштаб пока не такой. Разрабатываю стандарты, внедряю архитектурный комитет, регламентирую требования к системам. Я начал понимать, что, если буду действовать так дальше, то неизбежно приду к такому же результату. Сейчас, на текущем месте работы, у меня есть возможность построить работу подразделения архитектуры так, как я вижу правильным, но, оказывается, я не знаю другого пути. Мне кажется, это хорошая тема для развития, буду искать другие пути реализации архитектурных процессов.
Командам действительно записывается техдолг по несоответствию стардартам и они его копят. К сожалению, я не знаю как устроена мотивация лидеров команд, но, судя по тому, что устранять техдолг команды не стремятся, так работать выгоднее.
Из сисадмина может вырасти архитектор инфраструктуры. Именно ему нужен опыт работы в эксплуатации, широкий кругозор в инфрастуктурных решениях, сетях передачи данных, способах хранения данных, вендорах и моделях оборудования.
Другое дело, что сисадмину нужно предварительно пройти путь эволюции до руководителя группы или руководителя отдела эксплуатации, иначе неоткуда будет взяться навыкам, упомянутым в статье в разделе ТОП-5 скиллов профессии.
Насколько мне известно, в колледже нет платных мест и попасть в него можно только на основании аттестата, плюс достижения за олимпиады и прочие мероприятия по математике, физике и информатике.
Дети правда одаренные и талантливые.
Оснащение отличное, все новое, в каждом классе есть интерактивная доска и флипчарт, парты у детей удобные, есть шкафы для вещей, в каждом классе большие окна, плюс хорошее искусственное освещение.
Идея следующая, если ты хочешь стать айтишником и развиваться быстро, нет смысла тратить пять лет в университете слушая лекции о принципах работы перфокарт и логарифмических линеек. После ВУЗовского образования все равно придется еще два-три года поработать, чтобы актуализировать свои знания.
Колледж же, напротив, дает детям актуальные знания о применяемых в продакшне современных технологиях. Ребенок через три года может выйти на работу готовым специалистом. Колледж сотрудничает с ведущими айти компаниями, которые предоставляют своих преподавателей для обучения детей и они же готовы потом взять этих детей на работу.
Итого:
Институт - пять лет обучения, затем затруднительный поиск работы для вчерашнего студента, потом еще пару-тройку лет работы чтобы стать квалифицированным специалистом.
ИТ колледж Сириус - три года обучения, после колледжа сразу на работу в Ростелеком, Яндекс, Oracle или подобную компанию, минимальный срок адаптации и ты квалифицированный ИТ специалист.
В целом, я согласен, для одаренных детей должен быть доступен альтернативный путь развития, но, к сожалению, он пока не предусмотрен наши государством.
Согласен, такие дисциплины у детей тоже есть в плане обучения, и да, архитектуру лучше было ставить на конец семестра или даже на следующий год, чтобы у детей было базовое понимание, об этом я и рассказал в статье)
Вы правы и статья именно об этом.
Для абсолютного большинства людей очень сложно (читай невозможно) найти ответы на эти вопросы и решить проблемы, связанные с ними.
Также вы правы в том, что образование и опыт работы в офисе, не дают вам понимания с какими проблемами вы столкнетесь при основании собственного бизнеса.
Из этого следует, что написание кода по два часа в день в течение года не равно успешный бизнес.
Неплохой врыв для нового пользователя.
Меня одного смущает отсутствие корреляции между виртуальным образом джуна и обсуждение базовых постулатов взаимодействия с хорошо выстроенной подачей материала и стратегией поддержания огня в комментах?
Есть четкое ощущение, что автор профессионально набирает карму.
Статья наполнена болью от несоответствия реальности ожиданиям автора.
Сложно не согласиться со всеми описанными проблемами, но отношение автора к ним именно такое, какое может быть у молодого человека, который рассчитывал что работа программистом это лежание в гамаке на райском острове с макбуком и написание кода по четкому ТЗ. К сожалению, текущий уровень ожиданий молодежи от работы и мира в целом слишком завышен сверхпозитивными рекламами, лекциями и лозунгами от Яндекса, Сбера и прочих передовых компаний.
Сам начинал работу эникеем в небольшой организации, вижу несколько сценариев дальнейшего развития событий, при условии желания остаться в айти:
Сидеть страдать и дальше ныть на хабре как все вокруг плохо и какие все тупые и алчные, но ничего с этим не делать;
Если совсем нет другой работы, пытаться развиваться и поднимать свои компетенции на текущем месте работы, чтобы в дальнейшем ее сменить;
Сменить место работы на похожую небольшую или незрелую с точки зрения айти организацию, радоваться три месяца, затем дальше страдать там;
Сразу пойти работать в БОЛЬШУЮ айти компанию типа Сбера или Яндекса на любую предлагаемую должность, хоть помощником джуна и развиваться там. В дальнейшем тут тоже будут свои ограничения и компромиссы, но для старта карьеры это не плохой путь.
Увы, правильного выбора из предложенных сценариев не существует и каждый должен сам определиться.
Желаю автору найти в себе силы победить депрессию, спланировать, хотя бы верхнеуровнево, задачи по личностному и карьерному развитию и приступить к работе.
Решается легко, нужно изначально об этом подумать и разрабатывать требования под мультивендорное ТЗ.
Это по-разному работает на разном масштабе.
Вы все правильно пишите про материнскую плату на сервере, но когда у вас несколько десятков ЦОДи тысячи ИС - стандартизация, унификация и типовые решения начинают работать наоборот, на сокращение расходов.
Компания заключает рамочные договоры и не тратит время и другие ресурсы на торги каждый раз, плюс получает скидку за объем у одного вендора. Эксплуатацию не нужно учить работать с зоопарком оборудования и систем, достаточно научить работать с парой используемых вендоров, а дальше старшие инженеры бесплатно обучают младших, вместо постоянных вендорских платных обучений с полным отрывом сотрудников от работы.
Если есть стандарты для внедряемых систем, вы точно знаете каким требованиям они будут удовлетворять и вам не придется делать нетиповые интегарции, нетиповые авторизациии прочие доработки, которые стоят времени и денег, а также увеличивают гетерогенность вашего ИТ ландшафта.
Вы разработали типовое решение для разворачивания ЦОД в поле, написали требования по каналам связи, питанию, охлаждению, инженерной подготовке здания, запасли на складе типовых компонентов ЗИП, а все ваши системы своими нефункциональными требованиями вписываются в ваш типовой ЦОД. Больше эту работу по проектированию не нужно делать и оплачивать, строй по типовому проекту, это дешево.
Начать стоит с того, чтобы выбрать направление архитектуры, наиболее близкое к вашему текущему бекграунду.
Классический Togaf выделяет следующие слои архитектуры:
Архитектор предприятия
Бизнес-архитектор
Архитектор данных
Архитектор приложений
Архитектор технологий
На каждую позицию необходим свой бекграунд компетенций. В интернете полно статей об этом.
Нужно учитывать также, что не все организации живут по классическому Togaf и выделяют такие роли как Solution архитектор (архитектор конкретного решения, тут будет нужен бекграунд разработчика или лида разработки, а также аналитика, чтобы перерабатывать потребности заказчика в конкретные программные решения), архитектор сервиса (функционал похож на Solution, но могут быть нюансы). Некоторые компании декомпозируют роли на более мелкие, например в Ростелекоме в отделе технической архитектуры работают технические и сетевые архитекторы, а вот роль архитектора предприятия, архитектора данных и бизнес архитектора схлопнута в позицию под названием корпоративный архитектор.
В любом случае, необходимы прокачанные коммуникативные навыки, так как постановка задачи и требования это половина успеха проектирования. Придется много общаться с заказчиками, продуктовыми и техническими командами. Предполагается, что архитектор лидирует встречи, задает правильные вопросы и прорабатывает с коллегами сценарии. Зачастую, заказчик либо вообще не знает чего хочет, либо приходит с готовым решением, которое, по его мнению, удовлетворит его потребности, но ошибается.
Третье, необходимо в любом случае уметь визуализировать и структурировать информацию и работать с диаграммами и документацией. Неплохо было бы посмотреть в сторону актуальных нотаций описания процессов, сценариев, систем и их компонентов. Тут нужно гуглить BPMN, IDEF0, UML, C4.
Во время написания статьи у меня родилась мысль о том, что на текущем месте работы я, по сути, собираюсь сделать то же самое, просто масштаб пока не такой. Разрабатываю стандарты, внедряю архитектурный комитет, регламентирую требования к системам. Я начал понимать, что, если буду действовать так дальше, то неизбежно приду к такому же результату. Сейчас, на текущем месте работы, у меня есть возможность построить работу подразделения архитектуры так, как я вижу правильным, но, оказывается, я не знаю другого пути. Мне кажется, это хорошая тема для развития, буду искать другие пути реализации архитектурных процессов.
Командам действительно записывается техдолг по несоответствию стардартам и они его копят. К сожалению, я не знаю как устроена мотивация лидеров команд, но, судя по тому, что устранять техдолг команды не стремятся, так работать выгоднее.
Да.
Из сисадмина может вырасти архитектор инфраструктуры. Именно ему нужен опыт работы в эксплуатации, широкий кругозор в инфрастуктурных решениях, сетях передачи данных, способах хранения данных, вендорах и моделях оборудования.
Другое дело, что сисадмину нужно предварительно пройти путь эволюции до руководителя группы или руководителя отдела эксплуатации, иначе неоткуда будет взяться навыкам, упомянутым в статье в разделе ТОП-5 скиллов профессии.
Насколько мне известно, в колледже нет платных мест и попасть в него можно только на основании аттестата, плюс достижения за олимпиады и прочие мероприятия по математике, физике и информатике.
Дети правда одаренные и талантливые.
Оснащение отличное, все новое, в каждом классе есть интерактивная доска и флипчарт, парты у детей удобные, есть шкафы для вещей, в каждом классе большие окна, плюс хорошее искусственное освещение.
Идея следующая, если ты хочешь стать айтишником и развиваться быстро, нет смысла тратить пять лет в университете слушая лекции о принципах работы перфокарт и логарифмических линеек. После ВУЗовского образования все равно придется еще два-три года поработать, чтобы актуализировать свои знания.
Колледж же, напротив, дает детям актуальные знания о применяемых в продакшне современных технологиях. Ребенок через три года может выйти на работу готовым специалистом. Колледж сотрудничает с ведущими айти компаниями, которые предоставляют своих преподавателей для обучения детей и они же готовы потом взять этих детей на работу.
Итого:
Институт - пять лет обучения, затем затруднительный поиск работы для вчерашнего студента, потом еще пару-тройку лет работы чтобы стать квалифицированным специалистом.
ИТ колледж Сириус - три года обучения, после колледжа сразу на работу в Ростелеком, Яндекс, Oracle или подобную компанию, минимальный срок адаптации и ты квалифицированный ИТ специалист.
Обучение два года и десять месяцев, в дипломе будет написано "Системный администратор".
В современной армии тоже нужны айтишники.
В целом, я согласен, для одаренных детей должен быть доступен альтернативный путь развития, но, к сожалению, он пока не предусмотрен наши государством.
Согласен, такие дисциплины у детей тоже есть в плане обучения, и да, архитектуру лучше было ставить на конец семестра или даже на следующий год, чтобы у детей было базовое понимание, об этом я и рассказал в статье)
Для абсолютного большинства людей очень сложно (читай невозможно) найти ответы на эти вопросы и решить проблемы, связанные с ними.
Также вы правы в том, что образование и опыт работы в офисе, не дают вам понимания с какими проблемами вы столкнетесь при основании собственного бизнеса.
Из этого следует, что написание кода по два часа в день в течение года не равно успешный бизнес.