Я выступила с докладом о методе xBTM на конференции STARWest 2011. В зале присутствовал Джон Бах, который дал нам ряд полезных рекомендаций.

Недавно я тестировала версию 1.5 инструмента для управления сессионным тестированием STBTExecute. Команда хотела выпустить приложение как можно быстрее, а так как я тогда путешествовала, времени на тестирование почти не оставалось. Мы решили, что я буду тестировать финальную версию в течение четырех часов, и я выбрала xBTM-подход для тестирования. В этом посте я проведу вас через четыре часа тестирования при помощи этого метода, и расскажу о результатах.

Тест-план

Я начала с создания ментальной карты, которая служила мне тест-планом. Я предпочитаю XMind для этих целей. Вначале я создала новую карту и сделала наше приложение – SBTExecute – центральной темой. Несколько минут я размышляла над очевидными подразделами для этой темы и придумала следующие:

• Конфигурация
• Документация
• Запуск
• Импорт
• Генерация
• Отчетность.

Я добавила шесть этих подразделов на карту, после чего решила добавить стресс-тестирование:

Ментальная карта как тест-план. Центральная тема — наше приложение, подразделы – ключевые области или техники тестирования. В них группируются цепочки тестирования.

Затем я потратила минут двадцать, размышляя над идеями для тестирования (цепочками), и записывая их в соответствующей области ментальной карты. Так как тестировала я это приложение не впервые, у меня уже был ряд готовых идей. Итак, через примерно полчаса мой тест-план был готов.

Тестирование

Я начала с функции импорта, так как она ключевая для приложения. Если информация из отчетов о сессиях не импортируется – можно дальше не проверять. Я оценила цепочки в разделе «импорт» как укладывающиеся в сессию длиной в 45 минут. Чтобы отметить это в плане, я поменяла цвет всех этих цепочек на синий:

Тестирование всех цепочек раздела «Импорт» в течение одной сессии

Отчеты о сессиях я пишу в шаблоне SBTExecute для Excel, и использую функционал ментальной карты, чтобы привязать отчетность к плану тестирования. Иконка желтого листочка у раздела «Импорт» показывает, что для раздела есть заметка, которую можно просмотреть и отредактировать по клику на иконке:

Добавление заметок в программе создания ментальных карт. Заметка указывает на соответствующий отчет о сессии.

Я начала сессию тестирования, делая в процессе пометки в отчете. Как только я понимала, что тестирование какой-либо цепочки можно завершать, я добавляла зеленую иконку «проверено» на ментальную карту. Во время сессии я поняла, что не хочу тестировать цепочку «Неверные данные», так как валидация данных встроена в шаблон Excel. Я поставила эту цепочку на паузу, чтобы вернуться к ней позднее, если останется время. На ментальной карте появилась соответствующая иконка и комментарии, почему работа над цепочкой была приостановлена:

Цепочка «Неверные данные» поставлена на паузу.

Затем я вспомнила, что не расставила приоритеты для областей тестирования. Приоритет я выставила при помощи разноцветных цифр, где 1 – наивысший, а 6 – низший приоритет:

Расстановка приоритетов.

Как оказалось, инструмент работает только с файлами в xslx-формате, и не может читать старые xls-файлы. Я точно не знала, баг это или фича, поэтому пометила цепочку вопросительным знаком и оставила к ней заметку.

Когда у тестировщика возникают вопросы, цепочка помечается вопросительным знаком, и к ней добавляется заметка.

Я завершила сессию, но так как меня разбирало любопытство по поводу читаемого формата файлов, вместо новой сессии я решила взглянуть на область «Конфигурация». Несколько минут я провела, создавая отчеты о сессиях в версиях Office 97-2003 и Open Office, и пытаясь загрузить их в систему. Эти цепочки тестировались именно как цепочки, а не в рамках сессии. Я потратила на них всего несколько минут, так как это была область низкого приоритета, написала к ним короткую заметку, поставила цепочки на паузу, чтобы вернуться к ним позже. Если бы я вернулась к ним (чего я в результате не сделала), я бы продолжила делать заметки в специальном окошке:

Краткое тестирование двух цепочек и установка их на паузу.

Далее я решила протестировать все цепочки в области «Генерация» в рамках сессии, по аналогии с областью «Импорт»:

Тестирование всех цепочек раздела «Генерация» в рамках сессии.

Я нашла несколько дефектов и пометила их на карте красным крестом. Когда я обнаруживала дефект, я делала заметку на карте с ID и описанием дефекта. Эта же информация включалась в отчет о сессии.

Найденные дефекты помечались красным крестом, и к ним добавлялась заметка с номером дефекта.

Завершив сессию «Генерация», я углубилась в раздел «Отчетность». По моим прикидкам, подразделы «Итерационные отчеты» и «Сводные отчеты» были достаточно крупными, чтобы объединить их в сессионное тестирование.

Тестирование двух цепочек в рамках сессии.

Проведя три сессии и протестировав две цепочки по отдельности, я привела свою ментальную карту к следующему виду:

Статус тестирования после трех сессий и раздельного тестирования двух цепочек.

Документация к приложению состоит из трех учебников, и я тестировала их как цепочки. На этом моменте у меня уже практически не оставалось времени, поэтому я просто бегло пролистала их. Я использовала частично закрашенные квадратные иконки, чтобы продемонстрировать, как далеко я продвинулась в тестировании каждого документа, и я оставляла краткие заметки. Отчет о сессии я не оформляла, так как тестировала их как цепочки. Последние несколько минут я потратила на запуск приложения с различными параметрами, что тоже проверялось как цепочка, так как на сессию уже не хватало времени.

Тестирование цепочек с использованием частично закрашенных квадратиков, показывающих прогресс тестирования.

Отчет о тестировании

Мои четыре часа истекли, и я завершила тестирование. На этом этапе у меня был отчет о тестировании в форме последней версии моей ментальной карты:

Отчет о тестировании

У меня также были на руках три отчета о сессиях (Импорт, Генерация, Отчетность) и список дефектов.

Если бы у меня было больше времени, я бы вернулась к поставленным на паузу или частично протестированным цепочкам и продолжила работу, делая пометки к соответствующим подразделам. Я бы также исследовала еще непротестированные цепочки.

Запись Метод XBTM — применение на практике впервые появилась Портал TMGuru.

«Я много говорил о том, как мотивировать других людей, но ничего из того, что я говорил, не помогало. Поэтому сегодня я расскажу о том, как демотивировать:

10. Без необходимости ставь заведомо завышенные цели только для того, чтобы посмотреть, насколько люди будут выкладываться. Лучше всего поставить несколько задач в одно и то же время.

9. Никогда не объясняй логику своих решений. Вспомни своих родителей: «Потому что я так сказал!». Тут это тоже работает.

8. Назначай сотрудникам бессмысленные задачи. Самое важное в работе — выглядеть чем-то занятым, хотя бы и какой-то бессмысленной фигней.

7. Даже если задача сделана великолепно — критикуй! Добудь себе большой красный маркер и подчеркивай им все подряд. Не фокусируйся на содержимом или на главной идее — обращай внимание на строение предложений и раздражающих лично тебя словах.

6. Приписывай все заслуги себе. Ведь это ты создал эту команду, все началось с тебя! Каждый раз, когда тебе нужно пообщаться с руководством, иди один, чтобы ничего не помешало рассказать, какой ты классный.

5. Решай существующие проблемы созданием бюрократии. Помни, что нет простых проблем или простых решений — есть люди, которые недопонимают важность происходящего. Ты можешь справляться со сложными проблемами и решениями, поэтому формализуй все по-максимуму, с процессами, графиками и отчетами

4. Пропускай все мимо ушей. Главное — заставить людей думать, что ты слушаешь! Поэтому смотри им в глаза, кивай в знак согласия и думай о своем.

3. Отказывайся рассматривать любые способы работать эффективнее. Инструменты? Нам не нужны инструменты, у нас нет на это денег! Обучение? У нас был оплачен целый курс пять лет назад, вы что, забыли?

2. Воспринимай свою команду как набор механизмов, которые никогда не должны ломаться. Заболел? Он что, забыл о презентации, которую должен был сделать?

1. Никогда, ни при каких обстоятельствах никого не хвали и не признавай чужих заслуг! Иначе люди начнут чувствовать себя счастливыми. Помни — если ты не хвалишь людей, тебе даже не надо их оскорблять: ты просто их игнорируешь, и они увольняются. После этого ты сможешь нанять новых людей и демотивировать их!»

Оригинальное видео: Ten Proven Ways to De-motivate Your Team

Запись 10 способов демотивировать свою команду тестирования впервые появилась Портал TMGuru.

Резюме: Зачем ждать, чтобы увидеть нового сотрудника в деле? Организуйте пробы при приёме на работу, чтобы оценить реальный вес представленного резюме. Johanna Rothman даёт некоторые рекомендации, как повысить эффективность интервьюирования при помощи хорошо спланированных проб. Даже если Вы проводите интервью по телефону, а не лицом к лицу, пробы помогут Вам получить более богатое представление о возможностях кандидата и о его способности адаптироваться к Вашему рабочему окружению. Подвергните заявления кандидатов проверке практикой.

Если Вам случалось подбирать сотрудников на ограниченное количество открытых позиций, Вы, должно быть, знаете, как иногда бывает трудно выбрать одного из двух отличных кандидатов. Если привычные средства — технические вопросы и психологические тесты, уже не помогают в принятии решения, попробуйте организовать пробы.

Понаблюдайте за кандидатом в действии.

Пробы помогают увидеть либо непосредственно, либо по произведённым результатам, как кандидат справляется с реальной работой.

Определите ожидаемые навыки.

Определите те навыки, которые кандидаты должны продемонстрировать, чтобы успешно пройти пробы. Сделайте описание вакансии, уделив внимание как тому, что кандидатам предстоит делать, так и тому, какие результаты ожидаются от их работы. Если вы не знаете, как сделать такое описание, можете следовать предлагаемому ниже способу.

Сначала выпишите список всех людей, с которыми кандидату придётся работать, когда он будет принят. Если организация большая, выпишите названия подразделений. Разделите получившийся список на группы по тому, что для них будет делать новый сотрудник.

Затем определите, что каждый из перечисленных людей ожидает от кандидата, обращая внимание на то, какие результаты они ожидают от него получать. Наконец, определите навыки, необходимые для произведения ожидаемых результатов человеком, занимающим описываемую позицию.

Вот пример такого описания для позиции тестировщика:

Выберите навыки для проведения проб.

Когда точно известно, какой навык хотелось бы проверить, составление проб весьма просто — нужно составить задание, в котором именно этот навык демонстрируется. Но чаще хочется проверить более чем один навык. Приведённый далее пример показывает, как составить пробу для двух навыков: обзор способов тестирования и быстрое создание маленьких тестов. Предполагается проверить, что кандидат знает и понимает достаточно много разных способов тестирования и может быстро разработать много разных небольших тестов. Для этих двух навыков составляем две пробы: мини-проба для телефонного интервью и рассчитанная на 20-30 минут проба для личного интервью.

Создание пробы.

Для телефонного интервью лучше начать с навыка «быстрая разработка маленьких тестов».

Если кандидат имеет доступ к интернету во время интервью, отправляем ему (ей) ссылку на некоторый продукт, доступный через интернет (например, некоторое веб-приложение или загружаемый продукт), и просим сделать несколько тестов для этого продукта. После этого обсуждаем с кандидатом разные способы создания тестов для выбранного приложения и причины, по которым он (она) выбрала те или иные способы при создании тестов во время выполнения задания. Если кандидат не имеет доступа к интернету, даём ему предварительно время (5-10 минут) для создания маленьких тестов либо для широко известного приложения, либо для некоторого умозрительного приложения по описанию, после чего проводим обсуждение по телефону, как описано выше, выясняя, почему кандидат предпочёл те или иные способы тестирования.

Во время личного интервью можно использовать те же самые задания, что и для интервью по телефону. Но можно использовать для проб части вашего реального продукта, документацию, спецификации — то, что тестировщики в вашей организации обычно используют для выполнения своей работы. Попросите, например, кандидата перечислить все способы, которыми можно тестировать ваш продукт.

Перед тем, как приступать к пробам, убедитесь, что кандидат имеет общее представление о навыках, которые вы собираетесь проверить. Задайте некоторые вопросы, которые помогут вам определить, применял ли он (она) такой навык ранее в своей деятельности. Например, чтобы убедиться в том, что кандидат знаком с различными техниками тестирования, попросите его привести пример случая, когда он тестировал некоторую систему несколькими разными способами. Только в том случае, если кандидат демонстрирует удовлетворительные базовые знания, пробы позволят вам получить дополнительную полезную информацию.

Аккуратно и чётко формулируйте задания.

Во время разработки заданий для проб старайтесь не использовать вопросов, подводящих к ответу. Например, избегайте вопросов типа: «Назовите по крайней мере три способа сделать это». С одной стороны, при этом вы должны быть уверены, что каждый удовлетворяющий вас кандидат в состоянии найти по крайней мере три способа. С другой стороны, некоторые люди после такого вопроса находят три способа и останавливаются, даже если они знаю больше. Не забывайте, что во время интервью люди нервничают, и это в какой-то степени сковывает их мышление, не закрепощайте его ещё сильнее.

Задание лучше всего написать на листке бумаги, так чтобы кандидат мог в любой момент прочитать его ещё раз, не прося вас повторить формулировку задания.

Сначала проверьте пробы на своих сотрудниках.

