Точка входа будет, не телепатически же общаться. Точка входа может быть не фиксирована. Пример. У нас есть отдельная сервис команда - техспецы, в неросредственной близости от пользователей. С нами, командой разработки взаимодействие происходит так. При возникновении проблемы они напрямую пишут в мессенджер/телефон/почту любому нашему сотруднику, либо мне как роутеру по умолчанию. Каждый наш сотрудник является возможной точкой входа в команду, как и наоборот. И работаем так без привлечения менеджеров проектов.

иерархия будет всегда, не потому что нельзя без неё, можно и в анархию, просто если есть процесс - есть и иерархия

Иерархия будет всегда ибо так написано в военном уставе!

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

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

Прикинь.

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

Тут логический вывод бы подкорректировать. Я не говорю что во всей компании надо отменить иерархию обязанностей и принятия решений. Я говорю о том то не надо доводить её до абсурда на местах и обязательно выбирать кого-то из тестеров главным, потому что устав!

Макс, ну, я рад, что у вас это работает, пусть удача вас не покидает. Но, если честно, ты описываешь каку-то утопию.

Про устав Роман набросил. Я ничего такого не говорил.

я вообще ничего про устав не говорил, это Макс набросил )))

Я про то, что с таким подходом, который ты описал хрен найдёшь ответственного. И он будет работать только если сотрудники обладают большим уровнем ответственности и не умеют искажать информацию.

Я описываю нашу ежедневную работу. Мы работали и по иерархии через менеджеров. Тогда обработка кастомер кейса могла занимать ГОДЫ! Сейчас время первичной обработки и классификации сократилось до дня

Я про то, что с таким подходом, который ты описал хрен найдёшь ответственного. И он будет работать только если сотрудники обладают большим уровнем ответственности и не умеют искажать информацию.

А зачем у вас ищут ответственного и как часто? Чтобы наказывать?

Тут логический вывод бы подкорректировать. Я не говорю что во всей компании надо отменить иерархию обязанностей и принятия решений. Я говорю о том то не надо доводить её до абсурда на местах и обязательно выбирать кого-то из тестеров главным, потому что устав!

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

Нет. Есть человек, который обладает знаниями по проекту и делегирует задачи. То есть выполняет роль тимлида, коим и является.

Нет. Есть человек, который обладает знаниями по проекту и делегирует задачи. То есть выполняет роль тимлида, коим и является.

+++

А ещё он считает кипиаи и принимает решения.

«Ситуативно подчинённость может возникать по горизонтальному принципу, это качество гибкости системы управления» (из Википедии). Думаю, Max примерно об этом.

А ещё он приоритеты по тестам делает.

Ситуативная подчиненность есть и у нас. Макс про полное отсутствие иерархии.

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

У нас такое идёт по иерархии. От верхов к низам. Но виноват программист, который писал этот кусок кода, и тестер(ы) которые тестировали/регрессили функиональность.

А ещё он приоритеты по тестам делает.

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

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

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

это выставляется на этапе написания кейсов

Лолшто?

ну у тебя может не так, но кейсы пишутся соответсвенно требованиям, ревьювятся вместе (по хорошему) с девами и лидами и приоритетность их выполнения выставляется относительно требований

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

Прохождение тестов - как вариант ознакомления с продуктом. Для джуна.

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

прохождение тестов - да. приоритезация - это уже удел лида.

ну у тебя может не так, но кейсы пишутся соответсвенно требованиям, ревьювятся вместе (по хорошему) с девами и лидами и приоритетность их выполнения выставляется относительно требований

В идеальном мире так должно быть

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

нет кнеш, вы обновляете кейсы и обновляете значимость, why not?

нет кнеш, вы обновляете кейсы и обновляете значимость, why not?

И, соответственно, приоритеты смещаются.

именно так и есть

В идеальном мире так должно быть

Ах да, мы же в нём живём )

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

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

И да и нет. ты правильно всё говоришь, но здесь про другое сейчас разговор.

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

И да и нет. ты правильно всё говоришь, но здесь про другое сейчас разговор.

Ок, может быть выпал из темы. У вас тут всё быстро как-то >_>

Есть такое )

«Ситуативно подчинённость может возникать по горизонтальному принципу, это качество гибкости системы управления» (из Википедии). Думаю, Max примерно об этом.

Да, я об этом

Я не против ситуативной подчиненности. Это нормально.

Я работал с ней ,работаю и не вижу в ней плохого.

