Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

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

2 Пока команда тратит время на задачи, которые не важны, актуальные и срочные простаивают.

3 Прежде чем браться за задачу, нужно понять, действительно ли она важна и определить приоритеты. Это можно сделать с помощью<a>матрицы Эйзенхауэра</a>.

4 Команда избегает любых рисков в работе. Боится ошибок, поэтому использует только проверенные тактики и шаги.

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

6 Перестаньте ругать сотрудников за ошибки и научитесь управлять рисками. Здесь мы писали,<a>как это делать в digital</a>.

7 Ваши сотрудники скрывают неудобную информацию. Тянут до последнего, пока провал не станет очевидным.

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

9 Попробуйте проводить ежедневные короткие совещания - митинги. Это часть методологии Scrum. Каждый день собирайте команду и задавайте сотрудникам три вопроса:

10 <ol><li>Что ты сделал вчера?</li>

11 <li>Что планируешь сделать сегодня?</li>

12 <li>Есть ли что-то, что мешает работать?</li>

13 </ol>Что еще почитать про Scrum:

14 <ul><li><a>Будь гибким: как понять Scrum и создать agile-команду</a>;</li>

15 <li><a>Как создать план проекта в Scrum за пять шагов</a>.</li>

16 </ul>Команда не решает проблемы, не ищет реальные причины ошибки, а смягчает последствия. Например, разработчик не пытается понять, почему одинаковые баги есть в конце любого проекта, а каждый раз исправляет их и продолжает работать дальше.

17 Такие проблемы никуда не исчезают и никогда не будут решены. Они сопровождают проект и могут добавить забот в любой момент.

18 Если проблема повторяется часто, нужно найти причину и понять, что с ней делать, чтобы она больше не возникла. Например, написать тесты до начала разработки и использовать их после каждой добавленной функции. Это одна из практик<a>экстремального программирования</a>.

19 Команда постоянно готовится к работе. Проверяет ТЗ, обсуждает функции и задачи, переделывает спецификации. И никак не может начать проект.

20 Сотрудники тратят на подготовку время, которое нужно для работы, поэтому часто срывают сроки.

21 Если так происходит, это недостаток планирования. Когда команда не держит сроки на виду, то пропускает их. Чтобы этого избежать, визуализируйте все процессы с помощью kanban-доски. Вот здесь мы рассказывали, что такое и как работает<a>Kanban</a>.

22 Такое случается, когда вы внедряете новую методологию. Команда воспринимает все ее принципы буквально, слепо следует инструкциям и боится отойти в сторону.

23 Команда не учитывает контекст и особенности проекта. Про него нужно помнить при внедрении любой новой системы. Если принципы Аgile подошли одной компании, не значит, что они универсальны.

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

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

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

27 Внедрять новое или нет, решать вам. Но сначала подумайте и сформулируйте, зачем вам это. Помогут эти вопросы:

28 <ul><li>Что плохого в нынешнем методе?</li>

29 <li>Что мы можем улучшить, если воспользуемся новым?</li>

30 <li>Сколько времени понадобится, чтобы его внедрить?</li>

31 <li>Можно ли улучшить процесс без кардинальных изменений?</li>

32 </ul>Такие команды тоже бывают. Эти ребята не готовы мириться с принятыми руководителем решениями. Каждое совещание они начинают с обсуждения проблемы, которую менеджер решил еще вчера.

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

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

35 Есть сотрудники, которые все критикуют. Но только в конце, когда пора сдавать проект.

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

37 Такая критика не всегда обоснована. А если ошибки есть, то время упущено и исправлять их некогда.

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

39 Сотрудники перекидывают ответственность друг на друга. Например, команда сорвала сроки проекта, потому что много времени ушло на тестирование и исправление багов. Программист недоволен - ему добавили работы - и винит во всем дизайнера. Тестировщик злится на всех и считает, что только ему есть дело до проекта. В результате - скандал. Это происходит, когда нет четкого разделения обязанностей и никто не понимает, за что отвечает.

40 В команде возникает хаос, а менеджер не знает, с кого и что требовать.

41 Распределить обязанности, поделить зоны ответственности и контролировать проект на всех этапах.

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

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

44 Проводить общие совещания и давать высказаться всем членам команды. Если нужно оценить задачу и получить объективный результат, попробуйте<a>метод Planning Poker</a>. В нем сотрудники оценивают задачу числовыми картами. Действует принцип "сначала оценка, потом обсуждение". Это исключает любые зависимости мнений друг от друга.

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

46 Сотрудник не выполняет задачу, приходится делегировать ее другому или делать самому. Так вы упускаете время.

47 Прежде чем поручить задачу, проверьте загруженность сотрудника. Если он уже занят, лучше делегируйте кому-то другому. Вот<a>здесь</a>мы рассказали, как это делать правильно.

48 Команда предлагает добавить дополнительные функции, которых нет в ТЗ.

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

50 Когда сотрудник предлагает что-то добавить, задайте ему эти вопросы:

51 <ul><li>Зачем эта функция?</li>

52 <li>Как она улучшит продукт?</li>

53 <li>У нас есть на нее время и деньги?</li>

54 <li>Что скажет заказчик?</li>

55 <li>Нам хватит времени, чтобы решить остальные задачи?</li>

56 </ul>Такие ситуации не навредят, если случатся один раз. Но когда они стали частью каждого проекта - это шаблоны, от которых нужно избавляться. Или команда будет повторять одни и те же ошибки, которые могут стоить денег, времени и репутации.

57 Чтобы команда не превратила проект в пепел, нужен руководитель. Он будет планировать и распределять задачи, правильно расставлять приоритеты и помогать решать проблемы. А еще доверять сотрудникам, находить подход к каждому и быть частью команды, а не надзирателем. Стать таким менеджером можно: понадобится жажда знаний, терпение и пройти<a>курс по управлению проектами</a>.