Учёт задач и управление проектами – одно и то же? Где начинается разница

У задачи три основных поля: ответственный, срок и статус. Статусы вроде «открыта», «в работе», «выполнена» позволяют команде говорить на одном языке. Хороший список задач сокращает утреннее совещание: никто не спрашивает, у кого было это дело.

Сила учёта задач в простоте. Подготовка налоговой декларации в бухгалтерской фирме, обратный звонок клиенту в шоуруме, напоминание о продлении договора в офисе – отдельные задачи. Задержка одной не останавливает другую; каждая отслеживается по своему сроку.

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

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

Государственные органы тоже проводят это разграничение по уровням. Стандарт реализации проектов правительства Великобритании GovS 002 рассматривает управление портфелем, программой и проектом как отдельные уровни; текст стандарта находится на странице публикации на GOV.UK. Малой компании все эти уровни не нужны, но мысль о том, что задача – отдельная от проекта единица, та же.

У проекта есть ещё и объём работ: что будет сдано, а что нет. Если объём не записан, проект тихо разрастается. Клиент просит небольшое дополнение, команда добавляет его в список как новую задачу, а срок сдачи остаётся прежним. Список задач этого роста не показывает; управление проектами сразу спрашивает, как новая задача влияет на срок.

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

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

Если появляется один или несколько из этих признаков, списка задач начинает не хватать:

• Завершение одной задачи стало условием начала другой.
• Срок сдачи, обещанный одному клиенту, зависит от работы нескольких людей.
• На утреннем совещании вопрос 'кто отстаёт' сменился вопросом 'успеем ли к сдаче'.
• Когда меняется объём работы, никто не знает, какие задачи это затрагивает.

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

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

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

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

Согласование задачи тоже часть этой связи. Такие шаги, как согласование дизайна, должны закрываться, помимо отметки «выполнено», ещё и согласованием уполномоченного лица. Как проект связывается с записью клиента, можно прочитать в статье что такое ПО для управления проектами.

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

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

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