О собеседованиях и найме

На днях прочитал отличную статью (https://vas3k.ru/inside/46/) о собеседованиях и найме. Написано в основном о том, как нанимать программистов, но озвученные мысли подходят и для остальных. Идеи близки мне по духу, потому что я считаю, что типичные собеседования это пустая трата времени. Вопросы о сложности алгоритмов или о бинарных деревьях не покажут ничего, кроме того, что человек об этом слышал и запомнил, а интервьюер тешит своё эго, потому что прочитал об этом 5 минут до интервью. А заставлять писать код на бумаге или на доске это вообще лютый зашквар.

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

ОК, на этом этапе определились, что человек нам нравится и мы готовы с ним работать в одной команде. Но как проверить технические знания? Для меня лучший тест – это сесть и вместе решить задачу, которую сами недавно решали в продукте. В таком варианте интервью будет сразу понятно как человек мыслит, как строит логические цепочки, какие аргументы за и против приводит, какие потенциальные проблемы видит, на какие грабли наступал и т. п.

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

Рейчел Бергер написала о влиянии технологических компаний на дизайнерские портфолио.

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

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

Сами дизайнеры не считают это главной проблемой. Чтобы пополнять портфолио, надо делать проекты (1), которые хочется показать (2) в портфолио (3).

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

Дизайнер не создаёт в одиночку что-то своё, он делает вклад в развитие системы. Сложно выделить часть продукта и назвать её своей работой. Также часто приходится работать в стол.

2. Непонятно, что дизайнер получит от пополнения портфолио. Работа у него и так есть.

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

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

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

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

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

Чинить баги по TDD

Один из кейсов, которые я рассмотрю на своём мастер-классе 26 октября (https://tdd.timepad.ru/event/1074439/?utm_source=telegram&utm_medium=messenger&utm_campaign=mypost-bugs) — это исправление багов по TDD.

Вот прилетает к нам задача, скажем «Жму на кнопку — не работает». Обычно мы чиним такие баги весьма тупо — поднимаем фронт и бек, придумываем гипотезу, и начинаем дебажить: вносим исправление и жмём на кнопку. Если заработало — отлично, если нет — просто перебираем дальше гипотезу за гипотезой. Иногда мы перебираем гипотезы настолько беспорядочно, что даже не убираем следы предыдущих попыток.

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

Правильный процесс выглядит так: открываем контроллер в API, куда ходит кнопка, а дальше ставим под сомнение каждый нижележащий метод, проговаривая про себя гипотезы, к примеру: «я сомневаюсь, что метод get_users() не возвращает неактивных пользователей». Если сразу не находим теста, который доказывает обратное — пишем свой. Если тест падает — отлично, у вас уже есть тест, и остаётся только написать код. Если написанный тест не падает — git checkout --, и ставим под сомнение следующий метод.

Такой процесс заставляет вас тестировать баги изолированно — вы никогда не натолкнётесь ещё на один баг, который создали во время предыдущих бесплодных попыток. А ещё вы никогда не отправите в прод неработающее говно, потому что у вас нет состояния «кажется всё заработало» — всё или заработало, или нет.

UX-редактор как пчёлка

UX-редактор как пчёлка

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

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

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

Дизайнер Лили написала про 12 типов тёмных паттернов.

1. Завлечь и переключить. У пользователя нет уведомлений, но Фейсбук показывает, что они есть, когда тот не залогинен.

2. Заставить испытывать вину или стыд. 2 кнопки: «Скачать буклет о здоровом питании» и «Нет, спасибо, мне плевать на своё здоровье».

3. Замаскировать рекламный баннер. На баннере может быть изображено содержимое или элементы навигации, которые ожидает увидеть пользователь.

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

5. Собирать контакты друзей и спамить им от вашего лица. Как LinkedIn.

6. Отвлекать внимание. Если не снять флаги с малозаметных чекбоксов при обновлении Скайпа, можно сделать Bing поиском по умолчанию, а MSN — домашней страницей.

7. Затруднять сравнение цен. Например, одни и те же яблоки в упаковках и на развес.

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

9. Упрощать пользователям желательные (для вас) действия и затруднять нежелательные. Попробуйте удалить свой профиль на Фейсбуке.

10. Формулировки с подвохом. Кажется, что ставя флаг вы отказываетесь от рассылки, а на самом деле наоборот на неё соглашаетесь.

Запрещено в Великобритании:

11. Скрывать полную стоимость. На последнем шаге оформления стоимость заказа немного увеличивается: появляется информация о доставке или дополнительном сборе.

12. Добавлять в корзину товар или услугу по умолчанию. Например, страховка при покупке билетов на самолёт.

Итеративный процесс в дизайне и инженерном творчестве

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

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

Например, «ОКБ Сухого» Информационно-управляющее поле кабины самолета СУ-35 / Т-50 было разработано в нескольких вариантах в виде тренажера, прототипа геометрии кабины и интерфейса управления с обратной связью в среде купола виртуальной реальности, через который пропустили несколько сотен курсантов с летных училищ с типичными заданиями.

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

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

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