Ситуативная подчиненность есть и у нас. Макс про полное отсутствие иерархии.

Нет, я не за полное отсутсвие иерархии. Я говорю о том, что внизу, на уровне исполнения, она не является единственной и обязательной, как и KPI

Ну приехали.

Мы начали про наличие лида.

А скатились в исполнителей как-то.

Мы начали про обязательное требование назначения лида среди 5 тестеров

Исполнители тут у меня - это разработчики

а рядовые тестеры - не исполнители? 0_о

Тогда вопрос - исполнители чего?

Рядовые тестеры - это разработчики, Лёши на тебя нет

Привет всем, кто какие Test Management tools использует? У нас сейчас Zephyr, хотим поменять на что- то более удобное

Мы начали про обязательное требование назначения лида среди 5 тестеров

какая у вас структура команды? отдел кьюа выделенный, как у нас? тогда нужен лид, не выделенный - тогда лид может быть на 3+2 дев-кьюа, например

Привет всем, кто какие Test Management tools использует? У нас сейчас Zephyr, хотим поменять на что- то более удобное

сча вам скажут про TestRail и без меня, я рекомендую SmartBear QA Complete или InformUP TestUP

Ну да ладно. Ещё раз, исходный предмет спора - нужно или не нужно в группе из 5 тестеров выбирать формального лида. @RichardGears и @DJ_ZX утверждаете что обязательно нужно, ибо он должен быть единственной точкой входа в группу и ответсвенным за факапы всей группы. Я утверждаю что можно работать и без захаржкоденного лида.

Всё так.

Роман, спасибо;)

какая у вас структура команды? отдел кьюа выделенный, как у нас? тогда нужен лид, не выделенный - тогда лид может быть на 3+2 дев-кьюа, например

scrum, devteam = 3 кодера и 2 тестера, PO, PM, и много SME

Ну да ладно. Ещё раз, исходный предмет спора - нужно или не нужно в группе из 5 тестеров выбирать формального лида. @RichardGears и @DJ_ZX утверждаете что обязательно нужно, ибо он должен быть единственной точкой входа в группу и ответсвенным за факапы всей группы. Я утверждаю что можно работать и без захаржкоденного лида.

зависит от деталей проекта, у вас получилось - гуд, у меня вот при всей максимальной горизонтализации отношений в команде - всё равно без лида никак, неважно я или я в отпуске и кто-то вместо меня, особенно в аутсорсе, когда ещё и нужна стабильная точка контакте от кастомера к нам

scrum, devteam = 3 кодера и 2 тестера, PO, PM, и много SME

ну вот кто даёт приоритеты на 3 кодера и 2 тестера?

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

факт

зависит от деталей проекта, у вас получилось - гуд, у меня вот при всей максимальной горизонтализации отношений в команде - всё равно без лида никак, неважно я или я в отпуске и кто-то вместо меня, особенно в аутсорсе, когда ещё и нужна стабильная точка контакте от кастомера к нам

Естественно зависит от конкретного контекста. И решать в итоге автору вопроса. Я только делюсь опытом как оно может быть и без жесткой иерархии.

ну у нас в проекте в целом включая заказчика - 9 отделов только на фронтенд части

ну вот кто даёт приоритеты на 3 кодера и 2 тестера?

Приоритеты нам даёт PO. Кто какой конкретной задачей будет заниматься решаем сообща на планировании.

ок, 2 человека хотят одну задачу и не хотят другую

кто им скажет "ты то, а ты - то"? или камень-ножницы?

факт

Факт, для справки, это свершившемся обстоятельство. Мне никто не давал шанса попробовать =) когда я пишел на работу, у нас тоже была иерархия.

ERROR: S client not available

Она и сейчас есть, но я ее убрал правдами и неправдами оттуда, где она мешает

ок, 2 человека хотят одну задачу и не хотят другую

Мы не в песочнице детской, и гиков в команде у нас нет. Вопрос по другому ставится - кто лучше подходит к решению задачи в данном контексте, с учётом всего: навыков, отпусков, тп

а кто может определить навыки? вот "я сделаю эту таску за 20 часов", а "я за 18"?

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

У нас сейчас 2 отдела, функционирующих по описанному мной принципу - сервисы (20 человек) и разрабы (5). Годом ранее для одного из проектов таким Макаром я настроил работу четырёх команд: те же сервисы, сторонние тестеры-аутсорсеры (4), ещё одна скрам-команда (7) и нас самих тогда было 9. Никто не жаловался.

