Вот что-что, а знакомства очень тяжело завожу ((( максимум - перекинуться парой фраз в профсообществах, в которых состою. Или самой совета спросить, или помочь кому-то. Так что моё восхищение!
А я вот не понимаю что такого плохого в даунгрейде самом по себе. Почему таких людей не любят HRы? Например, пошёл человек в руководители, понял, что не его - вернулся в рядовые инженеры. Всё лучше, чем сидеть на неподходящей позиции и потихонечку выгорать.
Или изначально профиль сотрудника и вакансия были сформированы неправильно - в итоге на позицию вышел неподходящий человек (не важно, по софтам или хардам). Если он не дотягивает чуть-чуть, то ещё можно подтянуться (меня как-то взяли на такую позицию), а если речь о каких-то специфических знаниях, которые можно раздобыть проработав лет 5 в отрасли?
1 - а с каких это пор количество заведённых дефектов - показатель эффективности тестировщика? Если быть точнее - да, есть метрики, которые на этом показателе базируются, но если количество дефектов в вакууме без привязки к чему-либо используется как показатель эффективности тестировщика, то это не у тестировщика проблема с эффективностью.
2 - на моей практике в подавляющем большинстве команд не было принято заводить дефект на каждый чих. Обычно, если дефект обнаруживался на этапе проверки задачи, то задача просто возвращалась с соответствующим комментарием, отдельно дефект могли завести, если по какой-то причине решили его не чинить. Или он был обнаружен на более позднем этапе.
Но ведь начало нового проекта не отменяет необходимость поддерживать и дорабатывать старые. Например, в моей старой команде у нас было максимально 3 проекта, вот их примерные характеристики (подробнее не имею права, но будто бы достаточно для оценки по вашей таблице):
Проект 1: для заказчика. с высоты своего опыта думаю, что там баги там были крайне нежелательны, хотя это и не проговаривалось. это был чистый вэб со средним количеством логики (хоть её было и сравнительно немного, но она была непростой).
Проект 2: для заказчика. тоже вэб, но было важно, чтобы работало на любых устройствах, включая мобилки. допускались миноры (опять же не проговаривалось, но я думаю так). ещё эпизодически добавлялся пиксель перфект + проверялись письма на почту.
Проект 3: внутренний. вэб, который тоже должен работать на всех устройствах. логика несложная если говорить о стандартном пользовательском пути, но огромное количество доп. функциональности, которая пригодится дай бог 1 из 100 человек. допустимые баги - минор.
Подчеркну, что проекты принципиально разные - разная логика, разные технологии. Для каждого из них использовали даже разные производственные циклы. А теперь внимание - какое количество тестировщиков здесь надо, если у разработчиков не было жесткого закрепления за проектами?
Здесь просто обратила внимание, что буквально пару лет назад резюме работало само. За несколько дней можно было распланировать интервью на пару недель вперед. Сейчас так не работает - даже когда сам пишешь - приглашает если повезет 1 из 10.
Интересно, что там был за опыт у человека? Какой бэкграунд? Коллега тоже в декабре пыталась найти работу, но до собеседования дошло всего пару раз. Притом резюме вроде неплохое - раньше стоило обновить резюме сразу 10-15 звонков поступало. В итоге удалось сменить команду внутри компании.
В целом ок, я хоть и тестировщик, но мне тоже интересна не только функциональная часть вопроса, но и бизнес-концепция. И тут важно именно, что у человека есть интерес. И ещё момент - у него должно быть время на дополнительные активности.
Например, я рядовой специалист и я не умею управлять коллективом. И меня сильно раздражает когда на меня вешают ответственность за действия или бездействия других людей. Конечо, я могу показать и рассказать как правильно и в большинстве случаев мне удаётся донести до человека свою мысль, но если человек при дальнейшей работе не использует или делает по-своему, то это его выбор и если это приводит к не очень хорошим результатам, то это должно быть его проблемой, а не моей.
Мне кажется, что здесь надо учиться соблюдать баланс. У меня был опыт работы на проекте, состоящем из нескольких команд и атмосфера в них сильно различалась, хотя руководство было одним и тем же. Мой техлид, кстати, сильно поднял свой скилл от "а что это я должен заниматься планированием?" до ответственности за принятые решения (хотя спокойно мог всё свалить на нас).
Двоякое впечатление от статьи. Невольно задаёшься вопросом - а всё ли хорошо в команде у автора? Только в первом пункте
А потом я понял, что сила команды определяется не только тем, что она умеет, а тем, как она реагирует, как признаёт ошибки, как справляется с хаосом.
И здесь сразу попрос - а как часто в команде возникает хаос? Почему сотрудники вместо обычной работы, за которую им платят зарплату, должны с ним справляться? Я прекрасно понимаю, что идеальных мест не существует (или их очень мало), но если команда находится в перманентном хаосе, то это уже больше вопрос к руководителю.
Я работала как в местах с очень хорошими процессами, так и отвратительными (по сути с их отсутствием) и точно знаю, что хорошо выстроенные процессы - это залог максимальной эффективности команды, а выстраивание этих процессов - это одна из немногих вещей, которую я ожидаю от руководителя.
Да, такая система оценок есть боль. Вроде и делаешь больше, чем должен, но всё-равно ставят С в 90% случаев (однажды удалось получить В, но я реально упахалась в тот год ради неё).
Вот и вопрос - а ради чего вкладываться, если что бы ты не сделал - всегда найдутся люди которым или повезло с задачей (у бизнеса всегда будет ранжирование задач), или сделали ненамного, но больше, или просто лучше умеют себя презентовать (встречались и такие люди)?
Вот интересно, предположим я перешла работать в другую команду и получаю задачу, аналогичную той, которую уже делала в первой компании. С одной стороны - вроде как код реально принадлежит первой компании (интеллектуальная собственность и всё такое), с другой - код же уже был написан и он уже есть в моей голове. Получается, чтобы не попасть под суд надо мало того, что решить задачу, так ещё и решить её другим способом?
Эх... Где бы ещё взять время на подобное написание тест-кейсов? Вот у меня никогда не было достаточно времени, чтобы написать тест полностью бест-практик. Стараюсь писать, чтобы тест был проходим человеком минимально знакомым с проектом, в идеале конечно и сторонним.
Смех смехом, но некоторые ищут прям совсем нулейй. Ещё да ИТ пыталась устроиться в контору с требованиями 1-3года, ровно такого же опыта не было, но был близкий поэтому решила попробовать. В итоге решили взять нулей вообще без опыта.
Я играю не очень много, хотя и люблю это дело. В среднем это час в день. При этом старые игры жо недавнего времени спокойно шли на моем ПК (сломался недавно, к сожалению).
Облачный гейминг выглядит неплохим решением, вк даёт сейчас один из лучших результатов - лагов почти не было (играла во вторую часть Чумной сказки), но если игра не предустановлена - её нужно каждый раз устанавливать - это удорожает стоимость на 20-30%, да и времени жалко. МТС в этом плане лучше, но почему-то даёт довольно расплывчатую картинку, хотя выбирала варианты с минимальным пингом. На Дровах так и не смогла ничего запустить.
Может кто-то сможет посоветовать ещё оптимальные варианты, доступные из РФ?
Интересно описано, аж самой захотелось пройти, хотя я уже вкатилась, но не стану этого делать в пользу тех, кто ещё собирается сюда. Интересно посмотреть что покажет тест на тех, кто уже вошёл))
Жаль, что не удалось победить, но я не в претензии - статьи в номинации, в которую я подавалась действительно крутые=) Искренне поздравляю победителей!
А куда можно написать за рецензией? Не увидела в статье куда это лучше сделать=) Очень интересно получить общую оценку своих трудов!
Спасибо, опробую.
Вот что-что, а знакомства очень тяжело завожу ((( максимум - перекинуться парой фраз в профсообществах, в которых состою. Или самой совета спросить, или помочь кому-то. Так что моё восхищение!
А где вы находите этих людей? Как выцепляете?
А я вот не понимаю что такого плохого в даунгрейде самом по себе. Почему таких людей не любят HRы? Например, пошёл человек в руководители, понял, что не его - вернулся в рядовые инженеры. Всё лучше, чем сидеть на неподходящей позиции и потихонечку выгорать.
Или изначально профиль сотрудника и вакансия были сформированы неправильно - в итоге на позицию вышел неподходящий человек (не важно, по софтам или хардам). Если он не дотягивает чуть-чуть, то ещё можно подтянуться (меня как-то взяли на такую позицию), а если речь о каких-то специфических знаниях, которые можно раздобыть проработав лет 5 в отрасли?
1 - а с каких это пор количество заведённых дефектов - показатель эффективности тестировщика? Если быть точнее - да, есть метрики, которые на этом показателе базируются, но если количество дефектов в вакууме без привязки к чему-либо используется как показатель эффективности тестировщика, то это не у тестировщика проблема с эффективностью.
2 - на моей практике в подавляющем большинстве команд не было принято заводить дефект на каждый чих. Обычно, если дефект обнаруживался на этапе проверки задачи, то задача просто возвращалась с соответствующим комментарием, отдельно дефект могли завести, если по какой-то причине решили его не чинить. Или он был обнаружен на более позднем этапе.
Но ведь начало нового проекта не отменяет необходимость поддерживать и дорабатывать старые. Например, в моей старой команде у нас было максимально 3 проекта, вот их примерные характеристики (подробнее не имею права, но будто бы достаточно для оценки по вашей таблице):
Проект 1: для заказчика. с высоты своего опыта думаю, что там баги там были крайне нежелательны, хотя это и не проговаривалось. это был чистый вэб со средним количеством логики (хоть её было и сравнительно немного, но она была непростой).
Проект 2: для заказчика. тоже вэб, но было важно, чтобы работало на любых устройствах, включая мобилки. допускались миноры (опять же не проговаривалось, но я думаю так). ещё эпизодически добавлялся пиксель перфект + проверялись письма на почту.
Проект 3: внутренний. вэб, который тоже должен работать на всех устройствах. логика несложная если говорить о стандартном пользовательском пути, но огромное количество доп. функциональности, которая пригодится дай бог 1 из 100 человек. допустимые баги - минор.
Подчеркну, что проекты принципиально разные - разная логика, разные технологии. Для каждого из них использовали даже разные производственные циклы. А теперь внимание - какое количество тестировщиков здесь надо, если у разработчиков не было жесткого закрепления за проектами?
Интересная статья. А как быть, если на команде несколько приложений? Какие-то уже MVP, какие-то только разрабатываться начинают.
Да, но принимающая стороны может не согласиться на такое. Как минимум по причине отсутствия испытательного срока при переводе.
Здесь просто обратила внимание, что буквально пару лет назад резюме работало само. За несколько дней можно было распланировать интервью на пару недель вперед. Сейчас так не работает - даже когда сам пишешь - приглашает если повезет 1 из 10.
Интересно, что там был за опыт у человека? Какой бэкграунд? Коллега тоже в декабре пыталась найти работу, но до собеседования дошло всего пару раз. Притом резюме вроде неплохое - раньше стоило обновить резюме сразу 10-15 звонков поступало. В итоге удалось сменить команду внутри компании.
В целом ок, я хоть и тестировщик, но мне тоже интересна не только функциональная часть вопроса, но и бизнес-концепция. И тут важно именно, что у человека есть интерес. И ещё момент - у него должно быть время на дополнительные активности.
Например, я рядовой специалист и я не умею управлять коллективом. И меня сильно раздражает когда на меня вешают ответственность за действия или бездействия других людей. Конечо, я могу показать и рассказать как правильно и в большинстве случаев мне удаётся донести до человека свою мысль, но если человек при дальнейшей работе не использует или делает по-своему, то это его выбор и если это приводит к не очень хорошим результатам, то это должно быть его проблемой, а не моей.
Мне кажется, что здесь надо учиться соблюдать баланс. У меня был опыт работы на проекте, состоящем из нескольких команд и атмосфера в них сильно различалась, хотя руководство было одним и тем же. Мой техлид, кстати, сильно поднял свой скилл от "а что это я должен заниматься планированием?" до ответственности за принятые решения (хотя спокойно мог всё свалить на нас).
В прошлом году так и сдавала. В районе 10-15к стоило, если память не изменяет, но я у них же подготовку проходила (т.е. дали скидку).
Двоякое впечатление от статьи. Невольно задаёшься вопросом - а всё ли хорошо в команде у автора? Только в первом пункте
И здесь сразу попрос - а как часто в команде возникает хаос? Почему сотрудники вместо обычной работы, за которую им платят зарплату, должны с ним справляться? Я прекрасно понимаю, что идеальных мест не существует (или их очень мало), но если команда находится в перманентном хаосе, то это уже больше вопрос к руководителю.
Я работала как в местах с очень хорошими процессами, так и отвратительными (по сути с их отсутствием) и точно знаю, что хорошо выстроенные процессы - это залог максимальной эффективности команды, а выстраивание этих процессов - это одна из немногих вещей, которую я ожидаю от руководителя.
Да, такая система оценок есть боль. Вроде и делаешь больше, чем должен, но всё-равно ставят С в 90% случаев (однажды удалось получить В, но я реально упахалась в тот год ради неё).
Вот и вопрос - а ради чего вкладываться, если что бы ты не сделал - всегда найдутся люди которым или повезло с задачей (у бизнеса всегда будет ранжирование задач), или сделали ненамного, но больше, или просто лучше умеют себя презентовать (встречались и такие люди)?
Вот интересно, предположим я перешла работать в другую команду и получаю задачу, аналогичную той, которую уже делала в первой компании. С одной стороны - вроде как код реально принадлежит первой компании (интеллектуальная собственность и всё такое), с другой - код же уже был написан и он уже есть в моей голове. Получается, чтобы не попасть под суд надо мало того, что решить задачу, так ещё и решить её другим способом?
Или я это не так работает?
Эх... Где бы ещё взять время на подобное написание тест-кейсов? Вот у меня никогда не было достаточно времени, чтобы написать тест полностью бест-практик. Стараюсь писать, чтобы тест был проходим человеком минимально знакомым с проектом, в идеале конечно и сторонним.
Смех смехом, но некоторые ищут прям совсем нулейй. Ещё да ИТ пыталась устроиться в контору с требованиями 1-3года, ровно такого же опыта не было, но был близкий поэтому решила попробовать. В итоге решили взять нулей вообще без опыта.
Я играю не очень много, хотя и люблю это дело. В среднем это час в день. При этом старые игры жо недавнего времени спокойно шли на моем ПК (сломался недавно, к сожалению).
Облачный гейминг выглядит неплохим решением, вк даёт сейчас один из лучших результатов - лагов почти не было (играла во вторую часть Чумной сказки), но если игра не предустановлена - её нужно каждый раз устанавливать - это удорожает стоимость на 20-30%, да и времени жалко. МТС в этом плане лучше, но почему-то даёт довольно расплывчатую картинку, хотя выбирала варианты с минимальным пингом. На Дровах так и не смогла ничего запустить.
Может кто-то сможет посоветовать ещё оптимальные варианты, доступные из РФ?
Интересно описано, аж самой захотелось пройти, хотя я уже вкатилась, но не стану этого делать в пользу тех, кто ещё собирается сюда. Интересно посмотреть что покажет тест на тех, кто уже вошёл))
Жаль, что не удалось победить, но я не в претензии - статьи в номинации, в которую я подавалась действительно крутые=) Искренне поздравляю победителей!
А куда можно написать за рецензией? Не увидела в статье куда это лучше сделать=) Очень интересно получить общую оценку своих трудов!