В копилку менеджеру: 10 главных факторов, мотивирующих на работу

Просто хороший список мотиваторов для обсуждения с подчиненными - что из списка их сейчас не устраивает. Взято из книги "Незаменимый. Можно ли без вас обойтись". Автор - Сет Годин.

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

1. Задача и ответственность.

2. Гибкость.

3. Стабильное рабочее окружение.

4. Деньги.

5. Профессиональное развитие.

6. Признание коллег.

7. Стимулирование коллег и начальников.

8. Захватывающее содержание работы.

9. Культура организации. 

10. Местность и сообщество. 

Только один из этих стимулов является внешним (№ 4 — деньги). Все остальное — это либо то,что мы делаем сами для себя, либо то, что мы ценим само по себе. 

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

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

Tester Bill of Rights

Какая замечательная вещь этот биль о правах тестировщиков...

• You have the right to bring up issues related to testing, quality, and process at any time.
• You have the right to ask questions of customers, programmers, and other team members and receive timely answers.
• You have the right to ask for and receive help from anyone on the project teams, including programmers, managers, and customers.
• You have the right to estimate testing tasks and have these included in story estimates.
• You have the right to the tools you need to perform testing tasks in a timely manner.
• You have the right to expect your entire team, not just yourself, to be responsible for quality and testing.

Agile Testing. A practical Guide for Testers and Agile Team. Lisa Crispin, Janet Gregory

Software People. Поток Сознания

Прошла конференция Software People 2012. Давно не видел такую концентрацию идей на квадратный метр. Собственно хочу поделиться потоком сознания, который получил во время докладов.

Цитаты или переработанные цитаты не привязаны ни к дня конференции ни к докладчикам докладчиков. Также не всегда это только голые цитаты.

Просто поток...

Сильный удар под дых тестировщику оптимисту...

Проценты багов найденных различными техниками. 

Сильный удар под дых тестировщику оптимисту...

Взято: http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/

Закончил "Стили Менеджмента" Ицхака Адизеса. Второй день не дает покоя мысль, что "Бюрократы"слишком хорошо прижились в среде тестировщиков.

Как и Герой-одиночка, Бюрократ все понимает буквально. Чтобы поверить во что-то, -A-- непременно нужно увидеть это своими глазами. Он не любит рисковать...

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

-A-- не способен к догадкам. Большое ухо, большая нога и широкая спина не станут слоном, пока туман не рассеется. И тогда, потрогав и обнюхав слона, Бюрократ недоверчиво скажет: «Хм, может быть, это и слон». 

Бюрократ считает, что, пока есть сомнения, строить догадки недопустимо.

Переводя на наш язык

Тестировщик: Бага?

Программист: Фича.

Бизнес аналитик: Фича.

Клиент: Фича.

Тестировщик: Хм... ну может быть, может быть...

Опять про собеседование - 3 главных пункта

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

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


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

Идеальный тестировщик

В книге ТРИЗ прочитал занимательную фразу. 

"Идеальный прибор - это прибор которого нет"

На все книги накладывается отпечаток профессии. В итоге получаю интересные и порой занятные мысли:

"Идеальный тестировщик - это тестировщик, которого нет"

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

Рассказал разработчикам - хитро смеются за спиной...

Журналисты, качки, ученые... изобретатели

Продолжая совершенствоваться в think out of the box наткнулся на старую добрую ТРИЗ. Одна из цитат тронула самые тонкие материи

В школе и вузе будущий инженер привыкает к тому, что условиям задачи следует безоговорочно доверять. Если в условиях сказано, что даны А и Б и надо найти X, это значит, что найти надо именно X и что приведенные данные (А и Б) достоверны и вполне достаточны. В изобретательской задаче все иначе: в процессе решения может выясниться, что найти надо не X, a Y и для этого нужны не А и Б, а В и Г. Поэтому первые встречи с изобретательскими задачами порождают недоумение и неуверенность в том, правильно ли они сформулированы, конкретно ли поставлены и т.д. На самом деле правильно сформулированных изобретательских задач не бывает.

Генрих Альтшуллер. Найти идею. Введение в ТРИЗ

Оглядываясь назад, вспоминая как ставятся задачи тестировщикам, хочется продолжить: в жизни бывает, что найти нужно сначала Y, потом Z, а потом - XY, а для этого нужно АБВГД...Я.

Так что коллеги мы с вами не только журналисты, качки и ученые, но еще и изобретатели. 

Кто виноват?

Кто виноват в том, что баг пропустили?

Риторический вопрос.


Наверное разработчики, потому что они баг посадили.


Или, быть может, тестировщики, потому что они баг пропустили.


А может быть менеджер? - он су..а, времени не дал, чтобы нормально запрограммировать , а потом протестировать.


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

