Распределение ролей в команде.

Видится проблема, когда один сотрудник зацикливается на выполнении одних и тех же задач.
Кто как видит вопрос перемещения сотрудников внутри проекта.
С одной тороны не стоит давать человеку застаиваться на одних задачах - скучно.
С другой стороны конкретный Иванов такие срипты вызовов интерфейсов пишет просто сказка.
Как видится управление командой?

Управление на основе приоритетов... Там, где это не противоречит интересам проекта, учитывать пожелания команды -- это окупается (принцип "Мимино": Если мне будет приятно, я так тебя довезу, что тебе тоже будет приятно)

- если конкретный Иванов пишет чудесные скрипты вызовов интерфейсов и хочет их писать -- не трогать;
- если тот же Иванов больше не хочет их писать, а хочет писать тесты для сетевых протоколов -- дать ему попробовать: может, его новые тесты окажутся даже не сказкой, а песней...
- если Петров пишет плохие скрипты чего-то там, но хочет писать именно их -- дать испытательный срок и намекнуть, что если не научится, пойдет тестировать интерфейсы -- вручную ;)
- если Сидоров больше не желает делать ничего -- выгнать, даже если он был хорош, а вместо него взять вчерашнего студента Федорова, который, во-первых, еще хочет работать, во-вторых, по студенческой привычке обучаем... и отдать его Иванову, который с радостью научит его написанию своих сказочных скриптов, лишь бы переключиться на протоколы!

по-моему, это не проблема как раз, я согласен с el-step'om. кажды делает то, что у него лучше получается :-).

В итоге рано или поздно приходим к общему знаменателю:
Все пишут то что у них получается - (+)
Совместного владения кодом нет - (-)
Уход/болезнь любого из сотрудников влечёт за собой повисания конкретного куска процесса (интерфейсы останутся нетестированными вовсе) - (-)
Первый человек которому наскучит тестить "эту проклятую длл-ку" окажется не удел - перевести его просто некуда - везде сидят те самые которым нравится там сидеть - (-)
Всегда будет нудный кусок работы на который никто не будет садится, в итоге командное решение и кто-то в обиде ибо остальные делают то, что им нравится - (-)

Господа, мне одному очевидна необходимость ротации кадров?

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

А обиженных - этого всегда с лихвой хватает :)

Но я за ротацию кадров :) Когда есть кого переводить с места на место :)

У нас это немного не так получается.
Людей в QA команде немного.
Стараемся, чтобы каждый в команде был ведущим QA менеджером на каком-то из проектов.
И обязательно, чтобы над проектом работало как минимум 2 человека.
В случае перетасовки - кто-то уже точно будет знать проект и общие ньюансы работы с ним.
После окончания какого-то проекта человек обязательно идет на другой проект.
Каждого из тестеров обязательно грузим на выполнение всех типов работ независимо от его желания - принцип такой - каждый должен уметь все.
Конечно, качество и время выполнения конкретного типа работы у всех разное, но таким образом пытаемся всех сделать универсальными.
Конечно, в этой ситуации человек не всегда делает то, что ему нравиться, но с другой стороны - очень четко видно, когда человек работает месяц на одним типом задач, а потом переходит на другой - сразу такой прорыв в команде идет с точки зрения новых идей и методов работы.
Еще пытаемся сделать свою базу знаний - все, что относится к тестингу - группируется и кидается в эту базу - и там тоже четко видно, как идет обновление этой базы. что конкретный человек изучает, что ему нравиться - и сделать выводы о его приоритетах.
Но чаще всего личные приоритеты не учитываются. Идет принудительная перетасовка.
Может быть это и плохо, но таким образом страхуем себя от всяких неожиданностей по принципу - что бы не случилось в команде, работа не должна останавливаться, а для этого каждый должен уметь все.

2 chuk:
Чуть отвлекусь.
Относительно базы знаний - делитесь!
Наработки могут быть очччень полезны сообщетсву - давайте рассмотрим что у вас есть по материалам и обогатим сервер!

А относительно ротации кадров - то есть она нужна :) Хоть в этом у нас есть что-то общее.

Ольга - Вам не кажется, что Ваша ситуация требует существенного изменения?
Несколько моментов, которые меня задели:
Что значит ваш код? И его не хочется отдавать. Вы работатет в команде, это в принципе не должно обсуждаться.
Ваш код исключительно тот, что вы пишете дома для себя, имхо такая позиция.

Это раз, а потом я так и не сообразил :) Вы за или против?

_____________
То есть ротация если и есть то упорно командная (кто бы сомневался :)), хорошо - а принципы перетасовки?

Я обеими руками за, поскольку очень люблю перемены.
Только я - единственный тестер в команде и поэтому быстро меня не заменить, и переводить меня тоже не куда, разве только к конкурентам :)

А про мой код - общий, это воспоминания из моего программистского прошлого. Здесь речь, в принципе, шла о присвоении кем-то чужих результатов труда :(

Здесь речь, в принципе, шла о присвоении кем-то чужих результатов труда

Вы имеетв виду в этом топике?

2chuk:
Вопрос а зачем столько ведущих специалистов в каждом конкретном модуле или подсистеме?
имхо если тестируется командой то уровень работы повышается значительно.
Опять таки Вы и сами говорили про проыв идей когда перебрасывают кого-то с другого направления, так зачем создавать затыки идей?

по-моему, это не проблема как раз, я согласен с el-step'om. кажды делает то, что у него лучше получается :-).

Это не проблема если Вам не нужгно отвечать за весь процесс тестирования, качество получаемого продукта и руководить отделом ;)

