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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

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

Автор статьи: Светлана Коновалова





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

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





Первым делом — самолеты


Вам понадобится стратегическое мышление и навык правильно расставлять приоритеты, в соответствии с теми ресурсами, которыми вы располагаете. Инструментами для планирования вполне могут стать Trello или Jira, но еще до того, как вы найдете ответы на три главных вопроса, необходимо четко понимать, чем ваша команда занимается, а чем НЕ занимается.

Вопрос здесь стоит не только в умении делегировать, но и в четком разграничении сферы влияния. Не стоит пытаться «закрыть собой все дыры», в худшем случае, члены вашей команды и вы сами профессионально выгорите. Не врывайтесь в дизайн мерча или плакатов для конференции вашей компании, если вы дизайнер ЦИФРОВЫХ продуктов. Из этого редко выходит что-то хорошее, а непрофильные таски добавляют львиную долю когнитивной нагрузки.

Правильно расставляйте приоритеты и четко понимайте, где заканчивается ваша сфера влияния.



Внутренняя и внешняя политика


Работа внутри команды – тема для монографий и фолиантов, но есть еще и внешний мир. Другие отделы, например. И дизайнерам надо как-то с ними взаимодействовать. Хорошо, если работа налажена и автоматизирована (Sketch+Abstract, Figma API), а передача дизайна разработчикам не вызывает никаких проблем. Однако так бывает не всегда.

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

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

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

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

Читать первую часть.
Источник: https://habr.com/ru/company/otus/blog/463903/


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

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

Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ — анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ...
В докладе поговорим про концепцию io.Reader/io.Writer, для чего они нужны, как их правильно реализовывать и какие в связи с этим существуют подводные камни, а также про построение pipelines на ба...
Основное событие года, это, конечно, Windows 95. Пока ещё не очевидная победа — по прежнему сильны DOS (не только MS) и Windows 3.xx, IBM выкатывает русскую OS/2 Warp, где-то ещё шевелится Alpha ...
Пишем API для React компонентов, часть 1: не создавайте конфликтующие пропсы Пишем API для React компонентов, часть 2: давайте названия поведению, а не способам взаимодействия Пишем API для...
Здравствуйте. Я уже давно не пишу на php, но то и дело натыкаюсь на интернет-магазины на системе управления сайтами Битрикс. И я вспоминаю о своих исследованиях. Битрикс не любят примерно так,...