All streams
Search
Write a publication
Pull to refresh
107
0
Roman Elokhin @nihole

Пользователь

Send message
Сейчас под рукой только «боевые» схемы. Они достаточно сложные для примера, да и «светить» их нельзя. Но вот нашел статью на хабре с «правильными» схемами в том числе.
habr.com/post/230439
Понятно, что у интеграторов могут существовать довольно жесткие требования к тому, как должна быть нарисована картинка, какие символы использовать… Это полезно в принципе.
Но если по существу и если для себя (а не на продажу), то ИМХО, если ваша схема позволяет вам (и любому другому инженеру) во-первых понять как ходит трафик и во-вторых легко изменяема (если например это рисунок на бумажке, то не так легко изменить), то эта схема «хорошая». Ну и конечно должна быть схема физической коммутации.
Статья ведь не про тест. У нас как такового теста не было. Была просто сильная тестирующая тех команда (CCIE/JNCIE R&S, Security, SP) и по большому счету просто беседа с теоретическими/практическими вопросами/задачами.
Да, все правильно. Это конечно же не совсем «ширина» и не совсем «глубина». Невозможно так просто это формализовать, но «ширина» и «глубина» ялвяются неплохим первым приближением. Дальше же вы конечно должны как-то здесь учесть и soft skills и мотивированность и способность к обучению… Собственно, квадрант Гартнера тоже сложная штука и не понятно до конца, как его строят, но все же он нагляден и на мой взгляд отражает положение вещей.

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

Ну и все же эта статья не про менеджеров, а про инженеров :)
Да, это правильный вопрос. Не возможно составить такой опросник. Пример был приведен для того, чтобы показать как работает метод, когда вы уже каким-то образом определили в каких темах какой уровень знания. В конкретном случае нашего опроса там было несколько слоев собеседования. Очень важной темой было обсуждение опыта, какие задачи решались, решаются, какими методами, почему, какое взаимодействие в команде… Это была первая часть собеседования. Выжным моментом так же была оценка самим инженером уровня своего знания по различным темам. Далее — технические задачи по темам, где инженер считал себя сильным. После этого мы получали приблизительное распределение по знаниям. И совсем не обязательно все это делать формально. Обычно все же после собеседование у вас складывается впечатление насколько «глубоко» и «широко» знание. Но, конечно, это все довольно субъективно. Но собеседование вообще-то штука субъективная.
:)
Текст не о том какие мы хорошие а другие плохие. Текст про то что нужны разные подходы к разным задачам. Так же даются методы решать difficult задачи и пожелание менеджерам ценить людей способных решать эти задачи а не смотреть на них свысока.
Этим двум важным мирам нужно уметь ладить. Это как форма и содержание — и то и то важно
Просто слово сложный с русского именно так и переводится — complex/difficult.
Мы в этом слове не различаем эти нюансы. А английские термины отражают точно суть.
Но конечно термины это всего лишь термины.
Спасибо за комментарий.
Я написал этот текст не просто так. Это ответ на то что я вижу и видел в подходах коллег и следствие общения с ними. Ну вот не понимают они, что строительство дома и создание сетевой архитектуры с новыми (не создаваемыми раньше) решениями это разные вещи.
Я понимаю что вот слова про «новые решения» пугают, но поверьте, это было не дорого и красиво.
Хороший комментарий :). Да, такое ощущение что в MBA (судя по тем с кем я общался) учат прежде всего хорошему тайм менеджменту, но в том то и штука что в случае исследований это плохо работает. Должны быть другие процессы, другая атмосфера,…
Еще раз хочу сказать что это не значит что про время и деньги думать не надо. Конечно на уровне менеджмента это главная задача, но в мир инжеров это должно спускаться в другом виде.
Уверен что хорошему менеджеру нужно уметь решать difficult задачи тоже. Но что делать если не дано? Или должен быть еще один «менеджер» (работая сейчас в Европе, вижу что часто эту функцию выполяют архитекторы) или нужно уметь доверять и общаться с инженерами.
Если уж про Кастанеду, то наверно можно поговорить чуть и о мистике.

4 — это важное число в мистике :)
Четыре времени года
Четыре стороны света
Четыре — число смерти
Четыре стихии
Точка, прямая, плоскость, пространство
И если вы просто посчитаете
раз два три четыре
раз два три четрые
раз два три четыре
раз два три четыре

Законченый цикл. Не так ли?

В общем, четыре характеризует законченность
Вы затронули важный вопрос на самом деле. Надеюсь найдется время и я к нему вернусь. Так кто же важнее в IT — бизнес или техническая мысль? Менеджер или инженер?
Обсудим еще.
Спасибо за добрый отзыв :) Но все же претендую на объективность. Я вижу эти ступени во многом.
Да, есть общее. И это подтверждает тот факт, что за этим стоит все же объекивная закономерность. Когда я осознал эти ступени для себя я не знал про этот эффект (Данинга-Крюгера). Но, получается, что все же моя систематизация дает нечто еще, потому что, как я понял, Даннинг-Крюгер — это все же про 2 и 3 уровень, но там ничего нет про 4й, а ведь это самое важное
Екклесиаст от IT? :)
Воот. Тоже 4 :)
Эта статья все же об инженерах. Если человек чувствует, что быть инженером ему не достаточно, то наверно он не совсем инженер. Вот именно «не совсем». Не «больше чем» а «не совсем». Что не плохо и не хорошо. Просто человек чуть другой.

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

Information

Rating
Does not participate
Location
Люксембург
Registered
Activity