Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

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

2 Но даже люди одной профессии могут быть разными по характеру. Чтобы найти подход к каждому, менеджер должен знать своих сотрудников.

3 Вот четыре типа людей, которые могут встретиться в команде.

4 Рядовой

5 Есть профессиональные навыки, но работа для него - просто работа. Не любит новые инструменты. Использует то, к чему привык. Уравновешенный, спокойно ведет себя в стрессовых ситуациях.

6 Что можно делегировать

7 Любит стабильность во всем и не любит нестандартные задачи. Можно доверить любую рутинную работу, например, обновлять kanban-доску по результатам ежедневных совещаний.

8 Исследователь

9 Любит все новое и эксперименты. Нервный, его раздражают навязчивые вопросы и контроль. Но часто погружается в процесс настолько, что пропускает дедлайны, поэтому за ним нужно наблюдать. Привык общаться только с себе подобными. Любит свободу и работать в тишине.

10 Что можно делегировать

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

12 Отличник

13 Очень практичен. Чтобы работать, должен видеть четкую цель и понимать пользу, которую принесет. Зануда и любит критиковать работу других. Многое знает и умеет. Самостоятелен: не любит, когда им руководят. Остается спокоен в любой ситуации.

14 Что можно делегировать

15 Готов выполнять задачи, в которых видит необходимость. Можно доверить все, что требует концентрации, но польза дела для проекта должна быть очевидна, или ее придется объяснить.

16 Связной

17 Коммуникабелен и умеет быть убедительным. По техническим задачам лучше работает в команде, чем один: легко объясняет коллегам, что и как делать, но не всегда может повторить это сам.

18 Что можно делегировать

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

20 Чтобы делегировать задачи, нужно следить за текущим уровнем загрузки сотрудников. Это можно делать, например, в <a>MS Project</a>. В этой статье рассказали, как планировать проект с помощью этого инструмента.

21 Так в MS Project выглядят перегруженные ресурсы.Сначала кажется, что это несложно. Всего-то нужно объяснить, что и как делать, а потом проверить результат. На самом деле все не так просто. Вот о чем менеджер должен помнить, чтобы не рисковать проектом, но и не делать все самому.

22 Чтобы с задачей можно было работать, нужно понимать не только, что делать, но и зачем. Когда сформулировали цель, проверьте ее по методу SMART.

23 Согласно SMART, цель должна быть:

24 <ul><li>конкретной: точно определять результат, который хотите достичь;</li>

25 <li>измеримой: устанавливать критерии оценки, чтобы понимать, когда цель достигнута;</li>

26 <li>достижимой: нужно учитывать все ресурсы и ограничения;</li>

27 <li>значимой: быть выгодной для проекта;</li>

28 <li>ограниченной по времени: нужно достичь результат за определенный срок.</li>

29 </ul>Разберем на примере. Цель конкретная, когда понятно, что нужно сделать: например, провести декомпозицию задач.

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

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

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

33 И, наконец, цель должна быть ограничена по времени, значит, нужно установить сроки, предположим, провести декомпозицию задач за один день.

34 Вы по умолчанию должны разбираться в задаче, которую собираетесь делегировать. Потому что так вы всегда сможете оценить результат. А если поручите непонятную вам задачу, в нее все равно придется вникать, когда сотрудник придет с вопросами.

35 Расскажите, что хотите получить в результате. Например, вы просите дизайнера показать макет сайта клиенту. Задача сотрудника - поработать с возражениями: учесть замечания заказчика, но отстоять выбранную стилистику проекта. Как это сделать, думает сам дизайнер. Вы должны только уточнить, когда и какой ждете результат, как будете его проверять.

36 Когда объяснили задачу, уточните, правильно ли вас поняли. Вопроса, все ли ясно, здесь мало. Может получиться, что сотрудник понял задачу по-своему. Тогда все выяснится только на этапе проверки результата. Чтобы этого избежать, попросите описать, что конкретно понял сотрудник, или просто повторить то, что вы сказали.

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

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

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

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

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

42 Если вы совсем не умеете общаться с творческой командой, прочитайте наши<a>вредные советы</a>, чтобы знать, как точно не надо делать.

43 Правильно делегировать полномочия важно не только для успеха проекта, но и для развития сотрудников. Команде приятно знать, что вы в нее верите и не сомневаетесь в ее способностях.

44 Мы разобрали, как делегировать задачи в digital. Но одного этого навыка мало, чтобы управлять проектом и развиваться как менеджер. Нужно уметь общаться с клиентами и командой, управлять временем, ориентироваться в методологиях и уметь их внедрять. Всему этому учат на<a>курсе Skillbox</a>. А пока учитесь, сможете использовать полученные навыки в работе.