Cogito, ergo sum

Отзывы на тренинги - зачем и какие?

2010-12-18T04:02:00.004+03:00

Последнее время неоднократно поднималась тема отзывов на тренинги (пруф1 - в блоге Алексея Баранцева и пруф2 - в блоге Татьяны Голубевой).

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

В соответсвии со свежепридуманной классификацией, существует 4 типа отзывов:
* Позитивные неконструктивные
* Негативные неконструктивные
* Позитивные конструктивные
* Негативные конструктивные

Позитивные неконструктивные отзывы

Это отзывы "Всё супер!", "Спасибо, классно!" и "Приезжайте к нам ещё!".
Таких отзывов преобладающее большинство.

Что дают такие отзывы?

Тренеру: приятно.
Потенциальным ученикам: ничего - неинформативно. Если кому-то что-то было "супер", то кому-то ещё оно может быть совсем не супер, потому что "суперы" у всех разные.

Негативные неконструктивные отзывы

Это отзывы из серии "Полная фигня!", "Ерунда!" и "Бесцельно потраченное время!". Таких отзывов у меня, к счастью, не было :)

Что дают такие отзывы?

Тренеру: ничего*.
Потенциальным ученикам: ничего*.
* - зависит от %, если таких отзывов много - значит что-то явно не так. Но что?

Позитивные конструктивные отзывы

Это отзывы, проясняющие, что именно понравилось участнику. К примеру: "Упражнение про Емелю было очень показательным" или "Самостоятельные задания помогли многое понять и научиться применять на практике".

Что дают такие отзывы?

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

Негативные конструктивные отзывы

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

Что дают такие отзывы?

Тренеру: сразу видно, что следует улучшать. Какие моменты исправлять, что именно не нравится - в общем, "куда копать". При этом, изменения не всегда затрагивают тренинг. На тренинг "Управление автоматизацией" я однажды получила негативный отзыв, что этот тренинг рассчитан только на менеджеров. Но так как это полностью соответствовало действительности, то результатом такого отзыва стало дополнение описания, в котором я дополнительно сконцентрировалась на том, что тренинг рассчитан именно на управление и не затрагивает технические аспекты.
Потенциальным участникам: сразу видно, в каких случаях ходить НЕ стОит. Если описанный "выпускником" негатив для вас важен, то вы просто не пойдёте на такой тренинг и сэкономите своё время и деньги.

Выводы:

Тренеру: Делайте анкеты, способствующие конструктиву. Лично у меня в анкете по разным строкам/параметрам тренинга (Материал, подача, организация) идут 2 столбца: "что именно понравилось?" и "что хочется улучшить?".
Участнику: Если вы посетили какой-то тренинг, то помимо обучения вы так же были и его тестировщиком. Конструктивные отзывы (и позитивные и негативные) ОЧЕНЬ полезны как тренеру (он сможет сделать тренинг лучше), так и потенциальным ученикам. Не экономьте несколько минут - поделитесь мнением!

.

Kiev Post-Mortem

2010-12-15T04:48:00.005+03:00

На прошлой неделе я была в Киеве.

Нет.

Я БЫЛА В КИЕВЕ!!!

И это событие во многом знаменательное.

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

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

В-третьих, потому, что во время киевских тренингов был побит мой последний рекорд оценок. Средняя оценка за третий день составила 4,92. Этой цифре я тоже очень радовалась, но уже не по-детски :)

И в-четвёртых, потому, что у меня впервые была настолько интересная, открытая и весёлая группа. Три дня пролетели незаметно, и это было удовольствие, которое "работой" назвать не получается. Ребята, спасибо, вы просто супер!!!

Большое спасибо Киеву, участникам и уходящему году за это замечательное приключение!

Почему классно быть тренером?

2010-11-25T05:24:00.004+03:00

Кто-то может решить, что эта запись - пиар курса Орлова и Панкратова. Если и так, то это не специально :) На самом деле, я просто хочу похвастаться и сказать:

Я СЧАСТЛИВА, ЧТО Я - ТРЕНЕР!

Логичный вопрос: "Почему?". Ниже - логичные ответы :)

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

2. Я общаюсь с динамичными людьми. Динамика для меня важнее всего. Никогда нет чувства "болота". Всегда есть ощущение стремлений, роста. Развивающиеся ученики непрерывно транслируют развитие. Это мотивирует и привносит позитив!

3. Я бываю в разных городах. Только благодаря тренингам я смогла пообедать на 80 тысяч рублей. До сих пор хвастаюсь! :))
Ах, да, это были белорусские рубли в Минске.
Через 2 недели лечу в Киев - мой самый-самый любимый город!

4. Я всё время развиваюсь. Меня развивают ученики вопросами. У меня выписан огромный план по развитию, который я вижу необходимым, чтобы быть эффективным тренером. Надо не отставать от отрасли, надо всегда быть "на волне" - новые инструменты, новые техники. Тренинговая деятельность меня мотивирует развиваться ещё больше!

5. У меня много друзей. И, кстати, в разных городах. И, кстати, они очень умные и динамичные. Угадайте, где мы познакомились?

6. Чтобы провести 2х часовую онлайн-встречу, мне нужно в среднем 12-15 часов на подготовку. Обычно, я готовлюсь по ночам. С ноутбуком. В кафе. С чашечкой любимого латте с карамелью. Работа в подходящем графике и прекрасном окружении - для меня это важно!

7. И да, я на последок оставила самое главное. Я ОБОЖАЮ проводить тренинги, ОБОЖАЮ когда вижу прогресс у учеников, когда они делятся результатами и рассказывают про свершения. Мне это НРАВИТСЯ. I'm obsessed with it!!!

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

Представили?

Это я!

SQA Days в 2:00 АМ

2010-11-20T01:50:00.011+03:00

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

Но...

Если вы думаете, что доклады - самое интересное, то вы ошибаетесь :)

Для тех, кого здесь нет, поделюсь фотоотчётом ночной жизни SQA Days.

Почему бы в 2 АМ не обсудить протоколы?

На этой фото - эпичесий момент. Борис (кодовое имя "Форм") рассказывает Олегу (кодовое имя "Актив") личную историю про ванну, кота и свечи:

Это не просто бородатый человек. Это мой самый любимый бородатый человек в мире :)

Хвастаться не хорошо. Но майка классная :)))

Результаты конкурса на самого красивого бармена:

2 Великие Женщины:

На заднем плане пытаются обсуждать тестирование...
Подозреваю, что безуспешно :)