Макс, я говорю про > 10 человек.

коллеги, привет

а кто может определить навыки? вот "я сделаю эту таску за 20 часов", а "я за 18"?

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

вопрос к сообществу, интересно было бы послушать о вашем опыте

Ну вот опять же - у вас там своя атмосфера.

вопрос к сообществу, интересно было бы послушать о вашем опыте

Каком и в чём?

Макс, я говорю про > 10 человек.

Если представится возможность, я попробую и обязательно отпишусь про опыт =) Но смею заметить, то автор вопроса тоже говорил про 5, с не > 10

Да.

Ты очень избирательно споришь.

дано: сотрудник qa, который довольно медленно учится, с трудом проявляет творчество в своей работе, что, по моему мнению, для тестера очень важно то есть вдумчивость, усидчивость, старание имеются, а вот с исследовательским оголтелым тестированием, всякими нестандартными сценариями, багхантингом и прочими прелестями профессии беда ну вот вопрос: как развить недостающие качества? у кого-то опыт подобный был, возможно? кроме стандартного "курсы, книги, ментороство"

Спорю аргументировано и исхожу из начального тезиса

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

А как же ротация кадров? У нас компания большая, проектов много, некоторые совсем не долгосрочные, люди приходят на проект и уходят с него

А как же ротация кадров? У нас компания большая, проектов много, некоторые совсем не долгосрочные, люди приходят на проект и уходят с него

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

А как же ротация кадров? У нас компания большая, проектов много, некоторые совсем не долгосрочные, люди приходят на проект и уходят с него

Я не говорю об универсальном рецепте. Я говорю о частном случае.

Чтобы показать как ещё может быть.

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

ну у вас там и идиллия, у нас в команде в общем (с девами и кьюа и одминами) - около 40 человек у нас и ещё столько же на стороне заказчика, по разному пытались оптимизировать и мы и они и в результате всегда скатывались к большему числу лидов, вместо меньшего. но тут кнеш у нас ещё своя специфика - есть изолированные части проекта. а про 5+ - просто следить за командой в 4-5 человек - идеально, у меня было и 9 и 7 - ну вот 7 ещё более менее норм, но перебор местами. команда более менее стабильная. так вот как книжка пишет - 5 человек в группе - самое оно на 1 лида. причём лид может быть с уклоном в чистый менеджмент, быть скрам-мастером и ваще чо угодно, может быть девом, может кьюа, у нас все варианты, но вот когда лид, как @RichardGears забирает на себя работу с приоритетами, синхронизацию с другими лидами, точку входа от менеджмента или кастомера, а команда работает с упором на технические задачи и анализ - это получается отлично

И я устал на эту тему биться =) Теи более автор вопроса пропал, с без него это уже болтология.

дано: сотрудник qa, который довольно медленно учится, с трудом проявляет творчество в своей работе, что, по моему мнению, для тестера очень важно то есть вдумчивость, усидчивость, старание имеются, а вот с исследовательским оголтелым тестированием, всякими нестандартными сценариями, багхантингом и прочими прелестями профессии беда ну вот вопрос: как развить недостающие качества? у кого-то опыт подобный был, возможно? кроме стандартного "курсы, книги, ментороство"

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

с этим все понятно, и про курсы я упоминал

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

вопрос все-таки о другом

Вопрос в том как развить в человеке любознательность и свободу действий

Для начала - перестать бить =)

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

Для начала - перестать бить =)

фигня - иногда работает наоборот )))) но это уже зависит от того или есть у вас в команде мазохисты

дано: сотрудник qa, который довольно медленно учится, с трудом проявляет творчество в своей работе, что, по моему мнению, для тестера очень важно то есть вдумчивость, усидчивость, старание имеются, а вот с исследовательским оголтелым тестированием, всякими нестандартными сценариями, багхантингом и прочими прелестями профессии беда ну вот вопрос: как развить недостающие качества? у кого-то опыт подобный был, возможно? кроме стандартного "курсы, книги, ментороство"

Да не надо ничего решать. Сажай его на регрессию. У меня так чувак годами "регрессировал". посмотри на это с другой стороны: из раза в раз одно и то же проходить не у всех нервы выдержат )

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

Да не надо ничего решать. Сажай его на регрессию. У меня так чувак годами "регрессировал". посмотри на это с другой стороны: из раза в раз одно и то же проходить не у всех нервы выдержат )

++