Перед использованием проб проверьте их на своих сотрудниках, иначе вы можете разработать такую пробу, с которой никто кроме вас не сможет справиться. Дело не только в технической сложности задания, но и в том, что время на его выполнение сильно ограничено, особенно с учётом того, что во время интервью требуется ещё время для проверки результатов и их обсуждения с кандидатом.

Пробы — это не выпускной экзамен в университете, это просто техника, позволяющая увидеть, как человек работает. Поэтому пробы не должны быть сложными, но они должны отражать вашу реальную рабочую обстановку.

Подведём итоги

Пробы позволяют увидеть кандидатов в действии. Слушая по телефону рассказ о том, как кандидат решал задачу, или наблюдая кандидата за работой, вы получите более чёткое представление о его возможностях и о том, насколько легко он сможет адаптироваться к вашему рабочему окружению.

Об авторе

Джоанна Ротман (Johanna Rothman) консультирует, выступает и пишет на темы, связанные с управлением процессом разработки высокотехнологичных продуктов. Она помогает менеджерам, командам и организациям стать более эффективными за счёт использования разработанных ею прагматичных подходов к управлению проектами, управлению рисками и управлению персоналом. Джоанна ведёт два блога — Managing Product Development и Hiring Technical People. Джоанна является организатором конференции AYE conference и автором книги Hiring The Best Knowledge Workers, Techies & Nerds: The Secrets & Science of Hiring Technical People.

Оригинал статьи на английском языке: Watching Testers in Action: Auditions During Interviews.

Запись Как интервьюировать тестировщика? Понаблюдайте за ним в действии. впервые появилась Портал TMGuru.

Перед каждым руководителем группы или проекта тестирования стоит задача формирования эффективной команды. Как кажется новичкам, задача эта совсем не сложная – найти правильных людей и назначить их на правильную должность. Но почему же тогда так часто это не получается? К сожалению, в своей практике я очень часто встречаюсь с несогласованными командами, увольнениями, текучкой. И почти всегда причина более чем банальна (прошу прощения за возможную неполиткорректность!) – лень руководителя. Имею ли я что-то против лени? Нет! Лень – это эффективнейший инструмент оптимизации затрат на работу. Но использовать его надо с умом. Поверьте, потратив время и подготовившись к поиску сотрудников, Вы совершаете очень выгодную инвестицию. В качестве дивидендов Вы получаете слаженно работающую, эффективную команду, требующую значительно меньше Вашего внимания впоследствии. Так что же лучше – полениться на этапе поиска сотрудников, и потом «пожинать плоды» — или эффективно подготовиться к собеседованиям, после чего расслабиться и получить больше свободного времени на выполнение других своих обязанностей?

Предлагаю рассмотреть второй вариант. Что нам для этого нужно? Я составила свод из 12 базовых правил, позволяющих в разы повысить успешность проводимых собеседований. Вам остаётся только проверить, правда ли это действует ;) Отзывы о результатах можете высылать на natalya@quality-lab.ru – обсудим, что было сделано правильно и что ещё можно улучшить!

Правило 1. Не ищите несуществующее. Да, да, да! Все тест-менеджеры хотят найти опытного, целеустремлённого и технически грамотного специалиста, да ещё и в бюджет до 30 тысяч рублей. И Вы хотите? Проснитесь! Это невозможно. Хорошие специалисты зарабатывают хорошо. У Вас есть ограничения по финансам? Заранее продумайте, чем Вы жертвовать готовы, а чем – нет.
Почему это важно? Потому что иначе Вы будете принимать решение в последний момент, понимая, что желаемого специалиста найти не удалось. И вероятность ошибиться, спутав желаемое с показавшимся, будет значительно выше 50%. Через пару месяцев неуспешной работы Вы будете корить своего биг-босса за то, что он не выделил достаточно ресурсов. Хотя на самом деле Вы просто неэффективно их использовали.
Решение: Заранее выпишите все важные требования к кандидату. Сверьтесь с рынком – возможно ли найти такого специалиста? Если невозможно – заранее сузьте требования, не оставляйте это «на потом».

Правило 2. Здраво оценивайте требования к кандидатам на их «профпригодность». Вам правда важно образование Вашего сотрудника, если он эффективно решает поставленные задачи? Вас беспокоит наличие сертификатов? Вы правда считаете, что для чтения документации необходимо знание английского языка на уровне Fluent? К сожалению, часто менеджеры хотят максимума. Иногда это неоправданно, а иногда даже губительно. Подумайте, что нужно специалисту для решения задач, с которыми он будет сталкиваться – это единственное, что для Вас должно быть важно на собеседовании.
Почему это важно? Потому что в противном случае Вы будете концентрироваться на косвенных характеристиках, таких как сертификаты и пройденные курсы. Есть риск упустить самое важное!
Решение: побудьте честны с собой. Вам важно образование потому что оно есть у Вас – или потому что оно правда необходимо? Вычеркните из списка требований половину пунктов, необходимости в которых нет. Обещаю, Вам понравится результат! После этого вычеркните вторую половину :)

Правило 3. Не забывайте, что знания и опыт – это далеко не всё! В ИТ-мире это распространённая ошибка. Вы ищете сотрудника, имеющего опыт в создании тест-кейзов, и хорошо знающего Linux? Вы его нашли? Замечательно! Но если Вы оценивали только знания – не удивляйтесь, если он будет каждый день опаздывать, не сможет общаться с коллегами или попросту уволится через три месяца. Люди – не машины! Человеческий фактор никто не отменял.
Почему это важно? Потому что Вы ищете не софт, который может решать определённый функционал. Вы ищете сотрудника, который должен хорошо вписаться в коллектив и которому у Вас будет комфортно работать.
Решение: определите, какими личностными компетенциями должен обладать сотрудник, чтобы эффективно работать в Вашем коллективе. Придётся ли ему коммуницировать с другими участниками процесса, или он будет работать в одиночестве? Ему будут ставиться строго очерченные задачи, или уровень ответственности будет размыт? Насколько важна дисциплина в Вашем коллективе? Он будет работать в стрессовых условиях? В конце концов, решите для себя честно – диктатор Вы или демократ по стилю управления. Все вышеперечисленные вопросы влияют на то, какой сотрудник Вам нужен!

Правило 4. Не зацикливайтесь на том, что нужно Вам. Думайте и о требованиях сотрудника!
Почему это важно? Допустим, Вы нашли сотрудника, у которого идеально соответствуют Вашим требованиям и знания, и опыт, и личностные компетенции. Он готов протестить всё на свете!  Приходит к Вам на работу, усердно изучает продукт, и… в лучшем случае – результата ноль. В худшем – он увольняется. Почему? Потому что он Вам подходит, а вот Вы ему – нет. Перед приёмом сотрудника на работу Вам надо знать, что его мотивирует. У Вас вялотекущий проект на шесть лет, а к Вам приходит карьерист, желающий стать за год мега-боссом? Или он хочет всё время развиваться и получать новую информацию, а у Вас нет задач кроме запуска рутинных тест-кейзов? Или, наоборот, он ищет оазис спокойствия от гроз и бурь, а Вы бросаете его на стрессовую позицию?
Решение: определите, какие типы мотивации Вам доступны. От премий до карьерного роста, от новых задач до шоколадок, от ответственности до публичной похвалы. Ваш арсенал шире, чем кажется ;) Составили список? Определите, интересует ли это Вашего соискателя. Он не всегда знает, что Вы готовы ему предложить. Оцените, сможете ли Вы дать ему то, что нужно. И не надейтесь на чудо: если Вам нечего ему предложить – то есть смысл отказаться от самого потрясающего сотрудника. Вы же не хотите делать кого-то несчастным? :)

Правило 5. Забудьте о себе. Хотя бы на час :) Тот час, который Вы проводите собеседование. Мозг человека устроен таким образом, что мы судим всех по себе. И видим в других людях то, что есть в нас. Побудьте бесстрастным, иначе все усилия будут насмарку.
Почему это важно? К примеру, Вы не просто нашли подходящего сотрудника, Вы ещё и уверены в том, что Вы ему тоже подходите и ему у Вас будет хорошо. Он выходит на работу. А результата всё равно нет. Где ошибка? В нас. То есть в Вас. То есть в менеджере, проводящем собеседование! Зачастую, особенно новички, не готовы признать чего-то такого, чего нет в них самих. И если Вы карьерист и стремитесь занять высокую позицию, то слова соискателя «я не хочу быть руководителем» Вы воспримете не иначе как ложь… А зря ;) Он – не Вы. Мне очень долго не верилось, что есть сотрудники, обожающие рутину. Но моё неверие не смогло изменить этот мир. Они есть! И слава Богу за это!
Решение: будьте внимательнее, и оценивайте каждый свой вывод про сотрудника. Просто тестируйте себя вопросом «Не потому ли я так решил, что это про меня?». Сразу успехов не ждите :) Но со временем – я в Вас верю!

Правило 6. Подготовьте вопросы к собеседованию. Чуть ниже я расскажу, какие вопросы бывают и когда они нужны. А пока что просто советую – подготовьте их заранее. Запишите на бумажку, как шпаргалку для экзамена. Тогда у Вас будет значительно меньше шансов провалить собеседование
Почему это важно? Проведение собеседования – искусство. Никто не начинал рисовать картины «с нуля» — всем нам нужна для начала практика. Если у Вас будут готовые вопросы, Вы сможете провести собеседование результативнее. На этом совете 90% читателей должны зевнуть и решить перейти к следующему совету. Ну и зря! ;) Проверьте, может быть, совет не так уж и плох?

Правило 7. Задавайте открытые вопросы. Недавно я была на собеседовании в крупной ИТ-компании. Собеседование проводила руководитель отдела по подбору персонала. И задавала мне вопросы, не оставляющие даже шанса ответить «неверно»: «Вы любите изучать новое?», «Вы не боитесь стрессовой работы?», «Вы готовы много коммуницировать на английском?», «Вы любите ответственность?», «Вы готовы принимать срочные, важные решения?». Как Вы думаете, я могла ответить что-то, кроме «Да, конечно!»? Нет! Мне не было оставлено и шанса. Не мудрено, что по результатам собеседования мне сказали, что я идеальный кандидат. Более того – не удивлюсь, если у этого менеджера все кандидаты на собеседовании оказываются идеальными!
Почему это важно? Банально, но факт: все соискатели ходят на собеседование для того, чтобы получить работу. Никто не ходит на них ради интереса :) Следовательно, все хотят понравиться. Или почти все? Такими вопросами Вы сразу даёте понять, какой ответ понравится. А зря ;) Надо быть хитрее!
Решение: задавайте открытые вопросы. Открытыми называются вопросы, на которые нет определённого формата ответа. Пусть соискатель ответит так, как ему удобнее. Вы получите массу полезной информации! ;) Спросите, что человеку больше всего нравится в работе, а что – не нравится. Так Вы получите более реалистичный ответ.

Правило 8. Уделяйте меньше внимания теории, больше – практике. Вам правда важно, знает ли Ваш сотрудник, что такое «эффект пестицида», если он не понимает, как эту информацию использовать в работе? Возможно, термин «чёрный ящик» важнее способности структурировать информацию и находить ошибки? Хм. Не верю :)
Почему это важно? Потому, что теоретиков много, а хороших специалистов мало. Я подумываю создать «словарь тестера для собеседования». 30 терминов – и хорошая зарплата обеспечена ;) Но не у таких мудрых менеджеров, как мы с Вами.
Решение: задавайте вопросы об использовании информации, а не о теории. Спросите у человека, как обойти эффект пестицида. Спросите, в чём недостатки использования чёрного ящика и как их компенсировать. Попросите написать вариант тест-кейза. Баг-репорта? Узнайте его мнение, как правильно тестировать при недостатке документации. Узнайте, как он работает – а не что он знает! Вы же его берёте не для создания словаря, а для тестирования?

Правило 9. Следите не только за тем, что говорит человек – но и за тем, как он это говорит! Сейчас пойдёт немного теории, приготовьтесь записывать. Любые слова несут в себе так называемые номинативную и коннотативную части. Номинативная – это факт. Коннотативная – это отношение автора к собственному высказыванию. К примеру, фраза «Мне приходилось прогонять тест-кейзы» состоит из номинативной части (сотрудник выполнял тест-кейзы) и коннотативной (он это дело явно не любил, судя по слову «приходилось»).
Почему это важно? Представьте, что Вы ищете сотрудника на ручное выполнение рутинных кейзов. И соискатель это знает. Поэтому на вопрос «что Вы больше всего любили делать на последнем месте работы?» он может ответить про прогон тестов… которые на самом деле он не любил. И ответит он «Мне приходилось…». Если Вы не заметите коннотацию, то можете решить, что сотрудник Вам подходит. Но потом не удивляйтесь!
Решение: следите за такими словами, как «приходилось»(-), «было необходимо»(-), «к сожалению»(-), «из-за»(-), «была возможность»(+), «получалось»(+), «результат»(+), «к счастью»(+) и т.д. Очень быстро Вы составите свой собственный словарь. Плюсов тут аж целых два: Вы не только сможете лучше понимать людей, Вам ещё будет и интереснее проводить собеседования! Почувствуете себя как минимум частным детективом :)

Правило 10. Тестируйте чашки! Или ложки! Или калькуляторы, лифты, джинсы и даже сигареты. Дайте соискателю задание – и посмотрите, как он будет отвечать. Не мешайте ему с подсказками, он и так знает что Вы начальник. Главное – внимательно следите за ходом его мысли!
Почему это важно? Потому что тестировщики нужны для того, чтобы тестировать. Именно эту способность Вам важнее всего оценить.
Решение: дайте кандидату любое тестовое задание, но не акцентируйтесь на количестве ответов. Посмотрите за ходом мысли. Умеет ли специалист использовать все те виды тестирования, о которых рассказывал в теоретической части – или не догадается проверить лифт на перформанс? Умеет ли он приоритезировать тесты, или начнёт тестирование калькулятора с деления на ноль? Выделит ли он классы эквивалентности, или будет кататься на лифте с каждого этажа на каждый этаж, мешая соседям спать?

