Насколько влияет самое первое письмо будущему работодателю на потенциальное трудоустройство

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

Эксперимент проходил так:
- Ваня нашёл десяток примеров описаний вакансий продуктового дизайнера и скомпилировал из них усреднённый текст (https://research.mintblaster.com/#vacancy). Cамо по себе, кстати, интересное упражнение.
- Собрал группу из 16 экспертов (https://research.mintblaster.com/#experts) (в которую попал и ваш покорный слуга) — нанимающих дизайн-руководителей и руководительниц из Яндекса, Альфа-Банка, Почты России, Сбербанка, МТС, Mail.ru, Acronis, Miro, Revolut и других компаний.
- Сделал лендинг (https://research.mintblaster.com/) и предложил заинтересованным дизайнерам написать ровно одно письмо — такое, как если бы они по-настоящему хотели устроиться на работу. Всего удалось собрать 243 отклика, из них 228 человек отметили, что действительно искали работу.
- Дальше каждый эксперт отсматривал заявки дизайнеров-претендентов. Отреагировать на заявку можно было только кнопками «да» и «нет» — продолжил ли бы я общение с кандидатом на основании этого первого письма или отказал бы сразу. Практически Тиндер!
- Чтобы результаты были точнее, каждое письмо независимо оценивали минимум семь экспертов.
- В конце каждому кандидату пришла взвешенная оценка шансов оказаться приглашенным на собеседование на основании письма.

Получились такие результаты:
- Кандидаты распределились по нескольким группам по количеству положительных оценок экспертов:
- 3% — Все эксперты нажали «да».
- 8% — Больше 80% положительных голосов экспертов.
- 25% — От 50% до 80% положительных голосов.
- 22% — Между 30% и 50% положительных голосов.
- 40% – меньше 30% положительных голосов.
- (ещё 2% были отмечены как спам.)
- То есть по-настоящему сильных откликов — всего 11% (первые две группы). Это очень соотносится с моим опытом поиска дизайнеров.
- Почти половина всех откликов — 40% — очень слабые.
- Другая добрая половина (47%) попала в средние группы, когда голоса экспертов разделились.
- В среднем эксперты тратили 50 секунд на просмотр одной заявки (включая просмотр портфолио и вообще всех приложенных ссылок). Вот столько времени у письма есть, чтобы произвести впечатление.

Продираясь через десятки писем, я искал только одно: портфолио с хорошими работами (писал про это давным-давно (http://t.me/desprod/9)) и/или внятный свежий опыт работы над продуктами. Всё.

Остальное не важно. Длинные тексты, перечни навыков и дипломов, списки инструментов или интересов, желания и мечты — всё это больше мешает. Стаж работы вообще идёт во вред, если не подтверждается результатами.

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

Вот, кстати, Ксения Стернина, которая тоже была экспертом в Ванином исследовании, подробно рассказала про то, что стоит и не стоит писать в письме работодателю (https://blog.uxssr.com/2020/01/29/cover-letter-for-designers/).

Почитать полностью все результаты исследования можно тут (https://designer.mintblaster.ru/results). Там же Ваня проводит следующий эксперимент, в котором кандидаты могут рейтинговать друг друга. Кстати, по отзывам участников, когда они смотрят чужие письма и работы и сравнивают с тем, что написали сами, очень хорошо начинают понимать, как стоит писать и как не стоит.

Самое тонкое место в UX

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

А где самое тонкое место в UX?
Чаще всего самое тонкое место в UX — место, в котором пользователь соприкасается с человеком, представляющим продукт.
Для b2c продуктов узкое место в UX, как правило, поддержка.
Для b2b продуктов таких мест много: продажник, внедренец, поддерживатель.

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

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

Я решил уйти от МТС в Теле2 с сохранением номера.
На сайте Теле2 заполнил форму перехода, указал данные паспорта, чтобы, как написано на сайте: обработка запроса прошла быстрее в точке выдачи. Отправил запрос. Мне дали два дня, чтобы прийти в точку продаж, а после заказ протухнет.
Через день я пришёл в офис, а он закрыт, хотя время его работы уже давно наступило. А телефон менеджера офиса выключен или вне доступа. Подождал 15 минут и ушёл. Так меня Теле2 "выгнал" первый раз.

Я не сдался и написал сразу же красочное письмо в поддержку: пришёл, закрыто, как я могу вам доверять и что делать?
Мне не ответили в течение суток, как обещано на сайте Теле2. Я написал напоминание — сутки прошли, жду ответ.
Мне ответили и "не пустили" меня в продукт снова. Сапортница сказала: "Очень жаль. Заполните заявление на другой офис."
Другой офис, к слову сказать, в 10 км от меня. А новое заявление — это снова все поля и паспортные данные.

Что я подумал про такой сервис? Ничего хорошего. Заполнять я больше ничего не стал.

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

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

Заметки на полях. Из психологии.

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

Общая формула: событие → [автоматическая мысль] → эмоция

П Р И М Е Р

Событие:
прилетает внезапная срочная задача

Автоматическая мысль, которую не замечаем:
«Я не справлюсь» (или «Я могу не справиться»)

Эмоция:
тревога

Примечание: этот пример максимально базовый, чтобы все могли попробовать его примерить на себя. Уровень тревоги в подобном примере обратно пропорционален опытности специалиста, так что, если вы занимаете middle+ позицию, то вспомните себя пару лет назад.

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

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

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

И понятно, что будет полезно уметь замечать и работать с автоматическими мыслями в обычной жизни. Если вам интересно чуть подробнее покопать для себя эту тему, то можете просто начать хотя бы со статьи на Википедии (https://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D0%BC%D1%8B%D1%81%D0%BB%D0%B8), чтобы как-то сориентироваться. Понимаю, что источник не самый глубокий, но для старта может подойти.

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

1. Каковы доказательства, поддерживающие эту идею? Каковы доказательства, противоречащие этой идее?
2. Существует ли альтернативное объяснение?
3. Что самое плохое может произойти? Смогу ли я пережить это? Что самое лучшее может произойти? Каков самый реалистичный исход?
4. Каковы последствия моей веры в автоматическую мысль? Каковы могут быть последствия изменения моего мышления?
5. Что я должен делать в связи с этим?
6. Что я мог бы посоветовать ___ (другу), который находится в такой же ситуации?

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

Как дизайнеры рэп читали

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

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

После Мемус-батла Саша посвятил всех в таинство ретроспективы, объяснив суть и важность этого мероприятия.

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

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

Довольно часто перед ретроспективой мы проводили какую-то неформальную активность — играли во что-то, рисовали, заказывали пиццу, то есть делали что-то, что помогало снять флёр серьезности и субординации. Писать на стикерах можно было все что угодно: прочитал книгу, съездил в гости, заболел, сходил в спортзал — все это показывало общее настроение в команде и давало понять, что нами движет.

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

Подводя небольшой итог занятий с Сашей: хорошая и сплоченная команда — это залог успеха.

Британка у всех на слуху, что же она из себя представляет?

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

Мы занимаемся во вторник и четверг с 19 до 22, и в субботу с 11 до 18.
Обучение очное, и это круто. Можно вновь почувствовать себя учеником: поднимать руку на занятиях, выполнять задания и хлопать выступающим.
Одна из фишек очного образования — коммуникация с другими студентами. Это здорово стимулирует — когда ты видишь, что большинство уже выполнили задание, то волей-неволей сам начинаешь шевелиться. И конечно, это новые связи и знакомства — одна из причин, по которой я пошел в британку.

В данный момент у нас во всю идет блок исследования — экспериментальный курс на 1,5 месяца. Введение подобного курса — это попытка адаптации обучения под динамично меняющуюся индустрию.

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

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

7 важных факторов PHP-приложения

7 важных факторов PHP-приложения

Инженеры платформы Heroku (https://www.heroku.com/) на основе собственного опыта создали методологию (https://12factor.net/ru/) для разработки SaaS-приложений.

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

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

Кодовая база (https://12factor.net/ru/codebase). Забота о коде начинается с принципов его версионирования и хранения. Используйте Git Flow или его адаптацию с учетом специфики работы ваших команд.

Зависимости (https://12factor.net/ru/dependencies). Используйте менеджер зависимостей Composer (https://getcomposer.org/) и его основные операции install и update для манипуляций c composer.json (https://getcomposer.org/doc/04-schema.md) и composer.lock.

Конфигурация (https://12factor.net/ru/config). Предпочтительным методом обработки конфигурации является использование переменных среды. Для работы с ними мы применяем компонент symfony/dotenv (https://github.com/symfony/dotenv).

Параллелизм (https://12factor.net/ru/concurrency). Выполняйте процессы в фоне, тем самым снижая время отклика при взаимодействии с вашим сервисом. Выделяйте веб-процессы в реальном времени и рабочие процессы. Первые принимают http-запросы от клиента, а вторые — выполняют фоновые задачи, например, с помощью брокера сообщений RabbitMQ (https://github.com/rabbitmq).

Паритет разработки/работы приложения (https://12factor.net/ru/dev-prod-parity). Для того чтобы обеспечить схожесть сред разработки, тестирования и продакшена, мы используем виртуализацию на основе Docker и специально подготовленные образы, содержащие одинаковые наборы и версии библиотек. Промышленные и тестовые среды отличаются лишь степенью масштабирования, на основе технологий K8S и Swarm.

Журналирование (https://12factor.net/ru/logs). Фактор утверждает, что приложение должно просто писать в STDOUT и STDERR, а среда должна отвечать за маршрутизацию этих сообщений в хранилище. Технология PHP-FPM позволяет производить вывод логов в STDOUT, что крайне полезно при работе с Docker-контейнерами. Для организации процесса логирования на уровне приложения мы используем сторонние внешние библиотеки, например Monolog (https://github.com/Seldaek/monolog) или компоненты фреймворков.

Задачи администрирования (https://12factor.net/ru/admin-processes). Реализовать сценарии администрирования приложения можно с помощью внешних библиотек, например Symfony Console (https://github.com/symfony/console). Большинство современных фреймворков имеют встроенные средства для организации запуска консольных команд для служебных целей и миграций. Например, в Yii Framework есть понятие консольного приложения (https://www.yiiframework.com/doc/guide/2.0/en/tutorial-console) и команды.