Как месячные и эрекция влияют на способность адекватно мыслить? У нас столько половозрелого неадеквата!!
Конечно, хочется отфильтровать, например, людей с IQ меньше 100 от голосования на выборах, но это не сильно будет отличаться от сегрегации по цвету кожи или от канцлагерей для неарийцев.
Вот в каких-то европейских странах только работающие граждане (платящие налоги) участвуют в выборах — это мне кажется разумнее.
ИМХО в софте значительно чаще обратная проблема, хотя и тоже за счёт усреднения: пытаются сделать продукт, который подходит ВСЕМ.
Запихивают в один и тот же продукт фичи для начинающих, опытных и профи, раскидывают всё это по дополнительным менюшкам с табами тройной вложенности, в итоге фиг найдёшь нужную фичу.
И проблема как раз в том, что пытаются сделать универсальный продукт, который полезен всем, вместо деления на разные категории целевой аудитории: корпоративных, домашних, профи, начинающих, и т.д.
Да-да! Ещё лучше, чем у меня, и чётче сформулировано :)
Не совсем понимаю, как это противоречит точке зрения powerman
Мне тоже кажется, что мы об одном и том же :)
Ведь мы знаем, что оценка покрытия — это то, что нужно ПМу для собственного успокоения, т.к. адекватность этой оценки может понимать только тестировщик.
Проблемы начинаются, когда приходит босс и говорит: «посчитайте мне что-то и назовите циферку». Ничего хорошего из этого не выходит обычно :))) А когда мы для себя измеряем, и смотрим по своим табличкам, что проверено, что нет, куда копать, что доделать, что актуализировать, что важнее всего по приоритетам — то это работа не на циферку, а на результат.
Наверное мы вообще об одном и том же говорим. На проектах, где я РМ, я мыслю как вы, и чиню анализ с анализа, а не с тестирования. А если я ТМ, то приходится мыслить совсем по-другому, и принимать внешние процессы как данность.
Давайте по-чесноку: тестирование это вообще не тот процесс, который нужен! Писался бы сразу идеальный код — не нужно было бы продукт верифицировать. Были бы идеальные и всем понятные требования — не нужно было бы валидировать. Уберите ошибки разработки и аналитики, и тестировщики просто не нужны!
Как только такое получится, вот тогда и заживём. А пока что тестировщики неизбежно компенсируют проблемы со всех этапов разработки.
Я поняла ваш подход, и спорить, правильный он или нет, не готова. Похоже на религиозный спор :) Мне кажется, что пока требования тестирования не удовлетворены, очень важно делать со своей стороны максимум, зависящий от нас, не прикрываясь внешними проблемами.
Я ни в коем случае не говорю, что налаживать другие процессы не нужно. Нужно! Конечно! Но когда в тестировании бардак, бегать и ругать аналитиков за нехватку требований, а разработчиков за нехватку юнит-тестов, у меня совести не хватит :))) А вот сделав всё от нас зависящее, уже можно и за другие процессы браться. Но, это не задача тестирования, изначально это всё-таки задача РМа. А нам что пришло, с тем и стараемся по максимуму работать.
Не поняла, если честно, ваше предложение :) Появляется на проекте тестировщик, на проекте нет нормальных требований. Что ему делать?
Бегать и махать руками «ах вы негодяи, поставьте мне все процессы, чтоб я мог нормально тестировать»?
Я смотрю с позиции специалиста по тестированию, и из двух десятков проектов последнего года, с которыми я работала, ни в одном не было хороших продуманных требований. Могу везде спихивать ответственность и говорить «постройте процессы», а могу компенсировать, насколько это возможно, со своей стороны. Наверное, оба подхода имеют право на существование, и выбирает каждый сам.
Акронис — офигенная компания с офигенной командой, всем понравилась! Из моего опыта карьеры это самое приятное воспоминание, сумасшедше интересный опыт там получила.
Kaspersky — в то время, когда я там была, там был ад с бюрократией в отделе качества, в остальных мне кажется было получше. Не уверена что сейчас так же, вряд ли такой ад мог быть 5 с лишним лет подряд.
Текущая компания — свой бизнес, а это мне интереснее карьеры. Акронис и Касперский хорошие компании, акронис больше для звёзд и челленджей, касперский больше для соц.пакета и стабильности, но задачи в обоих очень интересные.
И чой-та я такое не в личку пишу… Мало ли, вдруг ещё кому интересно будет :)
Поизучаю. Часть наших клиентов в телеграме, поэтому некоторые чаты переехали туда. Я сначала думала что на него нам и надо со скайпа переехать, но с опытом использования что-то не прониклась :(
Ну в РФ два проводных интернета почти везде и просто и дёшево, так что обычно делаем. А в Азии даже первый проводной обычно проблема — там мобильные надёжнее.
Тут сложно делить по ролям, т.к. в каждой компании РМ и РО вечно разные задачи выполняют :) Расскажу с точки зрения задач. Если говорить про управление распределённой командой, то разницы никакой. А вот если говорить про сбор требований с заказчика, то, конечно, к нему (заказчику) должен быть доступ.
В нашей компании есть только один свой собственный продукт и соответственно только один РО. Продукт не заказной, пользователей сейчас уже тысячи, к каждому всё равно не поедешь — общение идёт в почтах, форумах, скайпах, телеграмах и прочем.
Некоторые проекты, с которыми мы работаем — заказные, но РО не с нашей стороны. РО часто ездит к заказчику (1-2 раза в неделю, перед сдачей этапов почти каждый день). Но команды всё равно распределённые, так что основная его часть работы с командой всё равно в тех же мессенджерах.
+ У нас есть проекты по тестированию достаточно большие, где у заказчика есть офис и вся их команда сидит в одном месте. Тогда наш лид ездит к клиенту 1-2-3 раза в неделю, а по началу почти всё время работал там. Так мы решаем проблему, чтобы наша команда не потерялась, не оторвалась от общего процесса.
Конечно, хочется отфильтровать, например, людей с IQ меньше 100 от голосования на выборах, но это не сильно будет отличаться от сегрегации по цвету кожи или от канцлагерей для неарийцев.
Вот в каких-то европейских странах только работающие граждане (платящие налоги) участвуют в выборах — это мне кажется разумнее.
Запихивают в один и тот же продукт фичи для начинающих, опытных и профи, раскидывают всё это по дополнительным менюшкам с табами тройной вложенности, в итоге фиг найдёшь нужную фичу.
И проблема как раз в том, что пытаются сделать универсальный продукт, который полезен всем, вместо деления на разные категории целевой аудитории: корпоративных, домашних, профи, начинающих, и т.д.
Боже, люди, что вы делаете, и чему вы учите других людей???
Мне тоже кажется, что мы об одном и том же :)
Проблемы начинаются, когда приходит босс и говорит: «посчитайте мне что-то и назовите циферку». Ничего хорошего из этого не выходит обычно :))) А когда мы для себя измеряем, и смотрим по своим табличкам, что проверено, что нет, куда копать, что доделать, что актуализировать, что важнее всего по приоритетам — то это работа не на циферку, а на результат.
Как только такое получится, вот тогда и заживём. А пока что тестировщики неизбежно компенсируют проблемы со всех этапов разработки.
Я ни в коем случае не говорю, что налаживать другие процессы не нужно. Нужно! Конечно! Но когда в тестировании бардак, бегать и ругать аналитиков за нехватку требований, а разработчиков за нехватку юнит-тестов, у меня совести не хватит :))) А вот сделав всё от нас зависящее, уже можно и за другие процессы браться. Но, это не задача тестирования, изначально это всё-таки задача РМа. А нам что пришло, с тем и стараемся по максимуму работать.
Бегать и махать руками «ах вы негодяи, поставьте мне все процессы, чтоб я мог нормально тестировать»?
Я смотрю с позиции специалиста по тестированию, и из двух десятков проектов последнего года, с которыми я работала, ни в одном не было хороших продуманных требований. Могу везде спихивать ответственность и говорить «постройте процессы», а могу компенсировать, насколько это возможно, со своей стороны. Наверное, оба подхода имеют право на существование, и выбирает каждый сам.
Kaspersky — в то время, когда я там была, там был ад с бюрократией в отделе качества, в остальных мне кажется было получше. Не уверена что сейчас так же, вряд ли такой ад мог быть 5 с лишним лет подряд.
Текущая компания — свой бизнес, а это мне интереснее карьеры. Акронис и Касперский хорошие компании, акронис больше для звёзд и челленджей, касперский больше для соц.пакета и стабильности, но задачи в обоих очень интересные.
И чой-та я такое не в личку пишу… Мало ли, вдруг ещё кому интересно будет :)
В нашей компании есть только один свой собственный продукт и соответственно только один РО. Продукт не заказной, пользователей сейчас уже тысячи, к каждому всё равно не поедешь — общение идёт в почтах, форумах, скайпах, телеграмах и прочем.
Некоторые проекты, с которыми мы работаем — заказные, но РО не с нашей стороны. РО часто ездит к заказчику (1-2 раза в неделю, перед сдачей этапов почти каждый день). Но команды всё равно распределённые, так что основная его часть работы с командой всё равно в тех же мессенджерах.
+ У нас есть проекты по тестированию достаточно большие, где у заказчика есть офис и вся их команда сидит в одном месте. Тогда наш лид ездит к клиенту 1-2-3 раза в неделю, а по началу почти всё время работал там. Так мы решаем проблему, чтобы наша команда не потерялась, не оторвалась от общего процесса.