Методики обучения сотрудников.

Давным-давно я тут писал пост про МОПС.
Сейчас хочу поделиться наблюдениями о том,
как происходит обучение в большинстве компаний.
На самом деле.
Я выявил три основных методики и назвал их соответственно.

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

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

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

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


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

А какие встречали вы?
Расскажите как обучали вас и как обучаете вы?

Недосмарт.

Не умеем ставить задачи.
До S.M.A.R.T. далеко ещё, его внедрять надо долго и упорно.
Главная проблема - это проецирование и путаница в признаках.
Спросишь человека "что делать"? А он тебе начинает пространно объяснять "как делать".
Даже через "5 почему" выходит что человек и сам не до конца понимает зачем это нужно.
Почему? Потому что ему не объяснили.

Вот три кита, на которых зиждится постановка задачи хотя бы на раннем и примерном уровне:
ЗАЧЕМ?
ЧТО?
КАК?

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

Хроники Отдела Тестирования. Часть 4: На недельку, до второго.

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

Там или тут?

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

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

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

А как считаете вы?

Рубрика "Хозяйке на заметку".

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

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

Люди начинают говорить тише и более конструктивно.

Градус накала реально снижается. Народ начинает давать реальный конструктив.

Креатив прет, да.

Приятное открытие. Может и велосипед, но я прочувствовал.

Холиварчик.

"Личный героизм сотрудников и менеджеров — всегда следствие недоработки в планировании и управлении" (с)

А вы согласны с этим утверждением?

Back to basics.

По следам поста Оли Киселевой
В принципе, базовая вещь, которую должен знать каждый тестер.
Оля всё правильно пишет. Красиво и с примерами.
Вот моя выжимка:

1. Тестирование на позитивных значениях.
Обычно используются пользовательские сценарии с корректными значениями.
Проверяем работоспособность заявленного функционала.

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

3. Тестирование в невозможных конфигурациях.
Своеобразный эд-хок. Проверка того, что система корректно обрабатывает нештатные ситуации и эксепшны.

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

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

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

Из разговора с сотрудником, который не понимал зачем нужно внедрение процессов и флоу и грустил по этому поводу:

Музыкальный холл.
Оркестр. Играет под палочку дирижера.
Зрители слышат чудесную музыку. Ни одной фальшивой ноты.
А перед тем как все начали хорошо играть по нотам их долго рассаживали по секциям с учетом акустики и инструментов. Вот секция скрипки - тут скрипачки сидят, рядом флейты. Тарелки - в жопе, чтобы никого не глушили.
Они сыгрывались и подбирали вместе с дирижером мелодию на слух. Записывали. Фиксировали.
Потом как-то раз тапёр пришел на репетицию в спортивных штанах и пьяный.
Так появились правила.
И вот они ВИА! Они сыгрались, у них есть четкие инструкции когда какую нотку сыграть, где затянуть, какой фрак одеть и во сколько приходить на репетицию и на концерт, в какой тональности настраивать инструмент.
Публика рада.
И тут один виолончелист вскакивает и говорит "Ну вашу мать! Ну сколько можно! По нотам играем же! Не интересно же! У меня мозг не работает! Никакого, блин, развития!"

Ищу тестера со знанием польского.

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

4 заповеди аналитика.

Нулевая заповедь аналитика.
Все требования к системе должны храниться в едином репозитории. Требования должны иметь иерархическую структуру, у каждого требования должна быть текущая версия и возможность просмотреть историю изменений этого требования.
Связи требований с релизами (спринтами, назовите еще 10 синонимов этого слова) ведутся при изменении статусов требований (а не их версий). В релиз попадают только согласованные и утвержденные версии требований.

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

Вторая заповедь аналитика.
Сначала - варианты использования. Потом - постановки задач.

Третья заповедь аналитика
Проверки требований (How to demo) пишутся одновременно с требованиями.

(с) Наталья Желнова