Школа Успешных Тестировщиков

2010-11-13T06:21:00.003+03:00

По последним данным разведки, 25 ноября, в 16:00 по МСК, начнётся онлайн-курс "Школа успешных тестировщиков".
Она будет проводиться впервые, поэтому я немного боюсь :)

НО это не главное.

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

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

По-хорошему, здесь надо дать ссылку на программу. Но настоящий тестировщик её и сам найдёт, а ненастоящих мы не берём :)

Так что, если Вы хотите быть Творцом и Исследователем в тестировании - Welcome!

А если не хотите - то лучше не записывайтесь!

Про микроменеджмент

2010-11-13T04:42:00.004+03:00

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

Хотя...

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

Это - МИКРОМЕНЕДЖМЕНТ.

Микроменеджмент - это подход, при котором сотрудникам даются маленькие задачки. За их выполнением зачастую непрерывно следят на каждом этапе. Сотрудникам чётко определяют, КАК что сделать. За них всё разжёвывают, стоя за спиной и говоря: "Нажми сюда, теперь сюда, таааак, чуть левее..."

Финиш.

И знаете, что самое ужасное?

Микроменеджмент проявляется почти у всех!

Почему микроменеджмент - это плохо?

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

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

3. Потому что он демотивирует сотрудников.
Я Вам не скажу про всю Одессу, но инициативные и стремящиеся к развитию сотрудники ненавидят, когда им всё слишком строго определяют. Им нужно ТВОРЧЕСТВО. А вместо этого микроруководиль превращает работу своих сотрудников в РУТИНУ.

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

5. Потому что он вызывает bottleneck. В лице руководителя.
Потому что ему везде надо сунуть свой нос. Но он сконцентрирован на мелочах. И он очень занят. Ну, вы понимаете, результат неизбежен.

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

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

Почему?

1. Так привычнее.
Откуда появились менеджеры? Не из отдельной капустины и не из соседнего института. Менеджеры - бывшие исполнители. Им привычно, уютно и комфортно решать исполнительские задачи. А бремя ответственности эффективного менеджера, умеющего делегировать - некомфортно и неуютно.

2. Так круче.
Представьте, насколько обидно неуверенным в себе менеджерам, если их получасовое опаздание на работу не вызовет панику, потоп и пожар одновременно? Зато, если они сделают себя узким горлышком, они всегда, всегда, всегда будут самыми важными и незаменимыми. Хм, и вправду круто!

3. Им интересно.
"Давайте поиграем в решение задачки Х", думают микроменеджеры. И играют :) Забывая, что это НЕ ИХ игра.

4. Они никому не верят.
Ни себе, ни окружающим. А вдруг он не справится? Нет уж, лучше я ему помогу заранее. Тогда мы точно не успеем сделать самые главные проектные задачи, но вот эту нанохреновинку мы прикрутим как надо!!

5. Им страшно.
Они боятся второго вселенского потопа и зачитываются статьями о теории заговора. И естественно они боятся, что их сотрудники будут слишком круты и посягнут на Босса. Поэтому, они очень хотят, чтобы их сотрудники были всё менее и менее толковыми, свободными и развивающимися.
И всё равно просыпаются по ночам в холодном поту :)

Если мой босс - микроменеджер, ТО...

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

Если я - микроменеджер, ТО...

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

p.s. При ответе на вопрос "Я микроменеджер?" важно быть честным с собой :)

Шаблон чек-листов

2010-11-08T02:50:00.005+03:00

Чек-листы иногда бывают нужны, иногда полезны, иногда необходимы. А знать, какими они бывают и как их можно использовать, нужно всегда.

Я свела в одной табличке 5 самых простых видов Ч-Л, снабдив их небольшими примерами и сравнением характеристик.

На полноту результатов не претендую, если есть что добавить - welcome!

Скачать сие творение мысли можно здесь:
http://quality-lab.ru/files/checklists.xls

Ода тестированию производительности, или ХВАТИТ ПУТАТЬ ЕГО С НАГРУЗОЧНЫМ!

2010-11-01T07:50:00.005+03:00

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

В результате такого восприятия теряется понимание тестирования производительности, которое является НУ ОЧЕНЬ важным, потому что:

1) Вы любите, когда что-то тормозит? Клиенты тоже не любят, обычно баги производительности являются критичными.
2) Чаще всего проблемы с производительностью являются архитектурными. Когда клиенты их репортят, исправлять их уже поздно.
3) Локализовать ошибки производительности - это сложно, это действительно искусство.
4) Неграмотное тестирование производительности ("здесь что-то тормозит") почти всегда ведёт к тому, что критичный баг переходит в разряд KNOWN ISSUES. Чтобы этот баг мог быть исправленным, тестировщику придётся потрудиться!

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

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

1) Отлавливаем "провалы" в производительности.
Разработчики могут вносить ошибки, связанные с производительностью, в любой момент. Чем раньше они узнают о проблеме - тем лучше.

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

Что важно:

- автоматизация. КАЖДЫЙ билд значит КАЖДЫЙ, это важно и чтобы вовремя заметить проблему, и чтобы чётче локализовать причины для разработчиков. Тесты на скорость работы - первые кандидаты в автоматизацию.

- "правильный" набор файлов. Это должны быть наиболее часто используемые пользователями размеры и типы файлов, чтобы наши тесты были наиболее приближены к жизни.

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

2) Сравниваем себя с конкурентами. В то время как маркетологи всё ещё гоняются за "фичез-листами", пользователи уже давно ищут телефоны без фотокамер. Пользователям важно ПРОСТО и БЫСТРО. Ну, и ещё 5-10% от функционала Вашего ПО. Поэтому, нам надо проверять, насколько наша скорость сопоставима со скоростью конкурентов. И если мы в 2, 3, 5 раз медленнее - бить в колокол.

Что важно:

- обеспечить абсолютно одинаковые условия. Окружения, файлы, последовательность действий.

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

3) Ищем "провалы" производительности, зависящие от внешних факторов.
Часто бывает такое, что пользователи жалуются "медленно", а мы вроде бы (по своим замерам) в несколько раз быстрее конкурентов. Поддельные тестировщики в ответ на такие жалобы в support отвечают "у нас всё хорошо". Настоящие тестировщики уже знают, в чём причина!
Узнаём всё, что может влиять на скорость работы. Типы файлов? Размеры архива? Файловая система? Операционка? Размер кластера? День недели? Расположение звёзд? И проводим тесты, сравнивающие производительность в зависимости от этих факторов. Зачастую бывает такое, что из-за использования неграмотного драйвера сохранение архива на фат может занимать в 30 раз больше времени, чем на нтфс, который входит в Вашу "стандартную" конфигурацию. Пользователи просто не дождутся результата!!
ОДНИМ из параметров тестов МОЖЕТ БЫТЬ количество подключений в клиент-серверном ПО. Все остальные тесты НЕ имеют отношения к нагрузочному тестированию.

