вторник, 23 февраля 2010 г.

Как бы я приготовил и протестировал омлет


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

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

Омлетная тема: как приготовить и протестировать амлет - это как раз один из тех вопросов, что я задаю на финальном этапе, называемых мной "странные вопросы".  

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

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

Почему?
Так почему же я так поступаю с людьми? Почему я такой монстр?! Что за проблемы с психикой у меня, что я отрываюсь на других? Кто мой психиатр???

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

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

Еще я ищу людей, которые читают и готовятся к собеседованию.  Если ты решил сменить место работы, пожалуйста, будь любезен, освежи свои познания. Прочитай модные книги. Пробегись глазами по блогам. Вспомни кто такой Джоэл Спольски. ТАМ ОБ ЭТОМ ПИШУТ. Если человек читает - это только в плюс. Я в месяц читаю уже не 5 технических книг, как раньше, но 1-2 книги точно. И специалист, которые не читает, если честно, меня настораживает.

ИТ специалист обязан читать. И обязан читать много.

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


Как задавать вопросы? 


Я не задаю вопросы подобные "омлетному" в начале собеседования.  

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

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

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

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

Главная обязанность того, кто проводит собеседование, поддерживать непринужденную беседу. Кивать. Улыбаться. Шутить. Ни в коем случае собеседуемый не должен чувствовать себя неуютно. Пусть лучше он подумает, что вы глупый и неадекватный, чем вы сломаете человеку желание искать работу дальше. Может быть и в другой компании.

Чего я жду?

Во первых я жду вопросов. 

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

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

1. Как приготовить? Рецептов амлетов до кукуя. Если у нас есть только один в меню, следует напомнить об этом клиенту. Если клиент хочет свой способ - спросить и уточнить у повара (обратная связь! - мы может случиться  и приготовить не сможем).
2. Количество порций (может статься, что клиентов несколько на один вид заказа - можно сэкономить время и приборы: сковорода, масло и т.п.)
3. Количество яиц (близко к вопросу 1)
4. Количество молока (близко к вопросу 1)
5. Соль, перец и другие с специи (близко к вопросу 1)
6. Другие ингредиенты (близко к вопросу 1)
7. На какое время рассчитывает клиент.
8. Уточнить сумму, на которую рассчитывает клиент...

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

 

не получил гигантский омлет из книги рекордов Гиннеса

 

тестировщик должен задавать вопросы, даже если до него потрудился бизнес аналитик.

Во вторых я жду описание техпроцесса

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

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

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

- хочу услышать фразы "если": Если у нас n яиц, то мы берем сковородку номер 666. Если у нас стандартный заказ - сыпем на n яиц соли и перца в пропорции столько-то грамм на количество молока+яйца. Если у нас заказ не стандартный - то у нас есть таблица что-с-чем-можно-смешать-в-каких-пропорциях. Либо нам эту таблицу нужно создать.

- хочу услышать шаги: 1. берем глубокую тарелку достаточную для количества яиц и остальных ингредиентов (см. таблицу что-с-чем-можно-смешать-в-каких-пропорциях). 2. По определенному порядку смешиваем продукты. 3. Разогреваем сковородку..... - ну вы как будто никогда не читали рецептов ж).

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

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

Какие выводы я делаю?


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

1. Разбить яйца.
2. Приготовить.
3. Попробовать.

Очень информативно, не правда ли?

Заключение

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

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

Несколько уточнений:
1. Я никогда не оценивают (и вам не советую этого делать) человека только по этим вопросам. Это только опция.
2. Человек не должен испытывать неудобство во время собеседования, иначе эти вопросы просто его добьют. Итог будет неутешителен и для вас и для собеседника.
3. Вопрос должен подразумевать, что специалист должен использовать свои знания в разработке программных продуктов.

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

Цитата недели: Никто не знает, сколько стоит качество

Недавно к нам приезжали менеджеры из далекого и туманного. Кроме корпоративного похода по ресторанам и их полных ужаса взглядов (погода то была в районе -24) я еще запомнил несколько стратегических целей и цитат.

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

Никто не знает, сколько стоит качество.

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

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

Как рассчитать сколько стоит качество? Ведь любой продукт (программный - не исключение) изначально обладает каким то качеством. Это уже позже идут формальные оценки на предмет того у кого качество выше (прям мужской подход - "мое пузо больше"). Но все равно оценивая формально, наверняка мы не можем точно определить, какое из качеств продукта сколько стоит. Фичу - да, фичу оценить можем. Ее заказывает клиент и мы ее продаем. Но клиент платит за функционал, который работает. А качество... Ну да, качество может быть от 0 до +100.

Другая сторона медали - доверие клиента. Мы разрабатываем продукт. Клиент доверяя нам - покупает продукт, надеясь на определенный уровень качества. Если его не будет, кто проиграет? Сколько мы потеряли в будущем, халатно отнесясь к своим обязанностям?

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


воскресенье, 14 февраля 2010 г.

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


Замечательный человек Yourdon Edward в своей книге процитировал не менее замечательного Kevin Huigens. Собственно Кевина цитировали несколько раз, мне больше всего понравился вопрос "Если ваш коллега собирается стать менеджером безнадежного проекта, что бы вы ... посоветовали ему не делать ни при каких обстоятельствах"

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

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

суббота, 13 февраля 2010 г.

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


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

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

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

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

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

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

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

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

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


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

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

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

понедельник, 8 февраля 2010 г.

Главное - это быть уверенным в том, что главное это главное. С. Кови

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

Не знаю следует ли своим советам Стивен Кови, но мне сейчас нужен хороший совет. Как начать жить спокойно. Как не перерабатывать. Как успокоить нервы. Как высыпаться за 8 часов. Как перестать мучаться из за совести (которая пилит, пилит -  что можное еще что то сделать, а ты домой - к семье). Нужен совет. Совет на оставшуюся неделю:

Главное - это быть уверенным в том, что главное это главное. 

С. Кови

Совет о том, что нужно уметь ставить приоритеты. Выше приоритетов ведь еще никто не прыгал ж).

Сам постараюсь следовать ему. И вам того же желаю.