Как пришли к разделению методов и работ
Ещё раз повторим, как мы выделяем метод и работу в поведении/активности/процессе/превращениях/действиях агента. Мы смотрим, как агент (например, Вася, или ChatGPT o5) что-то делает, а потом выделяем вниманием разные аспекты действий/процессов: содержательный аспект (метод: какие объекты как меняют состояния) и ресурсный (работа: как применение метода обеспечивается ресурсами). Физически Вася в это время ведёт машину, стучит питчером, пишет отчёт о проделанных работах, запускает рекламную кампанию. Мы же смотрим на этого Васю со стороны (даже если Вася – это вы) и выделяем во всем этом сложном процессе «метод» и «работу».
Можно сказать, что физически существует сложный 4Д объект Вася, который демонстрирует какое-то поведение: меняет объекты вокруг себя и сам меняет свои состояния, и вот этот набор/нарезка объектов со всеми релевантными сменами состояний и есть поведение/действия/процесс. Мы смотрим на этот сложный набор объектов (который мы можем условно считать одним сложным объектом) с разных сторон/точек зрения/viewpoints и по-разному выделяем важное: в одном случае мы смотрим как инженеры и выделяем «метод» и всё, что нас интересует при обсуждении метода – при этом опускаем разговор о ресурсах. Или, напротив, смотрим на поведение как на работу – и не выделяем вниманием то, что касается метода. Почему мы так делаем? Как вы уже знаете из раздела 2, это связано с особенностями работы нашего внимания, а также восприятия. Человеку сложно воспринять объект сразу во всей его сложности, поэтому в голове мы создаём упрощённые модели объектов, неизбежно опуская при моделировании какие-то важные атрибуты/характеристики/свойства этих объектов. Хотелось бы, чтобы мы сразу в процессе видели и то, как меняются состояния объектов, и то, как используются ресурсы для этого – но в реальности ограниченный объём внимания не даёт нам это сделать, поэтому мы вынуждены прибегать к обходному пути: выделить вниманием сначала «метод», чтобы понять, что вообще надо сделать, как и зачем, а потом «работу», чтобы понять, как организовать выполнение метода конкретными агентами в реальном мире.
Пришли к выделению «методов» и «работ» как разных аспектов поведения/действий (выделяемых вниманием!) относительно недавно. До 80-90-х годов 20 века все действия агентов считались по умолчанию «работой», разговора о методах не было вовсе. Лишь в конце 20 века начали говорить о практиках/методах, правда, упоминая другие слова – «процесс разработки» (процесс как метод, в котором важно содержание: написать код, проверить код, выпустить программу на рынок, а не кто из людей-разработчиков это делает и за какое время). Выделение объекта «метод» и использование понятия метода для обсуждения содержания поведения распространялось не без проблем[1], ведь это означало усложнение коммуникации в командах. Раньше надо было обсуждать лишь, кто должен выполнить работу, как найти ресурсы, как обеспечить исполнителей инструментами, – то есть, обсуждать работы – а что именно надо делать, считалось «очевидным». Теперь надо владеть и понятием «метода», и понятием «работы», уметь выделить их в поведении агента и уметь обсудить с другими. Однако такое разделение и такое обсуждение приводит к значительному ускорению выпуска/прохода конечных результатов, поэтому в 21 веке стало нормой и сейчас используется в большинстве state-of-the-art (SoTA) книг/учебников[2].
Если в 21 веке на предприятии не выделяется и не обсуждается метод, то у организации будут практически гарантированные проблемы. Так, стажер МИМ и один из руководителей в крупной телеком-компании обнаружил, что другие менеджеры/управленцы и он сам как менеджер постоянно обсуждают работы, но не обсуждают методы, которыми эти работы должны быть выполнены. В результате большинство возникающих в проектах проблем связаны с объектом «метод», который не выбирается сознательно и не обсуждается. Сотрудники не понимают, что именно им нужно сделать и в какую роль встать, чтобы успешно достичь результата, делают не то. В итоге работы не могут быть завершены в срок и в рамках бюджета: если мы потратили ресурсы на работу неправильным методом, нам придётся откуда-то брать новые ресурсы и растягивать сроки выполнения работ.
Итак, чтобвы наладить выпуск вещи (или объектов, связанных с вещью) и выпускать её в срок и в рамках бюджета, необходимо выбрать, выделить и описать метод, а затем организовать проведение работ по методу, проследить, чтобы работы были проведены, а потом ещё и подвести итог (организовать петлю обратной связи, чтобы научиться на ошибках и удачах). Обязательно выделяем метод и работу вниманием в поведении агента и обсуждаем их, когда ставим, делегируем задачи и обсуждаем результаты проведённых работ!
Подробнее об этом рассказано в руководстве «Методология» ↩︎
В современных учебниках для инженеров, продакт-менеджеров, лидеров вы обязательно наткнетесь на понятие роли/role (иногда будет называться stakeholder) и «действий по роли» («что делает архитектор продукта», «что должен делать лидер», «как различаются роли продакта и инженера»). Даже если слово/термин «метод» не упоминается, обсуждается де-факто именно он. Вы можете сами убедиться в этом: откройте любой качественный учебник для инженера или менеджера, выпущенный в течение последних 5 лет. ↩︎