Собственно это и есть третья ситуации. Для многих — завершить проект означает стать безработным. Особенно если проект был долгим. Безработным быть страшно.
Полностью с вами согласен. Но опытные участники проекта знают, что в проекте будут непредвиденные вещи — ошибки архитектуры, новые технологии, требующие дополнительных исследований и т.д. И соответственно закладывают это в сроки проекта. Я полностью поддерживаю идею творческого поиска и отнюдь не предлагаю снижать качество — есть мастфиксы с которыми выходить нельзя. Но по-моему опыту существенная часть «доделок» не повышают, а снижают качество проекта. Знаете — как ребенок напяливает на себя слишком много украшений. Мое мнение — если после трех иттераций продукт все еще не удовлетворительный — лучше начните сначала.
Ошибка #1. В самом начале необходимо определиться с уровнем кандидата на данную вакансию
Логическое нарушение. Долженствование без условий.
Пример: чтобы стать сильным, надо кушать овсяную кашу.
Вы проводите неявный, но знак равенства между наймом и закрытием вакансий. Более того, вы предполагаете логику – у меня есть работа, я ищу под нее подходящего человека. На самом деле, найм – это один из самых дорогих способов делать работу. В большинстве случаев гораздо выгоднее, удобнее, надежнее и быстрее если вам нужен результат работы – купить именно эту работу. А нанимать — это значит брать еще одного человека в команду, и именно эту команду он должен усилить, обогатить какими-то компенсациями, личностными качествами, умениями.
Как правильно:
В начале имеет смысл определиться с тем, кого мы хотим видеть у себя в коллективе.
Ошибка #2. Из вакансии должно быть понятно кто именно вам нужен.
Снова та же логическая ошибка.
Обычно ошибка долженствования приводит к подмене решения. Вам не нужна вакансия, которая понятна. Вам нужна такая вакансия, которая приведет к вам нужных людей.
Как у Паркинсона – «Требуется акробат, который может пройти по проволоке на высоте 200 м над бушующим пламенем. Ходить придется дважды в день, по субботам — трижды. Плата — 25 фунтов в неделю. Ни пенсии, ни компенсации за увечье не будет».
И заметьте – ни слова про смелость или навыки актерского мастерства.
Как правильно:
Вакансия должна привлекать нужных людей и отсеивать ненужных.
Отличные технические специалисты должны быть повелителями логики, а значит и в работе с людьми они должны быть предельны рациональны!
Предыдущая строка – это манипуляция. Работает она следующем образом: читателю предлагается согласиться с первым высказыванием, после чего следующая высказывание также становится истинным, хотя из первого вовсе не следует второе.
Давайте посмотрим на основные логические ошибки этой статьи:
Ошибка #1. HR-менеджер не должен собеседовать инженера. Он даже не должен к нему приближаться.
Логическое нарушение: «утверждение без условий».
Пример: «аппарат, тяжелее воздуха, никогда не полетит».
Мне страшно не нравится слово HR, довольно противно, когда людей считают ресурсом, который можно тратить. Но давайте обратимся к сути этой работы. HR – человек, который отвечает за коллектив Компании. Всей компании, а не одного отдела или тем более проекта.
Мы только что запретили человеку принимать участие в том, за что он отвечает и что является его работой. То есть если исходить из прямой логики – HR (не важно, кто именно исполняет роль, например, это может быть руководитель отдела) – должен собеседовать инженера.
<habracut /> Как должно быть:
Я как руководитель своего отдела хотел бы выполнять роль HR для своего отдела, определяя кого и как я хочу брать к себе в отдел (проект, группу подставить нужное). Я осознаю, что при этом я не нанимаю сотрудника в компанию, а беру его к себе на проект (с точки зрения юридических тонкостей, это, например, означает, что человек работает не по трудовому договору, а например, по договору подряда).
Ошибка #2. Чтобы понять инженера — нужно самому быть инженером.
Логическое нарушение: «чтобы понять «кого-то», нужно им самому быть «кем-то».
Пример: Чтобы понять кирпич, надо быть кирпичом.
За этим высказыванием стоит сколь справедливое, столь и бесполезное представление о собственной уникальности. Статистика говорит нам, что максимальный разброс между группами, всегда меньше, чем разброс между элементами. То есть, например, группа «секретари» отличается от группы «программисты» меньше, чем могут отличаться два отдельно взятых программиста. Например, по уровню интеллекта, различие вряд ли превысит 1 сигму, тогда как между двумя программистами может и 6 сигм быть.
Иными словами мы можем найти и нанять в компанию на позицию HR, человека, который ГОРАЗДО лучше нас понимает инженеров. Особенно, если мы специально искали такого человека.
Как должно быть:
Иногда я не уверен в профессионализме HR, его способности понять инженеров. Я думаю, мы не сможем нанять HR, который лучше бы руководителей разбирался в инжинерах.
Звучит, прямо скажем, не так пафосно, зато корректнее и правдивее. Не уверенность эта может быть продиктована как личным опытом (попался дрянной HR), так и не пониманием сути и содержания работы HR (мало кто из инженеров потратил 5-10 лет своей жизни, чтобы разобраться в этом вопросе).
Ошибка #3. HR никогда не сможет определить профессиональный уровень инженера, его пригодность для командной работы, так как он HR.
Логическое нарушение: «Объект не обладает свойством «А», так как обладает свойством «Б».
Пример: летучая мышь не может летать, так как она млекопитающее.
HR может лучше нас диагностировать уровень профессиональной компетенции. Например он может запросить экспертную оценку от нескольких специалистов (включая вас) и скорректировать ее, зная ваши особенности как оценщика. HR может лучше команды понять, кто в нее вольется, а кто нет (неужели, вам не встречались команды, которые принципиально не пускали чужаков, зато через месяц уже работали с «навязанным» человеком на ура?).
Как должно быть:
Чтобы хорошо делать свою работу HR следует обладать разносторонними компетенциями. Звучит банально, не так ли?
Лирическое отступление
Коллектив (состоящий из людей) представляет из себя гораздо более сложную систему, чем любой самый навороченный программно-аппаратный комплекс. Обратите внимание, не согласие с этим утверждением означает, что вы воспринимаете себя лично, как нечто попроще компьютера.
Резонно предположить, что управление более сложной системой требует большего опыта, знаний, личной зрелости, гибкости и других важных качеств.
Иными словами, требования к действительно хорошему HR гораздо выше, чем к хорошему инженеру, его зарплата выше, а найти его на рынке очень сложно. Разумеется, крашенная пустышка с двумя годами педагогического училища за плечами обычно не слишком успешно справляется с этой работой, иногда принося больше вреда, чем пользы. Но, как говориться, причем здесь HR?
Как любая классификация она не будет описывать все варианты, но если говорить про базовые эмоции, то это: гнев, горе, страх, отвращение, восторг, блаженство, интерес и гордость. Иногда блаженство и восторг объединяют в радость, иногда вместо интереса дают удивление, но это скорее методические сложности. Предполагается, что остальные эмоции являются или оттенками базовых (напр. Ярость, бешенство, злость, раздражение — это гнев разной силы и активности) или же смесью в разной пропорции нескольких базовых (напр. Восхищение — это смесь восторга и интереса). Каждая эмоция н только сопровождается коктейлем гормонов и ферментов, но и приводит к серьезным изменениям в работе всей нервной системы — изменению восприятия, мышления и поведения. Тот же гнев, например, приводит к резкой недооценки рисков, и то поведение которое раньше было невозможным — реализуется.
А как вы себе представляете интеллект без мотивационно-волевой и эмоционально-чувственной сферы? Как совершенно верно написал vics001 — как только такая программа задумается о том, «зачем она существует» — она поймет, что «незачем» — и прекратит свое выполнение.
Способность человека одушевлять все подряд весьма и весьма велика :) Поэтому удачная эмуляция эмоционального поведения, конечно, возможна и будет восприниматься как прогресс в создании ИИ.
Если же говорит про разум у живых существ, то разум абсолютно не отделим от этого самого существа. То есть разум это свойство живого организма целиком, а отнюдь не совокупности электронных импульсов в нейронах.
Если она за ответом будет обращаться к создателю — это всего-лишь будет означать, что создатель работает «внешними эмоциями» для программы. Кто же спорит, многие люди эмоции испытывают.
А вот как вы себе представляется «задавание философским вопросом» на уровне алгоритма, для меня загадка.
Последовательно снизу вверх:
1. Модель поведения построить можно, но точность этой модели будет слишком невелика (вижу в бронзе простенькую попытку моделирования поведения трехмерной молекулы ДНК).
2. Вот об этом я и говорю — достаточно развитый живой организм изначально воспринимает себя как «ценность» и следовательно может определять, что хорошо или плохо для него самого, а не для программиста. Так родители, например, могут считать, что для ребенка хорошо закаляться, и будут поливать его холодной водой. А ребенок будет с ними категорически несогласен, будет визжать и упираться :)
3. Со стороны программы (алгоритма) вопрос «зачем» никогда и не прозвучит. Именно поэтому программирование эмоций невозможно. Максимум — удачная эмуляция.
Ошибка #1. В самом начале необходимо определиться с уровнем кандидата на данную вакансию
Логическое нарушение. Долженствование без условий.
Пример: чтобы стать сильным, надо кушать овсяную кашу.
Вы проводите неявный, но знак равенства между наймом и закрытием вакансий. Более того, вы предполагаете логику – у меня есть работа, я ищу под нее подходящего человека. На самом деле, найм – это один из самых дорогих способов делать работу. В большинстве случаев гораздо выгоднее, удобнее, надежнее и быстрее если вам нужен результат работы – купить именно эту работу. А нанимать — это значит брать еще одного человека в команду, и именно эту команду он должен усилить, обогатить какими-то компенсациями, личностными качествами, умениями.
Как правильно:
В начале имеет смысл определиться с тем, кого мы хотим видеть у себя в коллективе.
Ошибка #2. Из вакансии должно быть понятно кто именно вам нужен.
Снова та же логическая ошибка.
Обычно ошибка долженствования приводит к подмене решения. Вам не нужна вакансия, которая понятна. Вам нужна такая вакансия, которая приведет к вам нужных людей.
Как у Паркинсона – «Требуется акробат, который может пройти по проволоке на высоте 200 м над бушующим пламенем. Ходить придется дважды в день, по субботам — трижды. Плата — 25 фунтов в неделю. Ни пенсии, ни компенсации за увечье не будет».
И заметьте – ни слова про смелость или навыки актерского мастерства.
Как правильно:
Вакансия должна привлекать нужных людей и отсеивать ненужных.
Предыдущая строка – это манипуляция. Работает она следующем образом: читателю предлагается согласиться с первым высказыванием, после чего следующая высказывание также становится истинным, хотя из первого вовсе не следует второе.
Давайте посмотрим на основные логические ошибки этой статьи:
Ошибка #1. HR-менеджер не должен собеседовать инженера. Он даже не должен к нему приближаться.
Логическое нарушение: «утверждение без условий».
Пример: «аппарат, тяжелее воздуха, никогда не полетит».
Мне страшно не нравится слово HR, довольно противно, когда людей считают ресурсом, который можно тратить. Но давайте обратимся к сути этой работы. HR – человек, который отвечает за коллектив Компании. Всей компании, а не одного отдела или тем более проекта.
Мы только что запретили человеку принимать участие в том, за что он отвечает и что является его работой. То есть если исходить из прямой логики – HR (не важно, кто именно исполняет роль, например, это может быть руководитель отдела) – должен собеседовать инженера.
<habracut />
Как должно быть:
Я как руководитель своего отдела хотел бы выполнять роль HR для своего отдела, определяя кого и как я хочу брать к себе в отдел (проект, группу подставить нужное). Я осознаю, что при этом я не нанимаю сотрудника в компанию, а беру его к себе на проект (с точки зрения юридических тонкостей, это, например, означает, что человек работает не по трудовому договору, а например, по договору подряда).
Ошибка #2. Чтобы понять инженера — нужно самому быть инженером.
Логическое нарушение: «чтобы понять «кого-то», нужно им самому быть «кем-то».
Пример: Чтобы понять кирпич, надо быть кирпичом.
За этим высказыванием стоит сколь справедливое, столь и бесполезное представление о собственной уникальности. Статистика говорит нам, что максимальный разброс между группами, всегда меньше, чем разброс между элементами. То есть, например, группа «секретари» отличается от группы «программисты» меньше, чем могут отличаться два отдельно взятых программиста. Например, по уровню интеллекта, различие вряд ли превысит 1 сигму, тогда как между двумя программистами может и 6 сигм быть.
Иными словами мы можем найти и нанять в компанию на позицию HR, человека, который ГОРАЗДО лучше нас понимает инженеров. Особенно, если мы специально искали такого человека.
Как должно быть:
Иногда я не уверен в профессионализме HR, его способности понять инженеров. Я думаю, мы не сможем нанять HR, который лучше бы руководителей разбирался в инжинерах.
Звучит, прямо скажем, не так пафосно, зато корректнее и правдивее. Не уверенность эта может быть продиктована как личным опытом (попался дрянной HR), так и не пониманием сути и содержания работы HR (мало кто из инженеров потратил 5-10 лет своей жизни, чтобы разобраться в этом вопросе).
Ошибка #3. HR никогда не сможет определить профессиональный уровень инженера, его пригодность для командной работы, так как он HR.
Логическое нарушение: «Объект не обладает свойством «А», так как обладает свойством «Б».
Пример: летучая мышь не может летать, так как она млекопитающее.
HR может лучше нас диагностировать уровень профессиональной компетенции. Например он может запросить экспертную оценку от нескольких специалистов (включая вас) и скорректировать ее, зная ваши особенности как оценщика. HR может лучше команды понять, кто в нее вольется, а кто нет (неужели, вам не встречались команды, которые принципиально не пускали чужаков, зато через месяц уже работали с «навязанным» человеком на ура?).
Как должно быть:
Чтобы хорошо делать свою работу HR следует обладать разносторонними компетенциями. Звучит банально, не так ли?
Лирическое отступление
Коллектив (состоящий из людей) представляет из себя гораздо более сложную систему, чем любой самый навороченный программно-аппаратный комплекс. Обратите внимание, не согласие с этим утверждением означает, что вы воспринимаете себя лично, как нечто попроще компьютера.
Резонно предположить, что управление более сложной системой требует большего опыта, знаний, личной зрелости, гибкости и других важных качеств.
Иными словами, требования к действительно хорошему HR гораздо выше, чем к хорошему инженеру, его зарплата выше, а найти его на рынке очень сложно. Разумеется, крашенная пустышка с двумя годами педагогического училища за плечами обычно не слишком успешно справляется с этой работой, иногда принося больше вреда, чем пользы. Но, как говориться, причем здесь HR?
Если же говорит про разум у живых существ, то разум абсолютно не отделим от этого самого существа. То есть разум это свойство живого организма целиком, а отнюдь не совокупности электронных импульсов в нейронах.
А вот как вы себе представляется «задавание философским вопросом» на уровне алгоритма, для меня загадка.
1. Модель поведения построить можно, но точность этой модели будет слишком невелика (вижу в бронзе простенькую попытку моделирования поведения трехмерной молекулы ДНК).
2. Вот об этом я и говорю — достаточно развитый живой организм изначально воспринимает себя как «ценность» и следовательно может определять, что хорошо или плохо для него самого, а не для программиста. Так родители, например, могут считать, что для ребенка хорошо закаляться, и будут поливать его холодной водой. А ребенок будет с ними категорически несогласен, будет визжать и упираться :)
3. Со стороны программы (алгоритма) вопрос «зачем» никогда и не прозвучит. Именно поэтому программирование эмоций невозможно. Максимум — удачная эмуляция.