Правило 11. Записывайте результаты собеседования. Да-да, опять бумажки, опять хочется зевнуть :) Но в противном случае у Вас есть шанс забыть всё на свете, особенно если соискатель вызвал у Вас личностную реакцию – негативную или позитивную. Я могла бы не говорить про бумажки и просто посоветовать быть объективнее – но без бумажек это сложновато…
Почему это важно? Потому что когда Вы прочитали про объективность, то явно решили «это не про меня». Поэтому и важно ;)

Правило 12. Если Вы соискатель – то лучше не пытайтесь использовать эти советы чтобы лучше пройти собеседование.
Почему это важно? Потому что Вам не нужна работа, на которой Вы не нужны или которая Вам не понравится. Звучит банально, но на собеседовании эффективнее быть искренним :)

Итак, вот он, максимально короткий свод правил о том, как успешно проводить собеседования тестировщиков. Прошу заметить, что приведённая здесь информация – не «сферические кони в вакууме». Это Практика. Возможно, что-то из написанного Вам не понравится, вызовет скепсис, покажется излишним. Попробуйте! Только тогда Вы сможете решить, что Вам нравится, а что – нет. Если будут вопросы – обращайтесь, обязательно постараюсь помочь. И, пожалуйста, ленитесь! Но делайте это эффективно!

Запись 12 правил успешного собеседования тестировщиков впервые появилась Портал TMGuru.

На конференции Test Labs 2009 в сентябре догадайтесь_какого_года я делала доклад на тему «Где брать тестировщиков, покупать или готовить.» Он основан на моем опыте набора людей на позицию тестировщик. Действие происходит на Украине, в г.Харьков. Харьков — город студентов, а вот с хорошими специалистами там дела похуже.

Если посмотрите слайдкаст — увидите картинки-графики, основанные на моих наблюдениях. В тексте же ниже — лишь голая теория.

Я уверена, что то же самое, практически слово в слово, можно перенести на набор абсолютно любых IT-специалистов.

Большой отклик на конференции вызвал рассказ о программе обучения, которую я, ещё работая в Никсах, вела для студентов.

Ссылка на сам слайдкаст: http://software-testing.ru/library/around-testing/management/863-where-to-get-testers, ну а сам текст, вот он:

Каждому тест-менеджеру время от времени приходится нанимать к себе в команду новых людей. В зависимости от ситуации, люди могут быть нужны срочно либо не срочно, несколько либо один, определенные люди со строго очерченным кругом умений, либо просто хороший человек, которого можно научить делать то, что нужно в данном проекте.

Думаю, каждый из вас сталкивался с ситуацией, когда нужного человека в нужный срок за нужные деньги подобрать не получается. Причин тому может быть множество. Сессия, – и способные студенты не ходят по собеседованиям. Или Гугл открыл филиал в вашем городе, и все хорошие специалисты уже там, и их оттуда не переманить ни деньгами, ни статусом компании, ни интересными проектами. Или на рынок вышел Слава Панкратов и набирает себе подмастерий, и тут уже даже у Гугла проблемы с набором сотрудников :)
Нам же деваться некуда – люди нужны.

Успех зависит от стратегии компании в наборе сотрудников, от её гибкости и способности к адаптации, а также от понимания ситуации на рынке, сопоставления её с потребностями и возможностями компании.

Как же можно набирать людей:

— Приглашать готовых специалистов с необходимыми знаниями;
— Набирать способных ребят без опыта работы в тестировании и обучать их не только специфике проекта, но и тестированию «взагалi»;
— Всегда иметь пул ресурсов, из которого можно выудить нужных людей в нужный момент и достаточно быстро ввести их в работу;
— Создать внешнюю систему обучения.

Да, и, конечно же, – не есть правильно просто следовать однажды выбранной стратегии независимо от ситуации на рынке и от того, какие именно специалисты, в какой срок, в какой бюджет нам нужны.

Способ 1. Набор специалистов с опытом работы в тестировании:

— Формулируем достаточные условия — навыки, умения, знания, опыт, которые нам нужны от кандидата, и сколько мы готовы за это платить;
— Открываем вакансию;
— Выбираем подходящего специалиста.

Плюсы метода:

— Такого специалиста не нужно обучать тестированию: тем дисциплинам, знаний о которых вы требовали от него при приеме на работу;
— Привнесенный опыт будет полезен проекту и компании: он обеспечивает вливание свежих знаний и способствует обмену опытом с уже работающими специалистами;
— Выигрыш во времени: нового человека достаточно обучить лишь специфике проекта.

Вы с большой вероятностью получаете выигрыш по скорости и качеству работы по сравнению со специалистом без опыта.

Минусы метода:

— Стоимость такого специалиста: нужно думать, обоснован ли выигрыш по скорости введения в работу и дальнейшей работы, за который придется больше платить;
— Человеческий фактор: в случае найма специалиста на основании лишь его технических навыков, без оглядки на его коммуникативные качества и на специфику уже устоявшегося коллектива, возможны проблемы с вливанием его в вашу команду.

Методика набора готовых специалистов оправдывает себя в том случае, если вам нужен и сразу (!) специалист с определенным набором знаний и умений и вы готовы за это платить.

Способ 2. Набор людей без опыта работы в тестировании и обучение их на производстве:

— Формулируем необходимые знания и навыки, которые нам нужны от будущего тестировщика: это может быть иностранный язык, знание протоколов, умение администрировать среду или что-либо ещё, специфичное для данного проекта.
— Открываем вакансию: лучше задействовать ВУЗы, потому как вакансия «тестировщик без опыта работы» на джоб-сайте ни к чему хорошему не приведет.
— Выбираем подходящего кандидата: обращаем внимание на обучаемость и желание учиться.

Плюсы метода:

— Мы сами обучаем ребят тому, что нам нужно;
— На первых порах зарплата такого сотрудника меньше: важно к моменту становления человека как специалиста достичь адекватного уровня оплаты;
— Стремление к обучению и отсутствие «звёздности»: вероятность ситуации «я уже всё знаю и мне нечему больше учиться» минимальна при условии выбора правильного человека;

Перед вами чистый лист, который вы сможете обучить так, как вы хотите, и тому, чему вы хотите. Относительно недорого. .

Минусы метода:

— Большой поток на собеседованиях;
— Возможность вырастить очень узкого специалиста;
— На обучение студента тестированию нужно дополнительное время: такой сотрудник войдет на проект не сразу;
— Возможность промаха с «обучаемый» и способный.

Таким образом, этот способ оправдывает себя, если вы не можете позволить себе платить большую зарплату готовому специалисту, если вам не горит вход ресурса на проект, то есть вы можете себе позволить потратить время на его обучение, если вам НУЖНЫ такие ребята, чистые и гибкие. Это может зависить от специфики проекта и специфики коллектива. .

Способ 3. Создание пула тестировщиков, откуда при открытии горящей вакансии сразу же берется нужный человек:

— Предсказываем расширение проектов количественно и качественно;
— Не торопясь, заранее набираем специалистов;
— Вводим их на проекты по мере надобности.

Плюсы метода:
— Уменьшение зависимости от колебаний рынка;
— Доступность специалистов в любой момент;
— Предсказуемость специалистов по техническим умениям и человеческим качествам;
— Снижение рисков, связанных с уходом сотрудников.

Минусы метода:

— Дорого: это может себе позволить только большая компания;
— Риск неоправдания предсказаний существует: нельзя полагаться на бекап полностью, может не оказаться нужного специалиста, может не оказаться нужного количества и т.д.;
— Люди могут «скиснуть»: бекап должен быть правильно организован, чтобы не превратиться в скамью запасных.

Если вы – достаточно большая компания и можете себе позволить всегда держать людей про запас, если у вас постоянный и предсказуемый прирост проектов и постоянная и, ещё раз подчеркиваю, предсказуемая нужда в людях, и вы умеете организовать этот бекап так, чтоб люди не чувствовали себя в запасе, то это вам подходит. .

Способ 4. Организация бекапа снаружи компании – внешняя система обучения:

— Изучаем предложение: смотрим на ВУЗы и студентов;
— Изучаем спрос: смотрим внутрь себя, понимаем, какие специалисты нам нужны в перспективе, чему их нужно научить;
— Создаем программу обучения;
— Стартуем программу, обучаем ребят, снимаем сливки, то есть по мере необходимости приглашаем ребят на работу.

То есть это такая себе ассимиляция всего вместе. Мы набираем способных ребят, обучаем их за свой счет, на выходе получаем пул готовых специалистов, которых всегда можем нанять к себе на работу.

Плюсы метода:

— Обучаем «под себя», но достаточно широко;
— Предсказуемость ребят в плане обучаемости и желания работать;
— Предсказуемость ребят в плане способностей и склонностей;
— За время обучения ребята становятся лояльными к вашей компании;

Обратите внимание – это готовые специалисты! Да, без опыта, но с теоретическими знаниями, широкого профиля, гибкие, мы наблюдаем их во время обучения, то есть они не преподнесут нам сюрпризов вроде неспособности обучаться.

— Имиджевая составляющая: компания, организующая собственную систему обучения, воспринимается как стабильная, серьезная компания с далекоидущими планами;
— Колоссальный и очень полезный опыт для компании и специалистов, которые к этому имеют отношение.

Минусы метода:

— Ресурсоёмкая организация процесса: договоренности с ВУЗами, разработка самой программы, ведение и поддержка процесса обучения;
— Ведущие такого обучения должны быть преподавателями в душе, а не просто техническими специалистами;
— Риск обучения для других компаний: за время обучения нужно заинтересовать ребят работой именно в вашей компании;
— Риск недостаточности знаний человека в других отраслях, нужных ему для работы в вашей компании: спастись здесь можно отбором на старте программы.

Если вы можете себе это позволить – это очень хорошая активность, очень полезная и очень интересная. Главное – определиться с целями и потребностями.

Нет верного ответа на все времена «как лучше и эффективнее нанимать тестировщиков». Перед тем, как принимать решение, где и как мы будем искать человека, нужно сесть и подумать: ЗАЧЕМ?

Какой человек нам нужен, в какой срок, в какой бюджет, что он должен дать нашей компании, и что мы сможем дать ему, какая сейчас ситуация на рынке труда и где проще всего встретить нужного человека.

Подход к набору людей – это очень важный момент стратегии любой компании, потому что проекты делаются в первую очередь людьми, а не технологиями. Поэтому на подход к набору людей нужно обращать особое внимание.

Запись Где брать тестировщиков? Принципы поиска и набора впервые появилась Портал TMGuru.

Цель этого документа — дать добрые советы любому начинающему руководителю группы.Руководитель группы это не человек, который заполняет планы. Руководитель группы — это лидер коллектива, который может привести коллектив к вершине, а может увлечь в пропасть.В документе собраны советы, которые покрывают наиболее ключевые области работы руководителя. Это советы не теоретиков, это советы практиков.Прочитайте этот документ, проникнетесь им и попробуйте следовать этим советам. Это не просто, но это стоит делать.

Содержание

• Работа с людьми
• Ответственности
• Оценки трудоемкости
• Переработки
• Планы и отчетность
• Добрые советы, по организации рабочего процесса
• Резюме

Работа с людьми

Вам подчиняются люди. Качество их работы во многом зависит от качества Вашей работы. Иными словами Вы непосредственно влияете на благополучие сотрудников в компании.

Вы отвечаете за работу каждого вашего подчиненного. Если человек дает плохое качество и Вы об этом узнаете от кого-то — это Ваша вина.

Например. Разработчик отчитывается о сделанном функционале, и Руководитель группы разработки (ЛидДев) заявляет функционал в тестирование. Если после этого тестировщик говорит, что все не по дизайну или половина дизайна не сделана — виноват ЛидДев.

Делайте ревью того, что делают Ваши подчиненные.

Вы можете аргументировано затребовать снятия человека с проекта (направления) — примеры тому были — но если Вы продолжаете работать с человеком и не ставите Руководителя проектов (PM) в известность о проблемах, то это Ваши проблемы. Для PM это значит, что Вы готовы помочь человеку и это:

• Не отразится на качестве выходных результатов по задачам этого человека
• Не отразится на сроках выполнения, как ваших задач, так и задач человека, которому Вы помогаете
• Не отразится на качестве Вашей работы на ваших задачах

Иными словами, если Вы покрываете человека, и PM не в курсе, то аргументы типа «я тут и так зашиваюсь, а меня еще спрашивают по моим задачам» или «давайте я все брошу и буду делать то, что обещал(ла)» не проходят.

Если Вы видите у человека проблемы, которые не можете решить в рабочем порядке, Вы обязаны обговорить это проблемы с человеком, чтобы сотрудник понимал, что Вы им не довольны. Вы должны не просто указать на проблему, но и аргументировать, что это действительно неправильно и дать рекомендации к исправлению. Если договориться с человеком не получается — говорите PM, и решайте совместно.

Информируйте PM-а о проблемах в команде, информируйте даже о решенных проблемах.

Каждую минуту рабочего дня Вы обязаны знать, чем занят каждый Ваш подчиненный и когда он закончит поставленные задачи. Для этого не обязательно его дергать ежеминутно, достаточно понимать, когда он закончит и на протяжении срока выполнения уточнять укладывается ли сотрудник в сроки, и нет ли проблем. Иногда проще созвониться, иногда подойти… как оптимальнее — пробуйте, подбирайте…