Социальные игры племен Разработчиков и Тестировщиков: Внутри же - конфликт веры.

Закончил на днях книгу BOSS, книга с некоторыми особенностями, но если вам говорят "Сюжет захватывает от первой до последней страницы" - не верьте, это булщит. Книга имеет ряд интересных идей, но попытка сделать роман не удался  (только мое личное субъективное мнение). Впрочем тем, кто любит Deadline. Роман об управлении проектами, наверное, такой подход придется по душе.

Странные метаморфозы термина BUG - в маркетинге

В книге Психология Влияния наткнулся на интересный маркетинговый трюк называемый BUG. Подробности ниже.

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

Компетенции инженера по качеству

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

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

Общее в профессии ученых и тестировщиков

О том как описывать баги, сказано уже очень много. О правилах поведения при встрече с багами на пальцах показал Cartoon Tester Andy Clover. О том, как баги искать, не менее убедительно расскажет любой человек, который их когда либо искал ;).

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

Об ученых:

(1) постановка проблемы, 

(2) гипотеза, касающаяся причины проблемы, 

(З) эксперименты, предназначенные для испытания каждой гипотезы, 

(4) предсказанные результаты экспериментов,

(5) наблюдаемые результаты экспериментов, 

(6) заключения из результатов экспериментов.

О тестировщиках:

Баг - по сути - это проблема.  

Мы выдвигаем гипотезы, о том как воспроизвести баг.

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

 Предсказанные результаты -> наблюдаемые результаты -> заключение в виде описанного бага в багтрекинг системе.

Оказывается любой тестировщик это ученый, поскольку: 

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

Занятная мысль: каждый день мы ставим научные эксперименты! - еще один камень на нашу чашу весов в выборе профессии ж).

Cartoon Tester: Bug Trophy

По адресу http://cartoontester.blogspot.com обитает замечательнейший человек, рисующий занимательнейшие карикатуры из жизни тестировщика. Про сайт узнал случайно, но рад, что вообще узнал. 

Одна из последних картинок про зал славы тестировщика.  

Очень сильно улыбнуло.

Classic Bugs at Microsoft:The new 2% milk cartons are clearly dysfunctional. They don't open properly

Занятный пример написания бага и ответа - от Microsoft из книги How We Test At Microsoft. Как говорится - улыбнуло.


Bug #65889: The new 2% milk cartons are clearly dysfunctional. They don't open properly .
Opened by …
The new 2% milk cartons are clearly dysfunctional. They don't open properly. This seems to be a regression from the older design. Building 35 is having the same issue. Clearly, this is a Pri1, Sev1 bug because I'm encountering it 2 to 3 times a day.

Response from Microsoft Dining
Thank you for contacting us about the new milk. We found out the reason that the milk is hard to open is because our milk provider has just bought a brand-new machine for the pint-size milk cartons and they are adjusting the machine now so as not to have such a tight seal. Thank you for your question, and should you require additional information, please feel free to contact me.

Suggested workarounds:
1. Drink water instead.
2. Bring your own cow.
3. Use elevator doors to clip off the seal.
4. Freeze the milk carton, let the frozen milk crack the carton, and then thaw.
5. Tell your manager that you can't work without milk and let him solve the problem.
This bug is causing a lot of churn—it might sour our attempts at the RI this week. I hope we can moove
on this issue quickly.

The exact same problem has been reported out in the Sammamish campus. We've discovered a local workaround that might be helpful. There is an alternate dairy located approximate 1.35 miles south of our location that bottles 2% in quart-sized containers that are sufficiently easy to open. The downside is that it is typically substantially more milk than a single person can comfortably consume in one sitting. An additional step to the workaround is finding 2-3 other people who also want to consume the milk at the same time. I'm not sure that this warrants downgrading of the bug's severity because of the caveats associated with this workaround: (1) the geographic location of the alternate source being much less convenient than the kitchen fridge, and (2) that efficient consumption requires pooling of resources.

The latest information I have from our dairy provider is that they will not be able to release the fix ASAP because the new fix will be required to go through extensive testing. The testers have refused to sign off on the fix. They said that they have merely tested the private for the bug fix but haven't run their full regression pass. Currently, only three testers are handling this component and they can drink only 8 cartons a day. The team could conduct more carton-opening tests, but carton-tasting, milk flow testing, and carton pressure tests are still remaining. In addition, since the seal has been made less tight they have been observing breaks in their stress tests.

Test needs 3-4 more weeks.

Любите не компании, а людей.

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

Давно хотел обдумать свое отношение к работе, компаниями и сослуживцам. Перенести акцент с требований любить компании. Посоветовать любить людей.

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

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

