Уровень тестировщиков.

:) Попробуйте перечитать топик с последними 3-мя сообщениями - такое впечатление, что кусок другой ветки ;)

На мой взгляд, чтобы привлечь хорошего тестировщика (или сманить из другой смежной прфессии), необходимо тщательно продумать реальную достижимую стратегию профессионального развития тестировщика, его карьерного роста в ДАННОЙ КОНКРЕТНОЙ КОМПАНИИ (куда хотите его привлечь).

Если эта перспектива вам самим нравится, то можно надеяться, что подходящий человек найдется.
Но когда найдется, не стоит расслабляться, т.к. он может легко уплыть наткнувшись на непонимание и недостаток уважения к его работе со стороны сотрудников компании.
А чтобы понимали и ценили, надо самим разработчикам посоставлять тест планы и потестировать ручками с фидбэком от заказчика ПО о качестве тестирования.

А чтобы понимали и ценили, надо самим разработчикам посоставлять тест планы и потестировать ручками с фидбэком от заказчика ПО о качестве тестирования.

Что-то мне это напомнило трудовое перевоспитание тунеядцев и алкоголиков в приснопамятные времена :)

Вообще, как мне кажется, слесарю - слесарево. Пусть себе программируют на здоровье. Плохо, если тебя не ценят твои боссы, а программисты это из другого ведомства. Не вижу смысла особенно переживать, если программисты смотрят на тестировщиков свысока. Во-первых, это говорит об их собственном непрофессионализме, а во-вторых, есть масса способов если и не заставить себя уважать, то по крайней мере сбить спесь с таких товарищей. Достаточно немного внимательнее потестировать то, что написал такой индивидуум, и количество багов, которые будут на нем висеть, резко увеличится. А одним из критериев оценки работы программиста, который напрямую влияет на его зарплату, является качество кода, который он пишет. Если он постоянно в первых рядах в отчетах по багам, которые очень любят смотреть разные боссы, то за это его по головке не гладят. Я не говорю, что это универсальный способ, но лично мною проверено на практике. Отрезвляло даже самых буйных.

Достаточно немного внимательнее потестировать то, что написал такой индивидуум, и количество багов, которые будут на нем висеть, резко увеличится. А одним из критериев оценки работы программиста, который напрямую влияет на его зарплату, является качество кода, который он пишет. Если он постоянно в первых рядах в отчетах по багам, которые очень любят смотреть разные боссы, то за это его по головке не гладят. Я не говорю, что это универсальный способ, но лично мною проверено на практике. Отрезвляло даже самых буйных.

А если дружить с программистами, то на баги можно глаза закрывать? <_<
Сомнительный подход...

И что именно отрезвляет? Количество багов? В моей практике бывало и так: разработчику поступает багов больше, чем он ожидал :D , он ссылается на недостаточно детальное ТЗ, требует дополнительной работы аналитика. В итоге, крайним становится не он, а кто-нибудь другой.
В результате противостояния нескольких человек замедляется весь процесс разработки.
ИМХО - такой подход не универсален и часто даже вреден.

2Case!

Вот Вы на меня нашумели:) а может я Вам смогу помочь чем....
Наезды на КА - это конечно не совсем обоснованные весчи, хотя понять их могу! КА довольно плохую репутацию себе сделали поначалу, впрочем, как многие другие сферы бизнеса. Для тех кто не знает, есть разные КА - какие-то хорошие, а какие-то так себе. Сейчас уже нет КА которые страются всех "нагреть". И небольшой совет, чтоб не бояться что Вас обманут, надо обращаться в КА, которые не берут денег с соискателя, а берут их с роботодателя.
Компания, в которой я работаю очень крупная, имени тут не называю, т.к. политика компании запрещает указывать зарплаты в объявлениях с именем компании. Я менеджер по персоналу и очень часто контактирую с КА. Могу сказать, что как в любом месте там есть профессионалы и есть так себе <_<
А что касается рынка, то это нормальная ситуация. Сегодня специалистов нет, а завтра есть! И несколько объявлений на Job сайтах и в форумах в рубрике "Работа" недостаточно :(
Нужно составлять интересные объявления, менять их постоянно. Грамотно обрисовывать перспективы роста и проф. развития.
Ну а если чего, обращайтесь ко мне:) вдруг я кого-нить Вам найду:)

