Зачем нужно различать метод и работу
Каждый день множество агентов/создателей/constructors что-нибудь делает, то есть, демонстрирует какое-то поведение: личности/люди водят машину, команды проводят презентации для инвесторов, организации строят дома и делают софт. Иными словами, создатели меняют мир/среду/окружение и состояния объектов в нём. Как на поведение можно смотреть?
На поведение/действия агента можно смотреть как на «процессы», то есть, нечто длящееся во времени и приносящее какой-то результат. Вася ведёт машину – это означает, что сейчас Вася в процессе (непрерывно что-то делает), когда-то «начал» вести машину и когда-то «закончит», в результате приедет в нужное место (домой). Операционный менеджер Люда составляет отчёт о проведённых работах – Люда «начала» составлять отчёт и «закончит», когда он будет готов к отправке руководителю.
Но процессы часто обсуждать сложно (а также непросто выделять из фона, и мы ещё это обсудим). И это неудивительно: надо, с одной стороны, обсудить, как вообще получить нужный результат, а с другой – как в нашей конкретной ситуации получить нужный результат. Первый разговор – это обычно разговор о методе, а второй чаще о работе.
Метод и работа – это два разных аспекта поведения/действий агента/процессов/активностей/изменений/превращений и два разных объекта с разным языком обсуждения. Когда мы смотрим на поведение агента как на метод (он же способ/паттерн/шаблон работ), мы выделяем то общее, что видим каждый раз, когда агент делает одно и то же. Например, каждый раз, когда Вася ведёт машину, он садится за руль, пристёгивается, вставляет ключ и включает зажигание, и так далее. Нас также может интересовать маршрут, которым Вася обычно добирается до офиса (или даже варианты маршрутов). Обратите внимание на язык обсуждения: нам интересно, что Вася будет делать вообще – и что в его действиях/поведении будет повторяться. Иными словами, мы смотрим на шаблон/паттерн/способ, которым Вася каждый раз что-то делает в физическом мире. Нам важно содержание поведения, или суть того, что нужно сделать: какие объекты выделить из фона и как сменить их состояния (Вася не пристёгнут – Вася пристёгнут, двигатель не работает – двигатель работает, и так далее).
Но мы можем посмотреть на это поведение Васи и как на работу. Тогда нас будут волновать другие вопросы: как конкретному Васе в конкретный день доехать до офиса вовремя? Во сколько придётся выйти из дома именно в этот день, учитывая важный звонок в 9:00, плохую погоду и 5-балльные пробки? Какой буфер по времени заложить, чтобы точно не опоздать? Сколько времени займёт путешествие? То есть, в данном случае нас мало волнует, как именно Вася применяет технику/практики/методы вождения (и даже разговор о маршруте не волнует – это разговор о методе[1]), зато очень интересует организация поведения/действий, или ресурсная сторона вопроса. Обратите внимание: мы всё еще (вроде бы) смотрим, как Вася ведёт машину – но при этом у нас совершенно изменился язык обсуждения, и мы начали выделять из фона какие-то другие объекты, которые не выделяли до этого!
Разные языки для обсуждения появились неспроста. Несмотря на то, что в физическом мире мы можем указать на конкретное поведение/действия агента (Вася Пупкин едет в офис 24 мартобря 20ХХ года в 09:00), для успешного достижения цели (прибыть в офис вовремя) потребуется выбрать и применить нужный способ/метод/паттерн/шаблон, а ещё обеспечить его ресурсами. И если мы начинаем думать, как это сделать, то внезапно обнаруживаем, что на метод обращают обычно внимание люди в одних ролях, а на работу – в других.
Метод обычно важен инженеру. Инженеры (разработчики, тестировщики, контенщики, проектировщики, операторы станков ЧПУ, водители и так далее) очень любят поговорить о том, что нужно сделать содержательно/функционально, в чём суть их действий. И побуждение со стороны инженеров говорить о методе в первую очередь правильное, потому что если непонятно содержательно, что вообще делать, обеспечивать ресурсами это непонятное практически бесполезно.
Работа обычно важна менеджеру (в частности – операционному/проектному менеджеру). Менеджеры обычно говорят о том, кто конкретно/физически должен выполнить работу, сколько ему нужно заплатить, сколько ещё и каких ресурсов потребуется, чтобы работа была выполнена, каковы будут сроки выполнения работ, и так далее.
Из-за особенностей выполняемых ролей инженер хорошо выделяет в поведении «метод», но очень плохо – «работу» (не его профессиональная предметная область). Менеджер, напротив, прекрасно выделяет «работу», но игнорирует «метод», применяемый инженером. Оба слепы в отношении важных друг для друга объектов – и потому не могут договориться: оба постоянно буквально говорят о разных объектах (аспектах поведения), даже если показывают на одно и то же поведение в физическом мире! В результате мы получаем ролевой конфликт.
Инженер хочет обсуждать, как ему написать код для фичи, может захотеть поговорить об архитектурных паттернах или о том, как именно проводить релиз. А менеджеру интересно, когда пользователям будет доступна конкретная фича, выпускаемая в составе релиза. Ему также интересно, когда разработанные фичи передадут тестировщикам для тестирования, потому что на следующей неделе два тестировщика уходят в отпуск, и скорость тестирования сильно замедлится (и, возможно, надо будет срочно подключать Claude или ChatGPT в качестве тестировщиков – проект, который до этого по разным причинам откладывался). При этом менеджеру безразличны архитектурные паттерны, а инженеру – успеют ли тестировщики в срок. Чтобы инженер и менеджер смогли договориться, им надо буквально увидеть важные для друг друга объекты. Менеджер должен знать, что инженеру важен метод, должен убедиться, что метод выбран, что выбранным методом умеют работать все исполнители/рабочие станции в терминологии операционного менеджмента – тогда работы не окажутся невыполненными в срок по причине «не разобрались с методом». Инженер должен знать, что менеджеру важны работы, должен уметь распоряжаться своими ресурсами как исполнителя/рабочей станции, должен понимать, что реальное время выполнения задачи – это не время касания задачи/Touch Time, а всё время с первого касания задачи и до передачи результатов выполнения работ (рабочего продукта) следующей станции – тестировщику (то есть, время касания задачи/Touch Time + время ожидания/Wait Time, когда инженер занимается чем-то ещё – правит срочный баг, участвует во встрече, но не работает над задачей непосредственно[2]). То есть, время выполнения задачи не «4 часа», а «два-три дня» реально. Вот это инженер должен понимать про свои работы, чтобы договориться с менеджером.
Только когда инженер и менеджер понимают, что важно каждому, а также осознают, что и метод, и работы нужно обсуждать, если вы хотите результат в срок и бонусы за хорошую работу, только тогда они получают возможность договориться. Для этого они должны знать о том, что такое метод и работа, уметь выделять их вниманием в поведении агента, а потом ещё общаться друг с другом по поводу этих важных объектов.