Интересное суждение) Но у ПМ'ов вообще не будет времени на такое (по крайней мере сколько я сталкивался). Речь собственно о том, что QA ведет фичу от идеи до реализации, и релиз (как я считаю) это тот шаг, который нельзя перепрыгивать. Конечно же в разных компаниях свои порядки, где то доступы только на dev/qa стенды, где то есть доступы чуть ли не до БД прода, все отличается, но, в одном я точно уверен, если ты берешь на себя больше ответственности (при условии что вывозишь ее) - это твоя точка роста из линейного QA как минимум в лиды.
"проще было самому исправить баги и сделать Pull Request. Но это вообще не говорит о здоровой атмосфере в компании, а очень даже наоборот. Это всё прикольно, только когда тебе интересно получить некий опыт." - да, тут так и происходит) это не есть постоянная практика =)
Да, согласен, кто то не захочет брать на себя ответственность, но тут опять таки дело в загрузке, если у вас релиз 1-2 раза в неделю маленьким скоупом задач, то тут ничего сложного нет (как у меня на проекте). Если же команда работает по другой методике, и каждый релиз это 40-50 задач, тут конечно же сложнее. Но, опять же, легче отдать эту задачу трем QA которые без того затерли до дыр эти задачи и знают как "буквально в 1 клик" проверить их на стенде, чем отдать человеку огромную инструкцию (которую он будет читать и вникать 2+ часа), а потом еще и ходить по другим коллегам и спрашивать: "я это сделал, у меня не завелось..."
В большинстве компаний на самом деле так и работает, ты ведешь фичу до самого прода. Более того, уверен что в 90% не просто сделали фичу, отдали и забыли, а передают ее в готовом виде, объясняют контент-менеджерам и редакторам как с ней работать и т.д. Это все ведет к тому, что затраченное время на релиз с полностью подготовленными данными от ответственного QA быстрее и качественнее, нежели от человека, который просто релизить и будет бегать 10 раз к тебе с вопросами.
Не знаю о доплатах за эту нагрузку, т.к. работаю от аутстаф компании. Но во всяком случае, мне легче самому свои задачи выводить в прод, чем объяснять миллион настроек человеку, который только поверхностно погружен в проект, и не особо следит за его развитием. Релиз-менеджер как правило отвечает только за релизы, и ему не важно откуда они летят и с какой периодичностью. Здесь я выбираю качество, скорость и брать на себя ответственность.
Есть пример, когда мой коллега QA поправил код быстрее коллеги разработчика и более изящным способом, но он как будто не от мира сего, сверхчеловек какой то =)
Рад что вызвал положительные эмоции, спасибо! "Не хватит компетенций, не лезь, не твоё дело... " - никогда такого не слышал, но думаю меня бы это демотивировало. В любом случае, лично мое понимание этого самого качества - это не просто закрыть таску с комментом что все ок. Я привык еще и пойти показать эту фичу аналитикам или бизнесу, обсудить с лидом, завести 3-4 задачки на доработку и улучшение и отправить их бизнесу, а там уж пусть сами думают, хватит ли на это ресурсов или нет) От меня не убудет, а вот вовлеченность в проект, и то что душа болит за продукт - сразу на лицо)
Проект огромный, но у нас разные команды с разными подходами в управлении. Бывает такое, что просто необходимо срочным образом избежать всю бюрократическую рутину, и да, тут ты становишься на какую то долю и руководителем, и аналитиком - и идешь к бизнесу чтобы решать вопросики) Если рассматривать отдельно QA специалиста, то да, в основном это просто линейный сотрудник, который должен следить только за качеством фичей, но если у него появится чуть больше ролей (даже на капельку) это в любом случае облегчит работу большой команды. п.с. опять же, стоит учитывать первого комментатора и его фразу "везде своя кухня" =)
Да, ваше мнение полезно, и в большинстве я согласен с комментариями. Где то не так сформулировал, где то не договорил про формы коммуникации. Обязательно это учту в следующих постах и буду конкретнее писать, например, что не все бизнес-аналитики понимают что такое API и как оно работает =) Есть моменты с которыми частично не согласен, но это опять же упирается в "везде своя кухня", и процессы везде разные, не всегда они каноничны. В целом, спасибо за уделенное статье внимание, это мотивирует!
Если не затруднит, можете дать развернутый комментарий по этому предложению? Интересно прочитать)
Интересное суждение) Но у ПМ'ов вообще не будет времени на такое (по крайней мере сколько я сталкивался). Речь собственно о том, что QA ведет фичу от идеи до реализации, и релиз (как я считаю) это тот шаг, который нельзя перепрыгивать. Конечно же в разных компаниях свои порядки, где то доступы только на dev/qa стенды, где то есть доступы чуть ли не до БД прода, все отличается, но, в одном я точно уверен, если ты берешь на себя больше ответственности (при условии что вывозишь ее) - это твоя точка роста из линейного QA как минимум в лиды.
"проще было самому исправить баги и сделать Pull Request. Но это вообще не говорит о здоровой атмосфере в компании, а очень даже наоборот. Это всё прикольно, только когда тебе интересно получить некий опыт." - да, тут так и происходит) это не есть постоянная практика =)
Ваша позиция мне больше близка)
у меня есть товарищ, который так и делает (конечно же если там небольшие правочки, и хватает знаний языка)
Да, согласен, кто то не захочет брать на себя ответственность, но тут опять таки дело в загрузке, если у вас релиз 1-2 раза в неделю маленьким скоупом задач, то тут ничего сложного нет (как у меня на проекте). Если же команда работает по другой методике, и каждый релиз это 40-50 задач, тут конечно же сложнее. Но, опять же, легче отдать эту задачу трем QA которые без того затерли до дыр эти задачи и знают как "буквально в 1 клик" проверить их на стенде, чем отдать человеку огромную инструкцию (которую он будет читать и вникать 2+ часа), а потом еще и ходить по другим коллегам и спрашивать: "я это сделал, у меня не завелось..."
В большинстве компаний на самом деле так и работает, ты ведешь фичу до самого прода. Более того, уверен что в 90% не просто сделали фичу, отдали и забыли, а передают ее в готовом виде, объясняют контент-менеджерам и редакторам как с ней работать и т.д. Это все ведет к тому, что затраченное время на релиз с полностью подготовленными данными от ответственного QA быстрее и качественнее, нежели от человека, который просто релизить и будет бегать 10 раз к тебе с вопросами.
Не знаю о доплатах за эту нагрузку, т.к. работаю от аутстаф компании. Но во всяком случае, мне легче самому свои задачи выводить в прод, чем объяснять миллион настроек человеку, который только поверхностно погружен в проект, и не особо следит за его развитием. Релиз-менеджер как правило отвечает только за релизы, и ему не важно откуда они летят и с какой периодичностью. Здесь я выбираю качество, скорость и брать на себя ответственность.
ну тут я имел ввиду бизнес-аналитиков) которые пишут "как пользователь я хочу зайти на сайт и тыкнуть кнопочку"))
Есть пример, когда мой коллега QA поправил код быстрее коллеги разработчика и более изящным способом, но он как будто не от мира сего, сверхчеловек какой то =)
Рад что вызвал положительные эмоции, спасибо!
"Не хватит компетенций, не лезь, не твоё дело... " - никогда такого не слышал, но думаю меня бы это демотивировало.
В любом случае, лично мое понимание этого самого качества - это не просто закрыть таску с комментом что все ок. Я привык еще и пойти показать эту фичу аналитикам или бизнесу, обсудить с лидом, завести 3-4 задачки на доработку и улучшение и отправить их бизнесу, а там уж пусть сами думают, хватит ли на это ресурсов или нет) От меня не убудет, а вот вовлеченность в проект, и то что душа болит за продукт - сразу на лицо)
Проект огромный, но у нас разные команды с разными подходами в управлении. Бывает такое, что просто необходимо срочным образом избежать всю бюрократическую рутину, и да, тут ты становишься на какую то долю и руководителем, и аналитиком - и идешь к бизнесу чтобы решать вопросики)
Если рассматривать отдельно QA специалиста, то да, в основном это просто линейный сотрудник, который должен следить только за качеством фичей, но если у него появится чуть больше ролей (даже на капельку) это в любом случае облегчит работу большой команды.
п.с. опять же, стоит учитывать первого комментатора и его фразу "везде своя кухня" =)
Да, ваше мнение полезно, и в большинстве я согласен с комментариями. Где то не так сформулировал, где то не договорил про формы коммуникации. Обязательно это учту в следующих постах и буду конкретнее писать, например, что не все бизнес-аналитики понимают что такое API и как оно работает =)
Есть моменты с которыми частично не согласен, но это опять же упирается в "везде своя кухня", и процессы везде разные, не всегда они каноничны.
В целом, спасибо за уделенное статье внимание, это мотивирует!
Спасибо за статью!