Конечно проблема, еще какая :) Имелось в виду (и уточнялось) -- высшим приоритетом являются интересы проекта.
Я это себе вижу так:

1. каждая задача должна выполняться (т. е. всегда должен быть человек, который может ее выполнять);
2. задачи в совокупности должны выполняться по-возможности эффективно (т. е. если есть равноценные задачи, нельзя направить на решение одной двух сильных, а на вторую оставить одного слабого);
3. текучесть кадров должна быть минимальной.

А уж после этого, вернее с середины пункта 3, начинаются личные приоритеты.

Совместное владение кодом и вообще наработками -- обязательно; не всеобщее, но до уровня заменяемости каждого кем-либо. Хотя глубина познаний все равно будет неравноценной.
Если есть кадровая возможность, хорошо, конечно, иметь "свободного агента", который достаточно в курсе многих задач/процессов, чтобы быстро переключаться с одного на другой для временной замены или поддержки.

Чтобы делать то, что нравится, недостаточно просто этого хотеть -- нужно еще уметь это делать лучше всех остальных. Если же тебе действительно так надоело тестировать длл-ку, а места заняты -- буть добр доказать, что ты можешь делать что-то другое, причем существенно лучше чем это делается сейчас. И поначалу это придется доказывать совместно с работой над длл-кой... Тогда "нудный кусок" достанется тому, кто не проявил достаточного мастерства в чем-либо еще.
Кроме того, "невостребованные" части можно раздавать в нагрузку (как книжки в советское время): хочешь делать то-то -- пожалуйста, но еще будешь делать то-то. Вот эти нагрузочные куски как раз можно тасовать как угодно.

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

Понятно что ротация не самоцель, а именно способ повысить качество работы команды.
Как задача повысить надёжность команды как инструмента (взаимозаменяемые части всегда удобнее чем один очень острый и модный инструмент/специалист), и в тоже время учитывать заинтересованность каждого кто работает - иначе срабатывает принцип цепи, где её надёжность измеряется её самым слабым звеном.
Как выход - слаженный колектив, в котором нет заточки под ведущего/ведомого изначально, и как всеобщий результат спокойная и нормальная работа без разрывов.

Господа - идея поделиться наработками (документацией, собранными ссылками, своими методиками (даже если это просто удобный для работы темплэйт офисного документа)) в силе.
Если есть желание влиться в коллектив Тестера как консультанты - wellcome.
Вложенное имхо окупиться когда народу притопает побольше и люди увидят, что проект по-настоящему а не на словах открыт к сотрудничеству.

1. На вопрос Case о необходимости большого количества ведущих специалистов:

Не знаю, правильно это или нет, но так сложилось, что одновременно в работе находится несколько проектов. На каждый проект выделяется QA менеджер, который несет ответственность за качество именно этого проекта. Т.е. есть начальник отдела (он тоже может быть QA менеджером) и есть все остальные, некоторые из которых ведут отдельные проекты. Т.е. сегодня он менеджер одного проекта, через полгода - другого, со всеми вытекающими требованиями к менеджеру проекта - составление планов, распределение людей и т.д. - в этой ситуации даже рядовой тестер, когда его нагрузить ответственностью, начинает думать глобально и болеть за качество проекта. Конечно, при назначении менеджера учитывается его опыт и сложность проекта.

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

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

OT: Эта методика ротации чудесно описана Борхесом в рассказе "Лотерея в Вавилоне" :D

А что ваапче удерживает людей на работе, если люди не страдают трудоголизмом в крайних его проявлениях? :)

ЗП имхо.

По поводу многих ведущих:
При наличии многих проектов - ключевая обьясняющая фраза. Всё вьехал. А то пред мои ясные очи так и встала картинка среднего проекта по размерам и 4 ведущих тестировщиков решающих проблемы глобальной автоматизации :)

ЗП имхо.

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

В конкуретной борьбе не мастак :)

Хотя видится не только ЗП фактор, если примется как пример моя скромная кандидатура.
Интересует и перспектива роста / развитие фирмы, и отпуск, и возможность в обеденный перерыв сьесть горячий обед, и вменяемость сотрудников (ибо тогда и я становлюсь жутко вменяемым человеком, в противном случае быстро порчусь, становлюсь ворчлив и не в меру придирчив :) - впрочем как и все , наверное) и отношение руководства к работе, которую мне поручили (копать от меня до обеда скучно) - словом многое, и не только ЗП.

А по отношению к работникам есть одна практика, которой я очень хотел бы придерживаться и далее: сколько получает каждый конкретный работник не есть вопрос руководителя отдела - для этого есть руководство фирмы или политика в отношении ЗП как таковой. Как руководителю лучше, наверное, всё-таки играться с премиальным фондом и возможностью депримировать конкретно за разгильдяйство (возможно и в %-тах от ЗП).

Интересует вопрос по обучение коллектива и повышению общего проффесионального уровня комманды - хотелось бы выслушать мнения, прошу в топик в разделе Работа (Повышение уровня комманды)