к вопросу о найме
Oct. 29th, 2015 11:36 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
sab123Вот написал большой коммент, решил вынести. Про вопрос, как суметь хорошо делегировать работу.
А я и сам не специалист :-) У меня самого в этой области небольшой опыт, плюс видел как работают большие организации, где процесс поставлен хорошо.
Я бы сформулировал, что есть несколько важных моментов. Они не то что бы сильно интеллектуальные, и наверное в-принципе всем уже знакомые.
Первый момент: кто-то должен знать, что и как именно надо делать. Либо нанимается специалист, и это должен быть старший специалист, хорошо знающий, как делаются нужные вещи (или умеющий самостоятельно в них разобраться), либо нанимается младший персонал, и его нужно научить, и тогда наниматель должен сам знать, как и что делается, чтобы быть в состоянии учить. Учение делится на две части: (1) показать и возможно выдать письменную инструкцию, и (2) потом наблюдать за процессом, замечать где что идет не так, указывать на это, и показывать как исправить. Мастерство заключается не в том, чтобы не делать ошибок, а в том, чтобы эти ошибки замечать на ранней стадии и быстро исправлять пока они маленькие. То есть, в голове должен быть некий эталон, как выглядит правильный результат каждой стадии работы, и с этим эталоном постоянно должно идти сравнение.
И желательно иметь какой-то процесс для быстрой проверки результатов. И этим процессом регулярно пользоваться, и человек не должен воспринимать регулярную взаимопроверку как какую-то обиду. Например, в программировании есть процесс code review, когда каждый написанная программа обязательно просматривается и критикуется как минимум одним другим человеком.
Один из способов сравнения эталона на промежуточных этапах и проверки окончательных результатов - это самопроверка. Когда исполнитель сам должен провести проверку результата по определенным пунктам перед тем, как показывать его кому-то еще. В программировании это называется unit tests. (В code review включается и то, как человек сделал unit tests).
Принципы проверки подходят и для младшего и для старшего персонала.
Второй момент: найти толковых людей трудно. Люди, которые не глупее вас, скорее всего уже трудоустроены не хуже вас. Поэтому надо приготовиться или платить достаточно много денег, или за меньше денег удовлетвориться менее толковыми людьми. Для менее толковых людей должен быть создан детальный процесс и контроль (см. первый момент). Тут тоже есть как минимум три варианта: люди могут быть или просто тупыми, или иметь эмоциональную привязанность к какой-то части работы и не сильно интересоваться деньгами, или быть толковыми но неопытными. С третьей категорией работать проще всего, но надо не забывать, что по мере приобретения опыта надо или обеспечить им путь карьерного роста, или они от вас уйдут. Первая категория потребует много усилий на обучение и контроль, но может задержаться у вас надолго и задешево. Вторая категория - это как бы смесь остальных двух. Они могут задержаться у вас надолго и задешево, но вместо карьеры и денег им интересен сам процесс работы как таковой, и они будут искать роста престижа и самостоятельности в нем. На первый взгляд, самый выгодный случай, но есть свои проблемы. Эта категория часто имеет проблемы с коммуникациями, будет особо кисло относиться к контролю, и хорошо, если окажется что способности человека соответствуют аппетитам к самостоятельности. А если нет - то выйдет самый ужас-ужас, напыщенный дебил, которого не увольняют за дешевость, но который на самом деле создает больше проблем, чем пользы.
Третий момент: у людей должна быть некая свобода в пределах своих обязанностей, возможность проявлять самовыражение. Это способстует удовлетворению от работы. А также если нет способа самовыразиться с пользой для компании, люди будут самовыражаться в направлении как ленивее работать. В больших компаниях большие начальники знают, что ничего не будет сделано в точности как ими задумывалось, особенно если задумывалось что-то новое и неопределенное, что еще ни разу не делалось. Но при успешном подборе людей оно будет сделано лучше чем задумывалось, в пределах имеющихся реальных ограничений на время, деньги и знания.
Четвертый момент: важно, чтобы человек в антропологическом смысле соответствовал культуре компании. И тут некоторые культурные особенности являются особо проблематичными, потому что они будут разъедать и портить культуру компании. Например, такие вещи как попытки обеспечить job security, собрав под себя какие-то исключительные познания. Или как особо наглая оптимизация в как бы ничего не делать. Тут остается или сразу гнать, или регулярно и больно дрючить. Дрючить надо, конечно, не просто так, а непременно с указанием на то, как надо было правильно поступать (см. первый момент).
А я и сам не специалист :-) У меня самого в этой области небольшой опыт, плюс видел как работают большие организации, где процесс поставлен хорошо.
Я бы сформулировал, что есть несколько важных моментов. Они не то что бы сильно интеллектуальные, и наверное в-принципе всем уже знакомые.
Первый момент: кто-то должен знать, что и как именно надо делать. Либо нанимается специалист, и это должен быть старший специалист, хорошо знающий, как делаются нужные вещи (или умеющий самостоятельно в них разобраться), либо нанимается младший персонал, и его нужно научить, и тогда наниматель должен сам знать, как и что делается, чтобы быть в состоянии учить. Учение делится на две части: (1) показать и возможно выдать письменную инструкцию, и (2) потом наблюдать за процессом, замечать где что идет не так, указывать на это, и показывать как исправить. Мастерство заключается не в том, чтобы не делать ошибок, а в том, чтобы эти ошибки замечать на ранней стадии и быстро исправлять пока они маленькие. То есть, в голове должен быть некий эталон, как выглядит правильный результат каждой стадии работы, и с этим эталоном постоянно должно идти сравнение.
И желательно иметь какой-то процесс для быстрой проверки результатов. И этим процессом регулярно пользоваться, и человек не должен воспринимать регулярную взаимопроверку как какую-то обиду. Например, в программировании есть процесс code review, когда каждый написанная программа обязательно просматривается и критикуется как минимум одним другим человеком.
Один из способов сравнения эталона на промежуточных этапах и проверки окончательных результатов - это самопроверка. Когда исполнитель сам должен провести проверку результата по определенным пунктам перед тем, как показывать его кому-то еще. В программировании это называется unit tests. (В code review включается и то, как человек сделал unit tests).
Принципы проверки подходят и для младшего и для старшего персонала.
Второй момент: найти толковых людей трудно. Люди, которые не глупее вас, скорее всего уже трудоустроены не хуже вас. Поэтому надо приготовиться или платить достаточно много денег, или за меньше денег удовлетвориться менее толковыми людьми. Для менее толковых людей должен быть создан детальный процесс и контроль (см. первый момент). Тут тоже есть как минимум три варианта: люди могут быть или просто тупыми, или иметь эмоциональную привязанность к какой-то части работы и не сильно интересоваться деньгами, или быть толковыми но неопытными. С третьей категорией работать проще всего, но надо не забывать, что по мере приобретения опыта надо или обеспечить им путь карьерного роста, или они от вас уйдут. Первая категория потребует много усилий на обучение и контроль, но может задержаться у вас надолго и задешево. Вторая категория - это как бы смесь остальных двух. Они могут задержаться у вас надолго и задешево, но вместо карьеры и денег им интересен сам процесс работы как таковой, и они будут искать роста престижа и самостоятельности в нем. На первый взгляд, самый выгодный случай, но есть свои проблемы. Эта категория часто имеет проблемы с коммуникациями, будет особо кисло относиться к контролю, и хорошо, если окажется что способности человека соответствуют аппетитам к самостоятельности. А если нет - то выйдет самый ужас-ужас, напыщенный дебил, которого не увольняют за дешевость, но который на самом деле создает больше проблем, чем пользы.
Третий момент: у людей должна быть некая свобода в пределах своих обязанностей, возможность проявлять самовыражение. Это способстует удовлетворению от работы. А также если нет способа самовыразиться с пользой для компании, люди будут самовыражаться в направлении как ленивее работать. В больших компаниях большие начальники знают, что ничего не будет сделано в точности как ими задумывалось, особенно если задумывалось что-то новое и неопределенное, что еще ни разу не делалось. Но при успешном подборе людей оно будет сделано лучше чем задумывалось, в пределах имеющихся реальных ограничений на время, деньги и знания.
Четвертый момент: важно, чтобы человек в антропологическом смысле соответствовал культуре компании. И тут некоторые культурные особенности являются особо проблематичными, потому что они будут разъедать и портить культуру компании. Например, такие вещи как попытки обеспечить job security, собрав под себя какие-то исключительные познания. Или как особо наглая оптимизация в как бы ничего не делать. Тут остается или сразу гнать, или регулярно и больно дрючить. Дрючить надо, конечно, не просто так, а непременно с указанием на то, как надо было правильно поступать (см. первый момент).
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-10-29 06:51 pm (UTC)no subject
Date: 2015-10-29 06:56 pm (UTC)no subject
Date: 2015-10-29 06:58 pm (UTC)p.s.
в рф особенно вообще тяжело найти кого то, я когда бизнес вел и пытался делегировать во вне, то натыкался что ниодна организация которой делегировал не сделала то что мне надо было, пришлось самим, одна даже вернула аванс, что в россии просто вообще показывает что "мы и сами поняли что не можем сделать"
no subject
Date: 2015-10-29 07:08 pm (UTC)no subject
Date: 2015-10-29 06:58 pm (UTC)В индустрии не бывает людей, которые "знают эталон". Точнее, бывают, но обычно это уже никому к этому моменту нафиг не надо. Оно всё меняется, идёт непрерывное освоение технологии, "первый деплой", постоянное революционное и не очень изменение, наращивание сложности решений для ещё большей эффективности труда. Все, кто так не делают, либо махровый энтерпрайз (который по другим причинам может себе позволить быть неэффективным), либо теряют эффективность за пяток лет до неконкурентноспособного уровня.
Сингулярность всё ближе.
no subject
Date: 2015-10-29 07:04 pm (UTC)А когда дело касается изобретательства чего-то нового, эталон тоже есть, но он этакий "мета-эталон", общие принципы, как примерно должно выглядеть хорошее решение.
no subject
Date: 2015-10-30 02:19 pm (UTC)В IT практики же не образуют "идеала". То есть можно сказать, когда кто-то что-то делает совсем неэффективно (читай - увидеть нуба), но вот дать полную картинку не может никто, даже в режиме "мне этому надо научиться".
no subject
Date: 2015-11-01 03:02 am (UTC)no subject
Date: 2015-11-01 03:45 am (UTC)С одной стороны все бегают с очередными крутыми методиками, и они заканчиваются, с другой - если "медленно спускаться, чтобы покрыть всех", то можно оказаться в прошлом веке. То, что было нормой 15 лет назад, выглядит как безумное " ну почему?" сейчас.
Условно, я помню времена написания программ без системы версионирования. И у меня в продакшене до сих пор есть стыдные сервера, настроенные вручную (без configuration manager).
И во многих других областях так же: сидишь на попе ровно - просираешь компетенцию.
no subject
Date: 2015-11-01 05:51 pm (UTC)Вот прям так без системы версионирования я писал уже больше 20 лет назад. Потом я открыл SCCS. А уж RCS - это было наше всё (я им до сих пор пользуюсь для мелких вещей). Но в приличных местах (например, AT&T) уже и примерно 30 лет назад все хранилось в центральных системах версионирования.
no subject
Date: 2015-11-02 01:18 am (UTC)no subject
Date: 2015-10-30 06:54 pm (UTC)no subject
Date: 2015-11-01 03:08 am (UTC)А в остальном - зависит только от приличности заведения. Как раз по вышеописанным причинам: если руководство не знает, как делать хорошо и не знает как отличить специалистов, которые знают как делать хорошо, то все будет делаться плохо.
Вдогонку: жажда точных спецификаций - это признак младшего специалиста, которому нельзя доверять самостоятельную работу, а непременно нужен руководящий надзор.
no subject
Date: 2015-11-01 05:00 pm (UTC)тут бы не помешали примеры. а то контрпримеров много =)
no subject
Date: 2015-11-01 05:40 pm (UTC)no subject
Date: 2015-11-01 06:36 pm (UTC)no subject
Date: 2015-11-02 08:56 pm (UTC)no subject
Date: 2015-11-02 09:26 pm (UTC)no subject
Date: 2015-11-02 10:02 pm (UTC)