А что первое тогда?

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

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

Офигенно. Спасибо. Круто смотреть в чат и понимать, что не у тебя одного какие-то такие штуки случаются.

Почитай правила чата пожалуйста.

ок, спсибо

#стать_лидом №2. Иерархия

Сегодня поговорим о том, что склеивает дизайн-команду в единое целое — иерархии. Если пренебрегать ей, дизайн делать бессмысленно, поскольку это всегда взаимодействие нескольких по заданным правилам с определённой целью. Эти принципы написаны кровью.

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

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

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

Управляемость или талант?
Когда тимлид задаётся вопросом, нанимать ли талантливого, но своенравного, либо среднего, но управляемого дизайнера, он уже делает большую ошибку и пренебрегает основами управления.

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

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

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

Пример: стажёр, которая села на шею
Я испытал это на себе, когда полгода промучался с первым стажёром. Она оспаривала каждое моё решение и я полагал, что это идёт на пользу качеству дизайна. Потом мне было жалко её увольнять, потому что я вложил много сил. Я пытался договариваться там, где уже было невозможно это делать. Мне сели на шею, а я ещё долго мягко доказывал правильность решений. Как оказалось, это тупиковый путь. Это была ошибка, из-за которой я потерял много нервных клеток и времени, стремясь вернуть её обратно в адекватное состояние. В итоге пришлось уволить. Тогда я выдохнул и понял, как много сил я потратил впустую.

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

Ты тимлид? Давай общаться! Оставляй комментарии об управлении дизайн-командой и задавай вопросы.

—
#для_профи

Очень интересная мысль
Вроде и согласен, но в конце рабочего дня не слишком готов вступать в дискуссию уже))

Возвращайся завтра на свежую голову! )

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

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

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

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

я думаю тут речь об этом балансировании контроля и свободы 🙃

Круто. Особенно это

Превращать рабочие задачки в то, что хочется делать 🙂

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

Плюсую)

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

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

Команда и работа — твой инструмент. Если он совсем не подходит для достижения твоих целей  и его нельзя доработать/по-другому использова, чтобы подходил — наверное да

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

Полностью поддерживаю

+1 интересно про разграничение ролей, особенно чьё мнение решающее: продакт менеджера, продакт дизайнера или даже старшего разработчика (мне знакомы много кейсов когда разработчики много чего решают)