Чем задача отличается от действия? Часть 1

От маленького камня и большой загрохочет; маленькими делами большие делаются

В статье «Чем задача отличается от цели?» мы разобрали различия между сущностью «цель» и сущностью «задача».

Есть ещё одна сущность, от которой надо чётко отделить «задачу». Это сущность — «ДЕЙСТВИЕ».

В статье «Что такое задача?» я писал: «Для того чтобы приступить к выполнению задачи её надо декомпозировать до уровня действий. Крупные (ёмкие) задачи, декомпозируются на более мелкие задачи, те в свою очередь — ещё на более мелкие, а задачи самого нижнего уровня — декомпозируются на действия».

Здесь довольно часто возникает вопрос: чем задача отличается от действия?

Раньше этот вопрос ставил меня в тупик.

Когда меня спрашивали: нужно ли фиксировать в качестве задачи всё, что делается? Каждое наше действие. Я не знал, что на это ответить.

Не знал, как соизмерить задачу и действие? Как их чётко разграничить, чтобы не мешать друг с другом? Не мог объяснить, на каком уровне декомпозиции мы ещё имеем дело с задачей, а на каком — уже с действием? В какой момент нужно завершать декомпозицию задач?

Сформулировать ответы на эти вопросы нужно было. Иначе эти понятия будут смешиваться, отождествляться и, тем самым, создавать путаницу.

Более того, сущность «действие» — это тоже очень важная сущность, участвующая в управлении потоком задач. Особенно в выполнении бизнес-процесса «Обеспечить воспроизводимость выполнения запоточенных задач» (кратко - Воспроизводимое выполнение ЗЗ)[1].

Поэтому отвечаю.

Объективная необходимость формулировать целевой результат заключается в том, что для задачи, чтобы оценить, выполнена она или нет и насколько успешно выполнена, объективно необходимо формулировать её целевой результат, а для действия — нет.

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

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

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

Компетентность есть способность обнаружить и удовлетворить личные вкусы начальства

Лоренс Питер[2]

Так вот, при делегировании надо всегда задаваться вопросом, что вы делегируете: действие или задачу.

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

В итоге, предсказуемо, получают разочарование — обман ожиданий: не то сделали, не так исполнили, не доделали, затянули сроки и т. д.

А что хотели? Вы задачу делегировали как действие. Вы же не определили целевой результат. На что ориентироваться-то при исполнении? С чем сравнивать? Как определить границы исполнения и объём работ?

У каждого свои представления о результате: у руководителя — свои, у исполнителя — свои. Эти представления различаются всегда. Все же люди разные. Отсюда, и обман ожиданий. Как говорится нечего «очаровываться, чтобы потом не разочаровываться».

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

В менеджменте часто используется образ «обезьянка на спине», придуманный Уильямом Онкеном-младшим[3]. Но всегда этот образ применяется к ситуациям, когда подчиненные стремятся переложить свою ношу на плечи начальника (пересадить обезьянку со своей спины на спину начальника).

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

Степень атомарности заключается в том, что задача всегда НЕ атомарна, а действие всегда атомарно.

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

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

С уважением к Вам и Вашему делу, Мотаев Александр

Обсудить эту и другие статьи блога вы можете в Telegram-канале «Управление потоком задач».

[1] – Подробнее об этом бизнес-процессе читай в статье «Бизнес-процесс “Воспроизводимое выполнение запоточенных задач”» в разделе «Система управления потоком задач (Система УПЗ)».

[2] — Лоуренс (Лоренс) Джонстон Питер (16.09.1919 — 12.01.1990) — канадский педагог. Изучал иерархическую организацию, известен благодаря сформулированному им принципу Питера: «В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности».

[3] — Уильям Онкен-младший (William Oncken, Jr.) — председатель совета директоров компании William Oncken Corporation (https://www.onckencorp.com), занимал этот пост до самой смерти в 1988 году. Соавтор знаменитой статьи «Менеджер и его время, или Кому достанется обезьяна», впервые опубликованной в Harvard Business Review в 1974 году и соавтор книги «Одноминутный менеджер и обезьяны».

[4] — Забегая вперёд, скажу, что одной из целей совершенствования УПЗ, в том числе с применением цифровизации, является такое изменение процедур и системы, при котором уменьшается количество действий, необходимых к исполнению в рамках выполнения отдельной задачи. Желательно до одного действия или вообще до нуля. Так чтобы задача превратилась в действие или вообще исчезла. Чтобы все действия или всю задачу делал робот, а не человек. Или чтобы вообще никто не делал.