Вы не имеете права допускать ситуации, когда кто-то в Вашей команде сидит без работы. Помните о разнице во времени между офисами. Помните, что многие приходят на работу раньше Вас. Каждый раз перед тем, как уйти с работы спросите себя, а все ли Ваши подчиненные имеют задачи на следующий день? Если нет, то пошлите хотя бы краткое описание, что надо делать, чтобы занять человека на утро, пока Вы придете или подготовьте более детальное описание.

Никогда не откладывайте постановку задачи на утро.

Вы не должны все делать своими руками, это значит, что Вы можете распределять часть своих обязанностей между подчиненными. Это позволит:

• Не умереть от загруженности
• Вовлечь в процесс других сотрудников и обучать их
• Сплотить команду

При проставлении еженедельных оценок сотрудникам Вы обязаны быть готовы объяснить сотруднику и PM, почему именно эту оценку Вы поставили.

Многие вопросы легче решать по телефону. Не ленитесь звонить в удаленные офисы… не надо создавать у удаленных сотрудников ощущение, что они на отшибе… это Вам же будет мешать, когда они замкнутся и информацию придется вытягивать.

Помните про разницу во времени между офисами.

Помните, про то, что все люди разные — Вы как руководитель обязаны научиться работать с человеком. Понять, КАК ему лучше ставить задачи, КАК его оптимальнее мотивировать на работу, КАК ему говорить об ошибках. Поймите, Вы можете сильно травмировать человека неосторожным словом… Вы можете часами объяснять человеку что-то и он никогда Вас не поймет, если Вы будете говорить непонятным для него языком и приводить несущественные для него доводы. Если Вы не найдете общий язык с человеком, Вы не сможете с ним оптимально работать. Причем подстраиваться зачастую должен не только он, но и Вы. Помните, про национальные различия. Хороший руководитель обязан знать основные национальные черты и особенности подчиненного.

Помимо работы с подчиненными Вы обязаны тесно работать со своим коллегой (2-м лидом). Для лидQA неприемлемо не знать дат ближайших билдов… для ЛидDEV неприемлемо не знать дат окончания основных этапов тестирования. ЛидDEV обязан делать ревью тестплана, ЛидQA — ревью дизайнов. За качество конечного продукта отвечают оба лида. Перед тем как говорить, что сроки двигаются из-за того, что тестировщики слишком поздно находить начали баги, подумайте, может девелопмент давал настолько сырые билды, что QA затратили на тестинг и багретест больше времени, чем планировалось? Перед тем как говорить, что сроки двигаются из-за того, разработчики все в последний момент правят, подумайте, может это QA тестирует дольше, чем планировалось?

Всегда помните, если Вы не сдержали обещания, и план поехал — это автоматом нарушает планы Вашего коллеги и ставит его обещания под угрозу. Не подводите друг друга

Ответственности

Под чем Вы подписываетесь, и что это значит:

• Заявка в тестирование — форма, которой ЛидДев подписывается под выполненной разработчиками работой
• Отчет по заявке — форма, которой ЛидQA подписывается под качеством проверенного билда
• Пройденный Тест план — подпись ЛидQA под качеством проверенных частей системы
• Дата окончания тех или иных работ — подпись лида под обязательством сделать что-то в оглашенное время

Любая неправильно поставленная подпись свидетельствует о том, что Вы плохо сделали работу. Бывали случаи, когда людей увольняли за подобные ошибки (к вопросу о серьезности).

Всегда думайте о том что Вы обещаете и приводите аргументы в поддержку Ваших мыслей.

За проект отвечает PM, если Вы принимаете решения вне зоны Вашей компетентности без ведома PM, значит Вы берете всю ответственность по этому вопросу на себя.

ЛидQA отвечает за оптимальный процесс тестирования на проекте. Оптимальным считается самый быстрый процесс, обеспечивающий своевременное нахождение багов и требуемое качество в результате.

ЛидДев отвечает за оптимальный процесс проектирования и разработки на проекте. Оптимальным считается самый быстрый процесс, обеспечивающий своевременные выдачи билдов в тестирование с заранее оговоренным качеством

Лиды обязаны своевременно отвечать на письма заказчика. Ни одно письмо не должно остаться без ответа. Если ответ не готов, то обязательно надо отписать, что ответ не готов, будет готов тогда-то. Если письмо касается Вашего проекта, но Вы не собираетесь на него отвечать, то обязательно скажите об этом PM. Если у Вас нет времени прочитать/ответить на письмо, обязательно пишите об этом PM.

Не ленитесь давать заказчику как можно больше информации. Помните, Вы потратите больше времени на понимание уточняющих вопросов и на подготовку ответов на них, если напишите что-то абстрактное или плохо структурированное. Помните, Ваше письмо будут читать люди разного ранга и с разным пониманием проблемы. Ваше письмо должно быть понятно им всем. В идеале оно должно быть интересным.

Если Вы пишете о проблеме или готовите вопрос, письмо всегда должно содержать:

• Вводную информацию — поймите, это Вы занимаетесь проблемой, и заказчик вообще не в курсе того, о чем Вы пишите и почему Вы это делаете
• Описание проблемы/вопроса
• Варианты решения с указанием плюсов и минусов и влияния на проект
• Рекомендации

Внимательно читайте письма заказчика и вовремя отвечайте на них.

Оценки трудоемкости

Вы отвечаете за оценки трудоемкости, которые даете. Не зависимо от того, кто оценивал — Вы или Ваш подчиненный. Не всегда возможно дать четкую оценку, но в этом случае, PM должен видеть оговорку, что оценка неточная и причину, по которой более точную оценку дать было нельзя. Если Вы даете  оценку, без каких либо оговорок, РМ считает ее окончательной и дальнейшие отговорки типа «ну я же быстрее оценить хотел (ла) и не успел (ла) все проверить» или «всегда есть риск» не проходят.

Вы не должны подгонять оценки под желания заказчика или PM. Если задача делается за 5 дней, а через 4 дня доставка — это не Ваша проблема. На основании информации от Вас PM принимает решение, как поступить. PM может принять решение делать за 4 дня но только если он:

• Договорился с Вами о переработке или
• Согласовал с Вами, как можно урезать задачу или
• Предлагает Вам помощь

В любом случае урезания сроков без Вашего ведома и согласия не было и не будет. PM просто не имеет права это делать.

Всякий раз, когда Вы оцениваете ту или иную задачу, Вы оцениваете наилучшее ее исполнение. Если Вы идете на компромиссы и это может отразится на качестве, Вы обязаны согласовать это с PM. Отговорки типа «я хотел (ла) сделать как можно быстрее, время было мало, поэтому получилось плохо» не проходят, если PM не был предупрежден.

Оценки всегда должны даваться из расчета 8-ми часового рабочего дня.

Вы обязаны уметь аргументировано защищать каждую данную Вами или Вашим подчиненным оценку. Если защитить не готовы — должна стоять соответствующая пометка, чтобы PM знал об этом. Зачастую, если PM спрашивает почему эта задача занимает 5 дней, а не 3 — это не «наезд» и не недоверие — это желание разобраться и убедиться в том, что Лид все продумал. Если в ответ на это следует ответ — «ну можно и за 3» или «ну мне кажется, что за 4 не успеем, а за 5 скорее всего успеем», то это большой красный флаг, что Лид дал оценку с потолка.

При работе над оценками Вы должны углубиться в вопрос настолько, насколько это требуется для выдачи наиболее точной оценки. Иногда PM может потребовать оценки АСАП, в этом случае лид должен оговориться, что оценки не точные, если не успел досконально вникнуть в вопрос и по возможности дать вероятный разброс.

Каждый раз, когда PM просит что-то сделать дополнительно, PM должен понимать, как это отразится на остальных задачах. Если лид не дает PM этой информации и просто говорит «сделаю», это значит, что на других задачах это не отразится. Если лид молчит, то аргументы типа «ты на меня стока навалил, что я забыл (ла), как семья выглядит» не проходят.

У каждого лида есть таск leadership. По опыту других проектов — это 10% от всего девелопмента. Но эта оценка может и должна меняться, если того требует специфика проекта или команды.

В leadership входит:

• митинги с руководством и подчиненными
• общение с заказчиком
• ревью работы подчиненных
• подготовка оценок на дополнительные работы
• обсуждение спорных вопросов с руководством и подчиненными
• постановка задач подчиненным
• планирование задач подчиненных
• ведение проектной документации
• сбор отчетности и проставление оценок
• подготовка статус репортов

Переработки

Переработки возможны в следующих случаях:

• PM попросил переработать — будет компенсировано либо отгулом, либо доп. оплатой (переработка в выходной обычно х2, в рабочий день х1.5)

Переработка не компенсируется, если сотрудник не выполнил свои обязательства

• Сотрудник вправе отказаться от переработки, если она не вызвана его ошибками.Подвела команда (например, тестировщики затянули хождение TP, поздно нашли баги и в результате, разработчикам приходится фиксить баги в очень высоком темпе, что часто приводит к переработкам. ИЛИ. Разработчики дали билд позже, чем планировалось и его надо тестить АСАП, что тоже часто приводит к переработкам). В подобных случаях вопрос о компенсации рассматривается отдельно. Вы должны помнить, что работаете в команде, и любые ваши ошибки отражаются на других членах команды и наоборот. Если доставка заказчику не будет сделано по плану, то наказаны будут оба лида, независимо от того, кто сделал ошибку. Поэтому не стесняйтесь требовать со своего коллеги выполнения обязательств в тех фазах, где вы пересекаетесь.
• Сотрудник стремится развиваться и старается сделать больше, лучше — в случае удачи компенсируется повышением ЗП, продвижением по служебной лестнице, желанием PM и других пойти на встречу в случае сложностей.
• Сотрудник отрабатывает отгул

В любом случае, если PM сам не договорился с человеком о переработке, разговоры типа «я и так тут ночами сижу» или «я тут пашу, а вы с меня еще и спрашиваете» или «меня здесь не любят, уйду я на фиг» не проходят, так как человек либо осознанно идет на переработку, либо свои же ошибки правит.

Лид не имеет права договариваться о переработке с сотрудниками без ведома PM — в этом случае переработка может быть не компенсирована.

Планы и отчетность

Планы должны строиться каждую неделю без напоминаний до 19-00 пятницы. Каждый лид планирует своих подчиненных. Если не ясно или есть сомнения, кто кому в данный момент подчиняется (бывает такое, когда человек у двух лидов или только что перешел от одного к другому) Вы обязаны уточнить это у PM.

Еженедельные статусы по проектам не должны писаться наспех

Еженедельные статусы  должны отражать все, что происходило на проекте за неделю + освещать открытые риски и вопросы.

Следите за тем, чтобы даты доставки в отчетах стояли правильно.

Cотрудники проектной команды обязаны присылать ежедневные отчеты и делать это в конце рабочего дня (а не утром следующего). Лид отвечает за то, чтобы отчеты приходили от всех его подчиненных ежедневно. Если отчеты не приходят в течении 2-3-х дней, для PM это значит, что лид плохо делает свою работу.

План всегда должен отражать реальное положение дел. Не фантазируйте, сами же потом запутаетесь. Не допускается иметь в плане закомпличенными задачи типа bugfixing, bugretest, customer support и т.д.

Все, что можно детализировать в проектном плане, должно быть детализировано

Все, что можно спланировать в проектном плане, должно быть спланировано на максимально возможный срок

Работайте с планом постоянно — Вы сами увидите, как это облегчит Вам работу — у Вас всегда будет полная картина перед глазами.

Требуйте от подчиненных, чтобы они постоянно сверялись с планами. Приучите их, что план — это святое, и если они его нарушают, они ставят под угрозу всю команду . Во избежание ситуации, когда кто-то будет работать ночами только из-за того, что в плане ошибка, требуйте от Ваших подчиненных присылать комментарии по задаче и требуемым срокам до начала выполнения задачи. В процессе выполнения задачи обязательно осведомитесь у него, не изменилось ли его понимание сроков, после того, как он вошел в тему.

Если Вы чувствуете, что человек не до конца понял задачу или Вы сомневаетесь, что он все запомнил, что Вы объясняли, требуйте прислать письменный отчет о понимании задачи. Помните, качество постановки задачи влияет на качество и сроки исполнения.

Не стесняйтесь уделять больше времени на формулировку задачи.

Принимайте это во внимание при планировании и оценках. Не забывайте, что не все присутствуют на митингах по обсуждению той или иной проблемы, не все участвуют в переписке с заказчиком. Многое, очевидное для Вас, совсем не очевидно для Ваших подчиненных.

Добрые советы, по организации рабочего процесса

1. Всегда ведите список своих задач на ближайшее время. Удобно выписывать их на лист бумаги вначале дня и вычеркивать по мере выполнения. Это позволит правильно расставить приоритеты и наглядно покажет, что еще предстоит сделать.
2. Научите Ваших подчиненных уважать Ваше время, общение с ними не должно занимать Вас на 100%. Если Вы чувствуете, что общение с кем-то занимает очень много времени, проанализируйте, как строится общение, и попытайтесь его оптимизировать. Иначе управляя 10 подчиненными, Вы только и будете успевать, что на вопросы отвечать. НО! Недостатка в общении быть не должно. Общение должно быть оптимальным.
3. Планируйте все, что можно спланировать. Ставьте себе дедлайны по своим таскам и соблюдайте их.
4. Возьмите за правило регистрировать ключевые моменты, произошедшие за неделю, как в ходе проекта, так и в управлении командой — это поможет Вам при составлении недельного отчета и оценке ребят за неделю.
5. Вот ключевые моменты дня:
   • Начало дня
   • Ревью почты и определение писем, требующих вашего ответа
   • Ревью списка оставшихся задач, составление задач на день
   • Оценка задач и определение приоритетов и последовательности выполнения (оставляйте время на непредвиденные задачи, сколько? смотрите по опыту на проекте).
   • Работа по задачам, апдейт списка задач
   • Прочтение дейли репортов от подчиненных, коррекция их действий, если надо
   • Ревью списка задач
   • Конец дня