Что важно:

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

- исследовать архитектуру продукта, делать тестирование производительности grey-box техникой. Поговорите с разработчиками. Они конечно же скажут, что ничто не может влиять на результат - у них работа такая :) Узнайте, какие ветви кода вызываются в зависимости от каких условий. Подумайте, как Вы можете вызвать не проверенные ветки кода, как задействовать эти условия?

4) Ищем узкие горлышки aka bottleneck'и. Если наш продукт неэффективно использует ресурсы компьютера, то мы либо теряем огромный запас в скорости работы, либо становимся почти неработоспособными на конкретных "железках". Свой продукт надо знать в лицо! Что ограничивает его скорость?
При проведении тестов, обязательно включаем все возможные мониторы. Какой ресурс занят на 100%?

Никакой, и до 100% всем далеко? Проблема алгоритма, мы написали немасштабируемый софт!

Один, а остальные близки к нулю? Очень велика вероятность того, что мы не используем огромный запас скорости!

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

5) Общие советы.
Чтобы сделать тестирование производительности эффективным:

- убедите аналитиков и маркетологов или кто-там-у-вас-определяет-что-нужно-пользователям, что производительность - это ВАЖНО! Во-первых, это действительно важно. Во-вторых, к счастью, почти все и так это понимают.

- привлекайте к тест-анализу разработчиков. Они могут помочь как никто другой.

- сделайте ОЧЕНЬ понятный отчёт. Если вывести в текстовый лог результаты операций, то есть шанс, что вы не поймёте результатов вообще. Где бага, где всё хорошо?
Грамотно сгруппируйте результаты замеров, чтобы результат был понятен и очевиден.

no pasaran!

Магия дедлайна

2010-10-17T07:26:00.006+04:00

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

Тимоти Феррис

Каждый день, каждый час я вижу подтверждение этому закону. Не пытайтесь, как все, работать больше: сутки не резиновые. Работайте лучше! Для этого не нужно пахать по 15 часов. Для этого важно только отсекать лишнее и ставить дерзкие дедлайны.

Почему тестирование - это тупо и скучно?

2010-10-15T22:24:00.004+04:00

Последние дни всё чаще натыкаюсь на сообщения в блогах и форумах про то, что тестирование - это либо очень скучно, либо тупая работа и т.д.
Что все эти люди делают в тестировании??

Позавчера я тестировала свой небольшой веб-проект.

За 4 часа я завела 25 дефектов.

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

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

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

Это захватывает, и время пролетает очень быстро. Это творческая, непростая, ответственная работа, которая увлекает на 100%!

И я задумалась. Кто пишет про "скучно", "рутина" и "тупая работа"? Почему не всем нравится? Постаралась выписать всё, что пришло в голову.

1. "Не моё". Я обожаю тестировать и проводить тренинги, но я ненавижу звонить по телефону. НЕ МОЁ! Тестирование - это набор конкретных действий, которые мы выполняем. Кому-то нравится этот процесс, кому-то нет. Если это не ваше - ищите своё! Явно есть вещи, которые увлекут так же, как тестирование - меня.

2. "Не умею". Тестировать - это навык. Я помню, как я тестировала в начале карьеры. Тынканье на кнопки, просмотр UI... нудно и скучно. Тогда я не использовала на лету интересные техники тест-дизайна, тогда я не понимала как правильно локализовывать дефекты и вообще не понимала насколько важно (и обычно сложно) их точно локализовать. Это была и впрямь тупая работа, это было скучно. Знание методологии меняет всё! Тестирование становится творческим и значительно более интересным!

3. "Не понимаю зачем". Когда я тестирую свой собственный проект, мне это важно и я понимаю, зачем я это делаю. Когда я участвовала в выпуске продуктов с мировым именем, которыми я гордилась и горжусь, я понимала важность тестирования для миллионов (МИЛЛИОНОВ!) пользователей. Это добавляет работе значимость и интерес. Работая в компании, в которой качество не ценится, испытывать удовольствие от тестирования сложно - оно же никому не нужно!
Работаете в такой компании? Бегите!

4. Неоправданно жёсткие процессы. Тестировать по 100 лет назад созданным тест-кейсам, повторяющимся каждый день, не просто скучно, но и бесполезно. В итоге и интереса нет, и ответственность не чувствуется. Надо уметь выбирать оптимальное соотношения исследования к документированию. Да, документы нужны. Иногда чек-листы, иногда даже тест-кейсы, иногда они даже необходимы. Но НЕ ВСЕГДА!

Может, есть ещё какие-то причины неинтереса.

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

то либо тестирование - это мега-супер-пупер-аж-захватывает-дух интересно, либо НЕ ВАШЕ!

Что вы будете на завтрак: яичницу или рецепт?

2010-10-12T03:15:00.004+04:00

Как вы думаете, какой повар лучше – тот, который умеет готовить 10 простых, вкусных, сочных блюд – или тот, который прочитал 10 больших кулинарных книг, но ни разу не стоял у плиты?

С каким водителем вы без проблем поедете – с тем, кто прочитал правила дорожного движения и впервые учится переключать передачи – или с тем, кто уже 10 лет безаварийно «таксует», не удосужившись пролистать ПДД?

С каким менеджером вы предпочтёте работать – опытным и доказавшим свою репутацию хорошего руководителя – или с новичком, но прочитавшим 5 книг по управлению?

И допустимо ли быть теоретиком в сфере тестирования?

В чём разница между знанием, навыком и опытом?

Вы можете прочитать об аэродинамике птиц и получить представление о том, как они летают. Сможете ли вы летать? Врядли. Это – знание.

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

Через год вы разговариваете по мобильному за рулём, засматриваетесь на особей противоположного пола и рекламу, а светофоры замечаете боковым зрением. Это – опыт.

Теория и практика – в поисках золотого сечения

Практиковаться без базовых знаний опасно. Прежде чем выезжать на улицу, надо знать, что красный свет светофора означает «СТОП», а зелёный – «Welcome!». Перед первой операцией хирургу не помешает ознакомиться с анатомией. Теория важна и даже необходима – хотя, увы и ах, без практики она ничего не даст.

