Здравствуйте, Pauel, Вы писали:

S>>Вы врали и сами это признали: "Слегка утрировал, что бы вы точно не прошли мимо."

P>Утрировать и врать это разные вещи:
P> — утрировать — преувеличивать с целью привлечь внимание, подчеркнуть какую то мысль.
P> — врать — искажать с целью ввести в заблуждение.

А еще можно юлить и пытаться доказать, что "сложность найма" == "риски найма", а "стаж" != "опыт", опыт не измеряется, и т.д., и т.п.

P>А что вы хотели — гнев можно выражать

Если бы вы с самого начала вели себя нормально или хотя бы вовремя реагировали на замечания, то не пришлось бы "выражать гнев". Хотя гнева-то и нет.

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

Мне привычнее прямота. Если я говорю что-то не то, что мне на это указывают. Форма не важна.

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

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

S>>Тогда еще раз афигеть. Боюсь, вы сильно недооцениваете глубину кроличьей норы, которая именуются "сложность найма".

P>Вы сейчас делаете необоснованное предположение. Мой опыт в найме вам неизвестен

Опыт здесь не при чем. Достаточно того, что вы отождествили "сложность найма" с "рисками найма".

Это еще хуже, чем называть Qt как QT.

P>На секундочку — в этом треде вы минимум дважды обнулили беседу, т.е. отказались воспринимать аргументы.

Домысливание аргументом не является.

P>Затыкаете временную дыру — риски

Риск -- это вероятность наступления или ненаступления некого события с оценкой тяжести последствий наступления или ненаступления этого события.

Найм -- это процесс.

Вы умудряетесь отождествить вероятность с процессом. О чем еще разговаривать?

S>> Одна из проблем, которая здесь стоит -- это как заткнуть временную дыру. Другая проблема -- как погрузить замену в проект как можно быстрее

P>А где здесь именно сложность найма?

Везде. Дословно расписывать не буду уж простите, написано и так слишком много.

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

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

P>И никак не раскрываетеся где тут особая сложность найма.

Потому что это примеры ситуаций, где "свой набор задач, свои приоритеты, свои ресурсы, свои планы "а", "b", "c", и т.д., и т.п." Сложность же в том, чтобы все это привело к должному результату.

P>И здесь опять же неразличимы сложность найма и риски найма.

Если вы чего-то не видите, то это не значит, что этого нет.
Хотя больше похоже, что вы либо тупите, либо троллите. Второе вероятнее.

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

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

Именно так они пишут (писали по меньшей мере).

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

P>А я думаю, что наоборот — если есть успешные применения, то это возможно.

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

S>>Если мы начинаем рассматривать сценарии типа "взяли сеньора, дали ему мелкие задачки уровня джуна на время, пока он входит в тему, и считаем, что он приносит пользу сразу", то OK, я был не прав.

P>Если у нас джунов на проекте нет, то можно и так.

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

P>Я вам процитирую свой текст из скайпа, на всякий
P>"A team of senior engineers without any junior is the team of engineers."

P>Идея понятна?

Нет. Более того, непонятно зачем это в контексте разговора.

P>Зачем нам сеньора тренировать на задачах для джуна?

Мне это почем знать. Вы привели пример, который выглядит именно так.

P>Вот-вот, ровно то, о чем я вам говорил — степень пересечения...а подкидываем ему задачи его уровня

Да научитесь же вы читать то, что вам пишут! Я вам привел пример задачи где нет никакой степени пересечения. Вот вообще.
У людей есть задача, готовых специалистов нет, готовых специалистов с пересечениями по предметной области нет.
Задачу нужно решить.

И если они наймут просто специалиста по C++, то никакого "сразу в бой" не будет. Вот о чем речь.

P>А почему вы решили, что я вам какой то другой пример привел?

На основании того, что вы же про свой пример и написали.

Сперва это выглядело как мелкий фиксинг.
Затем получилось, что главное -- это анализ системы, полезным дополнением к которому будет еще и мелкий фиксинг.

P>Свои технологии это не какое нибудь чудо. Обычно это упрощенные варианты имеющихся, только с дополнительными бенефитам.

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

P>Поэтому брать джунов-мидлов на такое мы не можем

Ну OK, не можете, не берите. Ктож вас заставляет-то?

P>джуны-мидлы нужны, но не как основные работяги, а как крайний случай или на вырост. Врочем, я про это уже говорил.

Во-первых, я с этим и не спорил. Если вы перечитаете наш разговор, то увидите.

Во-вторых, я и сам это говорил:

Из сказанного мной следует лишь то, что нет "сеньоров со знанием X" поэтому и бесполезно искать именно "сеньоров со знанием X". Не более того.

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

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

