Итоговое эссе по резидентуре R1 «Распожаризация»
Ниже делюсь достижениями, соображениями и планами за несколько дней до завершения резидентуры R1. Мысли строго мои, оформление частично отдано на откуп Qwen 3.6 35B.
Фокус на производимых вещах и поиск целевой системы
Фокусировка на том, что мы производим, определённо помогла мне и моей команде. Раньше, работая аналитиком, я уже фокусировался на некоторых объектах внимания, так как мне приходилось трассировать исходные неудовлетворённости конечного пользователя или заказчика в промежуточные и конечные артефакты. Резидентура «Распожаризация» помогла мне сфокусироваться на этом ещё глубже и заставила посмотреть на эти вещи с разных точек зрения.
Поиск целевой системы также принёс пользу. Я представлял её достаточно хорошо и раньше, но целенаправленное исследование позволило мне более внимательно взглянуть на то, как она вписывается в другие системы, как они взаимодействуют между собой, и увидеть те области и пробелы в эпистемах, которых я раньше не замечал.
Заземление и создание описаний
Я стал лучше понимать, как заземляться, и как за счёт этого создавать лучшие описания. В нашей компании существует выражение «приземлить что-то на что-то», которое означает переход к от абстракции к конерктике её применения. Например, проследить выполнение какого-то процесса на конкретном случае из жизни или развернуть какую-то систему в конкретном окружении силами конкретных людей для конкретных пользователей. Раньше я не в полной мере понимал смысл этого. Мне казалось, что люди делают это просто для того, чтобы лично они могли лучше понять, о чём речь, и, возможно, идентифицировать какие-то пробелы в текущем описании или в работах по этому описанию. На самом деле это так и есть, но теперь я лучше понимаю смысл и ценность заземления как системной техники. В конечном счёте любые изменения в системах и любые новые системы предназначены для того, чтобы улучшить и решить какие-то существующие проблемы. То, насколько хорошо эти проблемы будут решены и будут ли решены именно эти проблемы, можно понять, только столкнувшись с этими системами в реальном мире или смоделировав, как они будут работать в реальном мире. Как раз для этого и нужно заземление.
Выделение методов как объектов внимания и коммуникация
Мне явно помогло выделение методов как объектов внимания. Теперь в любой дискуссии я чётче вижу инженерный (или методологический) взгляд и взгляд менеджерский (в аспекте работ). Моя коммуникация изменилась: я стал чаще и легче (даже без специального фокусирования на этом) замечать смешивание этих подходов или пробелы, которые возникают в обсуждениях, когда мы разбираем выполнение каких-то задач. Как правило, мы чаще говорим о работах и упускаем из виду методы, потому что “ну мы же профессионалы и точно знаем, как надо”.
Что касается коммуникации и разных языков, я стал внимательнее относиться к целевой аудитории и использовать тот язык, который ей свойственен. Например, при совместной подготовке презентации я обратил внимание моего менеджера на то, что некоторые термины в его презентации могут и, скорее всего, будут истолкованы некоторыми слушателями не совсем верно. Я предложил ему более конкретную формулировку, которая, во-первых, более точно выразит мысль, которую требуется донести, а во-вторых, подаст эту мысль именно с точки зрения работ, как требуется для данной аудитории, а не методов.
Методы операционного менеджмента: использование, сложности и внедрение
В этой резидентуре я узнал и начал применять следующие методы операционного менеджмента:
-
Алгоритм разделения метода и работы. Я усвоил, что метод отвечает на вопрос, зачем что-то нужно сделать, какие объекты должны измениться по ходу этого делания и как они изменятся. Работа же отвечает на вопросы: кто конкретно, когда конкретно и что должен сделать по этому методу, чтобы достичь цели. Кроме того, результат этой работы (рабочий продукт) должен стать физически доступен и передан его получателю в удобном формате. Этот метод мне понятен, я считаю его ценным и фокусирую внимание на нём в повседневной деятельности, поскольку я проектирую системы и больше работаю над методами. Хотя на самом деле автоматизированные системы одновременно и работают по какому-то методу, который в них заложен, и осуществляют какую-то работу в конкретной среде с передачей рабочего продукта (в другую систему путём интеграции или конечному пользователю в слое пользовательского интерфейса). Поэтому подход с разделением метода и работы я активно использую. Пока я не рассказываю о нём явно окружающим, но, наверное, моё окружение уже вполне может заметить, что я стал обращать на него больше внимания.
-
Работа с версиями продукта и закон убывающей отдачи. Я внедрил практику производить как можно чаще промежуточные версии рабочего продукта, получать обратную связь по ним и дорабатывать продукт на основе этой обратной связи, используя принцип поставок мелкими партиями. Эта методика мне близка, и я использовал её и раньше, например в поставках продукта, который делали мы с другой командой. Я всегда выступал за частые поставки небольших изменений, в то время как владелец продукта любил накапливать много фич и поставлять их раз в квартал или даже раз в полгода. Мне это интуитивно не нравилось, и теперь я понимаю почему:
- замедляется поступление обратной связи;
- сложно разделить, к чему именно относится обратная связь, потому что изменений очень много, и между этими изменениями есть зависимости;
- одновременное привнесение большого количества зависимостей в рабочий продукт способно его в неблагоприятной ситуации сломать или затруднить его работу.
-
Последовательность системной оценки. Я начал применять чёткую последовательность: сначала определяю пользу качественно (зачем применяется метод, какую проблему решает и способен ли он дать нужный результат), затем перехожу к ресурсам, и наконец сопоставляю пользу и затраты в единых единицах. Если польза превышает затраты, значит есть или ожидается прибыль. Эта методика мне была понятна и раньше (возможно, это кажется задним числом), но вполне вероятно, что раньше я не задумывался и поступал интуитивно, когда нужно было оценить полезность какой-то фичи. Сейчас я ясно понимаю, что во-первых нужно определить пользу, то есть нужно ли в принципе заниматься этой задачей, и если нужно, тогда уже оценить, сколько это стоит и целесообразно ли этим заниматься. Перед глазами у меня есть пример: команда, у которой мы заказали разработку, пыталась вписать функциональность требуемой фичи в очень ограниченные ресурсы и в результате сделала решение, дающее некачественный результат. Сделана работа, которая не даст прибыли, потому что польза не окупает затрат. Этой фичей в том виде, в котором она есть, скорее всего, пользоваться не будут. Требуется либо её доработка, либо переработка.
-
Валидация метрик. Мне понятна практика регулярной проверки, не стала ли метрика самоцелью, сравнения отчетных цифр с физическими индикаторами процесса (например, время цикла и процент загрузки) и использования данных операционного учёта (например, трекеров задач) для проверки реальной пропускной способности и скорости выпуска результатов, а также анализа входного потока задач, метрик времени задач в очереди, количества одновременно выполняемых работ (work in progress) и так далее. На этом уровне я не работаю напрямую, я работаю только со своими личными задачами и соответственно слежу за их метриками. Вместе с тем я участвую в проектировании метрик работы программного обеспечения, которое мы разрабатываю, и здесь моя цель - проследить, чтобы метрика действительно адекватно отражала физические индикаторы автоматизируемого процесса, а не становилась самоцелью, оторванной от реальности, то есть не раззаземлялась.
Я не выявил явных сложностей в усвоении перечисленных методов, так как они легли на мой предыдущий опыт и интуитивные представления. Но я не внедрил полный цикл валидации метрик на уровне операционного учёта команды, так как не руковожу командой.
Мантра элегантности в работе/lean
Я оцениваю своё выполнение каждого пункта мантры элегантности следующим образом:
-
Прекратить делать ненужное. Я понял, что здесь есть потенциал, которого я раньше не видел. Буквально вчера я начал сокращать объём делаемого за счёт ненужного. В том числе это ненужное появилось из-за использования помощника в виде ИИ-агента, который производил довольно много лишней информации в составе плана работ на неделю и на день. Мне приходилось это лишнее читать, корректировать, тратить на это время и когнитивный ресурс. Я решил свести всё к минимуму и для этого перерабатываю формат ежедневного плана, подведение итогов по нему и скилл для ИИ-агента, по которому он этот план составляет и закрывает, чтобы там остался абсолютный достаточный минимум без лишнего “шума”.
-
Начать учитывать проекты и задачи в экзокортексе. Я пользуюсь экзокортексом с начала 2022 года, уже больше четырёх лет, и для меня это уже необходимая единая рабочая среда. В экзокортексе у меня и проекты, и задачи, и стратегия на разных горизонтах, и всё это очень помогает.
- Во-первых, потому что является единым пространством для работы, в том числе для мышления письмом, в котором есть вся необходимая информация
- Во-вторых, становится (опять же, при помощи ИИ-агентов), внешним мозгом. То есть, предоставляет мне экзокортекс не только в виде экзопамяти, но и в виде экзоинтеллекта, который именно думает, а не только что-то хранит.
-
Уменьшать время ожидания работ в очереди. Вот по этому пункту я, кажется, пока мало что делал, но постараюсь делать в будущем. Безусловно, считаю его полезным.
-
Задуматься об изменении методов работы по самым долгим операциям. Раньше я работал аудитором систем менеджмента качества, которые как раз описывают методы работы, и ключевой принцип системы менеджмента качества — это постоянное улучшение методов работы. Поэтому для меня изменение методов работы в сторону улучшения - это естественная и постоянная деятельность. Мантра элегантности предписывает заниматься этим в последнюю очередь. Ну окей, значит таков приоритет этой работы. Но с тем, что в определённых ситуациях нужно её выполнять, я абсолютно согласен.
Другие мантры я начал читать, но, честно говоря, не дочитал. Кажется, что на данный момент у меня достаточно теоретических материалов для освоения на практике. Так что освоение других мантр я оставлю на будущее.
Что ещё я вынес из этой резидентуры
В очередной раз утвердился во мнении, что лично мне лучше и продуктивнее заниматься, во-первых, с преподавателем, а во-вторых, в кругу других студентов, с которыми можно обсудить теоретический материал, успехи и сложности его применения на практике и “подумать друг об друга”, увидеть или услышать что-то полезное для себя в примерах других людей и поделиться своими примерами, своим опытом, таким образом практикуя всё то, что мы проходили.
Я осознал, что мыслить категориями агентов, методов, работ, передаваемых рабочих продуктов стало для меня критически актуальным. Помимо традиционных агентов, людей, подразделений, организаций, к нам присоединились такие агенты, как ИИ-агенты - программные сущности, использующие когнитивный ресурс LLM (больших языковых моделей). Я как раз занимаюсь проектированием таких агентов, поэтому для их успешной работы мне очень важно понимать, что необходимо предусмотреть и качественно реализовать в контрактах взаимодействия агентов с окружающей средой, друг с другом, и как построить внутренний рабочий цикл агента, чтобы он как можно успешнее выполнял данную ему работу по применимому методу. Так что всё, что мы прошли в этой резидентуре, я считаю полезным и ожидаю более глубокого раскрытия затронутых тем в следующих резидентурах.
).