Исходя из моих наблюдений, 90% тестировщиков НЕ УМЕЮТ использовать классы эквивалентности и граничные значения. Это простые (читай: элементарные), эффективные и необходимые техники. Про них все слышали. Про них все знают. Почти все знают что это. И почти никто НЕ УМЕЕТ их использовать (считая, что умеют :-) ). Хотя это – фундамент!

Зато, эти люди гонятся за новыми и новыми знаниями, которые они не смогут применять.

Китайский вопрос: «А нахуа?».

Почему так много тестировщиков – теоретики?

1. Потому что делать что-то новое страшно – а вдруг не получится?

2. Потому что в СНГ тестирование в зачаточной стадии и в 90% случаев «тестированием» называют мартышкины кликанья. Так принято!

3. Потому что вокруг полно теоретиков. С кого брать пример?

Почему надо становиться практиком?

1. Тестирование – это очень интересная и увлекательная область деятельности. Но только если вы не стоите на месте. Только если вы всё время пробуете новое. Только если вы всё время растёте. Иначе – скучные и нудные задачи с тыканьем на кнопочки.

2. Чтобы обеспечить себе быстрый карьерный рост. Почему у некоторых людей карьера стремительная и успешная, а некоторые годами работают младшими тестировщиками? Обычно, знания тут ни при чём…

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

Уболтала, чертяка языкастая. Что делать?

1. Не ждать приглашений что-то сделать. Не вините в отсутствии роста компанию или работодателя. Начните ДЕЛАТЬ сами. Не читать, не учить. ДЕЛАТЬ.

2. Выпишите конкретные, понятные, небольшие шаги. Нарисуйте свой первый майнд меп по продукту, если вы этого ещё не делали. Напишите тест-план. Поиспользуйте Pairwise. Попробуйте новый софт.

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

4. Читая книгу или посещая тренинг, проецируйте теорию на свою работу и выписывайте: что из новой информации я могу попробовать? Как я могу это сделать? Когда это будет полезно? Если после книги или тренинга вы не определили план действий – значит, вы совсем не получили пользы!

5. Если во время решения каких-либо задачек в области тестирования у вас возникнут сложности или вопросы – обращайтесь. Во имя искусства я помогу абсолютно безкоштовно, то есть даром. Условие простое: не спрашивать про сферических коней в вакууме. Конкретные примеры, задачи, проблемы. Вопросы «КАК… ?», а не «расскажи мне что-нибудь про Мадагаскар».

Не уболтала, ерунда это всё.

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

Результаты московских тренингов

2010-09-29T08:33:00.006+04:00

Всем привет!
Три тренинга в Москве позади, гастроли и много новых тренингов впереди.
23, 24 и 25 сентября я провела в Москве три тренинга для тест-менеджеров.
Команда все три дня была очень интересная. У всех было что узнать, со всеми было что обсудить - и это здорово!

В первый день, на тренинге "Управление командой тестировщиков", который проходил в офисе Билайна, удалось даже собрать видеоотзывы. Эта штука для меня новая, но теперь я знаю, что смотреть в пасмурные зимние вечера, если заблокируют торрент :) Средняя оценка по анкетам 4,7 по 5-балльной шкале. Единственный "трояк" поставил мой бывший руководитель - но ему можно, на то он и руководитель :)

Во второй день, на тренинге "Управление тест-дизайном", видеоотзывы собрать забыли. А жаль! Средняя оценка по анкетам - 4,85 по 5-балльной шкале!!! Для меня это новый рекорд :) Правда, одна тройка опять была - Игорь, я всё учту! :)
Зато, вместо отзывов получилось классное фото:

На третий день, на тренинге "Управление автоматизацией", который проходил в офисе "Акрониса", было пожарче. Этот тренинг я проводила впервые, и несколько сложных моментов в объяснении давались с трудом. К огромному счастью, опытные участники не только внимательно слушали и участвовали в групповой работе, но даже помогли с объяснениями, породив идеи "как это можно нарисовать ещё нагляднее". За что им отдельное спасибо!Видеоотзывы получились длиннее и насыщеннее, но моя квалификации в видеомонтаже не позволяет их выложить :( Обещаю исправиться до конца недели. На этом тренинге средняя оценка составила 4,6, а троек было аж две!

Выводы:
1) Всем большое спасибо, было очень интересно и надеюсь ещё неоднократно встретиться!
2) Видеоотзывы - это круто. Смотрю и радуюсь! :)
3) Никто не знает тренингов по видеомонтажу?

Осенний тренинг-марафон для тест-менеджеров

2010-08-08T17:43:00.006+04:00

Этой осенью я провожу какое-то сумасшедшее количество тренингов:

1) Управление командой тестировщиков
- Москва: 23 сентября
- Санкт-Петербург: 2 октября
- Минск: 14 октября
Это мой любимый тренинг :) Сейчас он полностью переработан и нашпигован секретной информацией тайных спецагентов тест-менеджмента. Этот тренинг - о людях, потому что тестировщики - это в первую очередь люди, и умение формировать команду мотивированных рыцарей-джедаев - самое важное, что Вы можете сделать для своего проекта :) На этом тренинге Вас ждут непрерывные упражнения в группах, которые позволят не просто узнать теорию, а прочувствовать все темы на практике! А тем, кто и так всё знает - понаблюдать за своим менеджментом со стороны и получить массу полезной обратной связи!

2) Тест-дизайн для менеджеров
- Москва: 24 сентября
- Санкт-Петербург: 3 октября
- Минск: 15 октября
Этот тренинг тоже существенно переработан на основании последних отзывов. Половину тренинга мы проведём, занимаясь коллективным творчеством и знакомясь с различными инструментами тест-дизайна, которые созданы для сокращения трудозатрат на тестирование в разы. Это будут основы, которые позволят Вам сориентироваться в существующих подходах к тест-дизайну и научиться выбирать оптимальные варианты. Помимо этого, мы уделим массу времени таким темам, как создание "работающего" тест-плана, формирование команды тест-дизайна, выбор подходящего инструментария. Внимание! Тренинг настолько насыщен мозговзрывающей информацией, что перед ним необходимо хорошенько выспаться! :)