Ну нашумел-то за дело? :)

На самом деле соглашусь с тем, что КА бывают разные, хотя тут особо на них никто и не наезжал. По опыту общения с коллегами могу только подтвердить - не кинут там, где за найденного человека платит работодатель.

А если дружить с программистами, то на баги можно глаза закрывать? <_<
Сомнительный подход...

И что именно отрезвляет? Количество багов? В моей практике бывало и так: разработчику поступает багов больше, чем он ожидал :D , он ссылается на недостаточно детальное ТЗ, требует дополнительной работы аналитика. В итоге, крайним становится не он, а кто-нибудь другой.
В результате противостояния нескольких человек замедляется весь процесс разработки.
ИМХО - такой подход не универсален и часто даже вреден.

Зачем утрировать? Если с программистами у вас дружба, то они не смотрят на вас свысока и проблемы, о которой шла речь, вообще не существует. Кроме того, времени на тестирование постоянно не хватает. Если проект не укладывается в срок, то в первую очередь сократят время на тестирование так что абсолютно все вы навряд ли протестируете очень тщательно. Что-то просто "потрогаете" слегка, чтобы убедиться, что на самых простых операциях система не сыпится, а где-то можно копнуть поглубже.

Отрезвляет то, что программер постоянно находится под прессингом - помимо того, что ему надо что-то новое разрабатывать на него постоянно сыпятся его старые грехи. На кого он будет дальше переводить стрелки - это пусть у него голова болит. Если он будет постоянно ссылаться на некачественное ТЗ это опять-таки в плюс ему не пойдет. Опять же тот, кто готовил это ТЗ не будет в восторге от того, что на него наезжают ну и т.д. Смысл в том, чтобы "попрессовать" такого программера, когда помимо основной работы ему еще придется доказывать некачественность ТЗ и заниматься кучей других столь же приятных вещей.

Я специально написал, что такой подход не является универсальным. Надо было выделить эти слова как disclaimer? Очевидно, что для тех, кто скоростью процесса разработки озабочен больше нежели высокомерным отношением к себе со стороны подобных программеров, такой подход не катит.

К вопросу о кадрах.
А может быть не стоит принимать людей, которые смотрят только на з/п ?
По - моему где - то на форуме уже была дискуссия по поводу людей, первый вопрос которых - з/п.
Если я не ошибаюсь, с Case (извините Case, если не Вы).
Конечно, все мы можем ошибаться, но цель менеджера - создать коллектив (не говорю слова команда,
т.к. не всегда это надо), который был бы более или менее постоянный. Иначе придется все время
работать на обучение ...
М.б. мы лучше обсудим приемы и стратегии проведения интервью?
Что скажете ?

А может быть не стоит принимать людей, которые смотрят только на з/п ?

A как можно определить только ли на зарплату смотрит человек или ему еще что-то важно?

на интервью. Понятно, что спрашивать человека напрямую бесполезно.

Отрезвляет то, что программер постоянно находится под прессингом - помимо того, что ему надо что-то новое разрабатывать на него постоянно сыпятся его старые грехи. На кого он будет дальше переводить стрелки - это пусть у него голова болит. Если он будет постоянно ссылаться на некачественное ТЗ это опять-таки в плюс ему не пойдет. Опять же тот, кто готовил это ТЗ не будет в восторге от того, что на него наезжают ну и т.д. Смысл в том, чтобы "попрессовать" такого программера, когда помимо основной работы ему еще придется доказывать некачественность ТЗ и заниматься кучей других столь же приятных вещей.

Попробую использовать Ваш метод на практике :)
После этого напишу о результатах.

Очевидно, что для тех, кто скоростью процесса разработки озабочен больше нежели высокомерным отношением к себе со стороны подобных программеров, такой подход не катит.

