Сообщений в теме: 27

[OlegSh]

Олешка Дата Oct 2 2003, 05:02 PM
--------------------------------------------------------------------------------
А очень просто - кроме выполнения тех работ, что описал Case, есть еще такой фактик: менеджеры проектов НЕ заинтересованы показывать ошибки своих проектов. Начальник отдела тестирования отвечает и за то, чтобы тестировщиков не заставляли их скрывать. 

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

[el-step]

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

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

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

По поводу отделов и проектных команд: если проектов несколько, то, как на мой взгляд совершенно правильно отмечает Alpha, одна из многих задач начальника любого отдела -- оперативно распределять ресурсы отдела между проектами. ПМ может это делать самостоятельно только в том случае, если всеми проектами рулит он один (что, само собой, совершенно не обязательно). А иначе что же -- ПМ's будут дуэли за ресурсы устраивать или заложников захватывать?
Если же ресурсы изначально поделены между проектами ("проектные команды"), то кто сможет эти команды переформировывать? Или, допустим, кто в компании сможет определить (и аргументированно убедить руководство), что имеется необходимость расширить штат тестировщиков?

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


Что же касается менеджера отдела тестирования как отдельной штатной единицы -

выделить отдельного человека, который будет добывать оборудование и программы, а также составлять графики тестирования и распределять ресурсы по проектам - менеджер

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

[Олешка]

1. Я тогда вообще не понимаю, как можно скрывать ошибки и от кого, если есть багтрекинговая система?

2. И к тому же за проваленный проект в первую очередь должен отвечать ПМ, а потом уже все остальные...

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

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

2. Когда проект провален, уже поздно и в общем неважно, ответит за что-то ПМ или нет. Фирма теряет проект и деньги.

3. Вдогонку к Case, el-step, Alpha - должно быть управление ресурсами. Что делать, если появляется новый проект? Брать новых людей и снова их обучать? А в это время тестировщики другого проекта сидят сложа руки и ждут очередную версию?

[OlegSh]

Попробую подвести итог, чем должен заниматься начальник отдела тестирования:
1. следить за загруженностью тестировщиков и распределять свободных по другим проектам
как он может за этим следить если проектов более 16 (в среднем на проекте 4-5 чел.)
ресурсы перебрасывеамые с проекта на проект не эффективны, т.к. у них нет ощущения, что это их проект и если они его провалят, то достанется всем, а так - вот я на этом проекте он уже накрывается, ну и на фиг, зато вот на другом все хорошо и могут дать бонус.
2. следить за качеством проектов
как он может быть достаточно компетентным в критичных багах при 16 проектах, хорошо если он будет в общих чертах в курсе всех проектов.
Если я что-то упустил, то не со зла :), просто я против этого лишнего рта. Причем большую часть работы этого бойца придется выполнять Лиду (у нас проекте такое-то кол-во критичных баг, такие-то ресурсы скоро освободятся, такие-то плохо работают, и т.д.), т.к. сей начальник просто физически не будет успевать все это делать сам, так на кой черт он нужен?
Аналогично с девелоперами.
Так не проще ли вместо двух оставить одного, который будет следить только за ресурсами вообще. Причем о компетентности того или иного сотрудника решение выносит Лид и докладывает ПМу, затем ПМ отправляет чел-ка к тому, кто занимается ресурсами, тот делает себе 1 заметку, несколько заметок и человек выгоняется.
Как только на проекте остаются не занятые люди и не предвидится в ближайшее время никаких работ, они выставляются на свободный рынок ПМам, те выбирают себе необходимое кол-во людей, если нет людей, то ПМ пишет чел-ку занимающемся ресурсами надо столько людей к такому-то числу и все, остальное его уже не волнует.
Это так в общих чертах.

