Хотел бы обратить ваше внимание на то, что для QA Аrchitect необходим огромный бекграунд, как и для QA Lead. В эти специальности нельзя вкатиться "с нуля"
Так какое же у "потолка", если это только начало пути... Заголовок не соответствует
Если ты линейный специалист отдела QA, то твой потолок, это грейд сеньора, а вот какие обязанности у него в работе (взял с первой же вакансии на HH)
"Чем предстоит заниматься:
Тестировать проект Hero Wars Dominion Era
Работать с тестовой документацией: написание, актуализация
Составлять схемы покрытия тестирования
Писать тест-кейсы
Коммуницировать с командой: разработчики, аналитики"
То есть, это базовые задачи QA, которые он должен делать хорошо. Вот для таких людей и написана эта статья, кто в течение нескольких лет выполняет базовые задачи и задумался о росте. Я рад за то, что с автоматизацией вы встретились в начале своей карьеры, и сожалею, что вы не принимаете иного развития QA специалистов, но поверьте, бывает, что годами люди занимаются одним и тем же, не зная, что можно прокачаться и в других направлениях)
Касаемо согласования, вопрос спорный. Представьте, что вы без предварительного согласования сделали кнопку за 10 минут, отправили задачу на проверку принимающей стороне, зада некоторое время у нее лежит, после чего, она ее смотрит (тоже тратит время время) и возвращает ее вам, вы ее снова правите, и снова двигаете задачу на проверку и хорошо, если ее со второго раза примут. В итоге выиграете ли вы этим что то, оставлю вопрос открытым
В текущем виде таблица - просто результат опроса команды
По горизонтали указаны все компетенции, которые так или иначе необходимы для работы на проекте, а тестирование лишь показывает, на сколько команда соответствует этим компетенциям. Матрица не обязует иметь в команде систему грейдирования, хотя и в моем случае она есть.
Обратите внимание на раздел с грейдами.
Джун, 1 ЛВЛа, должен знать все компетенции 1 приоритета на 2 балла
Джун 2 ЛВЛа, должен знать все компетенции 1 приоритета на 2+ балла и компетенции 2 приоритета на 2+ балла
Третий ЛВЛ, это мидл и он должен знать все компетенции 1 приоритета на 3+ балла и компетенции 2 приоритета на 2+ балла
4 ЛВЛ, это прокачанный мидл и он должен знать все компетенции 1 приоритета на 3+ балла и компетенции 2 приоритета на 2+ балла, а еще компетенции 3 приоритета на 2+ балла
5 ЛВЛ, это синьор, который должен знать все компетенции 1 приоритета на 3 балла и несколько на 4, так же компетенции 2 и 3 приоритета на 2-3 балла. Средняя оценка сотрудника 3.0+
6 ЛВЛ, это прокачанный синьор, который знает все компетенции 1 приоритета на 4 балла, так же компетенции 2 и 3 приоритета на 3 балла. Средняя оценка сотрудника 3.5
То есть тут указано, "какие навыки должны быть, чтобы соответствовать джуну, какие мидлу, и тд " - о чем вы как раз и пишете.
Я в комментарии выше как раз про это писал, что матрица показывает, на сколько навыки вашей команды соответствуют необходимым навыкам для работы над конкретным проектом, а вы уже решаете, что с этими данными делать и как эту информацию можно интерпретировать
Порой, смысла совершенно нет, например в маленькой команде или кросс проектной команде, так как в первом случае его обслуживание становится дорогим, а во втором он просто не будет работать, так как ему нужна подвязка к проекту. Отдельно хотел бы сказать, что это менеджерский инструмент и в идеале, доступ к нему есть только у Лида по понятным причинам.
Видит куда расти нужно?
Не совсем так. Это менеджер должен видеть, куда развивать своих спецов, если в этом есть потребность у компании. Согласно модели Ричарда Хакмана, одно из правил формирования команды, это возможность ее развития, и в этом нам помогает матрица, она показывает потенциальные возможности развития.
А есть ли для этого возможности в компании?
Прежде всего, я рекомендую (если вы менеджер) построить портрет команды, согласовать его с проектным менеджером, после чего вы увидите (не без помощи матрицы) на сколько команда соответствует портрету. Далее проводится очередной созвон, где обсуждаются возможности. В данном случае матрица отражает текущее положение дел.
Дали звание и что от этого сотруднику?
В некоторых командах, ЗП строго привязана к грейду, в этом случае, стоит структурировать навыки, чтобы как то систематизировать апгрейд.
Может он поймет, что нужно искать другое место?
Да, такое может быть. Если вы менеджер, такие кейсы стоит обрабатывать с помощью материальной или нематериальной мотивации сотрудника, хотя бывает и такое, что сотрудника уже не удержать или он перерос свое место, в этом случае нужно инициировать запуск поиска нового.
Так же хотел повторить свое послесловие, что многое зависит от мастерства самого менеджера. Вы тоже на это обратили внимание, что всем сотрудникам раздали звания и на этом все, менеджер не нашел инструменту другого применения (хотя может так выглядит только со стороны)
И закончить хотел бы вот чем
Согласно модели развития команды по Такману, "Расставание" это лишь один из этапов развития, так что, если вы чувствуете, что вы "переросли" команду, то вы, либо попали под эффект Даннинга — Крюгера, либо вам стоит двигаться дальше
Не обязательно. во всех проектах, над которыми я работал, существовала административная панель, содержащая в себе горячие клавиши, которые позволяли перейти на новую миссию и не проходить всю сюжетную линию. Это я и назвал "читами"
В продуктовую версию, доступную игрокам, этот функционал конечно не попадает.
Прежде всего речь идет о GDD (Game design document), внутри которых содержатся и требования , и доступность информации для пользователей и что либо еще.
Вы очень классно заметили, что я создал некую собирательную статью с перечнем свойств, которые документ может содержать, а может и нет. Например: "Обучение пользователей" - Если новый функционал не подразумевает обучение пользователей, то QA и не тестирует это свойство у документа, а если обучение нужно, то QA должен убедиться, что в GDD будет описано, как оно будет проходить и тд.
У этих видов документации разные цели и задачи, разная аудитория, по идее ее пишут разные люди и на разных этапах жизненного цикла продукта. Наверное и подходы к тестированию совершенно разные должны быть.
Вы абсолютно правы
Каким образом читы относятся к разработке доки тоже тема не раскрыта.
Попробую раскрыть более детально. Читы, это некие надстройки, которые дополнительно должен учитывать разработчик при создании нового функционала, следовательно на этапе декомпозиции и планирования (следующем то есть) он должен знать весь объем разработки. По этому еще при вычитке GDD стоит фиксировать и читы, так как потом этот объем работ будет сложнее учитывать (и дороже)
В идеале, выстроить хранение документации иерархическим образом, чтобы было прозрачно, где хранится какой документ. Для этого хорошо поможет Confluence например, он как раз обладает необходимым инструментарием. Следовательно QA желательно следить за тем, чтобы каждый документ лежал в соответствующем месте, согласно иерархии хранения
Хотел бы обратить ваше внимание на то, что для QA Аrchitect необходим огромный бекграунд, как и для QA Lead. В эти специальности нельзя вкатиться "с нуля"
Если ты линейный специалист отдела QA, то твой потолок, это грейд сеньора, а вот какие обязанности у него в работе (взял с первой же вакансии на HH)
"Чем предстоит заниматься:
Тестировать проект Hero Wars Dominion Era
Работать с тестовой документацией: написание, актуализация
Составлять схемы покрытия тестирования
Писать тест-кейсы
Коммуницировать с командой: разработчики, аналитики"
То есть, это базовые задачи QA, которые он должен делать хорошо. Вот для таких людей и написана эта статья, кто в течение нескольких лет выполняет базовые задачи и задумался о росте. Я рад за то, что с автоматизацией вы встретились в начале своей карьеры, и сожалею, что вы не принимаете иного развития QA специалистов, но поверьте, бывает, что годами люди занимаются одним и тем же, не зная, что можно прокачаться и в других направлениях)
Касаемо согласования, вопрос спорный. Представьте, что вы без предварительного согласования сделали кнопку за 10 минут, отправили задачу на проверку принимающей стороне, зада некоторое время у нее лежит, после чего, она ее смотрит (тоже тратит время время) и возвращает ее вам, вы ее снова правите, и снова двигаете задачу на проверку и хорошо, если ее со второго раза примут. В итоге выиграете ли вы этим что то, оставлю вопрос открытым
По горизонтали указаны все компетенции, которые так или иначе необходимы для работы на проекте, а тестирование лишь показывает, на сколько команда соответствует этим компетенциям. Матрица не обязует иметь в команде систему грейдирования, хотя и в моем случае она есть.
Обратите внимание на раздел с грейдами.
То есть тут указано, "какие навыки должны быть, чтобы соответствовать джуну, какие мидлу, и тд " - о чем вы как раз и пишете.
Я в комментарии выше как раз про это писал, что матрица показывает, на сколько навыки вашей команды соответствуют необходимым навыкам для работы над конкретным проектом, а вы уже решаете, что с этими данными делать и как эту информацию можно интерпретировать
@Lik7 Ответ для вас:)
Порой, смысла совершенно нет, например в маленькой команде или кросс проектной команде, так как в первом случае его обслуживание становится дорогим, а во втором он просто не будет работать, так как ему нужна подвязка к проекту. Отдельно хотел бы сказать, что это менеджерский инструмент и в идеале, доступ к нему есть только у Лида по понятным причинам.
Не совсем так. Это менеджер должен видеть, куда развивать своих спецов, если в этом есть потребность у компании. Согласно модели Ричарда Хакмана, одно из правил формирования команды, это возможность ее развития, и в этом нам помогает матрица, она показывает потенциальные возможности развития.
Прежде всего, я рекомендую (если вы менеджер) построить портрет команды, согласовать его с проектным менеджером, после чего вы увидите (не без помощи матрицы) на сколько команда соответствует портрету. Далее проводится очередной созвон, где обсуждаются возможности. В данном случае матрица отражает текущее положение дел.
В некоторых командах, ЗП строго привязана к грейду, в этом случае, стоит структурировать навыки, чтобы как то систематизировать апгрейд.
Да, такое может быть. Если вы менеджер, такие кейсы стоит обрабатывать с помощью материальной или нематериальной мотивации сотрудника, хотя бывает и такое, что сотрудника уже не удержать или он перерос свое место, в этом случае нужно инициировать запуск поиска нового.
Так же хотел повторить свое послесловие, что многое зависит от мастерства самого менеджера. Вы тоже на это обратили внимание, что всем сотрудникам раздали звания и на этом все, менеджер не нашел инструменту другого применения (хотя может так выглядит только со стороны)
И закончить хотел бы вот чем
Согласно модели развития команды по Такману, "Расставание" это лишь один из этапов развития, так что, если вы чувствуете, что вы "переросли" команду, то вы, либо попали под эффект Даннинга — Крюгера, либо вам стоит двигаться дальше
Хорошего дня!
Принял, учту в дальнейших статьях. Спасибо за рекомендацию
"По разделам"
Опечатка, прошу прощения :)
Не обязательно. во всех проектах, над которыми я работал, существовала административная панель, содержащая в себе горячие клавиши, которые позволяли перейти на новую миссию и не проходить всю сюжетную линию. Это я и назвал "читами"
В продуктовую версию, доступную игрокам, этот функционал конечно не попадает.
Вроде с утра не был :)
Прежде всего речь идет о GDD (Game design document), внутри которых содержатся и требования , и доступность информации для пользователей и что либо еще.
Вы очень классно заметили, что я создал некую собирательную статью с перечнем свойств, которые документ может содержать, а может и нет. Например: "Обучение пользователей" - Если новый функционал не подразумевает обучение пользователей, то QA и не тестирует это свойство у документа, а если обучение нужно, то QA должен убедиться, что в GDD будет описано, как оно будет проходить и тд.
Вы абсолютно правы
Попробую раскрыть более детально. Читы, это некие надстройки, которые дополнительно должен учитывать разработчик при создании нового функционала, следовательно на этапе декомпозиции и планирования (следующем то есть) он должен знать весь объем разработки. По этому еще при вычитке GDD стоит фиксировать и читы, так как потом этот объем работ будет сложнее учитывать (и дороже)
В идеале, выстроить хранение документации иерархическим образом, чтобы было прозрачно, где хранится какой документ. Для этого хорошо поможет Confluence например, он как раз обладает необходимым инструментарием. Следовательно QA желательно следить за тем, чтобы каждый документ лежал в соответствующем месте, согласно иерархии хранения
Читы, это некий функционал, который позволяет ускорить тестирование нового контента. Например чит код на выдачу оружия.