Регулярными будем считать те задачи, которые надо выполнять периодически - например, раз в день, раз в неделю, или раз в месяц. Периодичность больше месяца рассматривать не будем (хотя и месяц – длинноватый период).
Начну с главного: регулярные задачи – очень мощный инструмент повышения эффективности работы. А теперь попробую объяснить, почему, и как с ними лучше обращаться.
Ключевое отличие от обычных задач
Главное, чем отличаются регулярные задачи от обычных – они ставятся один раз. Разумеется, при использовании какой-либо информационной системы управления задачами.
Как сказали бы программисты, регулярная задача – это абстракция, или отдельный класс, или декларативное описание задачи, или компонент, или вообще – метаданные задачи.
Вот обычная задача – «18.05.2018 г. Проверить статусы задач клиентов, поработать с просроченными статусами». Конкретная, четкая, понятная, но – одноразовая. Когда наступит 18 мая 2018 года, и вы задачу выполните, она исчезнет, оставив лишь след в истории. На 19.05.2018 г. вам придется поставить новую задачу, аналогичного содержания.
В чем будет отличие новой задачи? Только в дате – «19.05.2018 г. Проверить статусы задач клиентов, поработать с просроченными статусами». Вот эта дата будет параметром нашей абстракции. Соответственно, можно программно запустить цикл от текущей даты до конца следующего месяца, и абстрактное декларативное описание – регулярная задача – создаст нам три десятка реальных, конкретных, атомарных задач. Эти задачи уже нужно будет выполнять.
Постановка регулярных задач – это своего рода программирование, т.е. создание алгоритма, только не для машины, а для людей. Постановка обычной задачи – тоже алгоритм, только очень простой и, главное, без повторного использования.
В 90-е годы прошлого века я программировал на компьютере Бейсик Корвет, и у меня не было возможности сохранить программный код. Включаешь, набиваешь программу, выполняешь, выключаешь – она исчезает навсегда. Ровно по такому же принципу живут обычные задачи, в отличие от регулярных.
А в чем проблема-то?
Казалось бы, чего тут такого? Ну пришел менеджер на работу, написал задачи на день себе и подчиненным, и работа закипела. Но что в реальности?
Самый распространенный вариант – менеджер записал задачи раз, другой, потом через день, потом через неделю, и бросил. Потому что надоедает тупая работа обезьянки. Часть задач, конечно, продолжают выполняться без записи – те, о которых сложно забыть, вроде походов на назначенные совещания.
Второй вариант встречается, когда менеджер упертый, и продолжает с завидной регулярностью записывать задачи каждый день. Как минимум, себе. Все неплохо, дела идут, но сколько он на это времени тратит?
Главная беда – именно затраты времени. Постановка – это не щелчок пальцами, даже если это повторяющиеся задачи. А есть еще контроль выполнения, проверка результатов и т.д.
Ведение регулярных задач на бумаге
Есть дисциплинированные менеджеры и сотрудники, которые ведут регулярные задачи на бумаге. Самые распространенные варианты, которые я видел – чек-лист, min-mid-max, и так называемый Standard Work (стандартная работа?).
Чек-лист обычно на один день. Он содержит и регулярные, и ключевые задачи на день. Составляется с утра, или с вечера на завтрашний день. Один из апологетов чек-листов утверждал, что они повышают эффективность на 25 %. Спорить не буду, я честно попробовал – надоедает через 1-2 дня записывать одну и ту же регулярку, да еще и переписывать ключевые задачи из системы.
Min-mid-max – это колхозное название, наверняка есть более правильное, но я его не знаю. Та же бумажка, только туда пишутся задачи-минимум, задачи-максимум, и нечто среднее. Задачи-минимум надо выполнить обязательно, нечто среднее – желательно, задачи-максимум – это вообще шикарно, это цель. Регулярка попадает в задачи-минимум. Этот способ внедрялся по всей компании, прожил примерно неделю, умер по той же причине – всем надоело записывать, в том числе инициатору внедрения.
Standard Work – это вроде плана на неделю, расписанного по дням и часам. Там содержатся, практически, одни регулярные задачи, а внизу делается приписка из одной-двух ключевых задач на неделю. В основном, этим пользовались менеджеры, хватило примерно на месяц.
Главная трудность понятна – лень каждый день записывать регулярные задачи. Их проще сделать, чем записать.
Вторая трудность – их крайне сложно контролировать и анализировать, это почти нереальная задача. Попробуйте сами по куче бумажек составить статистику, хотя бы самую простую – все ли регулярные задачи за месяц вы выполнили? А если вам надо проанализировать действия других людей?
Поэтому, даже если бумажная запись регулярных задач ведется, толку от них мало, т.к. настоящего управления не получается – ни собой, ни другими. Есть только первый этап управления – постановка задачи.
Что в итоге?
В итоге происходит ужасное – регулярные задачи просто не выполняются, в нужном объеме и с требуемым качеством. Практически весь этот поток иссякает, остаются только самые насущные, о которых невозможно забыть.
Работают только обычные задачи, атомарные, уникальные, каждую из которых один человек поставил другому.
Практика потери регулярных задач широко распространена, поэтому на нее, обычно, не обращают внимания, равно как и на потери в эффективности. Если бывали на совещаниях, особенно на заводах, когда случился кризис, и ищут виноватых, очень часто дело оказывается в невыполнении регулярных задач, или процессов.
Может, регулярные задачи – это часть процессов?
Грань между регулярными задачами и процессами несколько размытая, но она есть. Мне кажется, проще всего ее определить так: регулярные задачи не имеют входов.
В процессах, если посмотреть на схему алгоритма (в какой бы нотации она не была оформлена), всегда есть вход, или овальный блок «Начало» (бывает не только овальным). У квадратиков внутри процесса вход есть всегда – это линия от предыдущего(-их) блока.
Наличие входа делает процессную задачу обусловленной, или зависимой – она не возникает на пустом месте, из воздуха, всегда есть причина – другая задача, другой процесс, заявка, письмо, звонок, план и т.д. Пришел сигнал на вход – пошел процесс. Не пришел сигнал – процесс спит.
Регулярная же задача подвешена в воздухе, у нее нет входа. Какой вход у задачи «Записать одну идею в день»? Утро? Совесть? Желание развиваться? Бизнес-цели?
Некоторые чернокнижники (описатели бизнес-процессов) пытаются изобразить регулярные задачи на традиционных схемах алгоритмов. Результат, увы, плачевный, еще хуже, чем у чек-листов, Standard Work и т.д.
При этом, с точки зрения, например, системы управления задачами вход вполне себе имеется – это расписание. Неважно, как именно устроено выполнение чего-то по расписанию в конкретной платформе, но вход один – «Пора»(поставить задачу, или сделать задачу). Так работают, например, напоминалки в смартфоне, вроде передачи показаний счетчиков 14-го числа каждого месяца.
Но для человека, в виде традиционного бумажного процесса, такой алгоритм описать сложно. Потому никто и не пытается, оставляя выполнение регулярных задач в ответственности менеджера.
А может, и не стоит с ними возиться?
Еще как стоит. Особенно, если вы хотите изменить ситуацию в бизнес-системе (отделе, команде, службе, бизнесе в целом). Регулярные задачи – это низко висящий фрукт эффективности, в терминах одних известных проповедников.
Буквально на днях я рассказывал о практике выполнения регулярных задач, которая привела к росту эффективности вдвое. Это была, по сути, всего одна регулярная задача – прошу прощения за тавтологию, задача по управлению задачами. Там, кстати, хорошо видно отличие регулярной задачи от процессной. Процесс регулирует решение каждой конкретной задачи клиента. Каждая задача – экземпляр этого процесса. А регулярная задача смотрит на все экземпляры сразу, сверху.
Проще всего понять важность регулярных задач на примерах из жизни, только там это называется дисциплина, или тем, кто постарше, может быть знакомо понятие распорядок дня.
В жизни, если хочешь перемен, нужно регулярно выполнять определенные действия (или не выполнять определенных).
Хочешь похудеть – надо или питаться определенным образом, или заниматься спортом, или все вместе. Даже если решил использовать чудо-средства для похудения, надо не забывать их употреблять каждый день. Хочешь бросить курить – надо не курить, это тоже регулярная задача. Хочешь расширить кругозор, или нарастить компетенции – регулярно читай книги. Хочешь освободить 1-2 часа в день – не читай интернет. Ну и т.д.
Регулярные действия помогают добиться качественных, устойчивых изменений. Есть, конечно, проблемы, которые решаются решением одной задачи – например, аппендицит – но таких немного. Большинство успехов зависят от рутинных, регулярных действий.
Ровно такая же ситуация в бизнес-системе, никаких отличий нет. Большинство проблем решаются, а целей достигаются не разовым усилием, а регулярной, рутинной работой, которая состоит, в основном, из процессов, но есть в ней место и регулярным задачам.
Что делать?
Сделать нужно немного:
- Автоматизировать работу регулярных задач;
- Ввести и использовать систему измерения их выполнения;
- Пользоваться п.1 и п.2.
Автоматизация
Возможность постановки регулярных задач есть, наверное, в большинстве систем. Если нет – ничего страшного, программисты сделают.
Что там должно быть:
- Настройка расписания, в любом доступном для платформы формате, индивидуально для каждой регулярной задачи;
- Генерация сущностей «Задача» из метасущности «Регулярная задача». Регулярная задача – одна, задач – много. Часто сущностей не создают, делая только напоминалки, но с ними не получится сделать п.3;
- Измерение – должна быть возможность измерения количества задач из регулярки – поставлено, выполнено, не выполнено, выполнено вовремя, выполнено с просрочкой, закрыто как невыполненное.
- Должна быть возможность автоматического закрытия задачи, которая не была выполнена. Например, если вы сегодня пропустили работу со статусами, нет смысла завтра делать это дважды. Вчерашняя задача должна закрыться автоматически, как невыполненная.
- Аналитические отчеты по выполнению задач.
Как видите, ничего сложного. Человек декларативно описывает регулярную задачу – «каждый день в 9-00 работать со статусами задач, в 11-00 задачу закрывать как невыполненную». Программа автоматически генерирует задачи на нужный горизонт – например, с утра на весь день, или на неделю вперед, чтобы можно было видеть расписание и учитывать занятость на регулярку.
Измерение
Измерение, или статистика – то, чего сильно не хватает бумажной регулярке. Из-за отсутствия измерений нельзя ответить на простой вопрос: как человек выполнял регулярные задачи в течение месяца? Даже если этот человек – вы.
Надеяться на память бессмысленно, особенно если в течение дня вы работаете с большим количеством разнообразных задач (а это, скорее всего, так и есть).
Если у вас нет ответа на этот вопрос, вы не сможете оценить эффективность изменений – того, ради чего начали выполнять регулярные задачи. Будет ощущение «вроде чего-то делаю, а ничего не меняется». Если у вас есть статистика, и вы точно знаете, что выполняли регулярку, а изменений нет – нормально, значит надо что-то другое делать.
А если данных о дисциплине нет, и результата (в изменениях) нет, то вывод сделать невозможно. Хотя, как ни парадоксально, большинство людей вывод делают, причем тот же самый – надо что-то другое делать.
Подчинение
В данном случае – подчинение самому себе, в первую очередь. Решили выполнять регулярные задачи, автоматизировали, измеряете – но этого мало. Определенная роль остается личной дисциплине и силе воли.
На 100% необходимость в этих факторах заменить нельзя, по крайней мере у самого себя. Подчиненных в этом плане проще заставить заниматься регуляркой, т.к. для выполнения приказов воля и дисциплина не нужна. Скорее, нужна дисциплина менеджеру – выгонять тех, кто приказы не выполняет.
К сожалению, или к счастью, в выполнении регулярных задач нет ничего абсолютного и биполярного, т.е. метаний от «делать все задачи» до «не делать вообще никаких задач». Речь всегда о доле, проценте выполнения того, что запланировано.
Предложенные инструменты – автоматизация и измерение – призваны, как раз, этот процент увеличить. Я проверял эту систему несколько лет, и практика показала, что становится лучше, особенно от измерений.
По материалам https://business-programming.ru
