Комментарии 8
Это все очень хорошо, но у меня вопрос — а если QA на проекте это жена PMа, истерично пишущая в общий чат «Почему мне никто не отвечает!!!!!!!!111111111»?
Спасибо за статью. Заинтересовал момент:
Как реализуется эта договоренность? На какой проект вы тратите это время? Для чего нужна эта договоренность, если руководитель может просто доверять, что подчиненные делают нужное?
договорённость с руководителем, что до 20% времени я могу тратить на свой проект
Как реализуется эта договоренность? На какой проект вы тратите это время? Для чего нужна эта договоренность, если руководитель может просто доверять, что подчиненные делают нужное?
Естественно в процессе договоренности никто не следит за таймингом :) С одной стороны, в нашей команде есть бэклог задач для QA, отсортированный по приоритету задач. Команда QA ответственна за поддержание количества задач бэклога на определенном уровне. С другой стороны, каждый участник команды имеет свои проекты, связанные с улучшением внутренних инструментов. Проект иницируется, ведется и продвигается самим QA – в этом плане полная самоорганизация.
Возникает, если можно так сказать, небольшой конфликт интересов между тем, что “надо” делать (бэклог), и тем, что “хочется” делать (проект). Небольшая ремарка – в бэклоге также интересные задачи – но вы выбираете между двумя вещами “работа на ковейере” — “ведение проекта/разработка”. Команда заинтересована в пустом бэклоге, вам хочется самовыражатся. Руководитель заинтересован в том, чтобы у сотрудника соблюдался баланс между “надо/хочу” — потому что совсем убрать “надо” — означает, что участник не вносит вклад в работу, совсем убрать “хочу” — означает выгорание и демотивацию сотрудника.
Процесс договоренности происходит следующим образом. На тет-а-тет получасовом митинге с руководителем (у нас он проходит ежемесячно), мы обсуждаем успехи и трудности и примерно закладываем скоуп работ на следующий месяц. Например, руководитель может сказать “у тебя очень хорошая производительность, так держать”, “или, ты немного просел по задачам, были ли какие-то трудности возможно требуется помощь с какими-то задачами” — это видно по тому как вы работаете над задачами из бэклога. Я в свою очередь могу сказать, что “с задачами я справляюсь, есть идея оптимизировать такой то процесс, поэтому я могу в следующем месяце немного просесть по задачам из бэклога, с учетом общего состояния команды примерно насколько я могу просесть по бэклогу и поработать над своими задачами?”. Руководитель организует команду таким образом (следит за соотношением активные девелоперы, активные qa, состав задач в бэклоге), что каждый может просесть по бэклогу примерно на 20% от показателей, как если бы он стоял беспрерывно на конвейре бэклога.
Ответ на ваш вопрос: эта договоренность осуществляется за счет такой организации команды руководителем, что 20% моего времени закладывается на мои собственные задачи.
Вторая часть про проекты, какие они? Все типы проектов описаны в статье в классификации тулов. Я люблю различные “нечестные” методы: моки, стабы, а также форматтеры. Из больших проектов — это генерация кастомных чеков для платежей Apple, девел стаб для нотификаций мобильных операторов. У других коллег есть проекты по диагностике девельного окружения, есть пет-проекты по ведению документации с помощью майнд-мэпов, есть проекты по написанию плагинов для автотестов.
Из больших проектов один был подробно описан здесь (https://habr.com/en/company/badoo/blog/460667/ ) – он получился очень масштабным, потому что были привлечены разработчики клиентской части и команда автоматизации. Точнее внутри каждого из отделов назревала необходимость этих изменений, но никто не закладывал это в основной скоуп работ, потому что бизнесу было не до этого, в итоге когда выяснилось, что всем это надо, все это втихую делают, и делают примерно одно и то же – случился эффект синергии и произошел прорыв в качестве работы без просадки по основным задачам. Аналогичная история произошла с диагностикой девельного окружения — проект родился в голове одного из участников команды, затем был и подключены разработчики платформы, отдельных компонент.
Случается и обратная ситуация, когда синергии не возникает, у меня такое было с девел стабами мобильных операторов, я сделал инструмент под себя, когда начали привлекать другую команду, они сказали, “мы за честные методы, хотим песочницы”. Поэтому 20% — это очень разумная цифра, этого времени достаточно, чтобы оставаться в фокусе работы над проектом, это время не позволяет просесть по основным задачам, это время позоляет покрыть риск, если не возникнет синергии. Если будет больше времени — вы можете просесть по основным задачам, если меньше – просто будете терять фокус при работе над задачей
Возникает, если можно так сказать, небольшой конфликт интересов между тем, что “надо” делать (бэклог), и тем, что “хочется” делать (проект). Небольшая ремарка – в бэклоге также интересные задачи – но вы выбираете между двумя вещами “работа на ковейере” — “ведение проекта/разработка”. Команда заинтересована в пустом бэклоге, вам хочется самовыражатся. Руководитель заинтересован в том, чтобы у сотрудника соблюдался баланс между “надо/хочу” — потому что совсем убрать “надо” — означает, что участник не вносит вклад в работу, совсем убрать “хочу” — означает выгорание и демотивацию сотрудника.
Процесс договоренности происходит следующим образом. На тет-а-тет получасовом митинге с руководителем (у нас он проходит ежемесячно), мы обсуждаем успехи и трудности и примерно закладываем скоуп работ на следующий месяц. Например, руководитель может сказать “у тебя очень хорошая производительность, так держать”, “или, ты немного просел по задачам, были ли какие-то трудности возможно требуется помощь с какими-то задачами” — это видно по тому как вы работаете над задачами из бэклога. Я в свою очередь могу сказать, что “с задачами я справляюсь, есть идея оптимизировать такой то процесс, поэтому я могу в следующем месяце немного просесть по задачам из бэклога, с учетом общего состояния команды примерно насколько я могу просесть по бэклогу и поработать над своими задачами?”. Руководитель организует команду таким образом (следит за соотношением активные девелоперы, активные qa, состав задач в бэклоге), что каждый может просесть по бэклогу примерно на 20% от показателей, как если бы он стоял беспрерывно на конвейре бэклога.
Ответ на ваш вопрос: эта договоренность осуществляется за счет такой организации команды руководителем, что 20% моего времени закладывается на мои собственные задачи.
Вторая часть про проекты, какие они? Все типы проектов описаны в статье в классификации тулов. Я люблю различные “нечестные” методы: моки, стабы, а также форматтеры. Из больших проектов — это генерация кастомных чеков для платежей Apple, девел стаб для нотификаций мобильных операторов. У других коллег есть проекты по диагностике девельного окружения, есть пет-проекты по ведению документации с помощью майнд-мэпов, есть проекты по написанию плагинов для автотестов.
Из больших проектов один был подробно описан здесь (https://habr.com/en/company/badoo/blog/460667/ ) – он получился очень масштабным, потому что были привлечены разработчики клиентской части и команда автоматизации. Точнее внутри каждого из отделов назревала необходимость этих изменений, но никто не закладывал это в основной скоуп работ, потому что бизнесу было не до этого, в итоге когда выяснилось, что всем это надо, все это втихую делают, и делают примерно одно и то же – случился эффект синергии и произошел прорыв в качестве работы без просадки по основным задачам. Аналогичная история произошла с диагностикой девельного окружения — проект родился в голове одного из участников команды, затем был и подключены разработчики платформы, отдельных компонент.
Случается и обратная ситуация, когда синергии не возникает, у меня такое было с девел стабами мобильных операторов, я сделал инструмент под себя, когда начали привлекать другую команду, они сказали, “мы за честные методы, хотим песочницы”. Поэтому 20% — это очень разумная цифра, этого времени достаточно, чтобы оставаться в фокусе работы над проектом, это время не позволяет просесть по основным задачам, это время позоляет покрыть риск, если не возникнет синергии. Если будет больше времени — вы можете просесть по основным задачам, если меньше – просто будете терять фокус при работе над задачей
Привет. Спасибо за статью!
Можешь скинуть альтернативную ссылку чтобы посмотреть видео?
«третьим заблуждениями я подсмотрел на конференции TestBash в Мюнхене (для просмотра доклада нужно зарегистрироваться на сайте ministryoftestingorg.com, но там есть бесплатный пакет).»
www.ministryoftesting.com/dojo/lessons/qualitative-risk-based-test-reporting-nancy-kelln — похоже теперь только для pro member и платно.
Можешь скинуть альтернативную ссылку чтобы посмотреть видео?
«третьим заблуждениями я подсмотрел на конференции TestBash в Мюнхене (для просмотра доклада нужно зарегистрироваться на сайте ministryoftestingorg.com, но там есть бесплатный пакет).»
www.ministryoftesting.com/dojo/lessons/qualitative-risk-based-test-reporting-nancy-kelln — похоже теперь только для pro member и платно.
Да, действительно так (теперь только для про) – очень жаль. Сейчас у меня в доступе есть только подкаст с Нэнси, где она рассказывает про это же www.spreaker.com/user/softwaretestpro/nancy-kelln-spring-2020 – примерно с 17:05, когда интервьюер спрашивает про risk-based report.
Попробую найти все таки полноценное выступление, в подкасте вся базовая информция в сжатом виде, но Нэнси помимо всего прочего – отличный спикер и в выступлении у нее много полезных примеров.
Попробую найти все таки полноценное выступление, в подкасте вся базовая информция в сжатом виде, но Нэнси помимо всего прочего – отличный спикер и в выступлении у нее много полезных примеров.
Нашел! register.gotowebinar.com/register/6396514850757757197 , регистрация на вебинар бесплатная
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
QA — специалист по пожарной безопасности вашего проекта