Почему команда не укладывается в дедлайн и как этого избежать

08.09.2017
4920
Подпишитесь, чтобы получать новые статьи на почту

Анастасия Красноперова, менеджер проектов Tados, специально для блога Нетологии написала колонку о том, как боролась со срывами сроков и какие уроки из этого извлекла. Статья для конкурса блога.

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

Программа обучения: «Директор по онлайн-маркетингу»

Неправильное понимание задачи

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

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

Чтобы таких ситуаций не случалось, над решением нужно работать не только совместно с командой, но и с клиентом.

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

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

Проблема в ходе выполнения задачи

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

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

Проблему можно было решить, обратившись к тому, кто поможет и подскажет правильное направление.

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

Забытая задача

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

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

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

Это обязательно нужно сделать с участием самих сотрудников, так как их рабочий процесс достоверно известен только им. Пробуйте разные варианты и комбинации, анализируйте результаты и обсуждайте. Мы используем приоритеты и уведомления в таск-трекере, пользуемся ярлыками и напоминаниями Deskun в Gmail, используем Google Календарь и таймер в Trello. Постоянно улучшаем CRM, настраиваем удобные напоминания и планирование контактов с клиентами.

Неправильная расстановка приоритетов

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

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

Используйте приоритеты в таск-трекере и доносите до сотрудников, что задачи нужно выполнять в соответствии с ними.

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

Наличие более важных задач

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

Наш разработчик ждал от менеджера регистрации проекта в Microsoft BizSpark. У менеджера было много более приоритетных и срочных задач. Разработчик терпеливо напоминал о задаче и через несколько недель получил долгожданный доступ. Если бы он не делал этого, про задачу забыли бы.

Не стесняйтесь напоминать про задачу.

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

Много переработок

На моей практике чаще всего переделывать по несколько раз приходится макеты интерфейса. Это связано с тем, что при работе над ними открывается новая информация.

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

Имея на руках сценарии взаимодействия, можно двигаться дальше.

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

Читать еще: «5 советов для командной работы»

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

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

Выводы

  1. Постоянно сотрудничайте с заказчиком и пользователями, чтобы решать задачу, глубоко в нее вникая.
  2. Создавайте в команде атмосферу активного взаимодействия.
  3. Выстраивайте рабочие процессы и подбирайте инструменты совместно с сотрудниками. Постепенно повышайте удобство и эффективность труда.
  4. Обучайте сотрудников, убедитесь, что они разбираются в предметной области и понимают суть проблем.
  5. Напоминайте о задачах, которые поставили, следите за ходом выполнения.
  6. Двигайтесь к результату небольшими шагами, собирайте и анализируйте обратную связь.

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.

Анастасия Красноперова
Менеджер проектов Tados
Университет интернет-профессий
Мы используем файлы cookie
Чтобы улучшить работу сайта и предоставить вам больше возможностей для обучения. Продолжая использовать сайт, вы соглашаетесь с условиями использования файлов cookie.