Здравствуйте, Pauel, Вы писали:

S>>Вы врали и сами это признали: "Слегка утрировал, что бы вы точно не прошли мимо."

P>Утрировать и врать это разные вещи:
P> — утрировать — преувеличивать с целью привлечь внимание, подчеркнуть какую то мысль.
P> — врать — искажать с целью ввести в заблуждение.

А еще можно юлить и пытаться доказать, что "сложность найма" == "риски найма", а "стаж" != "опыт", опыт не измеряется, и т.д., и т.п.

P>А что вы хотели — гнев можно выражать

Если бы вы с самого начала вели себя нормально или хотя бы вовремя реагировали на замечания, то не пришлось бы "выражать гнев". Хотя гнева-то и нет.

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

Мне привычнее прямота. Если я говорю что-то не то, что мне на это указывают. Форма не важна.

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

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

S>>Тогда еще раз афигеть. Боюсь, вы сильно недооцениваете глубину кроличьей норы, которая именуются "сложность найма".

P>Вы сейчас делаете необоснованное предположение. Мой опыт в найме вам неизвестен

Опыт здесь не при чем. Достаточно того, что вы отождествили "сложность найма" с "рисками найма".

Это еще хуже, чем называть Qt как QT.

P>На секундочку — в этом треде вы минимум дважды обнулили беседу, т.е. отказались воспринимать аргументы.

Домысливание аргументом не является.

P>Затыкаете временную дыру — риски

Риск -- это вероятность наступления или ненаступления некого события с оценкой тяжести последствий наступления или ненаступления этого события.

Найм -- это процесс.

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

S>> Одна из проблем, которая здесь стоит -- это как заткнуть временную дыру. Другая проблема -- как погрузить замену в проект как можно быстрее

P>А где здесь именно сложность найма?

Везде. Дословно расписывать не буду уж простите, написано и так слишком много.

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

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

P>И никак не раскрываетеся где тут особая сложность найма.

Потому что это примеры ситуаций, где "свой набор задач, свои приоритеты, свои ресурсы, свои планы "а", "b", "c", и т.д., и т.п." Сложность же в том, чтобы все это привело к должному результату.

P>И здесь опять же неразличимы сложность найма и риски найма.

Если вы чего-то не видите, то это не значит, что этого нет.
Хотя больше похоже, что вы либо тупите, либо троллите. Второе вероятнее.

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

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

Именно так они пишут (писали по меньшей мере).

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

P>А я думаю, что наоборот — если есть успешные применения, то это возможно.

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

S>>Если мы начинаем рассматривать сценарии типа "взяли сеньора, дали ему мелкие задачки уровня джуна на время, пока он входит в тему, и считаем, что он приносит пользу сразу", то OK, я был не прав.

P>Если у нас джунов на проекте нет, то можно и так.

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

P>Я вам процитирую свой текст из скайпа, на всякий
P>"A team of senior engineers without any junior is the team of engineers."

P>Идея понятна?

Нет. Более того, непонятно зачем это в контексте разговора.

P>Зачем нам сеньора тренировать на задачах для джуна?

Мне это почем знать. Вы привели пример, который выглядит именно так.

P>Вот-вот, ровно то, о чем я вам говорил — степень пересечения...а подкидываем ему задачи его уровня

Да научитесь же вы читать то, что вам пишут! Я вам привел пример задачи где нет никакой степени пересечения. Вот вообще.
У людей есть задача, готовых специалистов нет, готовых специалистов с пересечениями по предметной области нет.
Задачу нужно решить.

И если они наймут просто специалиста по C++, то никакого "сразу в бой" не будет. Вот о чем речь.

P>А почему вы решили, что я вам какой то другой пример привел?

На основании того, что вы же про свой пример и написали.

Сперва это выглядело как мелкий фиксинг.
Затем получилось, что главное -- это анализ системы, полезным дополнением к которому будет еще и мелкий фиксинг.

P>Свои технологии это не какое нибудь чудо. Обычно это упрощенные варианты имеющихся, только с дополнительными бенефитам.

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

P>Поэтому брать джунов-мидлов на такое мы не можем

Ну OK, не можете, не берите. Ктож вас заставляет-то?

P>джуны-мидлы нужны, но не как основные работяги, а как крайний случай или на вырост. Врочем, я про это уже говорил.

Во-первых, я с этим и не спорил. Если вы перечитаете наш разговор, то увидите.

Во-вторых, я и сам это говорил:

Из сказанного мной следует лишь то, что нет "сеньоров со знанием X" поэтому и бесполезно искать именно "сеньоров со знанием X". Не более того.

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

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