3) Управление автоматизацией тестирования
- Москва: 25 сентября
- Санкт-Петербург: 1 октября
- Минск: 16 октября
Этот тренинг будет проводиться впервые. Его цель - помочь тест-менеджерам построить эффективную автоматизацию даже в случае, если Вы сами не являетесь продвинутым техническим специалистом. Мы расшифруем все те страшные слова, которыми обычно ругаются автоматизаторы-разработчики и поизучаем, как это устроено внутри, а главное - что с этим делать?? Как сделать автоматизацию не чем-то "для галочки", а полезной проектной активностью, которая позволяет экономить затраты ручных тестировщиков? В чём разница автоматизации в маленьких и больших командах? Как отбирать тесты? Как измерять их эффективность? К концу этого тренинга Вы самостоятельно развеете массу широкораспростренённых мифов, которые препятстсвуют результативному взаимодействию миров автоматизированного и ручного тестирования ;)

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

Балдеющие от адреналина или зомбированные шаблонами

2010-07-09T03:35:00.003+04:00

Большое спасибо Борису - подкинул книжку, которая заставила задуматься :)

Книга описывает стандартные поведенческие паттерны проектных команд. Наверное, в Орловско-Панкратовских "Играх в ИТ" нечно подобное. Смотришь на них со стороны и думаешь "вот жеж идиоты, так обычно и бывает"... и где-то внутри что-то начинает назойливо почёсывыть, постукивать, поскрёбывать... и тут ты понимаешь: "О! Я же вчера так сделала!"...
Советую всем прочитать эту книжку, будучи максимально искренним с собой и проанализировав, а не делаете ли вы сами все эти глупости? :)

Больше всего понравилась глава про менеджеров-нянь. Как минимум приятно, что звёдный состав авторов меня понимает :))) Как максимум - видно направление роста. Вот он, свет в конце тоннеля!

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

Usability- тестирование

2010-06-19T02:34:00.005+04:00

Долго писала комментарий к интересной теме, а он потерялся :(
Напишу ещё подробнее и здесь :)

Usability тестирование в сфере разработки ПО - это проверка удобства использования продукта. На эту тему есть как минимум одна интересная книжка:

Я постараюсь сформулировать своё мнению про юзабилити-тестирование, основанное как на чтении книжек/статей, так и на собственном опыте. Я не претендую на полноту описания и на полноценность списка способов. Отнюдь! Но это - те базовые шаги, которые являются 20% действий по закону Паретто и которые принесут угадайте сколько результата :)

1) Самое главное в тестирование юзабилити - определить его цели. Что будет делаться по результатам тестирования юзабилити? Будут ли исправляться дефекты, есть ли приоритет, направленность проекта/компании в целом на юзабилити? Если нет - Вы попусту тратите время. Почему это пункт 1? Потому что в России такого приоритета зачастую нет. А своё время надо экономить ;)

2) Если всё же смысл в юзабилити-тестировании есть, то следующий важный шаг - узнать Вашу ЦА, целевую аудиторию.
Почему важно понять, кто Ваши пользователи? Приведу пример с общеизвестными продуктами: антивирусами, средствами архивирования, графическими редакторами. Зачастую, приложения для домашних пользователей и корпоративных пользователей имеют идентичный функционал. Но антивирус для домохозяйки имеет все базовые предустановки, и в большинстве случаев ей просто надо нажать на кнопку. Но если это корпоративный антивирус, который настраивают админы, то им нужна панель управления космическим кораблём :)
Функционал один - количество кнопок, настроек, их сложность и т.д. - разные. Найти соприкосновение для таких целевых аудиторий будет сложно.
Аналогично - с графическим редактором. В MS Paint'e есть почти всё, что нужно простому смертному, который испугается менюшек фотошопа. Зато дизайнера явно не устроит MS Paint...

3) Целевая аудитория - это те люди, чьё мнение для Вас важно. Но помимо этого, Вам надо понимать, как обычно используется Ваш софт в "боевых условиях". Говоря простым языком, Вам нужно составить ментальную модель пользователя :)))
Когда ИТ-шники тестируют софт для бухгалтерии, они обычно ориентируются на свои предпочтения и свою специфику отрасли. Запуская одни и те же программы каждый день, мы привыкаем к любому неудобству. Потому, что мы тестируем, а не используем. Это - две большие разницы :) Цель создания ментальной модели - понять, как продукт ИСПОЛЬЗУЕТСЯ, и его тестирование соответствующим образом.
Как Ваш софт запускают? Из каких менюшек куда заходят? Что используют часто, а что - редко? Что важно? Какие проблемы и задачи решает пользователь при помощи Вашего софта?
Один раз я столкнулась с неприятным опытом. В продукте, который я зарелизила, среди прочих был один всем известный дефект, который казался нам непринципиальным. (Нам = 40 тестеров, 60 разработчиков и парочке аналитиков). Мы были уверены, что этот функционал никто не использует.
Как же мы удивились, когда получили массу жалоб и отказов именно из-за этой "мелочи"!
Этот полученный опыт я считаю хоть и негативным, но очень важным. Тестировщики всё же не пользователи. Надо узнавать настоящих пользователей, чтобы "отстаивать их права" :)

Теперь, переходим к процессу и техникам :)

4) Не торопитесь устраивать исследования. Тестируйте сами. В этом Вам помогут знание пользователей, common sence и общепринятые нормы юзабилити. Чтобы их узнать, погуглите usability guidelines. Они бывают для разных ОС, для ВЕБа и т.д. По ним, сначала проверьте сами и оцените, насколько соответствует им Ваш софт и насколько готова Ваша команда править ошибки. Если этот этап пройден успешно - идём дальше!

5) Проводим исследования.
* Ищем ЦА. Не просто "коридорное тестирование", чтобы найти кого-угодно, а конкретных, подходящих людей, которые будут использовать Ваш продукт!
* Мотивируем их. Мы можем предложить более качественный софт потенциальным клиентам. Мы можем предложить деньги подходящим людям. Не надейтесь, что кто-то будет серьёзно расценивать Ваши опыты просто так :)
* Не делайте многонедельных исследований. Это просто долго, и юзтестеры так же замылят глаза, как и обычные тестеры. Юзтестирование должно быть коротким и быстрым.
* Вы можете провести простое исследование, попросив пользователей
- Выполнить ~5 простых основных действий, не описывая ни в коем случае шаги! Только действия. Пусть они сами ищут, как это сделать, и опишут Вам проблемы, с которыми столкнулись.
- Потыкать кнопочки и описать, что понравилось и что не понравилось :)
- Пригласить их к себе и попросить сделать эти самые действия. Понаблюдайте, с чем они сталкиваются. В анкете они не смогут описать всего, с чем столкнулись, так как сами не заметят своих "заминок". Зато, это можете заметить Вы :)
- Используйте специальные средства для записи действий пользователей, которые Вы потом сможете проанализировать в спокойной обстановке.
- И да, я не советую Вам проводить лабораторные исследования и записывать количества движений глаз :) Во-первых, я сама этого никогда не делала, во-вторых, я ещё не работала с софтом, у которого достаточно высокий уровень юзабилити для того, чтобы эти исследования могли быть оправданными.

