Были случаи, когда тестировщик становился PM'ом?

Становились ли вы свидетелями, когда тестировщик впоследствии становился руководителем проекта?

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

Хочу услышать от вас все ЗА и ПРОТИВ того, почему тестировщик может (или не может) быть в будущем ПМом.

Все зависит от его личнохных качеств, которые важны для PM. Общение с Заказчиками, мотивация команды итд итп.
Людям, хорошо знающим проект, порой кажется, что PM вообще лишний, он же "дурак с улицы", не разбирающийся в вашей специфике.

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

ИМХО, PM может себе позволить слабо знать проект. Наоборот, нормально, будет смотреть на него с точки зрения пользователей, еще и баги вам какие-то найдет, которых люди с замыленным взглядом не видели))

Отвечая на вопрос - были и есть. Но позволю высказать свою точку зрения.

Хорошему тестировщику никто не разрешит стать плохим PM-ом. Наплодили уже менеджеров, что не знаем что с ними делать. А кто тестировать будет? Кто будет внедрять новые техники и подходы в тестировании, PM-ы? Уже навнедряли 100% автоматизации, спасибо. Нужно дать дорогу инженерам и повышать квалификацию! Если тестировщик говорит, что он уже знает все о тестировании и ему скучно - скажите "Погугли по запросу Software Testing" - About 141,000,000 results
Хороший PM не должен заниматься вопросами постановки процесса и техническими задачами, это дело команды! Хороший PM будет общаться с клиентами, уточнять как у них настроение и уровень счастья. Покупать команде сникерсы, приносить кофе, заниматься отпусками, зарплатами и прочими административными делами. Я встречал очень мало инженеров, кому такая работа по душе.

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

Спорно!

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

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

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

Ты верно заметила - главное результат.

Быть может в твоем контекте, где команда состоит из ПМ(папа, мама), а инженеры - дети которые их слушают, принесет результат.

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

В противном случае сильные "дети" от них уйдут к другим "родителям". Те кто послабее будут сидеть с пониженной моралью и что-то там кодить/тестить. Принцип "command and control"

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

Но опять таки, бывают разные команды, люди и т.д. где подход мамки PM-а вполне востребован, но мне не по-душе такие проекты.

Команда - как организм.

Вот у тебя есть сердце, печень, почки. Если ты поменяешь одно сердце на 2 почки, то с 4-мя почками и без сердца долго не протянешь, так? То же самое в команде. Решение задач требует слаженой работы всех органов. Задача менеджера - чтобы этот организм так работал, чтобы были все необходимые органы для решения задач. То есть главная функция любого менеджера - правильное объединение отдельно взятых людей в один организм, направленный на достижение нужных целей.

По желанию или по необходимости менеджер тоже выполняет роль каких-то органов.

Каких? Да неважно! Менеджер-папа он или менеджер-попа, менеджер-мозг или менеджер-пятка. Кто угодно, главное чтоб организм работал.

Я часто слышу все эти шаблонные "менеджер не должен делать того-то". Но почти всегда это пересказ чужого опыта или концептуализация своего собственного: "В одном случае вот такое действие привело к плохим результатам - значит больше не надо так делать". НЕЛЬЗЯ ни в коем случае так обобщать, всегда есть масса влияющих факторов:
* знания, навыки, опыт команды и самого менеджера
* предпочтения команды
* текущие условия работы и проектные приоритеты
* личные особенности команды, их предрасположенность к разным типам выполняемых активностей и стилям руководства

и т.д.

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

Менеджер может быть и нянькой, и папой-мамой, и бюрократом, и идеологом-вдохновителем, и кормильцем, и пчелой-трудягой, и доброй феей, и палачом. Может по kaizen со стороны наблюдать за гемба и фиксировать правильные процессы (потому что вовлечённый в работу сотрудник никогда не сможет это сделать настолько же эффективно). Может возиться с бумажками, больничными, отпусками. Может держать знамя и вести к светлому будущему, раздавая по дороге сникерсы. Может быть технарём и показывать примером, как надо работать. И если результаты работы отличные и команда счастлива - значит он всё делает ПРАВИЛЬНО. А если он следует любым шаблонам из любой книжки, а результаты работы не айс, команда не довольна - значит он что-то делает НЕ ПРАВИЛЬНО.

Других критериев правильности действий менеджера (кроме результата работа (краткосрочная перспектива) и сплочённости команды (долгосрочная перспектива)) НЕТ.

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

Если в моей команде менеджер будет заниматься только административной работой, я скажу ему спасибо за достигнутый результат и уволю, а на его место найму секретаря с зарплатой в 10 раз меньше. Вот она прелесть самоорганизованнх команд!

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

Если в моей команде менеджер будет заниматься только административной работой, я скажу ему спасибо за достигнутый результат и уволю, а на его место найму секретаря с зарплатой в 10 раз меньше. Вот она прелесть самоорганизованнх команд!

Вот вот, и я о том же. А хороший менеджер, это поймет еще раньше и уйдет сам!

Я этот разговор начал потому, что в СНГ наблюдается тенденция. Все хотят быть менеджерами. Как блин шаблон вдолбленный с самого детства "Вот станешь начальником, будешь много зарабатывать". ИТ-менеджер, это обычный трудяга среднего звена, который зарабатывает не больше хорошего инженера(если у вас не так, читай пункт 1 ниже), я сейчас не говорю о Business Owners и Excutives.