6. Не доводите до того, что у Вашего подчиненного осталось задач меньше, чем на день. Если человек во что-то уперся, и у Вас нет возможности ему быстро ответить, у него должен быть список работ, на которые переключиться, иначе Вам придется всем отвечать АСАП.
7. Ставьте себе дедлайн по уходу работы и стремитесь в него вписаться, выполнив все запланированное… частые переработки и работа ночами быстро истощает.
8. Не давайте команде вести Вас, Вы должны вести команду.
9. Старайтесь всегда иметь запас до дедлайна, никогда не планируйте и не работайте впритык. Всегда добавляйте время на непредвиденные ситуации.
10. Старайтесь поддерживать хорошие отношения с подчиненными и коллегами по команде. Бывает, что мы работаем в стрессовой обстановке — в такой ситуации ни в коем случае нельзя ожесточаться и идти напролом. Учитесь слушать и понимать своих коллег. Помните, в VDI в основном работают умные и грамотные люди и если человек поступает определенным образом, значит, у него есть на то причины и их надо понимать и уважать, даже, если человек ошибается.
11. Не стесняйтесь общения с PM — PM и 2 лида — это тройка, которая тащит на себе весь проект, если между ними нет согласованности и единых целей, то это будет лебедь, рак и щука…
12. При планировании бейте задачи как можно мельче — помните хороший план, это больше половины успеха.
13. Не берите на себя то, за что не можете ответить.
14. Избегайте предположений, старайтесь иметь близкую к 100% уверенность в правильности своих решений.
15. Периодически поднимайте голову и смотрите на то, как организован Ваш день, все ли Вас устраивает в процессе работы, не копится ли у Вас негатива, что хорошо, что плохо. Думайте, как улучшить процессы. Не стесняйтесь советоваться с PM. Старайтесь не доводить до того, что PM делает вам замечание. А если делает, то подумайте, почему?

Резюме

• На лиде ответственность за людей, которые ему подчиняются
• На лиде ответственность за то, что делает его команда
• Хороший лид не боится говорить правду
• Хороший лид умеет аргументировано отстаивать свое мнение
• Хороший лид всегда контролирует ситуацию и имеет представление о ходе проекта в целом
• Хороший лид немного психолог, немного воспитатель, немного учитель и всегда надежная опора, как для PM так и для подчиненных и коллег
• Хороший лид умеет организовывать свой день и работу своих подчиненных, так, чтобы успевать делать все запланированное
• Хороший лид всегда развивается, анализируя свои ошибки и успехи
• Без хороших лидов успешный проект невозможен.

Запись Памятка Руководителю группы впервые появилась Портал TMGuru.

В связи с выходом статьи «Идеальный час» поступила масса вопросов относительно того, как построен учет рабочего времени у нас в Компании. Больше всего коллег интересуют принципы учета, глубина его детализации и способы сбора информации. Не вижу препятствий к тому, чтобы поделиться хорошими практиками и дать ответы на эти важные вопросы.

Прежде чем перейти к этим важным темам, предлагаю спуститься еще на один уровень вниз и попытаться ответить на более фундаментальный вопрос — зачем мы это делаем? Ясное дело, что учет вызван какими-то объективными надобностями — иначе кто добровольно будет осложнять себе жизнь?

Собственно, объективных надобностей три:

• Требование Заказчика на предоставление детальной статистики. Практически неизбежно для проектов с почасовой оплатой, что естественно — так как Заказчик оплачивает ваше время, он хочет быть уверен в том, что вы работаете, а не курите бамбук.
• Сбор статистики для внутренних нужд. К каковым можно отнести: сбор исторической информации для оценок будущих проектов, определение эффективности исполнения проекта для исчисления бонуса, рассчет ключевых показателей (key performance indicators, KPI) проектной деятельности.
• Сбор статистики для исчисления заработной платы. Для нас очень актуально, так как почти вся наша разработка ведется контрактниками.

Разобравшись с тем, зачем мы собираем информацию, давайте определим особенности, присущие каждому назначению. Это позволит нам выработать методику учета, оптимально решающую поставленные задачи.

Случай первый — мы имеем требование Заказчика на предоставление детальной статистики. Здесь все просто. Требования к периодичности (день, неделя, месяц, этап) устанавливает Заказчик. Требования к детализации (четверть часа, час, день) устанавливает опять же Заказчик. Информация интересна в первую очередь Заказчику, а собирается сотрудниками Исполнителя. Соответственно, наибольших проблем можно ожидать в случае когда информация, собранная сотрудниками Исполнителя, Заказчику не нравится. Например, Заказчику кажется, что времени на определенную задачу потрачено больше, чем нужно. Соответственно, задача менеджера по сбору и обработке информации видится мне так:

a. Сделать информацию полной — чтобы Заказчик точно знал, сколько времени потрачено, и когда это время было потрачено.
b. Сделать информацию внятной — чтобы Заказчик мог понять, откуда взялись эти цифры, и как они были получены.
c. Сделать информацию наглядной — чтобы у Заказчика и мысли не возникло спорить.

Соответственно, что можно посоветовать дле решения этих задач? Программа-минимум для того, чтобы сделать информацию полной:

1. Выбирать осмысленные названия задач, поставленных исполнителям. Название должно быть достаточным для того, чтобы можно было понять, о чем идет речь, даже через месяц после того, как оно выполнено. Оптимально — каждая задача есть реализация конкретного требования или функционала, например «Сделать UC-01 Login» или «Сделать сервис wsPollTriggerStatus»
2. Собирать информацию ежедневно — в конце недели вместо мучительных раздумий о том, сколько времени было потрачено на какую задачу, исполнители обычно вписывают «на глазок» цифры, «похожие на правду». При ежедневном сборе и проверке обеспечивается необходимая очистка данных (я называю ее refinement, «дистилляция»).
3. Отображать информацию в сводной таблице — чтобы видеть картину по крайней мере с еженедельной детализацией.

Невнятность — один из самых частых дефектов информации об использовании времени. Чтобы информация была внятной, надо:

1. Заранее договориться о способе учета рабочего времени. То есть — как, кем и с какой периодичностью собирается, кому предоставляется, какова процедура утверждения заполненных табелей учета времени. Это спасет вас от трений, кто кому был что должен представить, а кто кому что должен был утвердить. Трения этого рода портят отношения с Заказчиками и проводят к срыву регулярной оплаты счетов — эксцессы такого рода очень злят начальство (поверьте, будучи начальством, знаю, о чем пишу).
2. Обязательно (ОБЯЗАТЕЛЬНО) договариваться, какие категории задач вносятся в табель, а какие нет. Это же касается работы конкретных исполнителей. Это спасет вас от трений о том, нужна ли была данная конкретная задача или данный конкретный человек. Трения этого рода гарантированно приводят к снижению объема оплаченного времени на проекте, что опять-таки отрицательно сказывается на проектной команде и отношениях с Заказчиком.
3. Установить способ учета рабочего времени. Для Заказчика наиболее оптимальным является способ учета рабочего времени «потрачено часов на каждую задачу в день». Собственно, у вас нет никаких оснований ему возражать.

Чтобы сделать информацию наглядной, надо:

Согласовать форму предоставления Заказчику информации — файл и печатный лист, на котором сразу видно, кто, что, когда, сколько и почему. О почему — ниже.

1. Требовать снабжать отчеты о потраченном времени комментариями. Во всяком случае, если по какой-то причине эти значения отличаются от тех, которые хочет увидеть клиент. Например, простой комментарий типа «пришлось не только обновить структуру базы, но и перелить в нее боевые данные, которые уже начал вносить клиент, хотя его просили этого не делать» экономит массу времени и нервов менеджеру проекта, которого Заказчик спрашивает «почему такая простая задача, как запустить скрипт обновления базы, заняла два часа?!!»
2. Сводить для каждой задачи комментарии в единый список — чтобы составлялся своего рода «тезисный план» о том, как работали по задаче. Это особенно актуально, если над задачей работало несколько человек. Например, задача «подготовка прототипов интерфейса». Работали над ней как минимум специалист по юзабилити, дизайнер и верстальщик. Задача одна, работу делали трое, каждый оставил комментарии — соответственно, все комментарии сводятся воедино.

Собственно, рекомендации нехитрые. Видимо, поэтому и работают.

Кстати, данный вариант сбора статистики работает и в третьем случае (сбор статистики для начисления зарплаты). Собственно, в данном случае Заказчиком выступаете вы сами — примерьте описанные выше рекомендации «на себя» и убедитесь, что они не лишены смысла.

Итак, нерассмотренным остается только второй случай:

Сбор статистики для внутренних нужд

Зачем собирается статистика для внутренних нужд? Целей как минимум три:

• Менеджер и Спонсор проекта хотят понимать состояние проекта. В первую очередь — не будет ли превышения бюджета и расписания? Эти характеристики легко высчитать на основании информации об использованном времени.
• Менеджер и Спонсор проекта должны иметь возможность точно предсказывать, сколько времени займет тот или иной проект. Для этого им необходима накопленная база статистической информации. Имея на руках эту информацию, они могут делать оценки будущих проектов методом прямой аналогии, коий из всех методов является наиболее надежным.
• Менеджер и Спонсор проекта хотят понимать финансовую эффективность команды и проекта.

Итак, мы определили три задачи, которые мы должны решать при учете рабочего времени, выполняемом для внутренних нужд. Следует отметить, что кроме установления порядка предоставления отчетности требуется решить еще ряд проблем, в том числе организационных — иначе задачи будут нерешаемы. Предлагаю исследовать механизмы выполнения задач и решения проблем более подробно.

Задача первая — определять, не будет ли превышения бюджета и расписания. Отправной точкой здесь является наличие бюджета и расписания. Они есть у любого проекта, независимо от типа: у типичной заказной разработки — контрактный бюджет и график проекта, у проекта с почасовой оплатой типа «доработка» — бюджет и график этапа\задачи, у проекта типа «поддержка» — объем предоплаченного Клиентом времени в контракте на поддержку. Соответственно, любой проект в системе управления проектами имеет два параметра — одобренный бюджет, у.е. ( approved budget ) и одобренная длительность, раб. дней ( approved duration ). Их устанавливает Спонсор проекта — руководитель организации, давший «добро» на начало этого проекта. Эту практику необходимо выработать и неукоснительно соблюдать.

Далее все происходит предельно просто. Менеджер ставит задачи и определяет трудозатраты (work), которые могут потратить исполнители на выполнение этих задач. Исполнители отчитываются о выполнении задач, при необходимости запрашивая дополнительные трудозатраты. Менеджер с помощью метода под названием «анализ освоенного объема» ( earned value analysis , про него написано достаточно и нет нужды повторяться) рассчитывает два параметра — CPI и SPI ( Cost Performance Index и Schedule Performance Index ). Если они больше единицы — менеджер чуствует себя спокойно. Если они меньше единицы — он напрягается и рассчитывает еще один параметр — EAC ( Estimate at completion , оценка на завершение). Считает он ее для того, чтобы сравнить с одобренным бюджетом ( approved budget ). Если EAC > Approved budget — то пахнет жареным, это означает, что мы будем иметь превышение бюджета по завершению проекта. Что делать для исправления ситуации — вопрос не по теме данной статьи.

Конечно же, менеджер считает эту информацию не вручную. Для него это делает система управления проектами предприятия (Enterprise Project Management System, EPMS). Данные ему она представляет в виде простой и доходчивой информационной панели — см. рис. 1.

Рисунок 1. Информационная панель с информацией об исполнении бюджетов и графика.

В теории все выглядит все достаточно просто. На практике бывает существенно сложнее. Сложность №1.

«Исполнители отчитываются о выполнении задач». Отчитываться можно минимум тремя способами:

1. Процентов выполнено (0-100%). Подразумевается, что если задача на 8 часов, и выполнение 100%, то потрачено 8 часов. В общем случае верно, но не учитывает возможность того, что для достижения 100% готовности могло понадобится 10 часов. Соответственно, если трудозатраты проекта выросли на пару часов, а график сбился на полдня, то никто этого как бы не заметит. Кроме того, есть чисто субъективные сложности исчисления процентов — что для одного 75%, то для другого — 10%. Ввиду этих недостатков крайне не рекомендую использовать этот метод.
2. Трудозатрат потрачено — трудозатрат осталось (часов). Мой любимый метод. Подразумевается, что если задача на 8 часов, и ты ее выполнил — ты указываешь, что потраченное время 8 часов. Система сама считает, что процент выполнения равен 100%. Прелесть в том, что если в конце дня ты понял, что осталось еще на 2 часа работы, то указываешь в отчете «потрачено» 8 часов, «осталось» еще 2 часа — и система рассчитывает соответствующий процент выполнения, включая твои 2 часа в общий план и при необходимости сдвигая график проекта. У метода есть один большой недостаток — что делать, если человек на самом деле сделал задачу за 6 часов? Во многих компаниях это станет неразрешимой проблемой — раз человек отдан на проект на весь день, он должен отчитаться 8 часами, и не важно, сколько он там потратил на самом деле! Такие подходы существенно снижают ценность собираемой статистики, так как она не отражает реального состояния дел (см. ниже).
3. Потрачено на задачу, часов в день — суть метода объяснена в названии. Наверное, самый распространенный способ учета рабочего времени. Имеет только одно неудобство — собирать данные нужно каждый день, иначе в конце недели менеджер получает от десятка членов команды табели рабочего времени, заполненные по принципу «ну-я-не-сильно-помню-но-вроде-того». Табели нужно внимательно читать и при необходимости возвращать для корректировки. Для 10 человек процесс довольно муторный: 10 человек * 5 дней * пару задач в день = таблица из 100 строк. Кто будет вдумчиво в них вчитываться?