6) Анализируем результаты.
* Не пытайтесь исправлять всё, на что пожалуются юзтестеры. Некоторые из них такие марсиане, что их комментарии окажутся бесполезными для всех остальных пользователей. Ищите золотую середину и не забывайте про common sence.
* Найдите способ подтвердить, что исправления полезны. В принципе, это следствие из предыдущего абзаца :)
* Выработайте критерии критичности юздефектов. Невозможность найти опцию и лишний клик - это разные весовые категории.
* Не пытайтесь компенсировать юзтестированием недостаток изначального анализа. Это будет выстрел пушкой по воробьям.

Когда полезен тест-дизайн?

2010-06-11T19:25:00.007+04:00

На форуме прозвучал вопрос про ситуации, когда необходим тест-дизайн, и когда - нет. Отвечаю расширенно и здесь :)

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

Чек-лист - это перечисление областей/действий, которые надо протестировать, без описания шагов.

Свободное тестирование - неограниченное рамками тестовых спецификаций творческое тестирование.

Чтобы ответить на вопрос, что и когда нужно делать, надо сначала понять, что и зачем нужно :)
Зачем пишутся чек-листы?
- Чтобы ничего не забыть
- Чтобы оценивать масштабы работ
- Чтобы иметь возможность приоритезации проверок
- Для подспорья неопытным сотрудникам
- Чтобы иметь возможность приблизительно отслеживать, что работает, а что - нет

Зачем пишутся тест-кейзы?
- Чтобы ничего не забыть
- Чтобы по ним можно было учить новых сотрудников
- Чтобы точно знать, что работает
- Чтобы иметь детальную отчётность
- Чтобы иметь возможность точного планирования
- Чтобы в работу можно было подключать не выскококвалифицированных сотрудников

Получилось приблизительно такая схемка:

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

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

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

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

Тренинги в Питере - 15 и 16 мая 2010

2010-06-09T02:26:00.003+04:00

Я уже 3 недели хочу написать о результатах поездки в Питер.
И вот, я добралась :)
ПИТЕР
О город, я люблю тебя :) Кафешки, мини-юбки, ощущение портового города. Класс, но работается плохо :))
ДОРОГИ
О питерские дороги, спасибо вам! Теперь я считаю, что московские дороги - супер :) Всё познаётся в сравнении!
Тренинг 1: 15.05, Управление персоналом:
Так нервничала, что забыла про пару упражнений :)) Тренинг прошёл на четвёрочку, обычно - лучше. Группа подобралась экстраинтересная, и несмотря на ночь за рулём перед тренингом, до вечера моя батарейка была 100%. Придумала пару новых "фишек" для тренинга, внедрю в следующий раз. Главное не забыть :)
Тренинг 2: 16.05, Управление тест-дизайном:
Тренинг прошёл на пятёрку с минусом. Группа была ещё интереснее. Здорово, что многие участники после тренинга обращались по почте с конкретными вопросами, которые мы и разбирали. Всё же, упражнения для примера и реальное использование каких-либо инструментов - "две большие разницы". А раз народ начал их использовать и даже задавать вопросы - то это щастье для тренера :) Но, этот тренинг я решила переделать почти полностью и уже это сделала :)) Пусть будет ещё круче.
Офис Yota
Как и обычно, помещение предоставила Yota, за что ей огромное спасибо!
И если бы это был просто офис! Это было много-много этажное здание с роскошным видом из прозрачных лифтов. Ух я и накаталась на них!
Но самое классное в офисе Yota - это пингвины :)
Ваня
Про Ваню можно говорить много и долго. Но честнее будет просто сказать, что он лучший :) Познакомившись на прошлогоднем тренинге, чрезвычайно этому рада.
Офис, Ваня, город - и всё на одной фотке:

Питер, до встречи!

2 умных мысли за один день

2010-05-06T11:23:00.004+04:00

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

ДАЙВ БАРРИ, американский юморист, лауреат Пулитцеровской премии.

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

БИЛЛ ГЕЙТС, основатель компании Microsoft

QA, QC, Testing & Process Managers

2010-05-05T02:51:00.007+04:00

Кажется, уже все всё давно знают... Но до сих пор задают вопросы :)
Кто такие QA, QC, тестировщики и процессные менеджеры?

Тестировщики.

Это такие ребята, которые никому не доверяют и всё проверяют самостоятельно :) Можно сказать, пробуют на вкус ;-)
Как они это делают:
- вручную и автоматически
- белым ящиком или в полном неведении
- по тест-кейзам или самостоятельно
- хаотично или придерживаясь плана
и т.д. Как бы они это не делали, они делают именно это: мучают продукты и заводят баги.

Quality Control (QC)

Эти бравые ребята ставят диагноз. Типа "Жить будешь" или "Вам бы подлечиться".
Для того, чтобы поставить диагноз, нужно произвести 2 действия:
- провести анализ (температура, биохимия, МРТ :)))
- определить, что является нормой, а что - отклонением.
Так вот, первая часть - это то самое тестирование. Но - есть бонус - в диагнозе :) QC не просто говорит "здесь бага" - QC определяет качество продукта, его готовность к релизу. Для этого создаются метрики качества, зачастую возможно личное общение с заказчиками. Более того, есть особо пронырливые QC, которые хорошо разбираются в предметной области и часто учат жить аналитиков. А точнее - переписывать требования :)
В нескольких компаниях, в которых я работала, QC обладают так называемым "правом вето" - то есть, пока они не разрешат, продукт релизить нельзя. Ответственность выше, эго шире :))

Quality Assurance, QA

В древнем Китае семейные врачи зарабатывали деньги всё то время, когда их клиенты были здоровы. Если же кто-то в "подконтрольных" семьях заболевал, им прекращали платить до полного выздоровления. Это всячески способствовало ориентации врачей на здоровье.
Немного похоже на QA... Потому что эти ребята предпочитают не лечить, а проводить профилактические мероприятия. Делают прививки, учат как правильно чистить зубы и агитируют за шерстяные носки :) Тестировщики расстраиваются, если багов нету. А QA счастливо потирают руки и гордятся.
Что они для этого делают? Определяют процессы, подходы, влияют как на тестирование так и на разработку, на билды и на требования. Их главная задача - чтобы продукт был качественным :) Если в компании всё хорошо, то их слушаются. Если плохо - то их просто нет :)

