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

[DrVal]

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

[JimR]

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

Но могу предположить, что для такого человека при управлении понадобится Lead Programmer, по-крайней мере на первое время, пока он близко не познакомиться с продуктом и его реализацией.
В любом случае всё зависит от базовой поготовки человека. То есть, откуда он пришёл в тестирование. Одно дело - он программист по образованию, а другое - специалист текстильной промышленности.

Сильная сторона обычно является и слабостью. В данном случае можно предположить, что качество продукта будет контролироваться достаточно жёстко. Но это же означает, что возможна излишняя задержка при выпуске финальной версии.

Более подробно при такой постановке вопроса трудно что-то сказать.

[DrVal]

Так и вопрос праздный :-)

Просто большинство QA engineers знают, как грамотно управлять проектами.
Интересно, применяются ли эти знания на практике.

Более подробно при такой постановке вопроса трудно что-то сказать.

[rlabs]

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

Большинство QA engineers думают, что знают, как грамотно управлять проектами.

[JimR]

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

[innovator]

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

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

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

[kire]

Сорри, а можно тему повернуть на 180 градусов?
Знаете ли вы менеджеров проектов, ушедших в тестирование?

З.Ы. Я знаю одного.

[AlexSUN]

Знаете ли вы менеджеров проектов, ушедших в тестирование?

+1
Я тоже знаю одного - это я сам :)
Все свою карьеру (больше 10 лет) занимался внедрение 1С и ERP систем (Dynamix AX). Начинал как программер,затем аналитик , Ит-дир , РП.
Сейчас занимаюсь тестирование 1С, этим практически никто не занимается, тема только-только развивается. Да, денег поменьше, задачи помельче (иногда менеджер внутри просыпается и пытается давать советы менеджерам в проекте :)), но ..зато спокойнее, в отпуск можно сходить и без телефона под подушкой спать.

[Artemis]

Собственно, я знаю менеджеров проектов, выросших из тестировщиков.

+1
Тоже знаю такого человека. Работал с ним примерно год.
С ним работать было намного лучше, чем с некоторыми ПМ-ами, выросшими из девелоперов, даже, не смотря на то, что разница во времени была 10 часов
Из личных наблюдений: ПМ-ами чаще становятся/назначаются люди, имеющие опыт девелоперской работы, но они не всегда имеют навыки "менеджера" и результат порой бывает печальным

[solidox]

Тут точно играет человеческий фактор. У меня есть несколько знакомых менеджеров которые пришли из разных направлений. Считаю что менеджером может стать каждый что понимает процесс разработки того или иного продукта, а так же имеет гибкость в отношении тестировщиков и программеров. В принципе лучше работать в тандеме, а то и в тройке: Test Lead <- Project Manager -> Developer Lead

[Natalya Rukol]

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

В том, что я абстрагирована от разработки, вижу только плюсы: трезво оцениваю готовность и не надеюсь на чисто программерское "вот-вот завтра всё будет готово" :) Ну и естественно в моих проектах выделяется достаточное время на тестирование

[VikaCP]

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

[Фрося]

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

ага то-то потом вот читаешь в блоге
http://prgtest.blogs...og-post_12.html
(здесь же на сайте ссылка была)
и пытаешься понять -почему так все специфично....Вроде - все дааавно расписано в ЕСКД и прочем..
Теперь понятно - похоже, менеджер не является техническим специалистом... АГА...

Просто умилило - "Правильный ответ лучше всего получить в "продажном отделе""

Спаси меня Господи..от пожара... все же - пожарная сигнализация, а не сайт с виртуальным магазином.

[Natalya Rukol]

Просто умилило - "Правильный ответ лучше всего получить в "продажном отделе""

Спаси меня Господи..от пожара... все же - пожарная сигнализация, а не сайт с виртуальным магазином.

Автор писал про business-oriented тестирование, которого так не хватает гикам-технарям.

[Фрося]

Просто умилило - "Правильный ответ лучше всего получить в "продажном отделе""

Спаси меня Господи..от пожара... все же - пожарная сигнализация, а не сайт с виртуальным магазином.

Автор писал про business-oriented тестирование, которого так не хватает гикам-технарям.

Автор писал про систему пожарной безопасности.
Ежели комплект поставки системы пожарной безопасности надо узнавать в отделе продаж - беда полная.
И полное впечатление - что у автора некий пробел в представлении о разработки систем типа системы пожарной безопасности....
Что есть покупное изделие, и что с ним делать, когда оно входит в комплект поставки.
Грамотный ГиК из технарей по крайней мере знает - что есть приемосдаточные испытания, есть проверки по ТУ и прочая...

[Natalya Rukol]

Автор писал про систему пожарной безопасности.
Ежели комплект поставки системы пожарной безопасности надо узнавать в отделе продаж - беда полная.
И полное впечатление - что у автора некий пробел в представлении о разработки систем типа системы пожарной безопасности....
Что есть покупное изделие, и что с ним делать, когда оно входит в комплект поставки.
Грамотный ГиК из технарей по крайней мере знает - что есть приемосдаточные испытания, есть проверки по ТУ и прочая...

