Кандидаты-психопаты

Кандидаты-психопаты

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

________________________
1. Человек в течение последнего года присылает резюме каждый месяц.
А в нём ничего не меняется. За год ничего не появилось.
Ничегошеньки не изменилось. Портфолио так и не появилось.
И ты каждый раз говоришь: без опыта нет. И в вакансии пишешь — нет.
Надо хоть что-то. А ничего не меняется.

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

________________________
2. Человек откликается на каждую вакансию, присылает резюме, ему отвечают что не подходит. А он потом находит тебя в личке во ВСЕХ соцсетях и начинает писать: А почему нет?

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

________________________
3. Или тебе пишут: откликаюсь на вакансию на сайте. А ты дружелюбно: Извини, сейчас не набираем, но сохранили резюме, как только будем — напишем 🙂 И смайлик. Смайлик ставишь в конце. Ибо дружелюбно. И сейчас дружелюбно — очень сложно.

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

Чтобы что?!
Ты этот вопрос задаёшь, чтобы что?
Да мы раздолбаи, повесили на сайт вакансии, которые у нас когда-либо могут случиться, чтоб они там были. Год назад повесили, с тех пор висят вот. Сейчас не набираем. Или что, думаешь решим тебя взять после этого вопроса? Ох, да, извини, раз висит — давай тогда возьмём тебя.

________________________
Самое лайтовое, с чем сталкиваются все — это когда ты три раза пишешь в вакансии «давайте не тратить время друг друга — без опыта мы сейчас не готовы брать».
И тебе в почту падает 2/3 резюме от людей без опыта.

Чтобы что?
Чтобы мы вдруг решили, что нам надо троих взять вместо одного? Одного, чтоб нормально работу делал(как нам и надо). Второго, чтоб учил. Третьего чтоб был учеником.
Или потому что вы такой охуенный, точно надо брать.
Ну это не исключено, кстати 🙂

________________________
Мораль:

Когда общаетесь, задавайте себе вопрос «Я это делаю чтобы что?»

ЧТОБЫ ЧТО ПОЛУЧИТЬ?!

Если ответ не укладывается в область профессиональную, а лежит на стороне ваших комплексов и фиксаций — ну оставьте это своему психологу. Больше никому это не нужно.

Не начинать с отмазки и нытья

Плохая практика начинать свой рассказ с отмазки, давления на жалость и запроса преференций:

  • Версия пока сырая, не судите строго.
  • Я, конечно, не профессионал в этом, но пара комментариев у меня есть.
  • Возможно, вам совсем не понравится, главное собрать обратную связь.
  • Я понимаю, что уже много есть статей на эту тему, но у меня ещё не было.
  • Я понимаю, что вы устали — постараюсь рассказать побыстрее.
  • Это мой первый проект, надеюсь, что вы не будете меня сильно критиковать.
  • Мне не рассказать так круто, как это сделал прошлый докладчик, но всё равно послушайте.
  • ... и т.д. и т.п.

Зачем ты мне это показываешь, если не хочешь, чтобы я дал честную обратную связь?
Если сам знаешь, что показываешь откровенное Г., то зачем вообще показываешь?
Если у тебя нет опыта, но ты почему-то взялся и написал/сделал — почему я не должен критиковать?

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

Модель двойного алмаза

Если дивергентное мышление — это поиск множества решений одной проблемы, то противоположным ему будет конвергентное мышление — отсекание всего лишнего, анализ вглубь.

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

Если рассматривать этот процесс в рамках разработки продукта, то получится примерно такая история:

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

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) и команды.

Как спрашивать «зачем»?

Как вы помните из заметки про фичреквесты, которые не стоит выполнять (https://t.me/pmdaily/98), вопрос «зачем?» — самый важный вопрос, который нужно задавать любому представителю бизнеса, который пришел к вам с задачей.

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

Вот пара трюков, чтобы процесс задавания вопросов пошел легче:

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

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

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

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

И казалось бы, ответ довольно очевидный: мол Нильсен говорит 5. Но почему 5? Откуда это магическое число? Без математики не обошлось.

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

Если прорезюмировать, то можно сказать, что Нильсен не был не прав 🙂 Однако стоит приводить полный ответ:

—————————————————————————

Если во время тестирования эксперименты будут независимыми, а выборка по крайней мере квазислучайной, то мы можем предположить, что при тестировании 5 пользователей мы обнаружим 85% ошибок, с которыми сталкиваются не менее 31% пользователей.

—————————————————————————

Последняя часть, вообще интересная, не правда-ли? ) «Не менее 31% пользователей», то есть в самом неудачном случае 59% пользующихся так и не столкнуться с проблемами. Но это не слишком страшно.

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

http://bit.ly/2UqfhOs