Comments 16
Больше похоже на делегирование обязанностей. Но я наверное преувеличиваю. Ведь ваша же компания доплачивает за обязанности релиз-менеджера работнику по QA? Верно?
Естественно не будет доплат)
Это он здорово придумал, надеюсь никто не возьмёт себе на заметку, был уже такой опыт на проекте, ничем хорошим это не закончилось, все уволились)
"Как внедрить релиз-менеджмент в обязанности тестировщика"
Вы уже определитесь. То манагеров всех сортов слишком много и они ничо не делают, но деньги получают, то нужен манагер который будет всё делать.
Считаю что как отдельная должность это бесполезная трата ресурсов. Но человеку который берёт на себя такие обязанности должны даваться плюшки.
В большинстве компаний на самом деле так и работает, ты ведешь фичу до самого прода. Более того, уверен что в 90% не просто сделали фичу, отдали и забыли, а передают ее в готовом виде, объясняют контент-менеджерам и редакторам как с ней работать и т.д. Это все ведет к тому, что затраченное время на релиз с полностью подготовленными данными от ответственного QA быстрее и качественнее, нежели от человека, который просто релизить и будет бегать 10 раз к тебе с вопросами.
Не знаю о доплатах за эту нагрузку, т.к. работаю от аутстаф компании. Но во всяком случае, мне легче самому свои задачи выводить в прод, чем объяснять миллион настроек человеку, который только поверхностно погружен в проект, и не особо следит за его развитием. Релиз-менеджер как правило отвечает только за релизы, и ему не важно откуда они летят и с какой периодичностью. Здесь я выбираю качество, скорость и брать на себя ответственность.
Я вот работал в компании, где проще было самому исправить баги и сделать Pull Request. Чем описывать 100500 одинаковых дефектов в каждом модуле. Ведь разработчики код писали копи-пастой и один дефект с перечислением модулей их не устраивал, подавай на каждый модуль отдельный. Но это вообще не говорит о здоровой атмосфере в компании, а очень даже наоборот. Это всё прикольно, только когда тебе интересно получить некий опыт. А потом понимаешь, что твоя оплата вообще не соответствует уровню обязанностей.
Почему менеджеры получают много? Потому что они несут на себе ответственность за успех продукта/проекта. Уровень ответственности прямо пропорционален уровню оплаты.
Почему так много фейлов на практике компаний? Потому что, менеджеры либо некомпетентны, либо на отморозе сбрасывают ответственность на QA.
QA не бывает в состоянии принять верные решения, просто потому что не обладает всей информацией особенно про зависимости с другими модулями, проектами, подрядчиками и т.д.
Его просто никто никогда не позовет на митинги, где торгуются компании, без этой информации про стоимость и сроки - невозможно сделать правильного решения про релиз. Ты можешь сделать все как можно лучше, всех пригнать в обозначенные сроки, а потом узнать что в этом нет смысла, потому что модуль подрядчика будет через пол-года. Так с ним договорились.
Эта информация уровня минимум QA Manager, но ведь в вашей компании вообще нет такой роли, раз поднимается подобный вопрос. Release Manager выделенного может и не быть, если проектов не так много. Но эта роль должна быть на Project Manager или Product Owner в крайнем случае.
Да что там, QA даже priority багам не должны выставлять, только severity. Но я встречал единицы представителей бизнеса, которые бы нормально делали свою работу и отвечали за приоритеты и риски и занимались риск менеджментом.
Я думаю, хоть раз слышали про Triage дефектов?
Почему слово-то такое? Да потому что тут своя триада - бизнес, разработка, тестирование. И этот процесс означает совместный анализ дефектов. А как на практике? Ты QA - вот или сам и триаж. А потом получаются компании уровня Боинг, у которых что-нибудь отваливается в полёте.
И я не понял, какое отношение команда имеет к MTTR? Это вообще понятие из категории надёжности продукта. Время за которое продукт восстанавливает работоспособность в случае непредвиденной ошибки. Т.е. сколько времени пользователь не сможет воспользоваться продуктом после наступления ошибки.
Я бы рекомендовал ознакомиться хоть немного с ISTQB. Эти идеи массово витают в стартапах, банально в силу неграмотности. Но не работают на практике, для любого продукта с хоть сколь-нибудь существующей фазой его поддержки(Maintenance Phase).
Интересное суждение) Но у ПМ'ов вообще не будет времени на такое (по крайней мере сколько я сталкивался). Речь собственно о том, что QA ведет фичу от идеи до реализации, и релиз (как я считаю) это тот шаг, который нельзя перепрыгивать. Конечно же в разных компаниях свои порядки, где то доступы только на dev/qa стенды, где то есть доступы чуть ли не до БД прода, все отличается, но, в одном я точно уверен, если ты берешь на себя больше ответственности (при условии что вывозишь ее) - это твоя точка роста из линейного QA как минимум в лиды.
"проще было самому исправить баги и сделать Pull Request. Но это вообще не говорит о здоровой атмосфере в компании, а очень даже наоборот. Это всё прикольно, только когда тебе интересно получить некий опыт." - да, тут так и происходит) это не есть постоянная практика =)
Если релиз менеджер не делает свою работу, а получает деньги просто так. Это вообще не означает, что эту работу должен начать делать кто-то другой бесплатно. Просто нужно уволить такого релиз-менеджера.
Просто он должен был выработать метрики и настроить их автоматический сбор. Получить тест репорт от QA с разбивкой дефектов по кластерам и если это укладывается в рамки оговоренные в тест-плане. Например, 0% - critical/major defects, <10% - minor defects, <25% - cosmetic defect. Цифры указаны для примера и должны быть установлены для конкретного проекта. Сверил репорт с реферальными значениями, прошел по чек-листу, что остальные компоненты тоже не пропущены. Например, пользовательская документация, собран пакет, обновлены ссылки, версии, копирайта и т.д. и закрыл релиз. Тут не требуется глубоких знаний.
Или эти все операции - тоже QA выполняет?
Проблема в том, что это должен быть один человек. А тестировщиков на проекте как правило шибко больше чем 1. И каждый понимает как работает продукт в зоне своей ответственности. Лиды безусловно участвуют в процессе подготовки и выпуска релиза, и отдельная роль действительно опциональна, но если продукт сложный, и лидов больше одного, могут быть ньюансы.
Да, согласен, кто то не захочет брать на себя ответственность, но тут опять таки дело в загрузке, если у вас релиз 1-2 раза в неделю маленьким скоупом задач, то тут ничего сложного нет (как у меня на проекте). Если же команда работает по другой методике, и каждый релиз это 40-50 задач, тут конечно же сложнее. Но, опять же, легче отдать эту задачу трем QA которые без того затерли до дыр эти задачи и знают как "буквально в 1 клик" проверить их на стенде, чем отдать человеку огромную инструкцию (которую он будет читать и вникать 2+ часа), а потом еще и ходить по другим коллегам и спрашивать: "я это сделал, у меня не завелось..."
Все ближе к мечте разрабов чтобы тестеровщики находили баги, исправляли их и самостоятельно заливали исправленную версию
Тестировщик проверяет функциональность, знает все актуальные баги, их приоритеты и серьезность, и соответственно влияние на конечного потребителя. Это позволяет ему принимать обоснованные решения о готовности релиза.
Это большое, детское заблуждение.
Если не затруднит, можете дать развернутый комментарий по этому предложению? Интересно прочитать)
Ошибка в исходном предположении, которое основано на ваших допущениях.
Тестировщик (один или команда) вряд ли проверил ВСЮ функциональность и не факт, что знает все баги и состояние ПО. Он ЧТО-ТО проверил, не более. И поэтому он условно догадывается о готовности ПО к релизу, боится и сильно рискует.
Вешать на него ответственность за релиз — так же самонадеянно, как ребенок верит в то, что «папа может всë, что угодно».
«Смерть релиз-менеджера: Как тестировщики устроили тихий переворот в IT»