«Проблемы бизнеса» это всегда управленческие проблемы: управление требованиями, мотивацией, персоналом, стратегией, тактикой, планированием. Если бизнес не справляется с управлением, то это не ответственность работника.
Вы путаете "проблемы бизнеса" с формализацией трудовых задач для работника. Работник не предполагает работать плохо, но не стоит втягивать его в управленческие вопросы без его согласия и соотв.компенсации. и эта компенсация как и обязанности в дополнение, а не вместо обычных. А когда проблем/задач нет это значит, что они качественно решены и следовательно доля(в сумме) должна вырасти, а не отмениться, вы ж партнеры уже, что за кидок ?!)
Программист пишет код в рамках своих должностных обязанностей, в зоне своей ответственности. Решать проблемы бизнеса не его KPI. А если хотят сделать его ответственностью — нужно договариваться, в т.ч. исходя из доходов компании, а не зп. Как то не очень получается, что человек, решающий проблемы компании делает это не за долю. Нужно отделять мух от котлет. И если к нему прибегают что «с завтрашнего дня налоги по-другому» это простите некудышний менеджер/бухгалтер, обычно это планируют, а не закрывают переработками разработчика и мантрой про необходимость решать проблемы бизнеса.
Несвойственная задача это решать проблемы бизнеса, для этого есть отряд менеджеров и замдиректоров. А то получается как проблема бизнеса так к программисту бегут, а как делить дивиденты так программисты не причем. Давайте долю чтобы человек чувствовал отдачу от вложения интеллектуального капитала. Пока что только манипуляции.
Какая муть! Программист это специалист в первую очередь. Чтобы он по своей инициативе решал несвойственные ему задачи он должен быть или мотивирован по самое нехочу или быть совладельцем бизнеса чьи проблемы ему нужно решать.
То, что в команде нет толковых продукт овнеров со знанием технического стека не проблема разработчика. Зачастую бизнес и сформулироать то не может какие у него проблемы.
Все красиво и правильно написано, но есть нюанс. Выбирая лучшего из лучших есть шанс, что именно этот человек оставит Вас без работы. Да, Вы наверное мотивированы создать сильную команду, но в этом и Ваша слабость если только это не Ваша собственная компания. Пока Вы продолжаете менеджерствовать не забывайте оглядываться кто метит на Ваше место из лучших Вами же найденных кандидатов. Селяви.
В данном случае вопрос оценки и построения процессов это вопрос компетентности того, кто за это отвечает. На практике нужно убить в себе хорошего разработчика, чтобы стать таким менеджером. И это проблема, вряд ли хороший девелопер подпишется проводить планерки и следить за счастье команды, вместо того чтобы писать нетленку и получать по 5 оферов в неделю.
Я бы не стал обольщать потенциальных тестировщиков. Сейчас войти на порядок сложнее, чем в 2006, когда начинал, например, я. Сейчас скорость смены стеков почти равна времени их освоения. Поэтому новичкам будет сложно угнаться если они приходят из других профессий, исключения возможны, конечно. Но собеседуя кандидатов с биологическим, филологическим и др образованием я замечаю, что им не хватает базы.
А мы вот ищем qa инженера уже давно, на нормальные деньги. И знаете что я скажу: многие кандидаты жмут "откликнуться" даже не дочитав вакансию, на шару, ковровыми бомбардировками рассылая свое говнорезюме. Указывают технологии, которые на собеседовании не подтверждаются. По 3-6 месяцев стаж на каждом предыдущем месте. Но с запоосами все в полном порядке. Мой совет — освойте 1 технологию, но освойте ее хорошо, с чем можно идти на собеседование.
Капитанская статья
Вы путаете "проблемы бизнеса" с формализацией трудовых задач для работника. Работник не предполагает работать плохо, но не стоит втягивать его в управленческие вопросы без его согласия и соотв.компенсации. и эта компенсация как и обязанности в дополнение, а не вместо обычных. А когда проблем/задач нет это значит, что они качественно решены и следовательно доля(в сумме) должна вырасти, а не отмениться, вы ж партнеры уже, что за кидок ?!)
То, что в команде нет толковых продукт овнеров со знанием технического стека не проблема разработчика. Зачастую бизнес и сформулироать то не может какие у него проблемы.
Тянет на целую книгу! Спасибо.
Все красиво и правильно написано, но есть нюанс. Выбирая лучшего из лучших есть шанс, что именно этот человек оставит Вас без работы. Да, Вы наверное мотивированы создать сильную команду, но в этом и Ваша слабость если только это не Ваша собственная компания. Пока Вы продолжаете менеджерствовать не забывайте оглядываться кто метит на Ваше место из лучших Вами же найденных кандидатов. Селяви.
А мы вот ищем qa инженера уже давно, на нормальные деньги. И знаете что я скажу: многие кандидаты жмут "откликнуться" даже не дочитав вакансию, на шару, ковровыми бомбардировками рассылая свое говнорезюме. Указывают технологии, которые на собеседовании не подтверждаются. По 3-6 месяцев стаж на каждом предыдущем месте. Но с запоосами все в полном порядке. Мой совет — освойте 1 технологию, но освойте ее хорошо, с чем можно идти на собеседование.
Как система понимает, что кликнув тестировщик проверяет заголовок, а не, к примеру, цвет кнопки?
Слишком предвзятое мнение о работодателях как надо, а как не надо собеседовать. Юношеский максимализм уже должен бы пройти.
Не зацикливаться на работе.
Зачем делать перепост своей статьи в виде комментария?!
https://m.habr.com/ru/post/497328/