Core Protocols 2

На прошлой неделе я начал писать про Core Protocols и мы посмотрели на список Core Commitments. Если вы пропустили пост и не понимаете, о чем вообще речь, можете вернуться вот к этому посту — https://t.me/designgest/377.

Сегодня хочется перейти к самим протоколам. Но не хочется пересказывать 100% того, что вы и сами можете прочитать в статьях и книжках, а хочется подсветить части протоколов, которые кажутся наиболее интересными.

И первый протокол, о котором хочется поговорить — Check In.

Чек-ин чаще всего используется в начале встречи рабочей группы. Цель чек-ина — в заранее определенной форме поделиться мыслями и эмоциями по поводу ситуации, проекта, задачи с другими членами команды.

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

Чек-ин протокол предлагает простую схему для изложения чувств, он предлагает использовать всего 4 основные эмоции (напишу их на английском, чтобы у вас потом не было путаницы, если пойдете читать книгу):

GLAD (радость)
SAD (грусть)
MAD (бешенство)
AFRAID (испуг).

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

Плюс комбинацией этих базовых эмоций можно получать описание более сложных эмоций. Так например, EXCITEMENT = GLAD + AFRAID.

Стандартные правила для чек-ина следующие:
1) высказывать свои чувства без оценки и цензуры. Можно объяснить причину, по которой вы испытываете конкретные эмоции. Нельзя преуменьшать свои эмоции, говоря, например: «немного грустно».
2) нужно говорить только о своих эмоциях
3) с уважением слушать чек-ины других
4) не обсуждать и не ссылаться на чек-ины других, если нет явного приглашения для этого.

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

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

Недожали

Сегодня речь пойдет о таинственной формулировке «недожали» или особенности преподавания UI.

Как вы помните, UI не самая моя сильная черта (https://t.me/bukhtiyar/161), поэтому я поделюсь взглядом человека, которому нужен был спасательный круг в этой новой сфере. И судя по отзывам, многие, из пришедших в британку, также ждали прокачки своих скиллов в визуале. Но были ребята и с богатым опытом в полиграфии и иллюстрации — им, безусловно, было легче. Но ни я, ни многие другие не получили должного внимания со стороны преподавателей. Давайте попробуем разобраться почему.

Что вообще нужно для того, чтобы научиться делать красивый UI (ну, кроме таланта, конечно)? Необходимо пройти через большое количество проб и ошибок, т.е. чем больше повторений сделано — тем более качественный результат.

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

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

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

Но однажды я все же получил небольшое пояснение этого термина. Одним вечером, после занятий я решил спросить, Сергея, что же делать когда ничего не получается? Он поделился своим опытом — когда ничего не получается можно начать решать проблемы постепенно, брать какую-то одну небольшую часть проекта, например, контролл и доводить его до совершенства. То есть фокусируешься на одном моменте, не отвлекаясь ни на что больше. И… постепенно «дожимаешь» весь проект.

Напомню, что мы работали в командах по 2-3 человека, и работа над UI выглядела следующим образом: каждый из студентов делал заход на визуал проекта, составлял мудборд и на основе его рисовал несколько экранов. В итоге, в каждой команде отбиралась самая проработанная концепция. На её основе составлялся UI-Kit, который затем раскатывался на всё приложение с дальнейшей шлифовкой.

На зачете по блоку UI наша команда предоставила три одинаково плохие концепции, и Женя Бондарев посоветовал смешать несколько идей из каждой концепции. На этом его активное участие в обучении закончилось. А мы остались один на один с очень сырым UI, и тут же стали его переделывать. Про мои страдания вы можете почитать в прошлом посте, скажу лишь, что все майские праздники я потратил на погружение в особенности работы над UI. Это время не прошло зря, я открыл для себя много нового и из зачаточных мои навыки стали чуть более крепкими.

Что же по обратной связи — то блок, который вел Женя закончился, и чтобы получать хоть какую-то обратную связь я стал донимать Сергея Гальцева, на что однажды получил комментарий, что он уже не отвечает за блок UI, т.к. со второго семестра является куратором курса. Исторически он вел блок UI, в первом семестре так и было. Но во втором семестре блок UI вел Женя Бондарев, при этом Сергей также продолжал комментировать макеты и принимать активное участие. Но четкого понимания, кто рулит процессом и несет ответственность не было. Я уже молчу про ситуации, когда комментарии разных преподавателей по одному макету противоречили друг другу.

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

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

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

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

Но практически до самой защиты я был недоволен результатом и постоянно переделывал экраны так или иначе.

Три правила организации процесса дизайна

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

Вопрос: есть команда из трёх человек

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

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

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

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

Вопрос: расскажи, какими должны быть должностные обязанности менеджера?

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

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

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

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

Спрашивали про точки развития для дизайнера.

Спрашивали про точки развития для дизайнера.

Точек роста для дизайнера четыре:

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

— Творческое развитие. Создание индивидуальной творческой траектории независимости и автономной работы. Частный проект в котором дизайнер один на один со своей личной задачей. Создание личного проекта с осознанными и глубокими мотивами самореализации.

— Postdigital. Отказ от цифровых методов создания вещей в пользу любой натуральной, аналоговой технологии создания объектов. Классические методы производства, длительные, основательные, трудоемкие, но развивающие практическое, прикладное мышление.

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