Нечто большее

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

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

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

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

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

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

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

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

Есть три группы ограничений, которые уводят в общение тет-а-тет.

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

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

3. Секьюрность.
– Мы работаем с чувствительными данными клиента, тестируя финансовые сервисы иногда на данных пользователя. В онлайне запустить такое сложно. У пользователя меньше доверия — он может опасаться, что лишние люди увидят экран.
– С другой стороны, мы работаем с банками-заказчиками под NDA и должны гарантировать, что новый продукт не утечёт за пределы команды дизайна, разработки и тестов до запуска проекта.

Иногда от этого приходится отходить, например, когда респонденты из Европы или США. Всё это грозит двойной потерей качества — из-за онлайна и языковых барьеров.

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

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

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

👉 Отправка почты по расписанию. Если кто-то мне что-то должен в определённый день, то я заранее отправляю отложенное письмо, которое придёт адресату за день до срока долга и напомнит. Примерно так: "Напоминаю, завтра жду от вас ...". Отложенная отправка есть и в Gmail, и в Яндекс почте и наверное, много где.

👉 Если долгов много — ставлю мероприятия в Гугл. Календарь, подключаю туда "должника" и в настройки ставлю: уведомить на почту за 1 день" (или несколько интервалов).

👉 Пару раз использовал отложенные сообщения в Телеграм (их недавняя опция) — тот же смысл, что и с почтой, но более личный.

👉 Можно задействовать Trello, подключая "должника" как исполнителя на задачи со сроком — этот путь чуть сложнее, так как требует вовлечения должника в Trello.

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

Цитата про формальный vs реальный дизайн-процесс из эссе Майкла Бейрута —дизайнера и сейчас партнера Pentagram, команда которого работала над новыми логотипами Mastercard, Slack, Yahoo, Verizon и дизайном предвыборной компании Хиллари Клинтон.

-----

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

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

Это могло бы звучать примерно так:
«Работая над дизайн-проектом, я поначалу внимательно слушаю, как вы рассказываете о вашей задаче, и читаю все найденные справочные материалы по проблемам, с которыми вы сталкиваетесь. Если вам повезет, у меня случайно окажется личный опыт работы в ситуации, похожей на вашу. Идея дизайна появляется в моей голове по ходу процесса, из ниоткуда. Я не могу это объяснить; это сродни магии. Иногда это случается даже раньше, чем вы успеваете рассказать мне о вашей задаче! Если идея хороша, я стараюсь придумать стратегическое обоснование такого решения, чтобы объяснить его вам, не полагаясь на хороший вкус, который у вас может отсутствовать. По ходу я могу предлагать другие идеи либо потому, что вы заставили меня согласиться на это, либо потому, что не уверен в первой идее. Во всяком случае, надеюсь, на ранних этапах я сумею заручиться вашим доверием и к этому моменту вы будете готовы принять мои рекомендации. Понятия не имею, как вы собираетесь проверять их пригодность, за исключением того, что в прошлом другие люди — по крайней мере те, о которых я вам рассказал, — последовали моему совету и преуспели. Иными словами, не могли бы вы просто, ну, знаете... верить мне?»

-----

Конец цитаты.