Процессные инженеры, процессные менеджеры.

Иди сюда... сюда... вот так... Теперь правой.. Оп! Не получилось? Попробуем с начала :)
Если в Вашей компании есть такие зануды, то это - процессные инженеры. Они всех учат жить, поэтому зачастую их любят меньше чем тестировщиков. Хотя, при правильном подборе, эти ребята творят чудеса! Их предназначение - искать наиболее эффективные пути выполнения тех или иных задач. Как сэкономить время на сборки? Как проводить Post Mortem? Как сделать так, чтобы тестеры и девелоперы не ссорились? Эти джедаи разрулят любые ситуации, как гаишник с палочкой, если светофор не работает :) Они напишут регламент, объяснят процедуры, найдут крайних и придумают Вам новую работу. И всё - на благо дела!

Выводы:
QC и Тестирощики - это почти одни и те же ребята, только с разными подходами к своему делу и разными уровнями возможности и ответственности. Перейти из одного амплуа в другое - просто, даже в рамках одной фирмы.
QA и процессные инженеры - тоже родственники. Но миссия QA - "Качество", а миссия проессных инженеров - "Оптимизация".
QA и QC - дальние родственники, несмотря на общую букву и то, что 90% тестировщиков называют себя QA инженерами :)

Challenge для тест-менеджеров

2010-05-03T01:59:00.006+04:00

Мне самой немного страшно :) Ровно через 2 недели начнётся Школа Тест-Менеджеров.
Никакой лишней болтовни, теоретических изысканий, "интересных" тем.
Всё - только полезное, практичное, и на собственном опыте. В общем, этот тренинг не для слабонервных, которые готовы прийти, послушать, и забыть. Это тренинг для тех, кто хочет за короткий срок прокачаться на два уровня и получить +80 опыта :)
Мы будем вместе планировать, налаживать процессы, учиться работать с персоналом, внедрять эффективную автоматизацию и строить тест-дизайн. И не на абстрактных примерах - а в реальной жизни!!
Впереди - 2 месяца непрерывного развития, после которых всё будет по-другому. Совсем по-другому!
В группе осталось 4 места. Торопитесь!

Оптимизируем свои ИР - часть 2, Тайм-менеджмент

2010-05-03T01:08:00.006+04:00

Тайм-менеджмент - это всё ещё модно. ОЧЕНЬ МОДНО. Пик популярности в России закончился лет 5 назад, но до сих пор по Т-М клепают пачки книг и море тренингов.
Почему?
Потому, что все мы хотим "волшебную таблетку" - типа, без тайм-менеджмента мы можем Х, а с этим инструментов - как минимум Х*2. Чаще всего ответ этим надеждам - "фигушки!" :) Рассмотрим почему:
1) Тайм-менеджмент - это набор практик и методик, которые позволяют оптимизировать свои временные затраты. То есть, делать больше за то же количество времени. А что, вы правда хотите работать в 2 раза больше??
2) В ресурсах по тайм-менеджменту слишком часто навязывают конкретные инструменты, которые подходят далеко не всем. Проверили - не работает - отказались от ТМ как факт. Судя по моим наблюдением, через этот этап проходит большинство начинающих читальцев-тренингопосетителей, которые в итоге так ничего и не начинают использовать.
3) Т-М обычно используется там, где нам НАДО что-то сделать. Если есть любимое хобби (цветочки, кошечки, вязание и т.д.) - то Т-М никому не нужен. Нравится процесс как таковой, и эффективность не беспокоит. А вот если нам что-то "надо", то мы начинаем беспокоиться об эффективности. А "надо" далеко не всегда равно "хочу", поэтому, начиная больше времени уделять тому, что "надо", мы получаем дискомфорт и демотивацию, и часто это можно свалить на Т-М.

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

Что такое ТМ: это набор практик, инструментов и подходов экономить время. Например:
- декомпозировать объёмные задачи
- начинать с наименее приятных задач, чтобы они не тормозили нас
- раскладывать писемки по папачкам, чтобы потом экономить на их поиске
- периодически вести хронометраж, чтобы контролировать "утечки" времени
- определять и правильно использовать приоритеты, следовать законам Парето, Важному/Срочному и т.д.
- подбирать подходящие способы планирования
- наводить порядок
- последовательно решать задачи
- и т.д.

Это хорошие, полезные, эффективные практики. Но при следующих условиях:
1) Выбранные задачи, цели согласуются с Вашими жизненными приоритетами, ценностями. Кажется просто? Как бы не так!
2) Вы любите делать то, что делаете. Не любите? Не делайте. Способы "полюбить" нелюбимое есть, но толку от них мало. Если вы давно хотите уйти из тестировщиков в фотомодели, то самое лучшее время для этого - прямо сейчас!
3) У вас достаточно жизненной энергии для активной работы. Достаточно чаще всего значит "много" :)
4) Вы умеете делегировать. Это - навык, которому учиться и учиться, и не только для менеджеров. Поверьте, даже уборщица в Вашей квартире - это ценная инвестиция. Проверить это можно эмпирическим путём :)

Как и что развивать:
1) Энергетика

Когда я впервые прочитала эту книгу, меня торкнуло. Масса базисной теории и практических советов по наращиванию мощи :) Полезно, MUST READ.

2) Целеполагание + тайм-менеджмент.

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

3) Непосредственно тайм-менеджмент.
Есть очень много книг, очень много тренингов, многие из них я читала и посещала, но сказать, что есть что-то "ВАУ" - не могу :( Тайм-менеджмент нагляднее всего в игровых тренингах, а не книжках - поэтому, посоветую тренинги Инны Иголкиной (timesaver.ru) - они "средненькие", но хотя бы стоят адекватных денег в отличие от почти идентичных тренингов Архангельского.
Куча книжек по тайм-менеджменту - здесь:
http://www.koob.ru/time/

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

Выводы из части 2:
1) Определяем цели
2) Форсируем кризис среднего возраста и бросаем всё, что не любим
3) Прокачиваем энергетику, чтобы на всё хватало сил
4) Читаем книжки и ходим на тренинги по тайм-менеджменту, как только поняли, что мы к этому готовы!