Итого — для того, чтобы исполнители осмысленно отчитывались о выполнении задач и на этих данных можно было использовать метод освоенного объема, требуется использовать 2-ой или 3-ий метод сбора отчетности. Первый, используемый почти во всех системах управление проектами предприятия по умолчанию, совершенно не годится.

Соответственно, необходимо принять один из методов в качестве организационного стандарта. И обязательно требовать от менеджера выполнения 4 основных задач:

1. Определить бюджет и длительность — сделать это правильно в начале проекта и корректировать оценки при изменения предмета и границ проекта.
2. Ставить задачи — оптимально каждая задача должны быть продолжительностью в день и поставлена в соответствии с критерием SMART — Specific, Measurable, Achievable, Realistic, Time-related.
3. Контролировать использование бюджета — ежедневно или в крайнем случае еженедельно, собирая отчетность об исполнении задач.
4. Контроливать исполнение бюджета — рассчитывая EAC и сравнивая его с одобренным бюджетом.

На этом сложности не заканчиваются. Сложность №2.

Знаете, зачем от вас требуют указывать каждый день 8 часов отработанного времени (даже если вы его не отработали)? Потому что оно должно быть отнесено на какой-то конкретный финансовый центр (cost center) — проект, отдел, заказ и т.д. Для каждого финансового центра в итоге считаются две вещи — затраты (cost) и прибыль (profit). После чего делается вывод о прибыльности или убыточности данного проекта, отдела, заказа и т.д. При этом возникает одна любопытная особенность.

Предположим, вас назначили на проект на один день на задачу с бюджетом трудозатрат 8 часов. Вы быстренько (за 4 часа) порвали задачу на британский флаг и тихо сидите и смотрите кино. При этом компания, что характерно, начисляет вам за это время зарплату. Поэтому при фактических трудозатратах в 4 часа на проект будет начислено 8 часов — думаю, вам теперь понятно, почему. Проблема в другом — эта вынужденная и экономически совершенно оправданная мера лишает статистику всякого смысла, так как на статистике в таком случае нельзя основывать оценки методом аналогии — получим погрешность в два раза (8 \ 4 = 2).

Что делать в такой ситуации? Программа-минимум — завести еще одно поле, назвав его real hours , hrs (реальные часы) и писать в него имеющие место быть значения, в том время как в поле work писать требуемые 8 часов. Подход неидеальный ввиду решения задачи «в лоб», но по этой же причине очень прост. В результате можно иметь статистику, подобную указанной на картинке, приведенной ниже, и делать осмысленные оценки длительности и стоимости будущих проектов. Другой способ — разнести ресурсное планирование и сбор отчетности в репозитарий проектной информации. При кажущейся излишней сложности метод в конечном итоге дает лучшие результаты.

Собственно, теперь осталось только рассказать о связи проектных метрик и бонусов. Но ввиду болезненности данной темы и существенного объема мыслей по поводу решил написать об этом отдельную статью, которая выйдет в ближайшее время.

В таком случае остается только резюмировать:

1. Нет идеального метода сбора отчетности. Метод надо соотносить с задачами, которые вы собираетесь решать с помощью накопленной статистики.
2. Статистика ради статистики бессмысленна. Конечно, интересно смотреть, на какие проекты уходит больше всего ресурсов. Но лучше использовать статистику для ответов на вопросы — как минимум вы можете использовать ее для того, чтобы делать осмысленные оценки будущих проектов. Но лучше всего использовать ее для измерения финансовой эффективности.
3. Накополение данных в репозитарии статистики опирается на метод сбора отчетности. При этом какой бы метод вы не избрали, потребуется его признание на организационном уровне, за исключением тех случаев, когда вы собираете данные «для себя» — например, для оценки будущих проектов конкретной команды. Но если не всех меряют одной линейкой, то полученные вами данные не могут служить показателем, скажем, вашей финансовой эффективности по сравнению с другими проектами.
4. В основе измерения финансовой эффективности — понятие «одобренный бюджет». Следовательно, пока такой термин не появится в официальном словаре организации вместе с процедурой его утверждения, методы измерения есть не более чем фикция.

Из этого следует, что организация учета рабочего времени — это не просто установка соответствующей программы с требованием предоставлять отчетность каждую неделю. Это — решение целого набора вопросов, в том числе организационных. И первый вопрос, с которого рекомендуется начать — «зачем мы это делаем?»

Запись Учет рабочего времени — почему, зачем и как впервые появилась Портал TMGuru.

Почему так трудно планировать? Почему фактическое время, потраченное на задачи, всегда выше запланированного? Даже когда мы доверяем оценки непосредственно тем людям, которые должны выполнять задачу, они все равно ошибаются. При этом они всегда находят тысячи оправданий превышению сроков — «дернули» на другой проект, кто-то помешал, отвлекли в бухгалтерию по поводу ИНН и так далее. Эта ситуация типична. В этой статье немного о проблемах планирования и их источнике — «идеальном часе».

«Во множестве компаний есть статистика об использовании рабочего времени. Но ни в одной я не видел статистики о качестве этого времени…» Том де Марко, Тим Листер. Peopleware, 2-nd Edition.

Хочу нарисовать гипотетическую ситуацию, которую, думаю, узнают многие менеджеры разработчиков.

Итак, предположим, что сегодня вечером было совещание по статусу на Вашем текущем проекте. У Вас работает разработчик Федя. Федя — вполне способный программист с солидным стажем. Вы ставите ему задачу Х. Выдав ему хорошо сформулированную постановку задачи, Вы спрашиваете — Федя, сколько времени тебе надо, чтобы закодировать задачу Х?

Федя немного думает и говорит — четыре часа, максимум — шесть. Вы резюмируете — окей, исходя из того, что завтра ты начнешь в 9 часов утра, в 6 вечера мы уже включим твое творчество в завтрашний дневной билд? Федя отвечает — Никаких проблем, все будет в лучшем виде.

Наступает завтра, 6 часов вечера. Федя не готов. Ему надо еще 2-3 часа. Почему не готов, объяснить толком не может. Вопрос «чем ты занимался весь день?!!» повергает его в ярость. Вы глубоко разочарованы в Феде. Оказывается, он разгильдяй — а ведь выглядит вполне способным программистом… Так трудно в наше время найти хорошие ресурсы…

Не грешите поспешными суждениями. Вы лучше меня знаете, что у каждого следствия есть причина. Давайте ее поищем. Понаблюдаем за Федей во время его работы, поищем эту причину.

Итак, хроника рабочего дня Феди.

• Реализация USE CASE-01 Login (4 часа)
  • 10:00. Пришел на работу. Был уведен на совещание по соседскому проекту в качестве консультанта.
  • 11:00. Выпил кофе. Встретил Ивана, вышли покурить.
  • 11:15. Сел писать UC-01.
  • 12:30. Пришли чинить кондиционер. Согнали с места, пью кофе, сходил покурил.
  • 13:00. Позвали в бухгалтерию. Долго распрашивали о каких-то бумажках со сложными аббревиатурами.
  • 13:30. Ушел обедать.
  • 14:30. Пришел с обеда, начал работать. Дописал почти все, осталась самая малость.
  • 16:00. Снова совещание. Сижу рисую в блокноте. Деваться некуда – меня сюда загнал заместитель директора.
  • 17:00. Через час выпуск дневного билда, а у меня еще ничего не готово!
  • 18:15. Получил от DTL нагоняй: «задача на полдня, а ты весь день с ней провозился, да еще и опоздал!»

Итак, причина прорисовывается, верно?

Сколько времени Федя потратил на непосредственно на написание кода? 15 минут + 1 час 30 минут + 1 час 15 минут. Итого — 3 часа! На осуществление его прямых обязанностей в Вашем проекте у него было всего три часа вместо четырех, которые были ему нужны! И он справился гораздо раньше — он потратил меньше чем четыре часа! Его хвалить надо было, а не ругать! Надеюсь, теперь Вы понимаете, почему его взбесил вопрос «чем ты занимался весь день?»

Он занимался работой. Просто КПД его деятельности был вынужденно низким. Не потому, что плох Федя. А потому, что продуктивность любого разработчика влияет то, что я называю «коэффициентом мусорного времени». Грубо говоря — это соотношение непроизводительных часов к производительным. В случае Феди — 5:3, что означает что для выполнения 4х часовой задачи ему был необходим весь день и еще немного следующего. Если посмотреть на его результат, то мы увидим, что это вполне справедливо — Федя лихорадочно заканчивал дописывать свой код после того, как рабочий день кончился.

Сразу хочется предостеречь тех, кто считает, что в их организации «мусорного времени» нет. «Мусорное время» есть всегда. У одних его больше, у других меньше. Пронаблюдав порядка двух десятков компаний, я вывел следующие значения «коэффициента мусорного времени»:

• Лучшие компании (две из 19)
  • 1\7
  • 1\6,5
• Средние значения
  • 2\6
  • 3\5
• Худшая
  • 4\4

Итак, лучше Вам, как менеджеру, сразу избавиться от иллюзии того, что «мусорное время» на Ваш проект не влияет. А теперь самое интересное — как учесть влияние «мусорного времени» на Ваш проект?

Действовать в данном случае стоит в двух направлениях:

1. учитывать «коэффициент мусорного времени» при планировании (обязательно)
2. снижать «коэффициент мусорного времени» путем устранения источников мусора (тема, заслуживающая отдельной статьи)

Давайте по порядку. Прежде всего — как учитывать коэффициент при планировании. Прежде чем учитывать, его надо определить. Определяется он элементарно просто — назначаете своим разработчикам несколько коротких и безрисковых, но осмысленных задач (при длинных или рискованных задачах начинают действовать факторы громоздкости или рисков, что нежелательно для «чистоты эксперимента»). Лучше всего на роль таких задач подходят типовые задачи по имплементации стандартных функций (отображение данных, создание элементов и т.д.) При этом просите их сформулировать оценки в «идеальных часах» (сколько надо времени, если сесть и писать задачу от начала и до конца, и никто при этом не будет мешать, без включения просадки, и если не надо будет есть, курить и т.д.) После этого нажмите кнопку секундомера и пусть все начинают. Сравните полученные фактические значения продолжительности с продолжительностью в идеальных часах. Поздравляем, вы получили «коэффициент мусорного времени». Идеально это будет что-то вроде 1:7 .

Итак, коэффициент есть. Теперь надо учесть при планировании. Самый простой способ сделать это — перейти от коэффициента к множителю, т.е. получить значение, на которое нужно умножить запланированную длительность проекта. В нашем случае для этого подойдет следующая формула:

Давайте рассмотрим действие формулы на примере. Предположим, у Вас есть проект, чистая продолжительность которого (без учета влияния «мусорного времени») равна 10 дням. При этом в рабочем дне 8 часов. «Коэффициент мусорного времени» равен 1:7, то есть один час в день «мусорный».

Уверен, что практика покажет, что эта оценка была правильной. Важно другое — без учета этого фактора Вы каждые 10 дней «теряете» один день. А если проект был длиной полгода, то по милости «коэффициента мусорного времени» Вы потеряете 12 дней — отстанете более чем на две недели… Знакомо, не правда ли?

Этот метод вполне точен и годится для оценок. Еще более точным методом может стать использование статистического моделирования — например, с помощью инструмента Riskology, разработанного Томом де Марко и Тимом Листером для моделирования влияния рисков на проекты. Получить его можно по адресу SystemsGuild.Com, и там же находится инструкция по применению. Согласно этой инструкции надо задать параметры проекта, внести новый риск непрерывного типа «Влияние мусорного времени», и задать коэффициент его влияния согласно инструкции.

Но учет влияния мусорного времени — это, собственно, только половина дела. Мусорное время есть не что иное, как непроизводительные издержки, а с издержками в любой индустрии принято бороться.

Что можно порекомендовать для борьбы с издержками? Мусорное время можно искать в четырех возможных областях рабочей деятельности:

1. Административная деятельность поддерживающих служб компании. Однажды с ужасом наблюдал, как строгая тетенька в очках несколько раз заставляла Ведущего разработчика проекта переделывать авансовый отчет, в то время как в переговорной томились представители заказчика. Стоит ли говорить, что такая ситуация недопустима. Не стоит забывать, что задачи Административно-хозяйственной службы — обеспечивать производственную деятельность, а не мешать ей. В своей компании, например, я установил такой порядок — бухгалтер готовит для сотрудника весь набор документов, и ему остается лишь поставить свою подпись.
2. Бюрократическая деятельность, связанная с проектным делопроизводством. Другая бездонная пропасть, поедающая время. Зачем заполнять журнал учета рабочего времени с пятнадцатиминутной детализацией, если заказчик этого не требует? Зачем снабжать документ из одной страницы тремя страницами шапок, обязательных к заполнению? Примеров такого бездарного использования рабочего времени можно привести много. Мой совет — обходитесь минимумом бумаги, и даже при этом автоматизируйте эту область деятельности по максимуму.
3. Рабочая обстановка самого офиса. Если люди начинают приходить на работу к восьми часам или уходить в час ночи — это верный признак того, что в офисе лучше всего работается когда никого нет. При этом может мешать множество факторов — скученность, телефонные разговоры, громкие обсуждения, духота.
4. Личные интересы сотрудников. Возможно, я кого-то удивлю, но достаточно много людей рассматривает работу как способ заниматься любыми делами за чужой счет. Чаты, форумы, поиск фильмов и музыки, онлайновые знакомства — вот далеко не полный перечень развлечений в рабочее время. Конечно, не надо путать теплое с мягким — форумы могут способствовать профессиональному росту, коммуникаторы можно использовать для общения с коллегами из других городов — но во всем хороша мера.