Тепреь по поводу багтрекинговой системы:
1. я не ошибусь, если скажу, что в любой багтрекинговой системе есть репортинг (я думаю, что в компании в которой есть должность нач. отдела тестирования, такая система просто обязана быть ;) ), в котором можно построить отчеты в которых будет отражено кол-во критичных, серьезных ... баг найденных за неделю, пофикшеных за неделю, общее кол-во баг с разбиением по priority, severity, кускам функционала. Причем рассылка совершается автоматически ПМу, Лидам, руководству фирмой.

[Олешка]

Попробую подвести итог, чем должен заниматься начальник отдела тестирования:

1. следить за загруженностью тестировщиков и распределять свободных по другим проектам

как он может за этим следить если проектов более 16 (в среднем на проекте 4-5 чел.)
ресурсы перебрасывеамые с проекта на проект не эффективны, т.к. у них нет ощущения, что это их проект и если они его провалят, то достанется всем, а так - вот я на этом проекте он уже накрывается, ну и на фиг, зато вот на другом все хорошо и могут дать бонус.

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

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

[Олешка]

Да, еще насчет ресурсов - у нас так же как и у Alpha, тестировщик не сидит только на одном проекте. Кроме того, и начальник отдела (лишний рот, по вашему утверждению) выполняет часть работ тестировщика на том или ином проекте.

[Alpha]

to OlegSh
В идеале нет таких вариантов что на фирме 16 проектов и все такие что можна выделить целое число тестировщиков. :) Реально это немножко другому. И также реально на разных фирмах, кроме стандартного списка типа теспланы-тесткейсы, тест менеджер может отвечать еще за что-то очень уж специфическое и нужное исключительно этой фирме.
На счет незаинтересованости в тестировании того или иного проекта самим тестером, то для этого и нужен менеджер чтоб видеть эту незаинтресованость и в нужный момент присечь.
Тест менеджер не должен вникать в детали каждого проекта, для этого он вибирает в команде ведущих тестировщиков. Какие-то проекты ведет сам, какие-то отдает под контроль тест лидеров.
Мы можем так же начать спорить нужен ли вообще директор на фирме.
Есть какой-то целостный участок работы и нужен человек ответсвенный за этот участок. Он может совмещать эту деятельность еще с чем-то. Может быть наоборот, что его работа разделяется на несколько частей, управление ресурсами падает на группу HR, контроль тестирования в своем проекте (или группе проектов) ведет менеджер проекта, который полностью сам отвечает за качество проекта, за развитие уровня тестирования, определиние что лучше Рейшинал или Меркури еще кто-то.. тогда менеджер проекта будет и менеджер группы тестирования, и обеспечения качества, и разработки. Это уже дело конкретной фирмы, какая исторически сложилась ситуация.
Мы путаемся в ролях (это чисто абстракция) и реальных сотрудниках на которых эта роль возлагается...

[el-step]

И вообще зачем отдел тестирования, отдел разработки? В чем преимущество такой организации компании? Почему нельзя их убрать в принципе и оперировать понятием проектная команда?

To OlegSh:
Почему же нельзя -- можно... можно убрать, можно оперировать. Такое бывает. Во всяком случае, я знаю компанию, где программисты, аналитики и тестировщики составляют единый отдел ("разработки"), ПМ'ы определяют необходимое количество ресурсов для своих проектов, а распределением этих ресурсов занимаются специальные люди -- видимо это та структура, которую Вы имеете в виду (конечно, никакого свободного рынка рабочей силы при этом нет -- ПМ'ы запрашивают ресурсы или объявляют об их освобождении, вот и все).

Далее начинаются расхождения.

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

Т. е. если в проекте А потребовался C-программист, а у только что освободившегося Васи никакого C в личной карте нет, то Вася не попадет в проект А, придется для проекта искать кого-то еще. И никто не подойдет к Васе, не похлопает его отечески по плечу и не скажет: "Вася, я же знаю что ты на C диплом писал, и вообще ты парень умный, разберешься... так что давай!"

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

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

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

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

А вообще, по-моему, мы все больше уклоняемся от темы "Ведущий тестировщик" :D