Оптимизируем свои ИР - Часть 1, Mind Management

2010-04-28T22:51:00.006+04:00

Человеческий мозг развивался сотни миллионов лет. Его основой является т.н. "мозг рептилий" - часть мозга, ответственная за основные инстинкты, определяемые стремлением к выживанию (страх опасности, голода и т.д.). После появился "мозг древних млекопитающих", в который средой развития оказались заложены стадные чувства, стремления к социуму, боязнь одиночества и отверженности. И не так давно в нашем мозгу появились передние отделы коры головного мозга, ответственные за логику, осознанность, и по мнению некоторых специалистов - духовные стремления.
Поэтому, когда мы говорим про свои осознанные стремления и интеллектуальный рост, мы работаем с самой молодой частью нашего мозга. Можно сказать, что это "бета" - над ней ещё работать и работать :)
Как?

1) Наращивать нейронные связи, то есть, увеличивать ресурс мозга.
Мозг можно развивать, натренировывать, и поддерживать активным долго-долго. Для этого надо непрерывно делать что-то НОВОЕ. Повторение одинаковых действий не развивает ваш мозг. НИКОГДА. Только новые действия, особенно:
- изучение иностранных языков
- использование левой руки, если вы правша, и наоборот
- головоломки, кроссворды, логические игры, судоку - только не одно и то же изо дня в день :)
- рисование!
- решение творческих задач на работе (учитесь делегировать повторяющие однотипные задачи!!)
Вообще, возьмите на вооружение жизненный принцип "стараться как можно больше делать нового, и как можно меньше - повторяющихся задач". Чего бы это ни касалось :)

На эту тему есть много вполне адекватных книг, особенно рекомендую:

2) Структурировать кашу в голове.
Когда я открыла для себя mind maps, я была в восторге. Но значительно бОльший кайф я словила, когда прочитала книжку:

Майнд-карты - это очень полезный инструмент для:
- Создания тренингов
- Определения scope тестирования
- Поиска решений сложным задачкам
- Проведения групповых брейнштормов
- и мноооогого другого.
Но самое главное - не то, что даёт использование инструмента самого по себе. Самое главное, что регулярно и активно его используя, эти карты начинают генериться в голове "на лету". В итоге, расчищается хаос мыслей, вместо которого появляются разложенные по полочкам и стопочкам мысли.
Чтобы этого достичь - надо прочитать книжку и нарисовать меньше чем за месяц 50 серьёзных карт. Результат гарантирован :)
p.s. Если религия не позволяет использовать нелицензионный софт, а денег на MindManager жалко - скачайте бесплатную версию XMind. Функционала меньше и юзабилити хромает, но он тоже неплох :)

Выводы из части 1:
1) Записываемся на курсы турецкого языка
2) Делегируем однотипные задачи
3) Читаем умные книжки
4) Учимся рисовать майнд-мепы

Оптимизируем свои интеллектуальные ресурсы - Часть 0, вводная

2010-04-28T02:03:00.003+04:00

Лично для меня жизненным фундаментом являются мои способности, навыки и знания. Это - то, на чём базируются мои решения, достижения, действия. Поэтому я непрерывно выделяю для себя время и финансы на развитие. Помимо конкретных навыков вроде "написать тест-кейз" или "настроить DHCP", есть более глобальные способности, которые являются фундаментом для любых других навыков. В моей системе мер, это:

1. Управление интеллектом. Mind Management, в общем. Для его развития, я использую:
* Упражнения на развитие интеллекта
* Mind Maps для структуризации информации
2. Тайм-менеджмент - чтобы всё успевать и использовать свои временные ресурсы эффективно.
3. Эмоциональный интеллект (EQ), в который входят:
* Чёткое понимание своих желаний
* Комфортное общение с окружающими людьми (взаимно комфортное)
* Вырабатывание "внутреннего стержня", жизненных ориентиров, стремлений и принципов
4. Коммуникативные навыки, а именно:
* Умение слушать и слышать собеседника
* Умение эффективно преподносить информацию
* Гибкость в общении и способность к компромиссам
5. Навык получения навыков :) То есть, самообразование.
* Умение объективно оценивать "где я сейчас"
* Прокладывание маршрута к "где я хочу быть"
* Выработка эффективных паттернов обучения, с удовольствием и от процесса и от результата
6. Мотивация и работа с персоналом
* Мотивация СЕБЯ
* Мотивация команды
* Развитие, движуха, жизнь, ЭВОЛЮЦИЯ!!!

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

CEE-SECR 2010 (13-15 октября 2010, Москва)

2010-04-13T02:35:00.001+04:00

Открыт приём статей на конкурс для включения в программу Шестой ежегодной конференции "Разработка ПО 2010" (CEE-SECR 2010). Подробную информацию о конференции можно найти на сайте http://cee-secr.org/ .
Срок подачи статей - до 24 мая.

Человеческие ресурсы

2010-04-09T01:54:00.001+04:00

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

1. Это просто слова.

В моём восприятии роль письменной и устной речи - обеспечение возможности коммуникаций. Поэтому, главное - понимать друг друга. Мне всё равно, что называть эксплоративным тестированием, а что - чайником. Главное - чтобы участники коммуникации имели общее определение.

2. Происхождение термина "ресурсы" применительно к human being.

Подозреваю, что термины HR и человеческие ресурсы вошли в активный оборот с введением методологий управления проектами и соответствующих тулов. И там это очень логично: задачи надо в чём-то измерять и контролировать, и проекты сколько-то стоят. А в ИТ основная цена проекта - человеческие ресурсы.

3. Объективное соответствие слова "ресурсы" контексту

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

Наверное, в семейных отношениях меня бы расстроил термин "ресурс": "Милый, удели мне 2 часа своих трудозатрат"... Но работа - это работа...

4. Негативная коннотация в слове "ресурсы"

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

5. Ресурсы - продажны?

О нет. Преобладающую часть своего времени я работаю на себя. И планируя задачи на неделю, оперирую своим рабочим ресурсом на это время. Может быть, я просто не знаю альтернативы термину "ресурс" применительно к свободным часам? Я буду очень признательна всем, кто выступает против термина "ресурс" применительно к человекам, если Вы скажете, на что его можно заменить, чтобы оно продолжало выполнять свою роль в управлении?

6. И самое главное - про человеков, которые называют других человеков (включая себя) "ресурсами".

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

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

Блог?

2010-04-09T01:33:00.000+04:00

Кажется, я завела свой блог.

Пока регистрировалась, обдумывала, зачем.