понедельник, 25 января 2016 г.

Бизнес как игра

Намедни прочел книгу "Бизнес как игра"  Сергея @Milfgard Абдульманова.
Пруф.

К прочтению - рекомендую. Не откровение, а как это и нужно - повторение простых, понятных и работающих вещей.

Позволю себе процитировать несколько глав.
О книгах:
Книги в офисе должны быть. {...} Так вот. Возьмите книги и положите их в офисе. Ваши люди будут их читать. Ну, те, которые хотят расти. 15 тысяч рублей за библиотеку - и вот вы уже резко увеличиваете скорость роста своих активных людей внутри компании. Оно того стоит. Так обучать очень дешево и очень эффективно. 
У нас первый шкаф стоял в колл-центре. Мы купили книги, поставили. Сразу стало понятно, люди, которые читают и хотят чего-то, уйдут на повышение. Мы никогда не говорили этого явно, но результаты доказывали все лучше слов. Читать книги внезапно стало очень круто. И всем захотелось.
 Будь как Ленин:
Дима Кибкало наставлял меня перед первой серьезной руководящей должностью:
- Ты должен быть как Ленин. Всегда справедлив, даже если это мешает текущим интересам. Ты должен подавать пример и всегда первым браться за самую хреновую работу. Если вдруг инвентаризация - бери самую большую коробку и тащи ее.
 Повышения:
Был у нас как-то переезд. Мы попросили продавцов магазинов помочь, не обещая ничего взамен. {...} Мы таскали вещи на пятый этаж и потом весело ели торт. Никто не получил ничего материального. 
Но вот что странно. Каждый раз, когда нам нужен был старший точки или еще кто-то рангом выше продавца, повышался один из людей, помогавших нам при переезде. Потому что мы всех запомнили и увидели, что человек готов сделать больше, чем обязан. Это всегда заметно и об этом не надо говорить.
 Увольнение:
Вы заходите в переговорку и начинаете разговор с фразы:
- Я решил тебя уволить. 
Можно и мягче, но смысл должен сохраниться. никаких вступлений, никаких обсуждений работы за прошлый месяц. Просто, честно.
Мессенджеры:
Лучший мессенджер - почта. По одной простой причине - не она вас дергает, а вы ее. {...}  Для срочных вещей есть телефон.

четверг, 21 января 2016 г.

DUMP

Уже в который раз мой способ пройти на конференцию - принять участие в создании.
Итак, DUMP.
В  частности, секция тестирования.

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

Интересные темы списком:
  • Держим руку на пульсе: тренды, книги, люди
  • Багдрайвен девелопмент
  • Мобильное вообще все
  • Как ручной тестировщик может залезть в смежные штуки и сам все зафигачить
  • Хардкор и пентест
  • Холивар с менеджерами и программистами об идеальном тестировщике
  • Как жить после пропущенного бага
  • Система непрерывной интеграции как ритм проекта и способ коммуникации
Набор докладчиков в секцию тестирования на дампе - открыт. Буду рад желающим поделиться опытом и мнением.

среда, 20 января 2016 г.

Неутешительных итогов пост

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

Итоги, как написано в сабже - неутешительны.
Измерения в днях.
Время подъема писалось с точностью до получаса и по будням с ним все в порядке - не позже 7-8 утра, как правило. Статистику тянут вниз выходные с утром в  12-14.

В остальном - так себе. Катать стоит как минимум вдвое больше. Читаю вообще неутешительно редко.

Думаю, что целевое состояние на 2016 - вдвое больше катать и 50 дней перенести из сериалов в книги.

Будем посмотреть.

понедельник, 18 января 2016 г.

О грейдах

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

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

