Большинство IT-компаний не делают версии своих продуктов под Windows Phone, потому что доля мобильной операционной системы от Microsoft меньше, чем у iOS и Android. Тем не менее, это третья крупнейшая мобильная операционная система на рынке, и в Badoo Windows Phone приложение уже давно существует.

Изначально оно было написано аутсорсным разработчиком на Silverlight и долгое время не обновлялось, и несколько лет у продукта не было выделенного отдела. В 2014 году в компанию пришел разработчик Windows Phone и стал поддерживать это приложение, а я стал получать на тестирование некоторые его задачи.

Через пару месяцев было решено написать полностью новое приложение, забросив почти все старые наработки во многом потому, что код был далек от идеала, а на его поддержку тратилось очень много времени. Первым новым приложением для Windows Phone стал экспериментальный проект Badoo — Hot or Not. По концепции он очень похож на Badoo, но в нем гораздо меньше функционала и он несколько отличается. Всего за 3 месяца мы вдвоем сделали приложение Hot or Not с нуля в одной ветке Git-репозитория, которую в итоге замержили в Master. А приложение TeamCity было настроено так, что каждый коммит разработчика собирался как отдельное приложение, что позволяло мне, как тестировщику, видеть историю изменений клиента.

Как ни странно звучит, но речь действительно пойдёт про usability кабинки туалета.

Цель статьи — немного размять мозги.

Сейчас многие говорят про usability. Но не многие всерьёз о нём задумываются.

— Сделаю-ка я высовывающуюсь панельку на своём сайте. Ведь это же… как его… юзабельно!

Но сейчас я хочу поговорить не про веб-интерфейсы и вообще не про интерфейсы, а про устройство кабинки туалета.

Бен Кэменс обнаружил, что в выпадающем списке Shop by Department на сайте «Амазон» ховер-эффект происходит очень быстро, абсолютно без какой-либо задержки. Тем самым происходит нарушение старого, выработанного ещё в 90-х годах прошлого века правила: перед отображением пункта подменю необходим так называемый гистерезис, запаздывание.



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

"… и пусть никто не уйдет обиженным..."

или пусть уходят, зато

"… правду говорить легко и приятно..."

---

Собственно проблема

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

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

Компания знает, что всегда нужно сообщать причины отказа, иначе «карма компании упадет, а бизнесу будет нанесен непоправимый урон». Сам по себе этот тезис явно спорный, но безусловно, элементарная этика требует поставить все точки над «i» и корректно завершить общение с соискателем. Поэтому будем отвечать всем и всегда.

Формулировать отказы дело не такое уж и простое. Хорошо, если есть четкая объективная причина, в которой «ничего личного — только бизнес». Ну, например:

• "… к сожалению, мы не можем предложить вам такие условия работы, как вы хотите";
• "… мы не можем предложить вам N денег";
• "… в тестовом задании содержатся такие-то ошибки, которые мы считаем принципиальными";
• "… мы не берем на работу студентов первого курса".

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

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

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

---

Введение (от переводчика)

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

И вот недавно случилось интересное — Патрик Вайат (Patrick Wyatt), один из тех людей, кто стоял у истоков Blizzard, и человек, который затеял разработку Warcraft начал цикл воспоминаний о тех временах. Первая статья, которую я вам предлагаю прочитать ниже — о начале разработки Warcraft. О том, откуда появилась идея; о том, какая сеть была организована у ребят в офисе, пока они грезили о мультиплеере; о EMS и тонкостях эстетики программирования под DOS; о команде проекта и так далее.

Я, увы, совсем не специалист в разработке под DOS, поэтому если читатели укажут мне на неточности в переводе, связанные с техническими деталями — буду рад и тут же исправлюсь.

Это касается, понятное дело, и любых других неточностей, опечаток, пунктуации и стилистики.

---

Давным давно, в начале времен, когда игры для PC писались под операционной системой DOS, я начал работать над игрой под названием Warcraft.