Кто девушку ужинает, тот её и танцует!
Цитата из фильма «Вокзал для двоих»
О заказчике, как об обязательном атрибуте задачи, я писал в статье «Что такое задача?». Указывал, что задача должна иметь заказчика. Что без заказчика задача – не задача.
Спрашивается: кто такой заказчик задачи? Для чего он нужен? Почему без него не обойтись?
Ответ на данный вопрос важен для обеспечения выполнения задач. Положен в основу одного из принципов управления потоком задач – принципа «петли ответственности»[1]. Поэтому требует прояснения.
Итак, приступим.
Заказчик задачи – это ответ на вопрос: кто заказывает и потребляет целевой результат задачи?
У задачи всегда должен быть один заказчик – тот, кто:
заказывает целевой результат задачи,
заинтересован в нём,
будет потреблять ЦРЗ,
использовать его в своей работе, в выполнении своих задач.
Этот заказчик должен принимать целевой результат задачи и оценивать, достигнут он или нет, и, соответственно, выполнена задача или нет.
Это и логично. Если никто не заказывает целевой результат задачи, а соответственно саму задачу, то значит этот ЦРЗ никому и не нужен, никто в нём не заинтересован, не будет его потреблять и использовать. А раз он никому не нужен, то зачем выполнять задачу и достигать никому не потребный ЦРЗ?
В организации заказчиком должно быть одно должностное лицо, имеющее конкретное ФИО. То есть заказчик – это всегда конкретный человек. Это единственный человек, которого можно чётко идентифицировать (по ФИО, паспорту, СНИЛС и т.д.).
Отсюда, заказчик является главным, кто оценивает степень выполнения задачи и акцептует предложение о её закрытии выполнением.
При этом в УПЗ у него есть права не акцептовать:
предложение о закрытии задачи выполнением, если целевой результат его не устраивает;
предложение о переносе задачи на новый срок, оставив её на просрочке, если он считает, что ответственный выполнитель виноват в просрочке и должен понести за это ответственность;
предложение об отмене задачи, если он считает её актуальной и требующей выполнения;
предложение об изменении других атрибутов задачи, если он считает эти изменения не адекватными своим потребностям и ожиданиям;
и т. д.
Мало сформулировать задачи, определив, что нужно сделать. Надо ещё добиться, чтобы это было фактически сделано.
Отсюда, задачи нужны, чтобы их выполнить. Вспомните, выше я уже писал, что общее предназначение (функциональное назначение) существования сущности «задача» - обеспечить её выполнением получение целевого результата[2].
Чтобы полученные целевые результаты были необходимого качества. Чтобы выполнение задач было гарантированным. Чтобы никто не мог закрыть задачу выполнением без при��мки её результата. Или имитированием её выполнения. Чтобы ответственный выполнитель задачи не мог отменить задачу, забыть про неё, просрочить, необоснованно перенести и т. д.
Замыкание задачи на заказчика, заинтересованного в получении её целевого результата, обеспечивает это. То есть в этом случае без заказчика не обойтись.
Заказчик потребляет полученный ЦРЗ, как «вход» для выполнения своих задач. У которых тоже есть ЦРЗ и срок. За которые он отвечает, как ответственный выполнитель. Поэтому заказчик заинтересован в получении на «входе» качественного ЦРЗ и в заданные сроки. Он это будет требовать от ответственного выполнителя задачи. Особенно когда действует ещё один принцип УПЗ – принцип «крайнего в цепи»[3].
Наличие у заказчика прав и заинтересованности на акцепт или не акцепт задач даёт инструмент влияния на ответственных выполнителей и качество выполнения задач. Решает проблему «неисполнительности»[4].
Выходит, что заказчик нужен, чтобы обеспечивать качество ЦРЗ, гарантированность выполнения и исполнительность.
При этом необходимо, чтобы заказчик задачи не был её же ответственным выполнителем.
Нельзя допускать, чтобы ответственный выполнитель сам себе в качестве заказчика формулировал задачи, сам их себе ставил и закрывал выполнением. Принимая сам у себя целевые результаты их выполнения, оценивая их степень достижения.
Это породит злоупотребления. Создаст возможности для них. И при их наличии ими обязательно воспользуются.
Из-за чего увеличится доля НЕфункциональных задач и псевдозадач. ИБД. Что приведёт к нерациональному использованию ресурсов, росту затрат и снижению производительности интеллектуального труда.
Получается, что введение заказчика в задачу нужно ещё для борьбы с потерями процесса «менеджмент» - НЕфункциональными задачами и псевдозадачами.
В управлении потоком задач есть механизмы отбора и закрепления заказчиков за каждой задачей. В процессе их (задач) делегирования – постановки сотрудникам.
При этом закрепление заказчиков задач осуществляется через закрепление ФИО за должностями. Через присвоение должностям выполняемых функциональных ролей. Через прикручивание функциональных ролей к атрибуту «заказчик задачи (ФИО)».
Чтобы всё это упростить, в УПЗ применяется автоматизация формирования заказчиков в ходе генерирования процессных и целевых задач. Но об этом, а также о «должностях» и «функциональных ролях», - позже.
Полная версия статьи доступна в моей книге «Задачи чудесные, или Козырная «ТУЗ» Мотаева!»
С уважением к Вам и Вашему делу, Мотаев Александр
Обсудить эту и другие статьи блога вы можете в нашем Telegram-канале "Управление потоком задач".
[1] - Подробнее о нём читай в статье «Принципы системы управления потоком задач» в разделе «Система управления потоком задач (Система УПЗ)»
[2] - См. статью «Сущность “задача” - это абстрактная сущность» в разделе «Главная сущность менеджмента – “задача”».
[3] - См. статью «Принципы системы управления потоком задач» в разделе «Система управления потоком задач (Система УПЗ)»
[4] - Речь об этой проблеме пойдёт позже в статье «Проблема “неисполнительность”» в разделе «Ключевая разовая проблема, мешающая повышению ПИТ»
