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