Если с 1м критерием я согласен, то с «2) сколько человек может принести денег компании.» нужно еще поспорить.
Я много где встречаю эту фразу, но все никак не могу понять, что же она означает.
Этот фактор может влиять на решение о необходимости найма, как такового. Т.е: «нужен ли нам дизайнер для повышения дохода? Да или нет?».
Объясните пожалуйста мне наконец-то, как посчитать сколько отдельный человек из команды приносит денег компании и сколько из этой доли ему нужно платить?
Я считаю, что все происходит точно наоборот: у работника есть какая-то цена. Вилка цены. Она определяется ситуацией на рынке, личными амбициями кандидата и текущими возможностями и ожиданиями нанимателя. Именно исходя из этих критериев работодатель делает предложение. И уже задача работодателя в этой ситуации — максимизировать прибыль. Если работник будет приносить больше прибыли — зарплату ему сразу же никто не побежит повышать. Если он приносит меньше прибыли — зарплату никто не снизит, иначе он просто уйдет к конкурентам.
Когда говорят «верстать легко», «писать код на php/python/c# легко», «писать код на c++ сложно», то, в большинстве своем, имеют ввиду порог вхождения.
Действительно, можно прочитать одну статью на хабре и сразу же начать верстать. Пару манов + развернуть денвер — и вот я уже простое что-то на php пишу. Несколько недель практики: и я уже готов делать какие-то корявые вещи, имеющие некоторую цену.
Только классный специалист что в верстке, что в программировании, что в покраске машин — на вес золота. И то что верстать можно начать после прочтения пары статей не значит, что это несложная и какая-то «неответственная» задача. И если с «четко работала» этот дешевый верстальщик исходя из своих знаний справится (а как тут не справиться, див либо спозиционирован, либо нет — бери да меняй свойства, пока не заработает), то для «код легко читался и понимался, и внесение изменений не сопровождалось лишними проблемами» уже нужен специалист подороже.
На зарплату должны влиять навыки человека и его потребности, но никак не зарплата коллег.
И вообще, что вы будете делать, по вашей логике, если к вам придет один из N важных сотрудников и скажет: «У меня жена родила/дом сгорел/ребенок заболел», я устраивался полтора года назад на зарплату 500, сейчас хочу 700, благо это в среднерыночный коридор по подобной должности укладывается. И у вас вполне себе будет бюджет на это + нежелание терять ценного сотрудника.
В обычной ситуации повысить ему зп и заиметь плюс к лояльности. А в случае с открытыми данными? Вы пойдете всем его коллегам объяснять, что у него такие-то проблемы? А если кто-нибудь из подобных придет и скажет «Я хочу себе машину, ему подняли ЗП, поднимайте и мне»?
И кстати, где логика в ваших «когда ты работаешь лучше, а платят меньше», если вы сами говорите, что «люди склонны переоценивать свой вклад и недооценивать чужой»?
а их там правда нет?((
Я не ставил себе его еще, но вижу, что пиктограммы есть даже в контекстном меню и вполне могут быть в выпадающих. А выпадающие меню разве нужно помечать пиктограммами?
предположим, что гугл это действительно «на подредактировать».
И допустим там сидеть не 8 часов, а час.
Но белый цвет никуда не делся, и по вашей логике это должно быть все равно ужасно. Дизайн не становится хуже/лучше от времени, которое юзер пользуется продуктом.
Но почему-то лучей ненависти в адрес гуглодоксов не наблюдается =)
В гуглодоксах белый цвет, например, и что-то никого не раздражает.
Это в каждом топике про МС такие двойные стандарты. Есть у всех — нормально, но как появляется у МС — «какой кошмарный кошмар, микрософт ничего делать не умеет выколите мне глаза!!!111»
localStorage это, конечно, хорошо, но не для хранения пароля в плейнТексте.
просмотреть все файлы из C:\Users\username\AppData\Local\Google\Chrome\User Data\Default\Local Storage, начинающиеся с chrome-extension на предмет «profile_password» и все =)
Придираюсь, конечно, но «параноик не одобряет». А обычный хэш туда засунуть и все ок =)
1к — 2к были.
И если один из тестеров находит баг в каком-то старом компоненте, то он должен проверить, а не создал ли его кто-либо еще до него. Поиск в баг-трекерах и расставление тегов помогает.
>Сразу отсеивайте ошибки, которые слишком незначительны, чтобы их записывать.
сомнительное какое-то предложение. Кто должен решать значительна ошибка или незначительна? Тестировщик? Пусть уж лучше она won't fix лежит и поиском находится, чем каждый раз на нее натыкаться и думать, надо ли ее фиксить или нет.
>Почему я обратил внимание на OSS? В первую очередь, это возможность начать использовать ПО, не потратив ни цента.
Это преимущество бесплатных программ, а не опенсорсных.
А вот есть, например, преимущество OSS перед free, но не open? Если честно, сомневаюсь. Деньги-то вот они лежат сэкономленные, а чтобы правки в популярный опенсорс продукт вносить по своему хотению, нужно достаточно неплохих программистов содержать.
>Если кандидат груб, то это заметит и его начальник, пожалуй. Запах тоже такое дело — тут особых навыков не надо.
Так предполагается, что время начальника дороже времени hr'a.
Это правильно, если у вас сервис одностраничный или близкий к этому.
Если для получения нужной функции пользователю надо пробираться через горы некачественного контента (под контентом я понимаю абсолютно все, что видит юзер), то он может до пользы так и не добраться.
по сути, так и есть. Если дизайн никудышный (плюс к этому никудышный в плане юзабилити) и непонятный (как видим, для пользователя отсутствие локализации — порог), то до оценки функциональности дело просто не сможет дойти.
Я много где встречаю эту фразу, но все никак не могу понять, что же она означает.
Этот фактор может влиять на решение о необходимости найма, как такового. Т.е: «нужен ли нам дизайнер для повышения дохода? Да или нет?».
Объясните пожалуйста мне наконец-то, как посчитать сколько отдельный человек из команды приносит денег компании и сколько из этой доли ему нужно платить?
Я считаю, что все происходит точно наоборот: у работника есть какая-то цена. Вилка цены. Она определяется ситуацией на рынке, личными амбициями кандидата и текущими возможностями и ожиданиями нанимателя. Именно исходя из этих критериев работодатель делает предложение. И уже задача работодателя в этой ситуации — максимизировать прибыль. Если работник будет приносить больше прибыли — зарплату ему сразу же никто не побежит повышать. Если он приносит меньше прибыли — зарплату никто не снизит, иначе он просто уйдет к конкурентам.
Когда говорят «верстать легко», «писать код на php/python/c# легко», «писать код на c++ сложно», то, в большинстве своем, имеют ввиду порог вхождения.
Действительно, можно прочитать одну статью на хабре и сразу же начать верстать. Пару манов + развернуть денвер — и вот я уже простое что-то на php пишу. Несколько недель практики: и я уже готов делать какие-то корявые вещи, имеющие некоторую цену.
Только классный специалист что в верстке, что в программировании, что в покраске машин — на вес золота. И то что верстать можно начать после прочтения пары статей не значит, что это несложная и какая-то «неответственная» задача. И если с «четко работала» этот дешевый верстальщик исходя из своих знаний справится (а как тут не справиться, див либо спозиционирован, либо нет — бери да меняй свойства, пока не заработает), то для «код легко читался и понимался, и внесение изменений не сопровождалось лишними проблемами» уже нужен специалист подороже.
в winPhone тоже могут, если нужно и разрешено.
что значит «за его счет»? Вы договорились с работодателем о зарплате, она вас устраивает же? Если устраивать перестала — идите к нему.
Продавцы на рынке кому-то уступают 100 рублей, а кому-то 500. Так и тут — вопрос торга.
На зарплату должны влиять навыки человека и его потребности, но никак не зарплата коллег.
И вообще, что вы будете делать, по вашей логике, если к вам придет один из N важных сотрудников и скажет: «У меня жена родила/дом сгорел/ребенок заболел», я устраивался полтора года назад на зарплату 500, сейчас хочу 700, благо это в среднерыночный коридор по подобной должности укладывается. И у вас вполне себе будет бюджет на это + нежелание терять ценного сотрудника.
В обычной ситуации повысить ему зп и заиметь плюс к лояльности. А в случае с открытыми данными? Вы пойдете всем его коллегам объяснять, что у него такие-то проблемы? А если кто-нибудь из подобных придет и скажет «Я хочу себе машину, ему подняли ЗП, поднимайте и мне»?
И кстати, где логика в ваших «когда ты работаешь лучше, а платят меньше», если вы сами говорите, что «люди склонны переоценивать свой вклад и недооценивать чужой»?
Я не ставил себе его еще, но вижу, что пиктограммы есть даже в контекстном меню и вполне могут быть в выпадающих. А выпадающие меню разве нужно помечать пиктограммами?
И допустим там сидеть не 8 часов, а час.
Но белый цвет никуда не делся, и по вашей логике это должно быть все равно ужасно. Дизайн не становится хуже/лучше от времени, которое юзер пользуется продуктом.
Но почему-то лучей ненависти в адрес гуглодоксов не наблюдается =)
Это в каждом топике про МС такие двойные стандарты. Есть у всех — нормально, но как появляется у МС — «какой кошмарный кошмар, микрософт ничего делать не умеет выколите мне глаза!!!111»
просмотреть все файлы из C:\Users\username\AppData\Local\Google\Chrome\User Data\Default\Local Storage, начинающиеся с chrome-extension на предмет «profile_password» и все =)
Придираюсь, конечно, но «параноик не одобряет». А обычный хэш туда засунуть и все ок =)
И если один из тестеров находит баг в каком-то старом компоненте, то он должен проверить, а не создал ли его кто-либо еще до него. Поиск в баг-трекерах и расставление тегов помогает.
сомнительное какое-то предложение. Кто должен решать значительна ошибка или незначительна? Тестировщик? Пусть уж лучше она won't fix лежит и поиском находится, чем каждый раз на нее натыкаться и думать, надо ли ее фиксить или нет.
Это преимущество бесплатных программ, а не опенсорсных.
А вот есть, например, преимущество OSS перед free, но не open? Если честно, сомневаюсь. Деньги-то вот они лежат сэкономленные, а чтобы правки в популярный опенсорс продукт вносить по своему хотению, нужно достаточно неплохих программистов содержать.
Так предполагается, что время начальника дороже времени hr'a.
Если для получения нужной функции пользователю надо пробираться через горы некачественного контента (под контентом я понимаю абсолютно все, что видит юзер), то он может до пользы так и не добраться.