Автор привёл абстрактный пример и сделал абстрактное высказывание: тестовое покрытие определяется в первую очердь тем, кто и для чего покупает наш софт, как они его используют и т.д.

Если провести абстрактное деление тестировщиков на бизнес-ориентированных и ГИКов, то ключевые отличия где-то здесь:

Гик проверяет на соответствие стандартам и требованиям ВСЁ. Гику важны способы реализации. Гик приоритезирует дефекты и тесты на основании субъективных "хорошо" и "плохо". Гик больше внимания уделяет деталям. Гик реально заводит больше дефектов :)

Бизнес-ориентированный тестировщик не лезет в реализацию и детали. БО-тестировщик создаёт ментальную модель пользователя. БО-тестировщик приоритезирует тесты и дефекты исходя из значимости функционала для пользователя и регулярности использования. БО-тестировщик заводит МЕНЬШЕ дефектов, но именно те, на которые бы пожаловались пользователи.

И лично мне на самом деле всё равно, о каком продукте речь: система пожарной безопасности или браузерная игрушка. БО умеет определять важность функционала исходя из требований ПОЛЬЗОВАТЕЛЯ, а не АНАЛИТИКА. БО валидирует больше, чем верифицирует. И уж явно БО вникает в особенности использования СПБ, так что мне, как пользователю, должно быть не страшно :)

Надеюсь что я не слишком много додумала за автора. Надо бы его сюда пригласить :)

[LeshaL]

...
Если провести абстрактное деление тестировщиков на бизнес-ориентированных и ГИКов, то ключевые отличия где-то здесь:
...

Предлагаю делить тестировщиков на Чуков и Геков!

[saezar]

Доброго времени суток.
Действительно говорят - "Язык мой - враг мой", особенно когда пишешь в половину первого ночи...
Даже не знаю, обсуждение моего поста вызывает у меня смешанные чувства. Мне жаль, что у меня не получилось донести свою мысль внятно до всех читателей, что ж, теперь я буду писать строже подбирая слова. У меня вызывает улыбку восприятие моего примера в буквальном смысле, но зато понятно, что он был неудачным. И, наверное чтобы избежать в дальнейшем обвинений в "непрофессионализме", следует заполнить свой профиль поподробнее.
Пост касался тех, кого нелегкая (рука директора) сделала в один миг руководителем в незнакомой области. Это мой личный опыт, и я им делюсь. Я, тогда, на момент становления отдела тестирования, был в теме, 5 лет в пусконаладке и сопровождении, более 40 городов за спиной, а уж заказчиков в этих городах... Казалось бы, я все знаю о системе, знаю из чего состоит, где основные траблы, как поставить и настроить, ну в общем всё. И вот, я во главе сначала группы тестирования. Первый месяц общения с начальниками отделов железячных, программерских, продажных, проектных, и все - я больше ничего не знаю. Дело не в системе, она не изменилась, дело в отношении к ней. Например, железячники искренне считали, что контора продает железо, а софт идет к нему нагрузкой, ибо на это железо теоретически можно было поставить и сторонний софт. Программисты смеялись над железячниками и прописывали в систему сторонние устройства. Всё это хозяйство делалось под заказ из проектного отдела, который в визио состыковывал кубики стрелками, и думал, что это может работать, а точнее должно работать, потому что продажники уже это продали. Комплексным взглядом на систему не обладал никто. Это была когнитивная катастрофа для неокрепшего менеджера. Я решил подойти с той стороны, которая мне была лучше всего известна - от конечного пользователя. Как я писал выше - их чаяния я знал лучше чем кто либо.

"Ежели комплект поставки системы пожарной безопасности надо узнавать в отделе продаж - беда полная."

это правда. Комплектность нужно узнавать не там. Только речь не о комплектности, а о цельном взгляде на систему. Хорошо, когда все просто и понятно, мне не повезло, хотя, теперь я понимаю, что повезло :) Из первых месяцев своего руководства я вынес способность очерчивать рамки проекта.
Хотел поначалу ответить на язвительные замечания от Фроси, но передумал, срач в комментах мне не интересен, тем более на столь уважаемом мною форуме.

[saezar]

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

[VikaCP]

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

Вот именно это я и имела в виду, когда писала про то, что менеджер - это не обязательно крутой технический специалист. Он должен уметь видеть всю проблему целиком, он должен уметь находить компоромиссы между бизнес целями и качеством (когда вопрос о сроках поставки), он должен уметь быстро оценить степень критичности той или иной проблемы, учитывая бизнес цели и ожидания пользователей... Он должен уметь сплотить вокург себя людей, создать атмосферу команды. Ведь в крупных компаниях не даром существует две линейки карьерного роста: техническая и руководящая. Можно расти в сеньера, консультанта и так далее, а можно в тим лида, менеджера и т.п. Я лично знаю кучу примеров, когда супер спец ставился недальновидным руководством на позицию менеджера и там казался беспомощным и бесполезным. Но, как только его освобождали от повинности, он снова просто блистал в своей области знаний.
Фрося, почитайте Peopleware. Классика, как-никакю