Раз:
Стажер-тестировщик
Младший инженер по тестированию
Инженер по тестированию
Старший инженер по тестированию
Главный инженер по тестированию
Ведущий инженер по тестированию
Руководитель группы
Два:
Стажер (Intern)
Младший тестировщик (Junior test engineer)
Тестировщик (Middle test engineer)
Старший тестировщик (Senior test engineer)
Специалист по тестированию (Expert test engineer)
Ну и для примера возьмем описание - например сеньора или старшего.
Раз:
Знает тестируемый продукт на 85%
Обладает экспертными  знаниями в области тестирования и начальными в контроле качества.
Использует разные техники тестирования, в зависимости от задачи.
Обеспечивает доступность (распространение) информации и опыта среди других участников команды.
Обладает навыками тест дизайна
Проводит анализ рисков перед тестированием для обеспечения качества
Обладает всеми необходимыми техническими знаниями
Оптимизирует  тестовые сценарии
Возложена определенная ответственность за какой-то процесс или функциональность системы
Умеет эффективно планировать задачи и быстро давать оценки по тестированию
Способен самостоятельно принимать решения
Два.
Условия входа:
Middle test engineer плюс: - обучение стажеров, - консультации коллег по ТС, - принятие решений по архитектуре ТС, - ревью кода тестов программистов. Инициирует работы по развитию тестирования и ТС. Выполняет задачи на исследование. Пресекает некомпетентные распоряжения руководства. Обладает чувством юмора. Самостоятельно локализует проблемы недоконфигурирования сервиса, ОС, оборудования.

Описание:
Задает уровень качества кода ТС. Учитывает и может сформулировать риски и последствия технических решений. Может оценить время выполнения задач. Выполняет задачи, требующие участия сотрудников других групп. В курсе планов развития сервиса. Ориентируется в конфигурационных опциях сервиса и среды, самостоятельно меняет их при необходимости. Способен предложить SLA при отсутствии заданного. Администраторы и разработчики приглашают на встречи по обсуждению архитектуры, инфраструктуры и разработки сервиса.

Мне приходилось наблюдать, как грейды внедряли для групп от 4 до 200 человек.
Успешно - ни разу.

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

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

Что-то здесь не так?
Пойдем с начала. Вопрос - а зачем? Какая решается проблема? Чтобы что?

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

2. Вторая возникшая проблема - разная квалификация внутри команды и компании. Есть допустим Вася в команде А и он получает 50 денег. А есть Петя в команде Б и он получает вдвое больше. Проекты и бюджеты - разные, команды - разные. А обязанности - похожие. И команды своими Петей и Васей в целом одинаково довольны. Но тут у руководства возникает вопрос - а может они одинаковые? Может мы переплачиваем Пете? Вместе с этим у Васи возникают сомнения в мировой справедливости. Он же тоже хорошо работает, команда довольна... Необходим механизм сравнения тестеров внутри команды. а пуще того - из разных команд. Зачем - чтоб повысить уровень справедливости и снизить напряжение, соответственно раздав зарплаты и бонусы.

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

Итого, есть версия, что при появлении легитимной системы грейдов, которую поддерживает руководство мы будем легко и изящно указывать hr'ам на грейд который мы изволим нанять. Мы скажем Васе, что он получает вдвое меньше, так как он эльф 20 уровня, в Петя - 80го. Согласно табличке грейдов. И мы покажем Васе, что нужно качать, чтоб докачаться до 80, выдадим алгоритм действий.

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

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

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

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

Что же получается в реальности?

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

Сравнение.
Я не представляю, как можно сравнить тестеров из разных проектов. Можно выделить наличие или отсутствие тех или иных бинарных признаков, как то "автоматизация/написание кода", "знание бухгалтерии", "nix системы". Но в разных обстоятельствах-проектах эти признаки имеют разный вес. И даже если этот вес зафиксирован - есть еще разные этапы развития команды. Ценность навыков будет меняться и я не представляю как можно будет взять средний для компании.

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

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

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

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

четверг, 14 января 2016 г.

Базовые концепты Ветхозаветных Историй

Крайне интересный взгляд. Рекомендую прочесть все три статьи.
http://alexthunder.livejournal.com/1273699.html

Цитата, дающая представление - о чем там вообще:

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

вторник, 12 января 2016 г.

Фарго

На днях закончил просмотр второго сезона.
Смело заявляю - это лучший фильм, что я видел за последний год.

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

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


Категорически рекомендую к просмотру.