Комментарии 5
Но у заказчика были инструменты воздействия на меня в виде служебных записок с жалобами
А какая разница, что у него там было, если по итогу вы всё равно покинули компанию, т.е. вы всё равно ушли оттуда и больше там не работаете. Итог получился одинаковым в обоих случаях.
Как говорит пословица: Ездят на тех, кто возит. Из-за низкой самооценки и небольшого опыта на вас было проще всего ездить, что менеджеры и делали.
Второй момент. Для тех, кто не умеет говорить нет, как автор статьи. Говорите: "Да, хорошо. Создай в Jira задачу и напиши там подробно, что тебе необходимо. Когда задача пройдёт все этапы согласования и будет назначена на меня, то я её обязательно посмотрю."
В этом случае мы не говорим человеку прямое нет, а посылаем его по процессам, т.е. через внутреннюю бюрократию компании. Как итог, лишь 40% людей в реальности создадут для вас тикеты. Срочность задача тоже куда-то исчезнет, ведь ждать 3 дня согласований это норма в текущей компании. А торопить высокостоящих начальников менеджеры боятся, так что будут ждать сколько понадобится. Так что со временем вас станут больше ценить и перестанут на вас ездить. А олени, которые хотят протестировать функционал за 10 минут до релиза, будут его сами тестировать, т.к. сами просрали все сроки.
'Итальянская забастовка' бесценна, в остальном очень правильно описано, именно так и надо начинать выстраивать SDLC, иначе это не процесс, а бардак!
Логично писать служебные записки на сотрудника, который там работает. Бизнес-партнер это делал, пока я там работала. Не понимаю смысла вашего вопроса
Это применялось тоже. Возвращала задачи с плохим описанием. А еще есть расписание релизов, которые не ждут корректного описания, к сожалению. +давление со стороны бизнеса.
Человек, который присылал функционал на тестирование за 10 минут до релиза - врал о том, что протестировал. Хотя мы после его "тестирования" находили ошибки. + этот кейс уже был, где разраб говорил, что протестирует предрелизную сборку Android, но тут же поступал запрет от всех лидов :(
Данный проект (или даже заказчик) для меня был как поезд, который едет, и кто успеет запрыгнуть в него, тот успеет. Да и против такого поезда не попрешь. Было достаточно много попыток облегчить нагрузку: это и приоритеты, это и помощь со стороны аналитиков (они подключились почти под конец моего увольнения), и помощь в функциональном тестировании со сторон разрабов и прочее. Что только не применялось, но кол-во функционала на тестирование не уменьшалось. Вот единственное помогло:
это прочесывание задач проекта в целом (бизнес-аналитики вовсе не закрывали устаревшие задачи или пустые таски)
пояснение разработчику STLC в целом
ну и сборка тасок, которые отправляем в общий релизный контейнер от команды (БА собирали только задачи по свои направлениям)
Корень проблемы была не в тестировании, как я думала. А в менеджменте. В нашей команде не было менеджмента как целого механизма.
Один в поле воин или не воин? Когда ты один тестировщик на 9 разработчиков. Часть 2