5 советов о Design Leadership. Часть 1

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.
Всем привет. Уже в этом месяце мы запускаем курс «Team Lead 2.0», который подготовлен специально для старших разработчиков, TeamLead’ов, SCRUM мастеров и специалистов, желающих повысить свой профессиональный уровень и получить уникальный опыт, необходимый для эффективного управления командами разработки.

В преддверии старта данного курса делимся с вами интересным материалом по теме.
Автор статьи: Светлана Коновалова




Design Leadership – это о лидерстве и менеджменте в области дизайна, по сути аналог термина Project Management для разработчиков. Только если второе в России уже прижилось достаточно хорошо, то первое встречается не часто. Каким должен быть человек, который будет отвечать за ваш дизайн-отдел или команду дизайнеров? Как вы должны себя вести и что постоянно помнить, если хотите стать таким человеком? Именно об этом мы сегодня и поговорим. Эта статья будет полезна тем, кто начинает или недавно начал свой путь в качестве тимлида. Однако, если вы уже имеете определенный опыт, можете просто лишний раз убедиться в том, что вы все делаете правильно.

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



Три главных слова


Задача лидера – мотивировать команду. Звучит максимально расплывчато, не так ли? Когда тимлид рассказывает о новой задаче, большее количество времени он уделяет технологическому аспекту, то есть поясняет требования, рассказывает ЧТО делать и КАК делать. Об этом он может говорить долго, в красках и деталях, стараясь ничего не упустить. Это правильный подход, лучше лишний раз объяснить, чем потом гадать правильно ли вас поняли, но разговор про ТЗ – это далеко не мотивация.

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

Зачем? Что? Как?

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



Вы – худший специалист


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

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

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



Дело не в тебе, дело во мне


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

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

На этом первая часть нашего материала подошла к концу. Очень ждем ваши комментарии и обещаем опубликовать завершающие два совета уже на этой неделе. ;-)
Источник: https://habr.com/ru/company/otus/blog/463353/


Интересные статьи

Интересные статьи

Продолжаем наше исследование, посвященное ситуации в США со стрельбой полицейских и уровнем преступности среди представителей белой и черной (афроамериканской) рас. Напомню, что в пе...
Заключительный перевод разделов Redis Best Practices с официального сайта «Redis Labs». Самое необычное и интересное сегодня под катом! Читать дальше → ...
В данном посте мы поговорим о только что выпущенном JetBrains языке с зависимыми типами Arend. Этот язык разрабатывался JetBrains Research на протяжении последних нескольких лет. И хотя репозитор...
В данной заметке будут рассматриваться различные "большие" программные средства для резервного копирования, включая коммерческие. Список кандидатов: Veeam Agent для Linux, Bacula. Будет провер...
И снова здравствуйте. Это продолжение статьи про организацию студенческого хакатона. В этот раз расскажу про проблемы появляющиеся прямо во время хакатона и как мы их решали, локальные ивенты ко...