Вспоминая прошедшие минскую SQA Days 12 и петербургскую SQA Days 13, по-хорошему завидую тем, кто в ноябре посетит очередную четырнадцатую, на этот раз в славном городе Львове, с новыми докладами и премьерным английским днем. Если вы еще не присоединились к тем, кому небезралично качество ПО и кто желает сделать мир лучше, у вас еще есть время.
А пока я хочу вспомнить свои старые выступления. Начнем с Питера, отзывы о котором я уже писал - вы можете почитать про первый и второй день. А теперь непосредственно текст моего доклада, переработанный и адаптированный под статью.
Довольно часто, очень хорошая идея приходит не прямо "из книжки" в готовом виде, но и из, на первый взгляд, неожиданного источника. Есть такой образовательный ресурс - http://www.coursera.org. Это онлайн-курсы по различным дисциплинам от ведущих университетов США, Англии и других стран. Число дисциплин более 30, а общее число онлайн-курсов - более 200 на текущий момент, и оно продолжает увеличиваться. Как работника ИТ-сферы, меня интересуют курсы по Computer Science и по менеджменту.
Один из представленных курсов - Grow to Greatness: Smart Growth for Private Businesses - рассказывает о росте команд в бизнесе. Принципы и факты о росте команд, озвученные харизматичным лектором Эдвардом Хессом, заинтересовали меня, я проанализировал свой опыт работы в командах тестирования, и решил рассказать об этом для вас.
За 5 лет работы в тестировании, я прошел стадии от момента, когда сам пришел и работал в команде QA из четырех человек, затем когда работал один QA на проекте (ситуация "сам себе начальник"), "пробивал" увеличение команды по тестированию в связи с увеличением проекта, и работа в новообразованной команде. Давайте рассмотрим переход, когда у вас уже есть опыт работы в команде (не лидом) либо как вы поработали как "тестировщик-одиночка", и перед вами стоит задача по формированию новой команды на стартующем проекте, либо расширение текущей в связи с увеличением круга задач по тестированию.
Я не буду рассматривать вопросы подбора, найма и адаптации персонала (могу порекомендовать литературу и полезные ссылки в этом направлении), в данном докладе мы рассмотрим сам факт, что команда увеличивается, и посмотрим, как нам сделать так, чтобы увеличение команды было не только количественным, но и качественным. Особенно это важно в самом начале, когда команда находится в стадии развития, людей совсем немного, и важно грамотно оценить свои возможности, чтобы не завалить процесс с самого начала.
Давайте сначала поговорим о том, что делать НЕ нужно, каким мифам нельзя верить.
Вы работали и набрали достаточно опыта, умеете отличать тест-кейс от тест-сета, знаете разницу между тестированием и проверкой, возможно, сдали на какой-нибудь красивый сертификат или успели поучаствовать в конференции. И хотя вы не Майкл Болтон, но кое-что в тестирование вы тоже знаете и умеете. И вы считаете, что будет легко управлять командой супергероев-Мстителей. Главное - найти их. Или вырастить. Но супергерои решают какую-то глобальную задачу, и им может оказаться "тесно" и не интересно на вашем проекте.
Еще одна обратная сторона медали - "эффект цунами". Слишком большой рост может поглотить людей, процессы и качество. Рассмотрим такую ситуацию, назовем ее "интерны". Вы один на проекте, и к вам добавляют трех способных рвущихся в бой джуниоров. Теперь ваша задача - не только самому протестировать, но и чему-то обучить джуниоров, дать задачи, проверить, скорректировать, мотивировать... Вполне может оказаться, что все ваше рабочее время будет уходить на управление джуниорами. Команда супергероев? Нет, это реклама МММ, или Moody Monkey Management - унылое управление обезьянками-тестировщиками.
Возможна и простая демотивация в коллективе. Если три человека работают успешно, затем приходит четвертый и начинает "не дорабатывать", то у других возникнет мысль "если он не работает и зарабатывает столько же, то зачем и мне напрягаться?"
Конечно, можно привести и контр-примеры, когда один человек "подталкивает", мотивирует другого, можно проводить парные "тест-сессии", исследовательское тестирование по методу "пилот-штурман", обмениваться полезным опытом... Как получать больше "положительных", нежели "отрицательных" последствий роста, мы поговорим во второй части.
Еще одно заблуждение, на этот раз количественное. Возникает соблазн - решить любую задачу увеличения объемов тестирования или расширения задач тестирования вводом новых сотрудников. Если мы, например, работаем в аутсорсе, можно пробовать "продать" больше тестирования, больше сотрудников заказчику. А это и новый опыт (управление командой 100500 человек) - красивая строчка в резюме, и осознание того, что мы работаем над чем-то действительно важным и масштабным, ведь не может же столько человек заниматься какой-то ерундой.
В реальности же, исследования роста, приведенные в курсе, показали, что:
- рост не означает преимущества. Далеко не всегда пять человек - лучше чем три, а привлечение двух новых сотрудников - лучше, чем одного.
- рост требует усиления управления командой. Это не время на выполнение тестирования, но без управления вы проиграете, как в притче про двух лесорубах. Или еще один пример, менеджеры-снежинки от Максима Дорофеева, у которых "руки там же, где и ноги". Что делать менеджеру-снежинке - здесь описан отличный кейс.
- рост происходит рывками, а не плавно. Спланировать процесс роста очень сложно, ситуация на проекте меняется, но подготовиться - можно.
Если провести еще одну аналогию, то мы не стремимся к исчерпывающему тестированию (оно не достижимо) - проверить все возможные комбинации, а к эффективному тестированию, используя методики белого и черного ящика. Меньшим количеством тест-кейсов мы достигаем лучшего покрытия всевозможных выходных значений программы. Так и в работе в команде.
С мифами мы разобрались. Теперь перейдем к конструктивной части. Далее мы рассмотрим универсальный инструмент для оценки риска роста и поговорим, как можно избежать вышеописанных проблем.
P.S. ссылка на вторую часть "Рост команд тестирования - мифы и реальность. Часть 2. Инструмент для оценки риска роста." - http://qastugama.blogspot.com/2013/09/2.html
А пока я хочу вспомнить свои старые выступления. Начнем с Питера, отзывы о котором я уже писал - вы можете почитать про первый и второй день. А теперь непосредственно текст моего доклада, переработанный и адаптированный под статью.
Как появилась эта тема.
Довольно часто, очень хорошая идея приходит не прямо "из книжки" в готовом виде, но и из, на первый взгляд, неожиданного источника. Есть такой образовательный ресурс - http://www.coursera.org. Это онлайн-курсы по различным дисциплинам от ведущих университетов США, Англии и других стран. Число дисциплин более 30, а общее число онлайн-курсов - более 200 на текущий момент, и оно продолжает увеличиваться. Как работника ИТ-сферы, меня интересуют курсы по Computer Science и по менеджменту.
Один из представленных курсов - Grow to Greatness: Smart Growth for Private Businesses - рассказывает о росте команд в бизнесе. Принципы и факты о росте команд, озвученные харизматичным лектором Эдвардом Хессом, заинтересовали меня, я проанализировал свой опыт работы в командах тестирования, и решил рассказать об этом для вас.
За 5 лет работы в тестировании, я прошел стадии от момента, когда сам пришел и работал в команде QA из четырех человек, затем когда работал один QA на проекте (ситуация "сам себе начальник"), "пробивал" увеличение команды по тестированию в связи с увеличением проекта, и работа в новообразованной команде. Давайте рассмотрим переход, когда у вас уже есть опыт работы в команде (не лидом) либо как вы поработали как "тестировщик-одиночка", и перед вами стоит задача по формированию новой команды на стартующем проекте, либо расширение текущей в связи с увеличением круга задач по тестированию.
Я не буду рассматривать вопросы подбора, найма и адаптации персонала (могу порекомендовать литературу и полезные ссылки в этом направлении), в данном докладе мы рассмотрим сам факт, что команда увеличивается, и посмотрим, как нам сделать так, чтобы увеличение команды было не только количественным, но и качественным. Особенно это важно в самом начале, когда команда находится в стадии развития, людей совсем немного, и важно грамотно оценить свои возможности, чтобы не завалить процесс с самого начала.
Давайте сначала поговорим о том, что делать НЕ нужно, каким мифам нельзя верить.
3 мифа о росте команд.
Миф 1. Любой рост - это хорошо.
Вы работали и набрали достаточно опыта, умеете отличать тест-кейс от тест-сета, знаете разницу между тестированием и проверкой, возможно, сдали на какой-нибудь красивый сертификат или успели поучаствовать в конференции. И хотя вы не Майкл Болтон, но кое-что в тестирование вы тоже знаете и умеете. И вы считаете, что будет легко управлять командой супергероев-Мстителей. Главное - найти их. Или вырастить. Но супергерои решают какую-то глобальную задачу, и им может оказаться "тесно" и не интересно на вашем проекте.
Еще одна обратная сторона медали - "эффект цунами". Слишком большой рост может поглотить людей, процессы и качество. Рассмотрим такую ситуацию, назовем ее "интерны". Вы один на проекте, и к вам добавляют трех способных рвущихся в бой джуниоров. Теперь ваша задача - не только самому протестировать, но и чему-то обучить джуниоров, дать задачи, проверить, скорректировать, мотивировать... Вполне может оказаться, что все ваше рабочее время будет уходить на управление джуниорами. Команда супергероев? Нет, это реклама МММ, или Moody Monkey Management - унылое управление обезьянками-тестировщиками.
Что получаем в итоге? Рост вызвал ухудшение процесса тестирования (вы не тестируете, ваша команда пока еще только учится, разбирается в продукте, производительность и качество их работы на данный момент ниже, чем ваша), причем изменения затронули, в первую очередь, вас. Вдобавок к этому, теперь вы отвечаете не только за себя, но и за команду - а следовательно, нужно контролировать выполнение задач. Как минимум. Клиент тоже недоволен - когда вы были один на проекте, было понятно, с кого спрашивать, а сейчас вы "багов не находите", а новые сотрудники еще "ничего не нашли". И кроме того, даже если после роста команды ваши роли и обязанности в команде более-менее перераспределились, то помните, что сейчас с вас субъективно будет больший спрос: раньше было - один тестировщик, что-то упустил. Плохо, но все мы ошибаемся. Теперь же ошибается и ответственность несет команда - в глазах вашего заказчика - каждый член команды QA пропустил этот баг. Другими словами, вы выходите на площадку с иным уровнем. Работа в одиночку - это "первая лига", работа в команде - "высшая лига". А готовы ли вы к "высшей лиге"?
Возможна и простая демотивация в коллективе. Если три человека работают успешно, затем приходит четвертый и начинает "не дорабатывать", то у других возникнет мысль "если он не работает и зарабатывает столько же, то зачем и мне напрягаться?"
Конечно, можно привести и контр-примеры, когда один человек "подталкивает", мотивирует другого, можно проводить парные "тест-сессии", исследовательское тестирование по методу "пилот-штурман", обмениваться полезным опытом... Как получать больше "положительных", нежели "отрицательных" последствий роста, мы поговорим во второй части.
Миф 2. Больше - значит, лучше.
Еще одно заблуждение, на этот раз количественное. Возникает соблазн - решить любую задачу увеличения объемов тестирования или расширения задач тестирования вводом новых сотрудников. Если мы, например, работаем в аутсорсе, можно пробовать "продать" больше тестирования, больше сотрудников заказчику. А это и новый опыт (управление командой 100500 человек) - красивая строчка в резюме, и осознание того, что мы работаем над чем-то действительно важным и масштабным, ведь не может же столько человек заниматься какой-то ерундой.
В реальности же, исследования роста, приведенные в курсе, показали, что:
- рост не означает преимущества. Далеко не всегда пять человек - лучше чем три, а привлечение двух новых сотрудников - лучше, чем одного.
- рост требует усиления управления командой. Это не время на выполнение тестирования, но без управления вы проиграете, как в притче про двух лесорубах. Или еще один пример, менеджеры-снежинки от Максима Дорофеева, у которых "руки там же, где и ноги". Что делать менеджеру-снежинке - здесь описан отличный кейс.
- рост происходит рывками, а не плавно. Спланировать процесс роста очень сложно, ситуация на проекте меняется, но подготовиться - можно.
Если провести еще одну аналогию, то мы не стремимся к исчерпывающему тестированию (оно не достижимо) - проверить все возможные комбинации, а к эффективному тестированию, используя методики белого и черного ящика. Меньшим количеством тест-кейсов мы достигаем лучшего покрытия всевозможных выходных значений программы. Так и в работе в команде.
Миф 3. Или расти, или умри.
Стиль решения любой проблемы - это принимать вызов. "Или расти, или умри". Либо наша команда тестирования растет, либо "умирает". И третьего не дано. Если мы любую проблему решаем количественным увеличением команды - мы снова в плену мифа номер 2. Если мы пытаемся просто "навесить" себе очередную задачу - превращаемся в "человека-снежинку", а потом - в "трухлявый пень" по Адизесу.
Напоминает ситуацию, когда маленького ребенка спрашивают: "Ты кого больше любишь, папу или маму?" Ребенок теряется, он видит лишь намеренно оставленные два варианта: выберешь папу - маму обидишь, и наоборот.
Решение в этом случае простое - возможно, вы попали в рамки своей игры, в которой есть якобы два варианта. Но "есть и другой выбор" (с) Трасса 60. Посмотрите на другие возможные варианты решения вашей проблемы, они наверняка имеются.
С мифами мы разобрались. Теперь перейдем к конструктивной части. Далее мы рассмотрим универсальный инструмент для оценки риска роста и поговорим, как можно избежать вышеописанных проблем.
P.S. ссылка на вторую часть "Рост команд тестирования - мифы и реальность. Часть 2. Инструмент для оценки риска роста." - http://qastugama.blogspot.com/2013/09/2.html
Комментариев нет:
Отправить комментарий