Судьи- сами сотрудники и их руководство. При этом для опытных сотрудников я стараюсь давать больше свободы- они сами предлагают идеи для собственного роста, тут я убиваю пару зайцев махом:
— могу взглянуть на амбиции сотрудника
— могу оценить скилл целеполагания сотрудника
т.е. узнать какие цели сотрудник считает достойными называться целями. Согласитесь, если укажет рутину, выполняемую и без целей ежедневно- это одно, а если поставит цель, которая потребует последовательных прыжков выше собственной головы- совсем другое.
Ну еще я ленивый в хорошем смысле слова, зачем придумывать самому, если дав сотруднику проявить инициативу и выказать доверие, можно утвердить интересные для него и полезные для компании цели:)
Мои личные цели на ближайшую и среднюю перспективы, например, следующие:
1. Настроить взаимодействие с отделом безопасников. В Mail.ru мы достаточно серьезно относятся к вопросам безопасности как на проектах моей зоны ответственности, так и в целом. Хочется поделиться опытом внедрения и обеспечения процессов качества с коллегами по цеху.
2. Наладить взаимодействие с технической поддержкой проектов моей и смежных зон ответственности. В компании уделяется немало внимания и приличное количество ресурсов на работу технической поддержки, но есть узкие места при взаимодействии отделов тех.поддержки, тестирования и разработки по заявкам пользователей. Хочется улучшить ситуацию в этом направлении.
3. Охватить процессами QA смежные проекты, где уровень обеспечения и контроля качества не столь высок, как на «родных». Тут и альтрустические корни, и желание сгладить углы в моментах интеграции нативных проектов со смежными.
Все три цели- моя личная инициатива, а не поставленные сверху, их я хочу добиться даже если к ним прибавятся целеуказания свыше.
А я ни одного слова по поводу Вашей проф.пригодности и не сказал, чтобы усомниться в ней тем более. Я переубеждать Вас не стану, если в Вашем «ваккумном мире» принято с плеча рубить без аргументов и фактов, то потом не удивляйтесь почему у Вас проблемы с кармой.
Тестировщики в нашей компании безусловно есть, но их распределение между проектами неравномерное. Т.е. где-то может быть 5-7 тестировщиков на проект, а где-то 1,5 землекопа специалиста по тестированию.
К тому же, в нашей работе есть такой момент, как невозможность нахождения всех дефектов. А также требования к качеству, которые определяют выделяемые ресурсы на нахождение большего процента дефектов на проекте.
Посему Ваш тезис весьма и аргументация к нему весьма спорны. Безусловно частный аргумент весьма вероятно имеет место быть (я, например, занимаюсь проектами Почта, Облако, Главная и рядом других, к играм не имеющих отношения, потому судить не берусь, но в свою очередь знаю, что многим играм в компании уделяется ОЧЕНЬ много внимания с точки зрения качества), но его применения к общему по меньшей мере неуместно, а по существу лишь показывает Ваши предположения касательно компании, но никак не «факты» и подтверждения.
Поэтому формулировки в духе «о каких еще тестерах может писать представитель Mail.ru, если у нас на руках есть факты» выглядят несуразно и поверхностно. Я вот, например, ни разу не встречал Вас в реальной жизни, но тем не менее не делаю скорполительных выводов уровня «Да это бот, тролль, скрипт», так как частное не является аргументом к общему:)
Вы же сейчас своими неосторожными формулировками ровняете с пустым местом несколько десятков специалистов по контролю и обеспечения качества, что работают в компании, лишь по тому, что на одном из сотен проектов уровень качества не соответствует ожиданиям конкретного пользователя (или пусть даже группы).
Согласитесь, это не показывает Вас, как аргументированного критика.
Это может быть как изучение каких-то более узких моментов в профессии — автоматизация тестирования, тест-дизайн, нефункциональное тестирование, или активностей менеджерских. Так и самостоятельное изучение какой-то области, инструмента, метода тестирования, с последующим тиражированием (сам факт тиражирования, т.е. тренерство так же отдельная наука которую можно изучать и учить). При этом могут быть и внутренние занятия, и внешние (например, получить теорию на внешнем тренинге, закрепить внутри компании на практике).
Для опытных KPI необходимы, как и для новичков, ведь это все равно, как не иметь цели по жизни и «жить ради жизни». Однако в силу опытности цели действительно несколько иные — выстроить процесс, поднять инфраструктуру и т.д.
Измеряемая цель упрощает достижение оной, как таковой. И опытность не может являться причиной отсутствия целей сотрудника. Слабо верится, что как только спортсмен получает МС, то он тренируется бесцельно и беззаботно, не ставя перед собой новые высоты и не добиваясь заветных результатов. Так и в работе независимо от профессионализма цели должны быть у всех и помогать, направляя в нужное русло, но не ограничивать.
Если пинг-понг массовый, то его обычно можно зарулить организацией встречи/обсуждения, или померить его средствами трекера, чтобы понять насколько это массовая проблема (иногда оказывается, что страдают этим вполне конкретные люди).
Недофикс в описанном кейсе вообще не возник бы, поставь тестировщик сразу два бага, а не объединяй он кучку в один репорт. Ну или если уж совсем невмоготу, то ставить в графе «ожидаемый результат» однозначную трактовку, несоответствие которой при проверке даст четкое понимание разрабочтику почему ему вернули ошибку на доработку. (Кстати количество таких возвратов тоже можно мерить, если массово).
Чтобы разработчики (менеджеры, админы, дирекция и т.д.) ставили понятные баги, достаточно при постановке тикета сделать минимальный шаблон для всех (тестировщикам жизнь упростит, а ксеносам путь истинный укажет), а также рядом поместить ссылочку на FAQ, если вдруг постановщик не в курсе происходящего:) Достаточно простого:
Нужно быть особо одарённым, чтобы стереть шаблон и написать отсебятину, или в рамках шаблона написать что-то запредельно непонятное, чтобы не удалось самостоятельно проверить исправление:)
Закрывать баги разработчикам вообще не рекомендуется, достаточно правами это ограничить, или настроить фильтр с выдачей багов, которые закрыли сами разработчики, для анализа менеджером/лидом/и т.д.
Трансформация бага в feature request вполне распространённая практика, хорошо работает в том случае, когда тестировщик (или другой участник) в состоянии сформулировать свою идею шире, чем просто «хочу-чтобы-было» и подкрепить аргументами.
Это и рабочими аспектами вызвано- много проектов, большая команда, сложные процессы, куча собственных задач и задач от руководства. И не рабочими тоже- у меня семья, сыну скоро 3 года, стараюсь побольше времени жене и сыну уделять, ремонт делаю, переезд готовим и т.п.
Кроме того, меняю немного профиль, обкатывая площадку QA-консалтинга, делаю аудиты в разных компаниях, помогаю с подбором кадров, читаю тренинги и мастер-классы. Аналогично, чтобы без помех основной работе, естественно.
В будущем, планирую вернуться к ремеслу, скрестив его с вышеобозначенными активностями. Все под флагом максимальной доступности для нишевых клиентов, которых год от года становится только больше. Ну и развивать это в ключе уютной небольшой кооперации единомышленников.
Ваш пример, не совсем корректен. Изначальный вопрос подразумевает слишком много вариантов ответов, лучше использовать тезисы имеющий полярные точки зрения. Т.е. перефразируя Ваш вопрос, будет уместно сыграть в эту игру с вопросом «Что ты больше любишь яблоки или бананы?»
Прием состоит в принудительной попытке принять сторону оппонента, найти доводы и аргументы самостоятельно, которые хоть сколько бы то ни было смогли бы служить базисом для принятия чуждой позиции.
Это учит слушать аргументацию оппонента, пытаться понять ее структуру и логику, а не отрицать банальным «мне все равно, что ты там говоришь, я знаю, что я прав». Эдакая интерпретация классического «поставь себя на его место».
В конечном итоге развитое умение слушать оппонента дает широчайшие возможности для того, чтобы основываясь на логике и структуре его доказательной базы разбить его утверждение в пух и прах. И делать это не только посредством собственных «неоспоримых» аргументов, но и ловя оппонента на слабостях его доказательств.
Если дополнить этот прием тем, что не только самостоятельно выстроить доказательную базу «противной» стороны решения, но еще и попытаться разбить оборону противника в этой игре (только он должен быть реальным сторонником идеи, т.е. близким по духу человеком), то это позволит в будущем при построении собственной линии доказательств быть максимально выверенным и стараться выдавать сильные аргументы, к которым сложно подкопаться даже самому.
==================================================================================== Приведу пример из работы:
PМ и QA Lead.
PМ: у меня есть задача, я хочу вбросить ее в итерацию, несмотря на то, что вы закончили «эти ваши регрессы», согласен? (т.е. либо за, либо против)
В обыкновении ситуация- кошмар и будни любого QA. Предположим, что QA Lead'у дана искусственная установка выбрать сторону «согласен» и дать возможность ее аргументировать.
Например, будет мысленно искусственно апеллировать к срочности, важности и большим финансовым рискам без этой задачи, т.е. использовать классической набор PМа, который «умирает без этой таски на живом».
Но вот, неувязочка, на деле-то задача стала срочной по вине самого РМа, который накосячил с планированием, ее важность сомнительна в аспекте скорой глобальной смены логики, затрагиваемой задачей, а финансовые риски и вовсе не подкреплены рассчетами, а взяты «из воздуха».
Узнать он это сможет, вернувшись в свое нормальное обличье, и задав правильные вопросы уровня «А чем вызвана срочность задачи?», «Почему она такая важная?», «Сколько мы потеряем без этой задачи в рублях?».
Если же QA не умеет принимать сторону оппонента, то он будет слепо стоять на своей позиции до потери пульса с криками «так нельзя, это неправильно» не вслушиваясь и даже не интересуясь в принципе аргументацией противоборствующей стороны.
+
Если усложнить игру, попыткой разбить собственную позицию. То получится что-то вроде такого продолжения.
QA1 — принимает искусственно сторону РМа. Хочет оспорить сторону QA2 (т.е. на деле оспорить свою собственную позицию).
QA2 — защищает позицию недопустимости вброса от позиции РМ'a.
QA1 спорит с другим QA2, из которого вместо «так нельзя» и «это неправильно» вытягивает конкретику уровня «Сколько времени уйдет на повторные регрессы?», «Есть ли ресурсы сократить сроки здесь и сейчас?», «Что нам сделать, чтобы в будущем быть готовыми к таким вбросам?» и т.д.
И уже вот тут QA1 начинает ловить самого себя (а в игре пока что QA2) на том, что на самом-то деле ресурсы есть, регрессы давно надо было автоматизировать, а чтобы вброс перестал быть вбросом начать участвовать в планировании задач наравне с аналитиками, разработчиками и менеджерами.
И для того, чтобы защитить изначальную позицию QA1 необходимы более весомые аргументы, желательно с демонстрациями и детализацией, которые послужат поддержкой для «времени уйдет очень много», «ресурсов совсем нет» и «не приходи больше с такими вбросами» (классичейский QA-коктейль).
На итоге же, практика в такие игры учит не только добиваться побед в спорах, отстаивая собственную позицию, ломая позицию оппонента. Но и видя слабость собственного утверждения уметь находить адекватный компромисс и договариваться с окружающими.
На фриланс меня подсадил изначально как раз непосредственный руководитель. А в одной из компаний на протяжении некоторого времени я официально работал в режиме 3 дня штат, 2 дня — аутсорсинг.
Работе в штате это никак не мешало, повторюсь, наоборот способствовало прямо и косвенно, например, новые знания/технологии/проекты давали возможность избавиться от замыленного взгляда при работе со штатными продуктами.
Общение с клиентами сильно зависит от типа взаимодействия, если, например, «под ключ» сотрудничали., то никаких проблем общаться вечерами не было. Если шла повременная оплата и резерв человеко-часов, то старался конечно сразу договориться на вечерние часы для коммуникаций или искали компромиссы с обедом или утренними часами (благо уже и не вспомню, когда последний раз работал в строгом график «пришел-ушел», всегда был ориентирован на результат).
Т.е. в целом преимущественно общался вечером, но бывало и днем, но опять же без ущерба для основной работы. Это, кстати, научило общаться в меру емко и по существу, когда речь о работе заходит. К тому же, я резко повысил эффективность собственного времени, так как вместо общения в чатиках и зависания в блогах и социалочках (пусть, кто не грешит этим бросит в меня клавиатуру) стал общаться с пользой для профессионального роста и своего бюджета:)
Уважаемый Neverln, прошу любезно, перечитайте пост. Фриланс 7+ лет совмещал с работой в штате на позициях от младшего тестировщика до нач.отдела разработки и тест-менеджера. В Rambler я не работал, в РБК был дважды, в Mail.ru тоже не с первого раза попал. Фриланс во многом поспособствовал карьере, открыв QA с точки зрения бизнес-заказчика, позволил понять процедуры, поработать с десятками самых различных продуктов и технологий. За что нанимают, стоит у работодателя спросить, наверное, но видимо есть за что, если берут.
Автоматизация применяется по разному- есть и UI тесты (over 1k) с фукидидом, дженкинсом, параллелизацией, экзекьюшенами в системе управления тест-кейсами и т.п. блэкджеком, есть API-автотесты (over 10k) с тимсити, опять же параллелизацией, собственными микро-сервисами и внушительным процентом покрытия. Есть автоматизация тестирования хранилищ и протоколов, немного мобильных приложений и еще куча мелочевки для регрессов. Возможно, эту тему осветим с коллегами отдельным постом.
Да это образно, не метрика это ни разу, я вообще тестированием занимаюсь и автоматизация тестирования далеко не самая сильная моя сторона, к тому же много- не значит качество, постигая азы различных языков в свое время, мои тренера как раз показывали мне то, как код из 100 строчек превратить в 40-50, способный выполнять ту же функцию, что и больший))
Да я и сам долго грешил тем, что не ставил эпических задач перед собой, после исправился и сейчас пожинаю плоды, ибо в офисной работе не всегда находится время для осуществления чего-то более глобального, чем рутинная работа в потоке, ибо сроками поджимают. качества просят и т.д., а в домашней обстановке сделать что-то большое и отстраненное от текучки много проще, главное желание и дял начала эти самые цели поставить.
Отличная статья, сам через все это в свое время прошел:)
И про микро-задачки здорово подмечено, и про домашних.и про лень, прям, как бы-то ни было банально, но +100500!
Добавлю парочку секретов собственного успеха на поприще фриланса (занимаюсь подобной работой с переменным успехом уже более 6 лет:)
Не рекламы ради, а толку для, рекомендую завести собственный трекер/ERP/CRM, я в частности использую Мегаплан. В нем можно и упомянуты tasklist вести и более глобальные вещи удобно хранить и использовать (документы, многочисленные ТЗ, аттачи, счета, доступы, клиентскую базу и много-много-много чего еще… пойду-ка набросаю пост о том, насколько и чем это удобно, спасибо за идею).
Вторая вещица, что заметно поспособствовала успешной работе, это планирование свое работы, Вы упомянули в статье про недельные наброски активности, но нередко на руку играют и более глобальные планы, вроде квартальных целей или хотя бы месячных, в духе «хочу изучить такую-то технологию», «хочу написать N строчек кода», «необходимо увеличить количество ежемесячных клиентов до N» и т.д., а затем уже микрошагами к ним идти. Без подобной штуки можно бесконечно долго «топтаться на месте» (естественно зависит от наклонностей человека), решая исключительно тактические задачи, забыв про стратегию, как таковую.
Ну а вообще если придерживаться вышеизложенных Вами приемов, то потом даже в офисной работе всему этому можно будет найти место, т.е. знания и навыки не будут утеряны, а порой и более того, будут только преумножаться в питательной до планктона среде;)
Ностальжи:) Ну там действительно плюс-минус, от компании зависело еще слегка. А так да, небо и земля прогресс за десятилетие! Дальше-больше, все в наших руках и головах ;)
Спасибо за идею! Постараюсьсделать, как только на наших проектах выведем эту процедуру на нормальный уровень, чтобы не пальцем в небо тыкать, а эмпирическим методом собрать наиболее кассовые правки и замечания к спецификациям в срезе хотя бы сотни протестированных документов:)
Если говорить о таких масштабах, то безусловно да, без адекватной спецификации или употребления «расширителей сознания/подсознания» такое воплотить в жизнь крайне сложно. Как правило у таких проектов всегда есть переходный период ломки, когда писать еще не начали, но не писать уже нельзя. Вот в этот момент нередко попадал в компании тестировщиком, пожалуй именно такие случаи и подвигли в свое время заняться тестированием документации.
Дальше-больше;) Проекты без спецификации- вот диво дивное для тестировщика (и в тоже время обыденность, как ни странно). В моей собственной компании по аутсорсингу тестирования ко мне то и дело приходят заказчики с просьбой протестировать их продукт «as is», без спецификаций, аналитиков и т.д. Вот тогда начинается самый ад, когда используя опыт предыдущих проектов и собственные знания по предмету проекта начинаешь писать баги по «домыслам и догадкам».
— могу взглянуть на амбиции сотрудника
— могу оценить скилл целеполагания сотрудника
т.е. узнать какие цели сотрудник считает достойными называться целями. Согласитесь, если укажет рутину, выполняемую и без целей ежедневно- это одно, а если поставит цель, которая потребует последовательных прыжков выше собственной головы- совсем другое.
Ну еще я ленивый в хорошем смысле слова, зачем придумывать самому, если дав сотруднику проявить инициативу и выказать доверие, можно утвердить интересные для него и полезные для компании цели:)
Мои личные цели на ближайшую и среднюю перспективы, например, следующие:
1. Настроить взаимодействие с отделом безопасников. В Mail.ru мы достаточно серьезно относятся к вопросам безопасности как на проектах моей зоны ответственности, так и в целом. Хочется поделиться опытом внедрения и обеспечения процессов качества с коллегами по цеху.
2. Наладить взаимодействие с технической поддержкой проектов моей и смежных зон ответственности. В компании уделяется немало внимания и приличное количество ресурсов на работу технической поддержки, но есть узкие места при взаимодействии отделов тех.поддержки, тестирования и разработки по заявкам пользователей. Хочется улучшить ситуацию в этом направлении.
3. Охватить процессами QA смежные проекты, где уровень обеспечения и контроля качества не столь высок, как на «родных». Тут и альтрустические корни, и желание сгладить углы в моментах интеграции нативных проектов со смежными.
Все три цели- моя личная инициатива, а не поставленные сверху, их я хочу добиться даже если к ним прибавятся целеуказания свыше.
А вот на личности я попрошу не переходить.
землекопаспециалиста по тестированию.К тому же, в нашей работе есть такой момент, как невозможность нахождения всех дефектов. А также требования к качеству, которые определяют выделяемые ресурсы на нахождение большего процента дефектов на проекте.
Посему Ваш тезис весьма и аргументация к нему весьма спорны. Безусловно частный аргумент весьма вероятно имеет место быть (я, например, занимаюсь проектами Почта, Облако, Главная и рядом других, к играм не имеющих отношения, потому судить не берусь, но в свою очередь знаю, что многим играм в компании уделяется ОЧЕНЬ много внимания с точки зрения качества), но его применения к общему по меньшей мере неуместно, а по существу лишь показывает Ваши предположения касательно компании, но никак не «факты» и подтверждения.
Поэтому формулировки в духе «о каких еще тестерах может писать представитель Mail.ru, если у нас на руках есть факты» выглядят несуразно и поверхностно. Я вот, например, ни разу не встречал Вас в реальной жизни, но тем не менее не делаю скорполительных выводов уровня «Да это бот, тролль, скрипт», так как частное не является аргументом к общему:)
Вы же сейчас своими неосторожными формулировками ровняете с пустым местом несколько десятков специалистов по контролю и обеспечения качества, что работают в компании, лишь по тому, что на одном из сотен проектов уровень качества не соответствует ожиданиям конкретного пользователя (или пусть даже группы).
Согласитесь, это не показывает Вас, как аргументированного критика.
Для опытных KPI необходимы, как и для новичков, ведь это все равно, как не иметь цели по жизни и «жить ради жизни». Однако в силу опытности цели действительно несколько иные — выстроить процесс, поднять инфраструктуру и т.д.
Измеряемая цель упрощает достижение оной, как таковой. И опытность не может являться причиной отсутствия целей сотрудника. Слабо верится, что как только спортсмен получает МС, то он тренируется бесцельно и беззаботно, не ставя перед собой новые высоты и не добиваясь заветных результатов. Так и в работе независимо от профессионализма цели должны быть у всех и помогать, направляя в нужное русло, но не ограничивать.
Недофикс в описанном кейсе вообще не возник бы, поставь тестировщик сразу два бага, а не объединяй он кучку в один репорт. Ну или если уж совсем невмоготу, то ставить в графе «ожидаемый результат» однозначную трактовку, несоответствие которой при проверке даст четкое понимание разрабочтику почему ему вернули ошибку на доработку. (Кстати количество таких возвратов тоже можно мерить, если массово).
Чтобы разработчики (менеджеры, админы, дирекция и т.д.) ставили понятные баги, достаточно при постановке тикета сделать минимальный шаблон для всех (тестировщикам жизнь упростит, а ксеносам путь истинный укажет), а также рядом поместить ссылочку на FAQ, если вдруг постановщик не в курсе происходящего:) Достаточно простого:
Нужно быть особо одарённым, чтобы стереть шаблон и написать отсебятину, или в рамках шаблона написать что-то запредельно непонятное, чтобы не удалось самостоятельно проверить исправление:)
Закрывать баги разработчикам вообще не рекомендуется, достаточно правами это ограничить, или настроить фильтр с выдачей багов, которые закрыли сами разработчики, для анализа менеджером/лидом/и т.д.
Трансформация бага в feature request вполне распространённая практика, хорошо работает в том случае, когда тестировщик (или другой участник) в состоянии сформулировать свою идею шире, чем просто «хочу-чтобы-было» и подкрепить аргументами.
Это и рабочими аспектами вызвано- много проектов, большая команда, сложные процессы, куча собственных задач и задач от руководства. И не рабочими тоже- у меня семья, сыну скоро 3 года, стараюсь побольше времени жене и сыну уделять, ремонт делаю, переезд готовим и т.п.
Кроме того, меняю немного профиль, обкатывая площадку QA-консалтинга, делаю аудиты в разных компаниях, помогаю с подбором кадров, читаю тренинги и мастер-классы. Аналогично, чтобы без помех основной работе, естественно.
В будущем, планирую вернуться к ремеслу, скрестив его с вышеобозначенными активностями. Все под флагом максимальной доступности для нишевых клиентов, которых год от года становится только больше. Ну и развивать это в ключе уютной небольшой кооперации единомышленников.
Прием состоит в принудительной попытке принять сторону оппонента, найти доводы и аргументы самостоятельно, которые хоть сколько бы то ни было смогли бы служить базисом для принятия чуждой позиции.
Это учит слушать аргументацию оппонента, пытаться понять ее структуру и логику, а не отрицать банальным «мне все равно, что ты там говоришь, я знаю, что я прав». Эдакая интерпретация классического «поставь себя на его место».
В конечном итоге развитое умение слушать оппонента дает широчайшие возможности для того, чтобы основываясь на логике и структуре его доказательной базы разбить его утверждение в пух и прах. И делать это не только посредством собственных «неоспоримых» аргументов, но и ловя оппонента на слабостях его доказательств.
Если дополнить этот прием тем, что не только самостоятельно выстроить доказательную базу «противной» стороны решения, но еще и попытаться разбить оборону противника в этой игре (только он должен быть реальным сторонником идеи, т.е. близким по духу человеком), то это позволит в будущем при построении собственной линии доказательств быть максимально выверенным и стараться выдавать сильные аргументы, к которым сложно подкопаться даже самому.
====================================================================================
Приведу пример из работы:
PМ и QA Lead.
PМ: у меня есть задача, я хочу вбросить ее в итерацию, несмотря на то, что вы закончили «эти ваши регрессы», согласен? (т.е. либо за, либо против)
В обыкновении ситуация- кошмар и будни любого QA. Предположим, что QA Lead'у дана искусственная установка выбрать сторону «согласен» и дать возможность ее аргументировать.
Например, будет мысленно искусственно апеллировать к срочности, важности и большим финансовым рискам без этой задачи, т.е. использовать классической набор PМа, который «умирает без этой таски на живом».
Но вот, неувязочка, на деле-то задача стала срочной по вине самого РМа, который накосячил с планированием, ее важность сомнительна в аспекте скорой глобальной смены логики, затрагиваемой задачей, а финансовые риски и вовсе не подкреплены рассчетами, а взяты «из воздуха».
Узнать он это сможет, вернувшись в свое нормальное обличье, и задав правильные вопросы уровня «А чем вызвана срочность задачи?», «Почему она такая важная?», «Сколько мы потеряем без этой задачи в рублях?».
Если же QA не умеет принимать сторону оппонента, то он будет слепо стоять на своей позиции до потери пульса с криками «так нельзя, это неправильно» не вслушиваясь и даже не интересуясь в принципе аргументацией противоборствующей стороны.
+
Если усложнить игру, попыткой разбить собственную позицию. То получится что-то вроде такого продолжения.
QA1 — принимает искусственно сторону РМа. Хочет оспорить сторону QA2 (т.е. на деле оспорить свою собственную позицию).
QA2 — защищает позицию недопустимости вброса от позиции РМ'a.
QA1 спорит с другим QA2, из которого вместо «так нельзя» и «это неправильно» вытягивает конкретику уровня «Сколько времени уйдет на повторные регрессы?», «Есть ли ресурсы сократить сроки здесь и сейчас?», «Что нам сделать, чтобы в будущем быть готовыми к таким вбросам?» и т.д.
И уже вот тут QA1 начинает ловить самого себя (а в игре пока что QA2) на том, что на самом-то деле ресурсы есть, регрессы давно надо было автоматизировать, а чтобы вброс перестал быть вбросом начать участвовать в планировании задач наравне с аналитиками, разработчиками и менеджерами.
И для того, чтобы защитить изначальную позицию QA1 необходимы более весомые аргументы, желательно с демонстрациями и детализацией, которые послужат поддержкой для «времени уйдет очень много», «ресурсов совсем нет» и «не приходи больше с такими вбросами» (классичейский QA-коктейль).
На итоге же, практика в такие игры учит не только добиваться побед в спорах, отстаивая собственную позицию, ломая позицию оппонента. Но и видя слабость собственного утверждения уметь находить адекватный компромисс и договариваться с окружающими.
Работе в штате это никак не мешало, повторюсь, наоборот способствовало прямо и косвенно, например, новые знания/технологии/проекты давали возможность избавиться от замыленного взгляда при работе со штатными продуктами.
Общение с клиентами сильно зависит от типа взаимодействия, если, например, «под ключ» сотрудничали., то никаких проблем общаться вечерами не было. Если шла повременная оплата и резерв человеко-часов, то старался конечно сразу договориться на вечерние часы для коммуникаций или искали компромиссы с обедом или утренними часами (благо уже и не вспомню, когда последний раз работал в строгом график «пришел-ушел», всегда был ориентирован на результат).
Т.е. в целом преимущественно общался вечером, но бывало и днем, но опять же без ущерба для основной работы. Это, кстати, научило общаться в меру емко и по существу, когда речь о работе заходит. К тому же, я резко повысил эффективность собственного времени, так как вместо общения в чатиках и зависания в блогах и социалочках (пусть, кто не грешит этим бросит в меня клавиатуру) стал общаться с пользой для профессионального роста и своего бюджета:)
Автоматизация применяется по разному- есть и UI тесты (over 1k) с фукидидом, дженкинсом, параллелизацией, экзекьюшенами в системе управления тест-кейсами и т.п. блэкджеком, есть API-автотесты (over 10k) с тимсити, опять же параллелизацией, собственными микро-сервисами и внушительным процентом покрытия. Есть автоматизация тестирования хранилищ и протоколов, немного мобильных приложений и еще куча мелочевки для регрессов. Возможно, эту тему осветим с коллегами отдельным постом.
P.s.: если есть вопросы оффтопом, можно в личку:)
И про микро-задачки здорово подмечено, и про домашних.и про лень, прям, как бы-то ни было банально, но +100500!
Добавлю парочку секретов собственного успеха на поприще фриланса (занимаюсь подобной работой с переменным успехом уже более 6 лет:)
Не рекламы ради, а толку для, рекомендую завести собственный трекер/ERP/CRM, я в частности использую Мегаплан. В нем можно и упомянуты tasklist вести и более глобальные вещи удобно хранить и использовать (документы, многочисленные ТЗ, аттачи, счета, доступы, клиентскую базу и много-много-много чего еще… пойду-ка набросаю пост о том, насколько и чем это удобно, спасибо за идею).
Вторая вещица, что заметно поспособствовала успешной работе, это планирование свое работы, Вы упомянули в статье про недельные наброски активности, но нередко на руку играют и более глобальные планы, вроде квартальных целей или хотя бы месячных, в духе «хочу изучить такую-то технологию», «хочу написать N строчек кода», «необходимо увеличить количество ежемесячных клиентов до N» и т.д., а затем уже микрошагами к ним идти. Без подобной штуки можно бесконечно долго «топтаться на месте» (естественно зависит от наклонностей человека), решая исключительно тактические задачи, забыв про стратегию, как таковую.
Ну а вообще если придерживаться вышеизложенных Вами приемов, то потом даже в офисной работе всему этому можно будет найти место, т.е. знания и навыки не будут утеряны, а порой и более того, будут только преумножаться в питательной до планктона среде;)