Менеджеры, вспоминайте чему вас учили по теории управления(если вы учились, чтобы быть менеджерами, а не стали им за выслугу лет или по знакомству):
1. Управляй и получай
Аналог западного command & control. Где есть огромные иерархии и действует логика "я начальник ты дурак"(как в армии). Вот это райский уголок для менеджера. Он большой начальник, его все боятся и уважают. Он как тот ёжик с ручкой, записывает всех в свой блокнот.

2. Направляй и созидай
Где люди работают вместе ради единой цели. Где каждый знает, чем он занимается в этом проекте. Где инженера уважают - как творца и лишь показывают ему направление, чтобы тот не сбился с пути. Вот здесь умный менеджер занимается развитием людей: заказывает тренинги, выбивает бюджет на конференции, бонусы и прочее админ. задания. Да, он может заниматься подсчетом метрик, как Наташа сказала. Но если своими метриками будет пытаться "нагнуть" команду и упрекнуть, что та плохо работает, произойдет то, что уже было описано выше. Так же, не исключаю вариант, что эту команду могут просто разогнать и будут правы, если метрики правильные и не врут. Почему бы не дать возможность команде самой улучшать свой процесс? Дать им 1-2 часа в месяц на то чтобы обсудить проблемы, которые возникали. Если в команде работают умные люди, они сами назовут все эти проблемы и смогут договориться и найти пути их решения. Считать метрики можно автоматически, благо хватает инструментов. Я сам это настраивал для своих команд и больше никто не парился. Да, здесь подойдут все эти кайзены, гембы, аджайлы, скрамы, канбаны и прочее. Потому что эти подходы, методологии направлены на рациональный подход и борьбу с "bottleneck". Но чтобы применить эти практики нужно их понимать. А не говорить потом на всю Россию "Наш PM заставил нас приходить на 10 утра, на планерку и делать релизы каждые две недели, вместо 12 как было раньше. У нас Agile". Это опять все тот же пункт 1(C & C). Команда должна уметь договариваться, а в идеале решать сама о том как им удобнее работать и приносить результат.

Вывод. Подход 2 не работает для команд, которые не умеют работать самостоятельно и без надзора большого папочки. Да, команды можно обучать при помощи консультантов или так называемых Scrum мастеров, но не всем это помогает.

Сдается мне, вы говорите о бригадирах, экспедиторах и секретарях. Причем тут менеджер?

Александр Калугин про эту тему давно говорит:
http://pmarcor.com/2...uality-manager/
http://www.slideshar...ORP/ss-10493069

Александр Калугин про эту тему давно говорит:
http://pmarcor.com/2...uality-manager/
http://www.slideshar...ORP/ss-10493069

Александр описывает всю ту же классику подхода. В принципе такой ответ и хотел получить создатель топика.

Мой вопрос же в другом. Нужны ли вообще менеджеры? И смогут ли инженеры-профессионалы обойтись без них?

Мой вопрос же в другом. Нужны ли вообще менеджеры? И смогут ли инженеры-профессионалы обойтись без них?

По моему скромному мнению, никоим образом не могут. Но, но, но.

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

Может ли стать менеджером:
* технический писатель?
* слесарь?
* плотник?
* системный аналитик?
* бухгалтер?
* архитектор?
* пекарь?

Это ровно те же самые вопросы, что и "Были случаи, когда тестировщик становился PM'ом?"
Да были.

* Были случаи, когда технический писатель становился PM'ом.
* Были случаи, когда слесарь становился PM'ом.
* Были случаи, когда плотник становился PM'ом.
* Были случаи, когда системный аналитик становился PM'ом.
* Были случаи, когда бухгалтер становился PM'ом.
* Были случаи, когда архитектор становился PM'ом.
* Были случаи, когда пекарь становился PM'ом.

Вопрос, Что нужно, чтобы стать хорошим PM'ом?

Сергей, очень близко.

Добавлю еще один вопрос. Чем должен заниматься хороший PM?

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

Мы будем говорить о настоящих менеджерах.

Э. Голдратт:
"Улучшение потока [уменьшение Inventory] - это первичная задача операционного менеджмента".

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

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

Лично мне интересно было бы "разобраться" как и с тем, так и с другим... Однако думаю, что данной ветке речь все-таки идет о проектном менеджере.


ИМХО: из кого угодно, может получитсья кто угодно, при наличии физической возможности, и приложении к переходу максимума усилий...

Александр Калугин про эту тему давно говорит:
http://pmarcor.com/2...uality-manager/
http://www.slideshar...ORP/ss-10493069

Отлично, то, что и хотелось узнать!

ИМХО: из кого угодно, может получитсья кто угодно, при наличии физической возможности, и приложении к переходу максимума усилий...

Мне тоже нравится такой посыл. Но Адизес говорит, что не все так просто. Хотя может я просто его не дочитал? Кому интересно посмотрите http://www.ozon.ru/c...ail/id/5136706/

Но его модель PAEI не имеет никакого отношения к тому тестировщик или не тестировщик. А так же технический писатель, проектировщик GUI, ДБА, ...

Были случаи, когда тестировщик становился PM'ом? Это ровно тот же вопрос
"Зачем у хвоста кошка?" или "Чем тестирование по вторникам отличается от тестирования в agile?"
Да ничем не отличается. Бредовый вопрос. Нет "тестирования в agile". Есть просто тестирование. И уже сама формулировка, как правило, говорит о слабой подготовке докладчика. Или если хотите, это: "Намеренное введение в заблуждение, с целью получения profit". Кстати, я не сильно против. Пусть люди сходят хоть на такой доклад, чем вообще никуда не пойдут. Только переучивать их потом приходится...

Просто потрясающий ответ, жаль плюсануть некуда!