Если Вы ищете способов сокращения влияния мусорного времени, обратитесь прежде всего к этим четырем областям. Из собственного опыта могу указать несколько вещей, которые при внешней незатейливости очень часто помогают сократить мусорное время в разы.

1. Разрешите своим разработчикам отвечать на все письма, не связанные напрямую с рабочей деятельностью, в конце рабочего дня. Данная рекомендация особенно актуальна для больших компаний. Каждый день сотрудники получают как минимум два-три письма типа «сообщите», «проголосуйте», «представьте данные». Все это мешает сосредоточиться и отнимает время, при этом не является критичным. В конце концов, если я проголосую по поводу качества обедов три часа спустя — неужели небо упадет в Дунай?
2. Требуйте использовать голосовую почту на рабочих и персональных рабочих телефонах. Во-первых, это существенно сократит уровень шума в комнате, а во-вторых, позволит людям сохранять концентрацию, так как они не будут отвлекаться на звонки. Голосовую почту можно проверять на перекурах или кофе-брейках, убивая двух зайцев.
3. Сядьте так, чтобы видеть мониторы членов Вашей рабочей группы. После этого удивительным образом возрастет количество времени, которое люди уделяют работе и соответственно снизится время, уделяемое auto.ru. Обычно лучше всего расставить рабочие столы по периметру комнаты вплотную к стенам — это, во-первых, обеспечит достаточное количество рабочего пространства, во-вторых обеспечит свободу передвижения что важного для парного программирования, например, и в-третьих поможет Вам занять стратегический наблюдательный пункт, с которого все видно. Тем не менее, лучше объявить, что все хобби в интернете остаются на вечер — в конце концов, должна же быть у людей личная жизнь?
4. Станьте брандмауэрами перед Вашими людьми. Защищайте их от бюрократов, попыток вовлечь их в бесконечные совещания, начать менять им мебель в середине рабочего дня — одним словом, от любых действий, которые могут помешать им работать.

Вот, вкратце, и все. Надеюсь, эти несложные рекомендации помогут читателям бороться с коварством «мусорного времени». Как всегда, если у кого-то есть аналогичный опыт, свои инструменты или наработки, которыми он хочет поделиться, или мнение, которым он хочет обменяться — жду его по адресу dp@dpconsulting.ru.

Запись Идеальный час впервые появилась Портал TMGuru.

Представляю перевод статьи Джеймса Виттакера «Если вы стали QA менеджером«. Оригинальному тексту почти год, я прочла его первый раз как раз, когда сама оказалась на месте героя поста. За это время у меня появились комментарии к мнению Джеймса, поэтому, можно сказать, что мы соавторы получившейся статьи.

Оговорюсь сразу, что под «QA менеджером», как я понимаю, здесь нарисован тест-менеджер, но с большим влиянием на процесс и на качество. Такое очень часто встречается в командах и компаниях, которые выпускают на рынок свой собственный продукт. Так что, я оставлю оригинальную терминологию Джеймса.

Начните жить своим продуктом!

Джеймс:
Итак, вы оказались новым QA менеджером. Первое, что вам нужно сделать, это начать жить своим продуктов, загореться им.

Полностью растворитесь в вашем продукте, запоминайте рекламные речи, поймите его конкурентные преимущества, но сохраните при этом ваш скептицизм.

QA-менеджер должен быть также увлечен своим продуктом, как и менеджер разработки, но нам нужно сдерживать нашу страсть доказательствами. Будьте уверены, что команда тестирования не прекратит тестировать функциональность, стоящую за жарким рекламным спичем.

Более того, частью жизни с вашим продуктом является быть его пользователем.

К примеру, я сейчас живу без лаптопа и использую в своей повседневной работе только Chrome OS Netbook. Так как люди видят меня с ним в коридорах, мне доводится произносить рекламные спичи по многу раз каждый день. Великолепная практика, скажу я вам! Мне же доводится жить и с огрехами, и записывать штуки, которые ещё надо доделывать. Это хворост для пламени спора между разработчиками и другими стейкхолдерами, и это тоже заставляет меня взвешивать конкурирующие продукты. Когда у меня не получается сделать что-нибудь, что мне нужно, на моем Chrome OS Netbook и я вынужден использовать конкурирующий продукт, это порождает здоровую дискуссию о том, как пользователи воспринимают недостатки наших продуктов, и о том, как мы можем правильно преподнести плюсы и минусы нашего продукта потребителям.

И это прекрасный путь для начинания нового продукта, кстати ;-)

Юля:
Если вы приходите не просто в продукт, выпускаемый вашей компанией, а в новую компанию, начните жить вашей компанией. Её культурой. Поймите, почему она выпускает именно такие продукты. Чтобы приносить людям пользу, чтобы отвечать на их вопросы, чтобы решать их проблемы? Чтобы веселить их? Чтобы что?

Побудьте пользователем других продуктов вашей компании, чтобы понять, как они относятся к вашей продукции. Чего им не хватает: внимания, скорости, скидок? Что они не могут сделать с продуктами вашей компании, и как компания реагирует на это?

Поняв, как это происходит на уровне всей компании, гораздо легче понять, как это работает для для вашего продукта. Вы поймете, кто в команде идет in-line с компанией, а чьи цели лежат в другой плоскости. Вы поймете, кто на вашей стороне (а вы ведь – именно тот человек, который хочет сделать ваш продукт лучше для пользователя и успешнее для компании, правда же?), а кого нужно ещё переманивать. На кого-то можно махнуть рукой, а кто-то просто мешает работе над продуктом. Это шанс улучшить ситуацию. Потому что вы — новый человек со свежим взглядом, и во-вторых – потому что тестирование – это фильтр.

Вы, как тест-менеджер всегда будете аккумулятором информации от менеджера, разработчиков, аналитиков и пользователей. Именно на вас сходится много дорог, и именно вы говорите менеджеру: «Эй, мы сделали классную штуку, этим ребятам понравится! К тому же, она не падает под тестами вот уже вторую итерацию», и именно вы приносите ему вести, рискуя цельностью головы: «Ты знаешь, вот эта новая фича не может выйти на стабильность вот уже 2 недели, постоянно ломает почтовую рассылку. Надо больше времени на отладку, давай не будем включать в релиз».

И именно вы знаете количество петиций от пользователей после каждого нового обновления. Только зная, какое значение каждый из этих фактов имеет для компании, вы сможете правильно понять нужную стратегию и эффективно применить вашу энергию и знания.

Фокусируйтесь на тест-плане, сделайте это высшим приоритетом

Джеймс:
Если вы заняли уже существующую роль тест-менеджера в уже существующем продукте, есть вероятность, что тест-план уже тоже существует и что этот тест-план неактуален. Я не наезжаю на вашего предшественника, я просто искренен. Большинство тест-планов являются «временными» документами.

Объясню, что я имею ввиду под этим.

Тестировщики незамедлительно жалуются при виде неактуальных спецификаций: мол, разработчики быстренько склепали спеку или диаграмму, но как только они начали писать код, спецификация устаревает, т.к. код начинает жить своей жизнью. Довольно скоро код перестает соответствовать спецификации и документация становится ненадежной. Мои поздравления, если это не про вас, но мне доводилось встречаться с такой ситуацией намного чаще, чем с постоянно обновляемыми спецификациями.

Тестировщики очень любят жаловаться на это: «Как мы можем тестировать продукт без полного описания того, что он делает?»

Но разве не то же самое мы зачастую делаем со своими тест-планами? Мы наскоро клепаем тест-план, но как только мы начинаем писать тесты (автоматические или мануальные), как они начинают жить своей собственной жизнью. Довольно скоро тесты начинают расходиться с тест-планом, так как мы догоняем новые разработки или наш опыт подсказывает нам новый тестерский инсайт.

Тест-план стал в точности, как спецификация: Документ-Который-Был.

Юля:
Тест-план (как и все тестирование, конечно же), может работать на вас, а может на продукт. Иными словами, часто хочется применить все свои теоретические знания и накопленный опыт и отразить все предыдущие годы работы в документе под названием Тест-План-Всего.

Он будет оформлен по всем канонам, он будет включать сотни страниц, подробно объясняя его читателям каждый термин и расписывая каждую задачу. Но подумайте над тем, что, если вы не продаете тест-план как отдельную активность заказчику, то продукту чхать на термины и пропущенный пункт «Обоснование необходимости нагрузочного тестирования».

Продукту нужен рабочий тест-план. И всей команде нужен рабочий тест-план. Отлично, если ваш тест-план – это список модулей на доске и написанные маркером же рядом номера задач в таск-трекере и тегов в свне. Отлично, если актуализация вашего тест-плана – это merge еженедельномитинговых фоллоу-апов. Отлично, если он отражает суть вашего подхода к тестированию продукта и понятен любому члену команды.

Если вы делаете его для того, чтобы потешить свое чувство сертифицированного тест-менеджера – будьте честными в этом признаться. Хотя бы себе.

Джеймс:
И вот вы – новый тест-менеджер, сделайте исправления этих документов вашей первоочередной задачей. Вы узнаете функциональность вашего продукта, и вы увидите пробелы в текущей структуре тестов, которые нужно закрывать. Плюс к тому, у вас будет почва для разговора с менеджерами разработки, и вы сможете показать им, что вы серьезно относитесь к качеству. Менеджеры разработки в Гугле любят хорошие тест-планы, это дает им понимание того, чем вы занимаетесь.

Разберитесь с процессом и приоритетами релиза

Поздний цикл предрелизного тестирования – это самая нервная часть всего цикла разработки. Тест-менеджеры должны поддерживать баланс между правильным тестированием и обеспечением гармоничного релиза. Я советую посещать все девелоперские совещания, но чем ближе к релизу – тем точнее вы не должны пропустить ни одного. Будьте очень внимательны к их беспокойствам и проблемам. Самые ужасные предположения имеют тенденцию претвориться в действительность. Добавляйте тесты в ваш набор проверок, чтобы убедиться, что эти сценарии не случатся.

Юля:
Будьте всегда готовы ответить себе, команде и инвесторам, почему этот баг встретился 20 процентам пользователей и породил тысячи петиций. Почему вы не наняли ещё троих тестировщиков, чтобы протестировать тщательно все области, а не только самые приоритетные? Почему вы держите именно такой баланс между знанием о качестве и затратами на его контроль? Почему вы в последний момент кинули все силы на эту область, хотя в недельной давности тест-плане она шла вторым приоритетом?

Главное, чтоб вы четко понимали это сами.

Джеймс:
Ключевым здесь является провести поздний цикл предрелизного тестирования без неожиданностей. На разработчиков здесь нельзя полагаться, поэтому убедитесь, что они понимают тот факт, что ваш тест-план движется к финальному рывку. Трюк не в том, чтобы опираться на разработчиков в том, как проводить предрелизное тестирование, а в том, чтобы убедиться, что они в теме и поддерживают ваш план.

Я обнаружил, что в Гугле увеличение фокуса команды на мануальном тестировании искренне приветствовалось командой разработчиков. Найдите комфортную зону вашей команды разработки и удерживайте баланс между тем, чтобы всё-таки правильно тестировать, и тем, чтобы сделать финальные часы (дни) как можно безболезненнее.

Тестируйте ваш процесс тестирования

Джеймс:
Начните с чтения каждого теста-кейса и просмотра всей информации. Можно ли привязать эти тесты к тест-плану? Сколько тестов у вас есть на один компонент? А на фичу? Если баг находится за пределами процесса тестирования, создаете ли вы на него тест-кейс? Есть ли у вас процесс исправления или выбрасывания испорченных или неактуальных тест-кейсов?

Полноценность и основательность набора тестов – это ваша работа как QA менеджера. Вы можете не участвовать в написании или выполнении большого количества тестов, но они вы должны держать их все в голове и быть первым, кто выявляет прорехи. Это должно быть тем, за что новый менеджер возьмется с самого начала и должно оставаться ключевым для него всегда.

Юля:
Чем критичнее вы относитесь к своей работе, тем больше у вас права критично относиться к чужой. Считается, что тестировщик не должен ошибаться и не должен пропускать баги. В то время, как программисту вполне позволено их делать. Чтобы изменить это мнение, нужно действительно крепко тестировать не только работу программистов, но и свою собственную. Вы должны всегда видеть ещё возможности протестировать что-то лучше, тщательнее, если представится такая возможность. И вы должны четко понимать, от чего вы осознанно отказываетесь. И уметь объяснить это всей команде.

Чем более требовательны вы к своим тестам, тем более требовательными у вас получится быть к разработчикам.

Ищите пути для инноваций

Самый легкий путь выглядеть хорошо в глазах разработчиков – это поддерживать статус-кво. Многие руководители разработчиков высоко ценят покорную и зависимую команду тестирования. Многие из них любят предсказуемые и легкопонятные практики тестирования. Эта та штука, о которой надо беспокоиться меньше всего (ведь даже перед лицом очевидной неэффективности знакомый путь часто считается самым близким).

