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

Раньше я работала в Битриксе, и по какой-то неведомой причине мы с коллегами упорно игнорировали все задачи, которые ставились в системе. Выполняли лишь то, о чем нас просили устно или по телефону. Сейчас я работаю в YouGile с командой, которая развивает эту систему.

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

Этот пункт – первая причина, по которой в компании не задерживается надолго любая система управления, будь то Битрикс или YouGile, неважно. Как правило, в компании отсутствуют какие-либо прописанные процессы. Если их не было до появления системы управления, они и не появятся после. Хаос сохраняется.

Перед внедрением стоит сесть и прописать в виде алгоритма всё, что хочется организовать. А затем придумать как это реализовать в системе досок с колонками.

Часто ситуация выглядит примерно так. «Молодой» PM (проектный менеджер) делает три колонки – «Новые», «В работе», «Готово» – и говорит команде: «Начинаем работать». И… Команда не работает, по крайней мере в системе.

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

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

• Руководитель добавляет к проекту двух человек – себя и менеджера Лену.
• Делает три колонки – «Новые», «В работе», «Готово».
  
• И говорит: «Я буду в «Новые» добавлять задачи и тебе надо их делать. И да, если сама видишь, что что-то нужно, то добавляй задачу и приступай. Самое главное – чтобы у нас в офисе было очень хорошо и всём хотелось тут постоянно находиться. Короче, надо сделать как дома…».
  

Так не работает! Это не бизнес-процесс!

Через неделю Лена скажет что всё сделала, просто что-то ещё не успела отметить. Через две – появятся задачи, которые вообще прошли мимо. Через три недели всё благополучно вернётся к тому, что ген.дир. регулярно будет приходить к Лене и говорить что делать. Если компания растет, он постарается «делегировать» эту обязанность – и теперь руководитель HR будет ходить к Лене и говорить что делать.

Например:

• Каждый понедельник до 11:00 в колонке «В работе» должно появится ровно пять задач. Лене нужно самой выбрать задачи с расставленными приоритетами из большого списка возможных работ. Если останется время, можно решать другие задачи.
• Все срочные задачи должны быть помечены «Срочно» теми, кто ставит задачу.
  
• Все задачи, лежащие в работе больше одной недели должны быть с дедлайном.
  
• Каждую пятницу в 17:00 проходит планерка между руководителем и офис-менеджером, где обсуждается два вопроса: «Что сделано?» и «Что планируется сделать?». По результатам планёрки составляется и обсуждается список возможных работ и расставляются приоритеты.
  

Конечно, это только возможный пример, всё сильно зависит от конкретной ситуации даже при таком простом процессе, как работа над офисом. Как обычно, дьявол в деталях: «Какой специалист Лена? Сколько человек в офисе? Чем вообще занимаются в офисе? Что является критерием хорошего офиса? Сколько этажей? Какой климат за окном?» И так далее.

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

Вот пример доски, по которой сразу можно сказать, что работа идёт:

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

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

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

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

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

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

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

Примеры простых работающих правил, со временем становящихся негласными:

• Сотрудник отвечает за то, чтобы колонка была пустой как можно быстрее.
• Сотрудник отвечает за переход всех задач с приоритетом «Важно!» в последний столбец к концу недели.
  
• Во всех задачах поставлен комментарий «Со всем разобрался» (например, на доске обучения).
  
• Сотрудник отвечает за максимальное кол-во взятых на себя тикетов из первой колонки.
  
• Сотрудник отвечает за заполнение колонки карточками с точно описанными проблемами на объекте. И к концу неделе отвечает за то, что других проблем нет.
  
• Сотрудник отвечает за прикрепление фото в день окончания работ.
  

Конечно, не по всем сотрудникам возможно так сделать. Отлично, если это получилось с 30% команды и со временем стало очевидными правилами.

И для контраста несколько примеров правил, которые не работают:

• Сотрудник отвечает за ведение доски.

• Сотрудник отвечает за своевременное выполнение задач.
• Сотрудник отвечает за качественное написание текстов описания.
  
• Сотрудник отвечает за продажи и фиксацию этого в системе.
  

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

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

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

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

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

Итак, по моим наблюдениям – если эти несколько моментов выполняются, то команда перестает саботировать поставленные задачи и охотно вовлекается в работу над проектами. Я вижу это на собственном опыте в системе YouGile, но эти принципы актуальны и для любой другой системы управления проектами.