Зачем нужно различать метод и работу
Каждый день множество агентов/создателей/constructors что-нибудь делает, то есть, демонстрирует какое-то поведение: личности/люди водят машину, команды проводят презентации для инвесторов, организации строят дома и делают софт. Понятие создателей/агентов/constructors берем из физической теории создателей/constructor theory Дэвида Дойча и Кьяры Марлетто (David Deutsch, Chiara Marletto) и называем **агентами/**создателями такие объекты/физические тела, которые способны выполнить какое-то действие (иногда говорят «выполнить задание») и затем повторить это поведение, не разрушаясь[1]. То есть, нам важно, что агент/создатель/constructor/субъект[2] принципиально способен выполнить действие целенаправленно, а не продемонстрировал его разово, случайно под воздействием обстоятельств – это означает, что его поведение можно предсказать при помощи различных физических теорий и (для некоторых агентов[3]) теорий принятия решений. Теория создателей интересна нам тем, что позволяет обсуждать возможные и невозможные изменения/преобразования/transformations мира («возможные и невозможные миры»), тогда как классическая физика больше фокусируется на описании движения объектов.
Действуя, агент/создатель/constructor меняет мир и состояния объектов/makes transformations. Агентами/создателями могут выступать самые разные объекты. Чаще всего мы будем выделять таких агентов, как «личность», «команда», «организация», «сообщество», ИИ, например, «вы как личность», «ваша команда», «ваша организация», «сообщество ваших клиентов» или «сообщество танцоров, в котором вы участвуете», «ИИ, исполняющий роль водителя в беспилотном автомобиле». Это всё создатели разного уровня организации/системного уровня организации[4].
Вы встретите много синонимов к слову «агент»: это и создатель/constructor в физической теории создателей Дойча, и субъект в психологии, и форма жизни в эволюционной биологии, и информационно-обрабатывающая единица/information processing unit/IPU в эволюционной биологии и эволюционной информатике. Мы чаще всего будем пользоваться словом/термином/знаком «агент», чуть реже – «создатель». Периодически синонимы будут перечисляться подряд через знак «/»: агент/создатель/constructor/субъект/форма жизни/информационно-обрабатывающая единица/information processing unit/IPU. Если вы встречаете в руководстве такую «колбаску», значит, вы встретили синонимический ряд, то есть ряд перечисленных друг за другом синонимов. Мы будем периодически давать такие «колбаски» вместо упоминания одного или двух слов, чтобы вы смогли удержать внимание на общем для всех слов-синонимов значении/смысле/идее/понятии/концепте: различия в значении вы и так увидите, когда придёте в соответствующую предметную область. Например, если вы заглянете в учебники психологии и физики, вы сможете сказать, чем различаются «физическое тело» и «субъект»[5]. Однако нам важно не только видеть различия в значениях слов-синонимов, но и увидеть то общее/объединяющее в смыслах, к которым эти слова отсылают. Это важно, чтобы вы могли видеть общие объекты внимания, которые есть у вас на предприятии и которые вы будете называть по-разному на языках разных предметных областей. Вас не должно смущать, что один и тот же объект – ваш офисный стул – может называться «мой стул в офисе» и «имущество организации под инвентарным номером 45450», и что эти два названия не противоречат друг другу и имеют равные прав на существование. Просто одним названием («мой стул») вы будете пользоваться, когда захотите отличить свой стул от стула коллеги, а вторым («имущество под инвентарным номером 45450») – когда инвентаризационная комиссия будет проводить инвентаризацию имущества организации. Начинаем привыкать к тому, что один и тот же объект в разных контекстах будет называться по-разному.
Итак, агенты/создатели/constructors выполняют действия, которые как-то меняют мир вокруг/окружение/среду. В поведении агентов (людей/личностей, команд, организаций, сообществ) нас может интересовать:
- Содержание поведения/деятельность, суть того, что нужно делать, или метод,
- Организация поведения/операции, достижение результатов в реальном физическом мире, акт превращения одних объектов в другие при помощи ресурсов, или работа.
На уровне личности разделять метод и работу, различать их в поведении не требуется, пока вы выполняете простые действия. Например, если вам нужно зайти в комнату, задернуть шторы и включить свет. В таком случае можно обсудить, какой метод выбрать (будете ли вы заходить шагом или бегом, шторы задергивать до конца или оставите окна частично незашторенными) и отдельно – как выполнить работу (сколько времени вам потребуется, какие инструменты понадобятся), но не нужно: действие можно пойти и выполнить сразу, не особо задумываясь, и результат вас устроит. В таких простых ситуациях специально выделять метод и работу обычно нерационально: вы не сможете таким образом ускорить получение результата или улучшить его качество. В таких простых случаях мы будем тренироваться смотреть на поведение как на метод и как на работу (то есть, с разных точек зрения/способов рассмотрения/способов описания/способов моделирования) только в рамках учебных примеров и только на старте изучения понятия. Зато в более сложных случаях, например, в ваших рабочих проектах, разделение метода и работы позволит быстрее договориться о том, что и как делать, и ускорить получение результатов.
Смотреть на поведение личностей, команд, коллективов организаций отдельно как на метод и отдельно как на работу стали лишь недавно. До 80-90-х годов 20 века все действия агентов считались по умолчанию «работой», разговора о методах не было вовсе. Лишь в конце 20 века начали говорить о практиках/методах, правда, упоминая другие слова – «процесс разработки» (процесс как метод, в котором важно содержание: написать код, проверить код, выпустить программу на рынок, а не кто из людей-разработчиков это делает и за какое время). Выделение объекта «метод» и использование понятия метода для обсуждения содержания поведения распространялось не без проблем[6], ведь это означало усложнение коммуникации в командах. Раньше надо было обсуждать лишь, кто должен выполнить работу, как найти ресурсы, как обеспечить исполнителей инструментами, – то есть, обсуждать работы – а что именно надо делать, считалось «очевидным». Теперь надо владеть и понятием «метода», и понятием «работы», уметь выделить их в поведении агента и уметь обсудить с другими. Однако такое разделение и такое обсуждение приводит к значительному ускорению выпуска/прохода конечных результатов, поэтому в 21 веке стало нормой и сейчас используется в большинстве state-of-the-art (SoTA) книг/учебников[7].
Если в 21 веке на предприятии не выделяется и не обсуждается метод, то у организации будут практически гарантированные проблемы. Так, стажер МИМ и один из руководителей в крупной телеком-компании обнаружил, что другие менеджеры/управленцы и он сам как менеджер постоянно обсуждают работы, но не обсуждают методы, которыми эти работы должны быть выполнены. В результате большинство возникающих в проектах проблем связаны с объектом «метод», который не выбирается сознательно и не обсуждается. Сотрудники не понимают, что именно им нужно сделать и в какую роль встать, чтобы успешно достичь результата, делают не то. В итоге работы не могут быть завершены в срок и в рамках бюджета: если мы потратили ресурсы на работу неправильным методом, нам придётся откуда-то брать новые ресурсы и растягивать сроки выполнения работ.
Без разговора о методе мы не можем сказать, какие по содержанию/сути действия приведут нас к желаемому результату и как изменить эти действия, чтобы результат улучшить, поэтому скорость выпуска результатов падает: команды/создатели действуют хаотично, «как привыкли», даже если такие действия повредят, и не могут увеличить скорость выпуска результатов. Без разговора о работе мы не можем сказать, как изменение методов приведет к увеличению скорости выпуска результатов. Таким образом, разговоры о методах и работах хоть и взаимосвязаны, но сфокусированы на разном. Вести такие разговоры вы буквально будете на разных профессиональных языках*/языках описания*, которые сотрудники обычно не различают, что часто приводит к путанице в проектах.
Типичный пример: инженер, например, разработчик ПО и менеджер, например, операционный менеджер, договариваются о выполнении задания. В этот момент инженер обычно думает о методе: продумывает, что он будет делать для получения нужного результата, в какой последовательности, что должно получиться в коде на выходе. Менеджер же очень интересуется работой: ему не так важно качество написанного кода, не так важно, какие приемы будут использоваться для его написания – ему важно, чтобы результат появился в определенный срок, потребовалось как можно меньше ресурсов для выполнения работы, было поменьше переделок, и чтобы скорость выпуска результата была как можно выше. Если инженер и менеджер не понимают, о чем первым делом, по умолчанию, подумает каждый из них, то шансы договориться будут малы. Внимание инженера удержится на методе, но работы пройдут мимо: он не организует максимально быстрое, «бесшовное» выполнение метода. Инженер не отправит задачу в очередь на выполнение, не будет проводить приоритизацию по очереди, а возьмет это новое задание сразу в работу, отложив то, чем занимался ранее. Он также не заземлится: не оценит, сколько времени реально потребуется в физическом мире на выполнение работы по методу с учетом других задач, встреч, перерывов на обед и так далее, и даст идеальную оценку «как быстро я мог бы выполнить работу, если бы не было никаких других задач». Кроме того, инженер не выделит как «важное» скорость выпуска результата и может даже не понять, что менеджеру это важно.
Внимание менеджера, напротив, очень хорошо удерживается на скорости выпуска результата, сроках и дедлайнах, ресурсах, он будет настойчиво этим интересоваться, а вот способы написать код ему не очень интересны. Но если он не поймет, о чем по умолчанию думает инженер, а о чем – нет, то он будет опираться на оценку времени выполнения, данную инженером, как реалистичную, хотя на самом деле она оторвана от реальности и живет в идеальном мире, где инженер может сфокусироваться на одной задаче и не отвлекаться ни на что другое. После, когда инженер закономерно не успеет в названный срок, даже если будет работать по ночам, между инженером и менеджером вероятен конфликт, в котором каждая сторона будет считать себя правой.
И метод, и работа относятся к поведению агента, выступают её разными аспектами. Это то общее, что есть у метода и работы. Однако есть и различия: о методах чаще будут думать методологи и прикладные инженеры (разработчики ПО, маркетологи и так далее), а о работах – менеджеры. Для разговора о методе и работе будет применяться разный язык описания, а еще потребуется три разных *«способа описания с разных точек зрения»/**способа смотреть на мир/способа моделирования/способа рассмотрения объектов/*viewpoints: функциональное/логическое плюс стоимостное/ресурсное для метода и конструктивное/физическое плюс ресурсное/стоимостное для работы.
Об этом подробнее в следующих подразделах.
Можно найти видео, в которых Кьяра говорит, что «информация» сама по себе может выступать «создателем». Мы требуем бОльшей онтологической точности и говорим, что информация сама по себе не создатель, но объект, который перерабатывает информацию и выполняет задания – очень даже создатель. Например, молекула ДНК передаёт белкам инструкции, согласно которым белки выполняют работы по различным методам: например, белки-ферменты ускоряют химические реакции, т. е. выступают в качестве катализаторов, белки-антитела обеспечивают защиту организма, обезвреживая вирусы и бактерии, и так далее. Выполнение этих работ белками возможно благодаря инструкциям, полученным от молекулы ДНК. «Создателем» в этом случае будет молекула ДНК (физический объект), передающая инструкции, а не переданная ею информация. ↩︎
С точки зрения теории создателей, создателем можно назвать двигатель внутреннего сгорания и ИИ. Однако мы не говорим о том, как принимать решения двигателю – такое рассуждение не имеет смысла, поэтому для вещей вроде двигателя теории принятия решений не применяются. А вот разговор о том, как ИИ принимать решения, уже имеет смысл. Например, в случае аварии ИИ-водитель беспилотного автомобиля будет принимать решение, кого спасти: пассажира или пешеходов. Оказывается, что ответ будет различаться в зависимости от набора участников, условий аварии – и даже в зависимости от страны проживания: в восточных странах скорее спасут пассажиров и законопослушных пешеходов, а в западных – «как можно больше людей», и не важно, виноваты ли они в создании аварийной ситуации или нет: https://www.moralmachine.net/ ↩︎
https://tenchat.ru/media/2881919-sistemnyye-urovni-v-organizatsii-zhizni-kakiye-oni-byvayut ↩︎
Конечно, у каждого из синонимов будет свой оттенок значения. Например, «формы жизни» в эволюционной биологии – это не любые создатели, а только те, что состоят из клеток (классическая версия понятия, исключает вирусы), либо биологические репликаторы/воспроизводители информации с неограниченной наследуемостью признаков/информационно-обрабатывающие единицы/IPU (SoTA версия понятия из молекулярной биологии, включает вирусы). Обе версии понятия не предполагают возможность назвать двигатель внутреннего сгорания или мяч создателем, тогда как в теории создателей Дойча-Марлетто это возможно. Но в большинстве случаев вы будете иметь дело с агентами/создателями, для которых эти нюансы значения не важны, например, с личностями и командами, поэтому термины «форма жизни» и «создатель» считаем в типовых случаях синонимами. ↩︎
Подробнее об этом рассказано в руководстве «Методология» ↩︎
В современных учебниках для инженеров, продакт-менеджеров, лидеров вы обязательно наткнетесь на понятие роли/role (иногда будет называться stakeholder) и «действий по роли» («что делает архитектор продукта», «что должен делать лидер», «как различаются роли продакта и инженера»). Даже если слово/термин «метод» не упоминается, обсуждается де-факто именно он. Вы можете сами убедиться в этом: откройте любой качественный учебник для инженера или менеджера, выпущенный в течение последних 5 лет. ↩︎