Как новый менеджер, ваша работа – не дать им отделаться так легко! Вы должны сделать список тех частей процесса, которые вас настораживают, и тех частей, которые кажутся чересчур громоздкими или неэффективными. Это те места, где стоит применить инновации. Будьте готовы к нервозности со стороны разработчиков, но покажите, что ваши старания приносят пользу и заключите долгосрочное пари!

Юля:
Очень важно выдерживать баланс между «так у нас принято» и «я знаю, как сделать лучше». Когда вы приходите в новой роли в новую команду, у вас есть огромный плюс и страшное оружие: «свежий взгляд». Если его применять правильно – вы взорвете тестирование на проекте (в хорошем смысле). Будьте готовы столкнуться с «это не заработает, потому что…», «мы это пробовали, это фигня…», «да ну , бред какой-то, лучше делать по-старому…». Жизненно важно отличать реальные причины того, почему здесь делается именно так, от пустых отговорок, за которыми люди скрывают привычку и нежелание двигаться.

Если вы возьмете правильный опыт этой команды и дадите ему новое дыхание – будет бомба!

Джеймс:
Нет совета, который мне показался бы универсально применимым касательно «Как лучше внедрять новшества». Что работает для меня – так это найти звезд в своей команде и убедиться, что они работают над тем же, чем горят. Как менеджер, это одна самая важная штука, которую вы можете сделать, чтобы повысить продуктивность и внедрить новшество.

Юля:
Так что — дерзайте! И удачи вам.

Запись Если вы стали QA-менеджером впервые появилась Портал TMGuru.

За последние 2 года мне удалось «поосваивать» — в хорошем смысле слова — несколько разных по сложности о составу команды проектов. Каждый проект уникальный. А задачи с созданием группы тестирования — вроде бы одни и те же…

Новый проект. Новые люди. Новые традиции и новые горизонты в тестировании.

1. Взаимоотношения с командой и пользователями
2. Тестовая лаборатория
3. Учет работ и планирование
4. Документация и База знаний
5. Визибилити и Отчетность

Обозвать шагами — не поворачивается клавиатура. Каждый шажок из одного направления должен включать шажок в другое — и вот таким осминожком нужно двигаться, чтобы успеть везде.Заметка получается громадная (не знаю откуда у меня появляется такое стремление к гигантомании), поэтому разделил на две (а может и на три — будет видно куда приведет психоанализ).Сегодня поговорим про взаимоотношения и тестовую лабораторию. Мой опыт. Мои евристики.

ВЗАИМООТНОШЕНИЯ С КОМАНДОЙ И ПОЛЬЗОВАТЕЛЯМИ

КАК ЖИВЕТЕ?

Первый вопрос команде

Знаете, какой мой первый вопрос к новой команде?Ни о технологиях, ни о практиках, ни о хотелках менеджеров этот вопрос. И кстати, я его никогда не произношу, никому не задаю, но «подразумеваю» постоянно.Главное, что я хочу понять с самого первого шага в проекте:

Что это вы за команда такая, что это вы за групка людей, которая вот так просто, легко и беззаботно жила все это время без тестировщика и, может быть, жила бы и дальше если бы я не пришел?

Первые вопросы команды

Вы может быть удивитесь, но

Очень может быть, что разработчики и менеджер проекта хотят от вас совсем не того, что вы пришли им дать.

Честно! Ожидания с обеих сторон могут быть различными.Вы хотите зрелых процессов, а им, может быть, нужно только пройти аудит.Вы хотите продукт с небольшим количеством критичных багов, а они, может быть, только быстрой победы, промоушена и уйти на более зеленое пастбище.Вы хотите знать нужды пользователей, а они понимают это как посягательство на их полномочия (это больше про менеджеров).

Спроси чего ждут от тебя начальники и команда — договорись что будешь делать в первую очередь, пусть это не будет нежданчиком для тебя и для них.

У меня в календаре стоят даты, когда я набираюсь смелости и задаю в лоб менеджерам вопросы
- вам хорошо, от того что делают тестировщики?
- вы довольны достигнутыми результатами?
- что еще могут сделать тестировщики?
- когда вы хотите это иметьА потом смотрю на список и произношу:
- … ммм…да… а теперь, когда мы все поняли, что хотим очень многого — давайте расставим приоритеты что ли…Понять чего хочет «начальника» поможет не наступить на мозоль или грабли. В первом случае можно сделать неприятно кому-то, а во втором случае — заработать шишку себе. Шишка — не орден — гордиться нечем ;).

Делиться опасениями, рисками и проблемами
Очень может статься, что о проблемах, с которыми вы сталкиваетесь знают только вы и ваша семья.На совещании промолчал, дома — наорал на жену.

На работе, в отличии от семьи есть две крайности:

- Ну ты же ничего не говорил.

и

- Ну тебя же взяли, чтобы ты проблемы решал, а не рассказывал о них.

Когда то меня подобные ответы заставляли выпучивать глаза и глотать ртом воздух: они что ничего не видели?

Прошло время и я поседел поумнел и набрался наглости опыта. Теперь каждый в команде знает о моих проблемах и как я их решаю. Ибо

Если человек говорит, что он решает проблему и планирует решить ее к определенному сроку, определенным способом, можно либо посоветовать, как сделать быстрее, либо — не мешаться под ногами.

Хотя всегда могут найтись излишне инициативные сослуживцы и начальники…и ведь лесом их не пошлешь…

КОМАНДА — МОЙ КРУГ… МОЙ ПЕРВЫЙ КРУГ… ВТОРОЙ… ТРЕТИЙ…

Знакомиться активно

Быть новичком это и выгодно и невыгодно одновременно. Выгодно, поскольку у нет еще груза ошибок, невыгодно — также нет и авторитета полезных решений. Но ни в одной команде не бывает так, что все против — всегда найдется человек, который может стать первым кругом.Построить первый, второй и прочие круги общения — одна из первых главных задач новичкаПозже вы будете складировать людей в свои круги, но сперва попытайтесь найти среди этих сильных личностей тех… кто любит печеньки )))). Нет честно — ни одна команда разработчиков так и не устояла перед анекдотами, историями из жизни и печеньками. Программисты как дети, ей богу!

Запоминать новых людей

 

Как опытный новичок советую вам с первого дня создать страницу в вашей локальной вики и описывать в ней людей, с которыми вы общаетесь. Конечно, когда ваша команда локальна и не превышает 10 человек, можно обойтись без крайностей.В текущем новом проекте, за три месяца мне уже пришлось общаться кроме своей команды (15 человек в 6 странах) еще с 7-ю специалистами из 5 параллельных проектов. Из 23-х специалистов три месяца назад я знал только двоих.  С 6-ю я общался всего один раз. Без записи — как вспомнить имя Rohit Gnapnadesh и, что именно он отвечает за Emma сервисы на UAT?


Не бояться быть дураком и задавать вопросы
Я не знаю лучшего способа узнать о чем-то, чем спросить самому. Редко в командах есть хорошие учителя. Приходится самообучатся, записывать и применять все самому (Если вы ничему не научились из этой книги — это ваша собственная вина).Если не знаешь где что найти, то подход только один — спрашивать, спрашивать, спрашивать. Ибо

Быть дураком не стыдно. Стыдно продолбать баг на 300 килоевро из за своей скромности.

КТО ТАКОЙ КОНЕЧНЫЙ ПОЛЬЗОВАТЕЛЬ?

Познакомиться с пользователями

Еще жив в моей памяти проект, в котором мы не знали своих пользователей. Вернее не знали всех пользователей. А их были десятки… К тому времени как сменилось две команды разработки, 3 ITPM-а, несколько вендоров, и, наконец, пришел я — остался список из 7 проектов, которым мы и предоставляем услуги передачи и обработки данных. Про проблемы остальных мы узнавали, только когда релизили новую версию продукта. Узнавали весьма с печальными последствиями.Это конечно редкий случай, но каждый раз, когда я появляюсь в проекте я хочу знать, кто использует нашу программу и как он ее использует.Только зная как конечный пользователь использует программу — я понимаю как действительно работает программа и как ее нужно тестировать, а также  — как она не используется и как ее тестировать не нужно. Определяются риски и уменьшается объем тестирования. Уменьшается объем тестирования! Нет даже так УМЕНЬШАЕТСЯ ОБЪЕМ ТЕСТИРОВАНИЯ!!!

Найти способ собирать жалобы пользователей

Я сразу пытаюсь присосаться к любому каналу связи, где пользователи жалуются. Нет ничего полезнее, чем крик души от пользователя. Желательно, чтобы этот канал был единственным и широким — там должны быть все.В этом похожи все сервисы — и продажа товаров, и туристические туры и разработка ПО:Жалобы пользователей формируют стратегию улучшения качества продукта, потому что о качестве продукта правду могут сказать только те, кто его используют, кто зарабатывает или теряет деньги используя продукт.


Жалобы пользователей это не тот случай, когда молчание — золото ;)

ТЕСТОВАЯ ЛАБОРАТОРИЯ

ГДЕ ТЕСТИРОВАТЬ?

Разработчик может сказать: «У меня баг не воспроизводится… Будем закрывать?»


Тест менеджер может спросить: «Нашел проблему?…А как работало раньше — в предыдущей версии?»

Проект менеджер может поинтересоваться: «А насколько данные в тестовой лаборатории близки к тем, что на проде?»


Вопросы не редкие, единого рецепта нет, и задуматься нужно уже с самого начала.

Отказаться от «не воспроизводится»

Разные данные, разные способы установки/запуска приложений, разные наборы компонент — все это очень сильно влияет на конечный результат.Если в системе может быть разным вообще все — утверждать, что тестировщик в описании бага не упомянул главные детали конфигурации не совсем честно. Кстати, сохранять целиком конфигурацию — тоже не всегда возможно (объем данных, архитектура компонент и т.п  и т.д)
Не каждый разработчик (к сожалению — и не каждый тестировщик тоже) понимает, что нужно одна точка входа для тестировщиков, разработчиков, пользователей и других заинтересованных в проверке лицСлова «у меня не воспроизводятся» — стоят дорого. От их причин нужно избавляться. Моя первая задача в этом случае выбить себе тестовую лабораторию.Вторая задача выбить тестовую лабораторию для программистов.Третья задача  — сделать их похожими.Понимать как работало раньше — в предыдущих версиях

Бывает, что баги живут несколько релизов. Поэтому приоритеты у таких багов, как правило, но не обязательно — ниже чем у регрессионных.Понять — как работало в предыдущем релизе — еще одна задача, связанная с настройкой тестовой лаборатории. И не всегда эта задача простая. Ох, не всегда.Определиться с детализацией псевдо-прода:

Игра «давайте сделаем одну тестовую лабораторию» нередко проходит с крайностями:Раньше и без этого обходились — т.е. и за баранку с бубликом нам этого не нужноДавайте сделаем все как на проде — т.е. не важно сколько времени нам понадобиться, не важно что мы пока не знаем что именно нужно, но не начнем тестировать, пока не будет все прям как на проде. И сердце — нам в руку и данко — во главе тест группы.И вот такие бальные танцы бегемотиков между двумя полярными мнениями порой и называют стратегией развития отдельно взятой тестовой лаборатории … хех.Цена и риски — это два основных существительных в споре.
Тестер:Будет лучше?
Менеджер: Да
Тестер: Сколько мы потратим на это времени или денег?
Менеджер: Нужно тратить деньги и время?Все работы связанные с тестовой лабораторией нужно свести к минимиму

Легко и быстро установить с нуля

Легко и быстро переустановить

Легко и быстро настроить

Легко и быстро скопироватьЛегко и быстро перегрузитьЛегко и быстро получить сообщения об ошибкахЛегко и быстро прочитать логи

Легко и быстро понять — какой релиз кандидат установлен…

Тратить на поддержку тестовой лаборатории мало, ибо есть много других вещей, которые нужно сделать.

ОТ КОГО БЕРЕМ, КУДА ОТДАЕМ

Построить карту приложения

Первый, второй, третий круги бывают не только у людей. Они есть и у приложений тоже.Представьте себе схему метро.Кольцевая это ваш проект.Все что вне — приложения с которыми обмениваемся данными.Первая станция — это первое приложение, вторая это приложение, которое общается с первым приложением, третье…очередное….последнее известное. Примерно так выглядят приложения в банках. И порой черт ногу сломит, чтобы узнать откуда  к нам приходят данные и куда уходят. И — кто на этом заработает ;)Поиск зависимостей, upstream|downstream приложений — еще один важный вопрос. Ибо это практически то же самое, что искать и разговаривать с клиентом.Понять — можно ли использовать псевдозаменители приложений

Проблема всех  зависимых приложений обменивающихся информацией —  в том, что они не подвластны тестировщику.Можно планировать, отслеживать, упрашивать, но жизнь показывает свою пятую точку и оказывается, что на последней неделе регрессионного тестирования одно из приложений, за которое отвечает другая команда отваливается, либо из за инцидента на проде они вынуждены гонять тесты производительности, либо еще какая нибудь детская неожиданность и твоя команда опять остается один на один с решением:
— выкатиться не протестировав связку приложений,
— отложить релиз.

Псевдозаменители, симуляторы, заглушки — одно из дешевых решений.

Понять где мы можем заменить реальные внешние системы на симуляторы и насколько будет критично их использовать — еще один хороший вопрос в копилку новичка тестировщика

Оригинальная публикация

Запись Процесс с нуля. Первые шажки — 1: Взаимоотношения и Тестовая лаборатория впервые появилась Портал TMGuru.