Мне так же говорили - нужно ценить ценности компании. Я же думал о том, что ценить нужно прежде всего ценности отношений между людьми. Ценности любой компании в том чтобы выжить на рынке (чтобы они не писали в своих миссиях). А это чревато ох каким отсутствием человеческих ценностей, которые мне близки, во времена кризиса.Спрашивали ли Microsoft/IBM/etc: мы вас увольняем, но вы ведь продолжаете любить нас? Как бы мне хотелось увидеть эту статистику.

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

Давным давно мне посчастливилось прочитать Тайм Менеджмент Для Системных Администраторов. Мне очень нравиться то, что думает автор. И хочется процитировать. Если в очередной раз нарушил копирайт...совесть меня не замучает, но извиниться могу.

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

Раньше существовал так называемый «неявный общественный договор». Мы работаем на фирму 40 часов в неделю, а она платит нам, чтобы у нас были средства к существованию, и что-то отчисляет в пенсионный фонд нам на старость. Это была честная сделка. Но теперь корпорации отбирают у нас все больше времени без какой бы то ни было  компенсации. Профессионал работает 60-70 часов в неделю, а потом подпадает под массовое сокращение штатов из-за ошибочных решений бестолковых топ-менеджеров, зарплата которых в 100, если не в 1000, раз превышает его зарплату. 

В 1990-е годы я работал в AT&T/Lucent,  и нам постоянно напоминали, что могут уволить нас в любой момент независимо от того, насколько хорошо мы справляемся с работой. Нам говорили, что надо радоваться переходу от гарантированных пенсий  к принципу «каждый сам за себя» в соответствии с новым пенсионным планом, принятым фирмой. И при этом в последние годы моей работы в этой компании руководство было поражено и встревожено снижением лояльности сотрудников. Лояльность - улица с двусторонним движением.

Томас Лимончелли

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

PS. Да, кстати, мое мнение может не совпадать с официальным мнением компании, в которой я работаю сейчас или работал раньше.

Карма, пестициды, танцующий медведь и все все все

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

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

Собственно речь пойдет о парадоксе/эффекте пестицида  - о том, что нам мешает видеть дефекты.

Основной принцип данного парадокса/эффекта в том, что если мы тестируем приложение, одними и теми же тестами, не изменяя тесты со временем, то количество багов будет увеличиваться - баги будут расти за пределами покрытия данных тестов. Будут приспосабливаться к нашим тестам. Собственно в подтверждение своих слов  играм разума приведу цитату про избирательную систему активации взятую из книги Дэвида Алана - Как разобраться с делами (Getting Things Done)

В выпуске журнала "Научная Америка" ( Scientific American) за май 1957 года была статья об открытии области мозга, имеющей сетчатую структуру, и лежащей в его основании. Эта область отвечает, главным образом, за доступ к вашему осознанному знанию, это кнопка, которая включает ваше восприятие идей и информации, это то, что позволяет вам спать, даже когда включена музыка, но заставляет вас проснуться, если в соседней комнате заплачет ребёнок.

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

Выделенное жирным выношу (с большим опозданием) в цитату недели.

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

A Good Tester has these qualities:

Есть замечательная статья Classic Testing Mistakes  (залежи полезного тут), в которой приводятся личностные характеристики Хорошего Тестировщика:

- methodical and systematic.
- tactful and diplomatic (but firm when necessary).
- skeptical, especially about assumptions, and wants to see concrete evidence.
-  able to notice and pursue odd details.
- good written and verbal skills (for explaining bugs clearly and concisely).
- a knack for anticipating what others are likely to misunderstand. (This is useful both in
finding bugs and writing bug reports.)
- a willingness to get one’s hands dirty, to experiment, to try something to see what
happens.

Brian Marick// Classic Testing Mistakes

Что тут добавить спросит обыватель тестировщик?  - Я бы добавил еще знание иностранных языков ;-)

Программная ошибка как артефакт существующей и правильной спецификации

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

Спецификации, технические задания, планы проектов быстро и безвозвратно устаревают. Редкий менеджер (в моей памяти) ведет историю документа и только QA, как мячик скачет от спецификации к менеджеру, от менеджера к разработчику, от разработчика к программе, что бы собрать крупицы правды. По этому же поводу Сем Канер отозвался очередной цитатой недели:

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

Сем Канер и др. Тестирование ПО

А если спецификации нет или она неправильна? - Скачите Шура, скачите.

Цитата недели от Сема Канера: ценность плана тестирования

Ценности в жизни QA - это вообще отдельная ветка размышлизмов. Но сегодня будем цитировать мудрых. Например Сема Канера. У одного их столпов QA выявление ценностей звучит с легким бюрократическим уклоном:

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

Сем Канер и др.
Тестирование Программного Обеспечения