Проекты – замечательный инструмент, но, как и любая модель, он имеет ограниченную область применения. Наверняка вы примеряли проекты на свои задачи и возникала мысль: "слишком громоздко" или "слишком много документов" или "нужен целый руководитель проекта". Конечно, не все изменения требуют проектов, но начинать, в любом случае, лучше сверху вниз: посмотреть на все задачи и подумать, какие из них лучше будут управляться одним человеком, так как содержат одни и те же цели или используют одни и те же ресурсы. Будет это проект или нет – уже другой вопрос.
Зачем группировать задачи? Каждая задача является объектом управления, а один человек физически может управлять ограниченным количеством объектов. И руководству организации проще спрашивать с одного человека, а не с тех, кто отвечает за подчинённые задачи. Как группировать задачи? Проект или проектная инициатива является лишь одним из способов группировки – как правило, это связано с необходимостью выделить на группу задач определённый бюджет. Проектный менеджер – и есть та самая фигура, которую спрашивают за трату бюджета (а заодно и срыв сроков). Но ведь могут быть и другие группировки:
- Элемент организационной структуры – для текущего развития каждого подразделения требуется выполнение единоразовых задач. Логично и ответственным за задачи назначить руководителя этого подразделения, но иногда есть выход лучше – дать возможность рядовому сотруднику проявить себя, сделав его / её ответственным за задачу.
- Межфункциональная группа / комитет – может проводить совещания (заседания), в ходе которых пачкой выдаётся набор задач. Как правило, ответственными за задачи становятся линейные менеджеры, но есть также функция администрирования внутри группы / комитета: убедиться, что исполнители получили и поняли задачи, снимать промежуточный статус выполнения задач, готовить сводный отчёт по статусу выполнения задач.
- Инициатива руководителя компании или подразделения, которая пока не тянет на проект, но имеет определённую направленность. Это может быть проработка новой области ведения бизнеса или то, что в будущем может стать проектом, да и просто смена поставщика закупаемых товаров или услуг (требуется исследование рынка, подготовка отчёта и принятие решения).
Нет ничего плохого в том, чтобы начать вести реестр таких задач в электронной таблице. Единственное, что за этот реестр в идеальном случае должен отвечать один человек, и он должен быть независимым от любого подразделения, на которое падают задачи. В том же идеальном случае это сотрудник или подразделение, которые подчиняется руководителю организации. К сожалению, если отчётность собирает любое линейное подразделение, то либо оно в какой-то момент либо бросает эту отчётность (есть другие важные операционные задачи), либо начинает манипулировать данными ("почти сделали", "уже доделываем"). Суть здесь в конфликте интересов: честный статус сразу влечёт за собой наказание, люди это понимают и не подставляются.
Как только реестр начинает работать, организация вступает в следующую стадию: задачи начинают сыпаться, как из рога изобилия, ведь у нас всё контролируется "автоматически". В реальности "ручной привод" – сотрудник, обновляющий реестр – имеет явные ограничения "пропускной способности". Одна задача может требовать его вовлечения несколько раз: узнать статус, проверить выполнение, запросить подтверждающие документы – и так для нескольких статусов задачи. Логично переложить эту работу на самих исполнителей: они заинтересованы как можно быстрее отчитаться, что задача выполнена. А проверку (и сотрудника, который её осуществляет) можно оставить, но сделать не сплошной, а выборочной.
Электронная таблица принципиально не может быть многопользовательской системой, пожалуйста не пытайтесь с ней этого делать. То, что вам требуется, называется разделением доступа на уровне строк, таблицы этого не умеют. Кроме этого, вам захочется, чтобы отчётность не "плыла", то есть не изменялась задним числом, чтобы статусы задач не откатывались произвольно с любого на любой без указания причины. Иначе у вас несколько месяцев будет "всё выполнено", а потом окажется "ничего не выполнено". Такие задачи решают системы управления задачами (task management), они же трекеры (tracker).
Трекеров существует великое множество, многие из них бесплатны, а уж сколько всего интересного заложены в платные продукты... Но тут надо помнить, что любой инструмент будет отражением того, что вы в него заложите. С трекерами ловушка именно в отсутствии аналитики, о которой шла речь выше. Если не придумать и не заложить (относительно) неизменные группировки задач, то в этом море задач можно "утонуть". Также могут помочь задачи разных уровней, чтобы контроль на верхнем уровне осуществлялся по небольшому числу задач (и их исполнителей – линейных менеджеров).
Можно уйти от проектов в ряде случаев, но от календарного планирования уйти не получится. И внедрение трекера подсветит, если вы раньше ставили задачи без учёта сроков ("по приоритетам"), трудоёмкости задач, доступных ресурсов, взаимосвязи задач – ресурсы окажутся перегруженными, а задачи – невыполненными. Внедрение трекера (и это также сложно реализовать в электронной таблице) вынудит (и это хорошая новость) перейти от приоритетов (которые каждый понимает по-своему) к обсуждению на единой временной шкале. Окажется, что это целый процесс – оценивать план и факт трудоёмкости, но это единственный известный способ получить результат в ожидаемые сроки. Самый неожиданный эффект, который я неоднократно наблюдал – конфликты исчезают. А что спорить? Что в сутках больше 24-х часов? Можно обсудить трудоёмкость задач, но кто может сделать быстрее, пусть и сделает быстрее.
Напишите пожалуйста в комментариях, с каким трудностями лично вы сталкивались при управлении задачами на уровне организации. Постараюсь ответить, если чем-то могу помочь!
Комментарии