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

[daniel]

Должен ли менеджер отдела тестирования уметь ставить процесс?

[Clauster]

А вы про какой процесс?
Если тестирование-да.

[serega]

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

[cd__]

Должен ли менеджер отдела тестирования уметь ставить процесс?

а разве есть другие обязанности у менеджера отдела тестирования кроме как "ставить процесс" и участвовать в нём?

[barancev]

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

[daniel]

я говорю о процессе тестирования.

вопрос в том, что мы с вами исходим из нашего опыта.

кому-то пришлось поднимать отдел с нуля, в том числе и процесс, и они считают, что процесс - must.

те, кто пришел на готовый процесс, столкнулись с тем, что процессу нужно просто следовать.

вопрос - как правильно?

[daniel]

а разве есть другие обязанности у менеджера отдела тестирования кроме как "ставить процесс" и участвовать в нём?

Проект - это временное предприятие, предназначенное для создания уникальных продуктов или услуг.

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

Заметьте, ни слова о постановке процесса.

[Nadezhda]

Проект - это временное предприятие, предназначенное для создания уникальных продуктов или услуг.

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

Заметьте, ни слова о постановке процесса.

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

[daniel]

2 Nadezhda:

Сразу скажу, что у меня нет окончательного мнения по этому поводу. Есть, как минимум, 2 точки зрения на этот счет.

Согласитесь, что устанавливать и следовать тоже понятия разные.

[Clauster]

Вы же не можете утверждать, что тот процесс, которому вы следуете-идеален? Совершенству нет предела. Поэтому надо уметь ставить и развивать процесс. Хотя, правильнее сказать - управлять процессом.

[Green]

Коллеги,

должен вас разочаровать. Как правило "ставить" процесс приходиться крайне редко. И думаю, что этим придеться заниматься только тому, кто будет создавать фирму с "нуля".

Во всех остальных случаях процесс уже существует (даже если он не правильный, с вашей точки зрения).

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

Следовательно, вопрос можно сформулировать так - каким способом руководитель группы тестирования может усовершенствовать процесс тестирования? Именно правильная постановка вопроса помещает нас на распутье выбора методологии (прямо, как в сказке - направо пойдешь - RUP ты найдешь, но гибкость потеряешь; налево пойдешь - XP ты найдешь, но масштабируемость потеряешь; и т.д. )

[daniel]

Сергей,

2 вопроса:

1. вы не упомянули MSF. для этого есть причины?

2. как вы считаете насколько подробно менеджеру нужно разбираться в RUP, XP или MSF? Ведь при переходе на новое место работы нужно будет вникать в специфику нового процесса.

[romanl]

Должен ли менеджер отдела тестирования уметь ставить процесс?

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

[Mila]

Сергей,
2. как вы считаете насколько подробно менеджеру нужно разбираться в RUP, XP или MSF? Ведь при переходе на новое место работы нужно будет вникать в специфику нового процесса.

ИМХО разбираться нужно во всем... и из этого набора выбирать те вещи, которые будут эффективно работать в вашем конкретном случае ...

[daniel]

2 Mila:

Имхо хорошо разбираться во всем невозможно :)

Вы придерживаетесь концепции "каждому проекту своя методология"?

[Green]

Сергей,

2 вопроса:

1. вы не упомянули MSF. для этого есть причины?

2. как вы считаете насколько подробно менеджеру нужно разбираться в RUP, XP или MSF? Ведь при переходе на новое место работы нужно будет вникать в специфику нового процесса.

Про MSF -
Просто не вспомнилась эта методология, когда писал сообщение. Хотя Делл работает именно на базе MSF. И, возможно, это является показательным примером.

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

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

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

Процессы нужны не работчикам, не тестировщикам! Они нужны менеджерам!


Да, да, именно менеджеры придумали методологии разработки софта. Почему? Что бы быть независимыми от конкретной личности. Далеко не всегда собирается хорошая команда под руководством талантливого лидера, у которой на выходе всегда положительный результат. Фирма становится зависимой от такого руководителя (будь то руководитель группы тестировщиков, разработчиков или нарезчиков мяса ). С его уходом в конкурирующую компанию, все может рухнуть, и фортуна побежит за ним.

Как этого избежать? - Сделать набор его действий тиражируемым!

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

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

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

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

Закономерен вопрос. Следует ли менеджеру знать и применять какую-нибудь методологию в работе его команды? Да, знать и применять обязательно. Иначе хаос. Но какую? Это зависит от вашего опыта. Если вы не представляете себе полный цикл разработки ПО, то лучше изучить хоть какую-нибудь. Я, например, начал с RUP и методично ее проштудировал.

[Boltick]

2 Mila:

Имхо хорошо разбираться во всем невозможно :)

Вы придерживаетесь концепции "каждому проекту своя методология"?

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