Хм... я Вас не обидела случайно? Если да, то прошу прощения.
Для меня более важен конечный результат, а не личные отношения. Возможно, кому-то такой подход не
понравится. Но это уже не относится к теме "Уровень тестировщиков" :).
Дело не в скорости процесса разработки, а в получении качественного продукта в оговоренные сроки. И если кто-то из программеров будет неадекватно ко мне относиться, то это скорее его проблемы, чем мои :)

Хм... я Вас не обидела случайно? Если да, то прошу прощения.
Для меня более важен конечный результат, а не личные отношения. Возможно, кому-то такой подход не
понравится. Но это уже не относится к теме "Уровень тестировщиков" :).
Дело не в скорости процесса разработки, а в получении качественного продукта в оговоренные сроки. И если кто-то из программеров будет неадекватно ко мне относиться, то это скорее его проблемы, чем мои :)

Нет, не обидели :) В принципе, если неадекватное отношение со стороны программеров мало волнует, то и проблемы то нет :) В конце концов Ваш профессиональный и карьерный рост от программеров не зависит.

Отрезвляет то, что программер постоянно находится под прессингом - помимо того, что ему надо что-то новое разрабатывать на него постоянно сыпятся его старые грехи. На кого он будет дальше переводить стрелки - это пусть у него голова болит. Если он будет постоянно ссылаться на некачественное ТЗ это опять-таки в плюс ему не пойдет. Опять же тот, кто готовил это ТЗ не будет в восторге от того, что на него наезжают ну и т.д. Смысл в том, чтобы "попрессовать" такого программера, когда помимо основной работы ему еще придется доказывать некачественность ТЗ и заниматься кучей других столь же приятных вещей.

Ну, отрезвить может и не отрезвит, но то, что у тестровщиков и ИК нервы крепче - это точно.
Скорее с какого-то момента после начала такого прессинга программер (или прогламер? ;) ) уйдет в себя (или в HR) и не вернется :D зато другим неповадно будет.

Хотя ИМХО - прессинговать не нужно. Это только накалит отношения в коллективе, и совершенно пагубно скажется на общем качестве продукта. Скорее нужно собрать свой тим в маленький кружок и сказать "не спорьте с дураком, со стороны разницы не видно" ;) А такие прогламеры и так не задержатся.

Здесь надо не пропускать момент и вовремя поднимать з/п на 20 тугриков.

Я не владея знаниями по работе с персоналом могу предложить схему: каждые пару месяцев + 20?
Вариант с пересмотром ЗП по результатам работы возможен если человек себя реально проявляет, а такой человек и так виден из толпы и с ним пролем, наверное меньше, чем с рядовым тестером, которые как раз и бегают.

Вот еще несколько мнений по поводу
"Как удержать высококвалифицированных ИТ-специалистов? "

http://www.siliconta....asp?artId=2640

Вот еще несколько мнений по поводу
"Как удержать высококвалифицированных ИТ-специалистов? "

http://www.siliconta....asp?artId=2640

Забавный тезис нашел в этой статье.

"Выбирая между компанией с хорошим имиджем на рынке, хорошей заработной платой, но рутинной работой, и малоизвестной компанией с меньшим уровнем заработной платы, но с нетривиальными «высокими» и значимыми ИТ-задачами, ИТ-специалист в большинстве случаев предпочтет именно второй вариант."

Что-то сомнения меня берут в справедливости такого утверждения, особенно если такой ИТ-специалист, не энтизиаст-одиночка, который может решать "нетривиальные IT-задачи" по 10-12 часов в день, а семейный человек.

Решил опрос устроить на эту тему: Что важнее в работе?

Что-то сомнения меня берут в справедливости такого утверждения, особенно если такой ИТ-специалист, не энтизиаст-одиночка, который может решать "нетривиальные IT-задачи" по 10-12 часов в день, а семейный человек.

Когда-то давно идея silicontaiga была именно в том, чтобы собрать хороших специалистов со всей страны и не только. Что-то типа БАМа :) в ИТ.
Время внесло свои корректировки, но идея кое-где осталась:)