Skip to content

Смены состояний объектов

Выполняя работу по методу (или иначе – демонстрируя некоторое поведение), агент меняет состояния объектов – предметов метода. Например, столяр изготавливает ступень лестницы[1]. Для этого он выбирает доску нужной породы дерева, затем распиливает её на бруски, строгает бруски, фрезерует и склеивает их, обрабатывает, затем повторно строгает и фрезерует, сверлит отверстия для соединения ступеней с подступенками и площадкой и отдает на шлифовку. То есть, ряд объектов проходит через изменения: доска сначала «выбрана», затем вместо «доски» появляется «брусок», который сначала оказывается «обстроганным», «фрезерованным», потом набор брусков становится «склеенным» – и тут уже можем говорить о появлении вместо набора/группы брусков о появлении «ступени». Ступень далее превращается в «обработанную», «обстроганную», «фрезерованную», «с отверстиями для сборки».

Когда мы говорим о работе по методу, нас будет очень интересовать именно это: как получается результат, то есть, какие «объекты внимания метода»/«предметы метода» должны сменить свои состояния – и как они это сделают. Состоянием индивида будем называть полную темпоральную часть индивида, принадлежащую к определенному классу с одного момента времени и до другого. Причем мы можем замерить при помощи часов, когда темпоральная часть возникла и когда она прекратила существовать (то есть, выделить её во времени). Вернемся к примеру с помидором из раздела 6:

Помидор с уникальным номером (в жизни вы часто услышите об «уникальном идентификаторе» или ID, например, ID пользователя) 91 находится сначала в состоянии «зелёный» с 20 июля по 5 августа 20ХХ года (объект с уникальным номером 92), затем с 6 августа и до 10 переходит в состояние «красный» (объект с уникальным номером 93), а затем оказывается съеден (прекращает существование). Мы можем представить это описание в виде кортежей < «помидор с 20 июля по 5 августа», «зелёный»>, <«помидор с 6 августа по 10 августа», «красный»> или как состояние «зелёный помидор» (с 20 июля по 10 августа), «красный помидор» (с 6 августа по 10 августа).

Чтобы обозначить, что объект сменил состояние, в разговоре часто используют прилагательные («зелёный» помидор стал «красным») и причастия (помидор «съеден»). Причастия часто используются в чеклистах, то есть описаниях, которые используются для проверки выполнения работ по методу или для напоминания, как надо применять метод. Например, посмотрите на один из авиационных чеклистов, используемый перед взлётом и после посадки:

В приведённом выше чеклисте перечислены классы объектов: «заглушки», «чехлы», «фонари», и состояние, в которое должен быть приведен конкретный объект, с которым пилоту придётся иметь дело. Например, «высотометр №2 самолёта P-2002 Sierra с уникальным номером 322400, принадлежащий компании «Челавиа», который находится в состоянии «проверен» после 20:32 17 сентября 20ХХ года. Такие чеклисты активно используются в авиации для автоматизации выполнения методов пилотами.

Еще один способ указать на смену состояний объектов – указать на версию объекта. Этот подход активно используется в разработке ПО: вы можете зайти в раздел «О телефоне» в настройках вашего телефона и проверить версию операционной системы. Вы также можете использовать версионирование при создании рабочих продуктов.

Например, когда вы пишете отчет, то вы можете указывать на версию файла:: носителя отчета. Изменение содержания (например, корректировка ошибок) приводит к тому, что носитель тоже меняется. Таким образом, темпоральные части описания тоже оказывается разными – описание меняет свои состояния. «Отчет по бюджету за квартал» можно представить как файл с названием «Отчет по бюджету за квартал версии 1.0», существовавший с 20:37 вчерашнего дня (дата и время создания) до 12:00 сегодня (одна темпоральная часть) и файл с названием «Отчет по бюджету за квартал версии 1.1», существующий с 12:00 сегодняшнего дня (и пока не закончит существование). Слова «файл с названием» обычно опускаются, остается только «Отчет по бюджету за квартал 1.1». Точно так же можно представить любые результаты выполнения работ, будь то индивид, например, деталь с инвентарным номером 3234, или описание.

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

Вернемся к примеру со ступенью лестницы. Метод изготовления ступени можно записать в виде чек-листа с указанием на класс объектов («доски», «бруски» и так далее – поскольку мы не указываем на конкретного индивида, то мы имеем дело с описанием класса объектов) и состояниями, в которые должны будут прийти конкретные индивиды в физическом мире. Метод можно записать так:

  • Доска для ступени – выбрана (да / нет)
  • Бруски – напилены (да / нет)
  • Бруски – обстроганы (да / нет)
  • Бруски – фрезеровка проведена (да / нет)
  • Ступень – склеена (да / нет)
  • Ступень – обработана (да / нет)
  • Ступень – обстроганы (да / нет)
  • Ступень – фрезеровка проведена (да / нет)
  • Отверстия в ступени – просверлены (да / нет)

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

Иногда объекты могут меняться в разных ситуациях схожим образом. Как различить состояния в таких случаях? Например, отчет был возвращён на доработку, в нём скорректировали ошибки, и он вновь в состоянии (ещё говорят «в статусе») «готов к проверке». Как отличить текущее состояние «готовности к проверке» от прошлого? Очень просто: по времени! Темпоральные части отчёта будут разными. В первый раз отчёт пришел в состояние «готов к проверке» вчера, а во второй – сегодня. Класс статусов тот же самый, но объект изменился, темпоральная часть уже другая. В рабочих проектах это отражается при помощи версионности.

Состояния могут накладываться друг на друга. Например, вы начали выполнять задачу, но не закончили и пошли на встречу. С точки зрения TameFlow, раз задача взята в работу, но не завершена, продолжает течь потоковое время/Flow Time как «общее время на выполнение работы». Но, поскольку прямо сейчас вы на встрече, то задача непосредственно не выполняется, она находится в «режиме ожидания». Для отражения этого в TameFlow предлагается учитывать это время как «время ожидания»/Wait Time и отделять его от непосредственно «времени выполнения/касания задачи»/Touch Time. Общее время выполнения работ/Flow Time считается как время ожидания/Wait Time + время касания/Touch Time. Поэтому счётчик общего времени выполнения работ продолжает «накручиваться», но одновременно с ним – увеличивается время ожидания/Wait Time. Задача, выполнение которой отложено, одновременно находится в статусе «незавершенки»/Work In Progress/WIP и в статусе «ожидает выполнения». Мы можем указать на дату и время, когда работа по задаче начала выполняться, когда она была прервана, и можем после возвращения к работе назвать дату и время её завершения.

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


  1. https://journal.tinkoff.ru/woodworker/ ↩︎