Варианты предварительной подготовки

К выполнению работ по методам нужно готовиться. Подготовка обычно зависит от того, какой объект надо создать и какой именно тип линии используется.

Например, если мы создаем «железные» системы вроде моста, ленточного конвейера для шахт, здания и прочих, то для работы линии вам потребуется подготовить сырье и материалы/raw materials. Они должны прибыть к началу работ линии или её части, чтобы железная система была воплощена без задержек. Соответственно, требуется закупить и привезти необходимые материалы, а перед началом работ линии убедиться, что все материалы в наличии.

То же самое касается инструментов/экзокортекса, который требуется для выполнения работ. Инструменты нужны любым создателям: у разработчиков инструментами будут выступать ноутбук/компьютер (гаджет) и необходимые приложения для разработки. На производстве окажутся необходимы ЧПУ станки или какие-то ещё.

Кроме того, нам потребуется описание метода работы. То есть, нужно будет отмоделировать метод, которым будет выполняться работа. Иногда для этого предварительно придётся отмоделировать сам объект. Например, организатор мероприятия сначала моделирует создаваемый объект (мероприятие, например, конференция), а затем выбирает и моделирует методы создания объекта. Конечно, такое пре-моделирование не может быть всеобъемлющим. На старте, когда нет никаких моделей, а работа выполняется интуитивно, без какого-то явно выделенного метода, нужна первая модель создаваемого объекта и первое описание метода. Эти описания обычно впоследствии оказываются неверными, но полезными. То есть, первая версия описания почти никогда не останется неизменной (разве что у вас хорошее онтологическое и прикладное мастерства), её всегда критикуют, но она позволяет начать выполнять работу чуть лучше – а ещё сознательно улучшать метод работы.

Пре-моделирование можно выполнять кусочками и в минимальном или расширенном варианте. В минимальном варианте обычно это делается так: берется пример хорошо созданного объекта, например, качественно построенного моста, максимально похожего на ваш, изучается чужой опыт создания этого моста, то есть, применение методов создания моста, и сопоставляется с онтологией предметной области/domain (обычно описана в стандартах), после чего генерируется вариант онтологии и вариант(ы) методов для создания объекта (в данном случае моста). Это облегчённый эмпирический способ моделирования (empiricist-lite), при применении которого обеспечивается более высокая скорость до конечного результата, чем при применении «экспертного» способа, когда эксперты придумывают онтологию «с нуля» и лишь затем начинают её проверять в реальном мире.

При предварительной подготовке к первой работе по новому сложному методу можно прописать очень простую модель не очень высокого качества. На старте важнее скорость получения модели, а не её точность: первые версии мы должны получать максимально быстро, а затем за много мелких интераций повышать точность последующих версий модели. Это эволюционный аргумент: когда агент только начинает что-то создавать, скорость важнее точности. Работа выполняется максимально быстро, и агент/создатель максимально быстро получает обратную связь, которая позволяет скорректироваться. Когда скорость получения результатов замедляется, значит, пришла пора повышать точность моделей, для чего нужно много небольших быстрых итераций по обкатке моделей и дальнейшее уточнение онтологии.

При моделировании обязательно нужно будет выделить объекты, которые потребуются для успешного завершения работы – и которые невозможно качественно создать сразу в момент основной работы. Например, во время звонка с потенциальным покупателем продажники пользуются скриптами, успешными клиентскими кейсами, статистическими данными о результатах применения созданной вещи, списком клиентов, который должны обзвонить – и чтобы звонок прошёл успешно, все эти описания должны появиться у продажника. Ресторану нужен своевременный подвоз ингредиентов и технические карты, по которым блюдо может быть приготовлено, даже если придётся заменить повара.

В рамках предварительной подготовки также проводят исследования. Однако исследования можно проводить по-разному. Например, можно проводить исследования нового рынка и возможности запуска на нём нового продукта; а можно проводить исследования, необходимые для до-моделирования метода выполнения работы. Например, если вы не можете составить законченное концептуальное описание системы/ConOps, то есть смысл пойти поизучать учебники. В таком случае можно говорить, что исследование, после которого линия получает задание/task запустить новый продукт – это часть предварительной подготовки, а до-исследование, необходимость в котором возникла после начала выполнения работ линией, уже просто обычная работа, а не предварительная подготовка.

В предварительную подготовку включают обычно активности вроде изучения продукта с целью найти новые точки роста/product discovery. Однако если есть целая команда, которая занимается только этим, то такое изучение продукта будет для неё «операционкой», те текущей операционной деятельностью, а не предварительной подготовкой к ней. Так что определять составляющие предварительной подготовки надо будет обязательно с учетом типовой работы по типовым методам, выполняемым линией.

Часть работ по тестированию гипотез в продуктовой команде тоже можно отнести к предварительной подготовке. Например, когда команда выдвигает гипотезы о возможных функциях продукта и затем проводит первичную оценку этих гипотез, оценивая уверенность команды в ней: продуктовые менеджеры приносят какие-то обоснования, почему гипотеза не является плохой и почему операционная команда/линия, включающая в себя разработчиков, тестировщиков и так далее как части линии/рабочие станции, должны начинать работать над гипотезой. Линия должна начинать работать над гипотезами, которые точно не являются плохими, т.е. над теми, которые нельзя отвергнуть при ранней проверке (без сложных тестов и без тестов для пользователей, проведение которых требует значительных ресурсов).

Кроме того, к предварительной подготовке можно отнести и предварительное планирование работ по методу. Когда создатель определился с методом, который нужно применить, и отмоделировал его, надо заземлиться и выполнить планирование работ: какие именно создатели (линии, части линии) будут применять какие части метода, сколько ресурсов потребуется, какие работы будут сгруппированы так, чтобы выпускать объект (или его часть) минимальными партиями/лотами/batches/lots.

Зачем группируют работы? Обычно это делают по следующим причинам:

• Во-первых, чтобы уменьшить время на переключение/перенастройку создателя (setup costs). Если станок производит один тип деталей, а потом переключается на другой, то есть затраты на переключение. Если личность выполняет работу одним методом, например, выступает в роли финансиста, а затем переключается на работу другим методом, например, операционным менеджером, то у него тоже есть затраты на переключение и перенастройку, особенно если одна из исполняемых ролей даётся тяжело. Поэтому группировать работы и выполнять их сразу пачкой, получая набор/kit/партию/лот/batch/lot результатов выгодно.
• Во-вторых, чтобы увеличить скорость выполнения отдельной операции. Если вы готовите как операционный менеджер сразу ряд однотипных отчётов, то скорость выполнения отдельной операции будет в среднем выше, чем в случае выполнения единичной операции.
• В-третьих, таким образом можно экономить время на «несокращаемых» операций. Например, вне зависимости от размера релиза требуется писать релизные заметки/release notes и проводить проверку кода/code review. Загрузка/производственная способность/capacity технического лидера/техлида, который проводит проверку, обычно очень ограничена, возможности проверять релизы каждые несколько часов нет. Поэтому, даже если линия может организовать выпуск релизов каждые несколько часов, смысла обычно в этом нет: требуется увеличить размер «партии» так, чтобы релизы удобно было выпускать.

Однако слишком большие партии означают увеличение времени на формирование партии и на трансфер этих партий между частями линии. Поэтому сейчас принято формировать партии небольших размеров/small batch size. Например, в случае релиза это означает, что мы выбираем размер релиза так, чтобы выпускать релиз каждую неделю по 1-2-3 раза в неделю, и выделяем ресурсы (включая время техлида) так, чтобы обеспечить бесшовный выпуск этих релизов.

Подготовка обычно нужна перед мероприятиями, например, перед встречами. Чтобы встреча прошла успешно, нужно ещё до встречи поработать со следующими объектами внимания:

• Повестка встречи, которая описывает тему и вопросы, которые будут обсуждаться на встрече. Файл с повесткой встречи должен быть доступен каждому участнику до встречи (минимум за 1 день), чтобы все успели ознакомиться с вопросами и быть готовым на них отвечать;
• Ответы на вопросы, которые будут обсуждаться. Обычно требуются данные об экземплярах объектов, например, данные о выполненных за неделю работах, а также результаты обработки этих данных, например, выводы о том, когда удастся завершить работы при текущей скорости работы.

Кроме того, требуется провести работы по методам организации встречи: выбрать место встречи, обеспечить рассылку повестки и данных встречи всем участникам, выбрать тех, кто будет вести протокол встречи/meeting notes (при необходимости – транскрипт встречи), отредактирует его после встречи и разошлёт участникам, а также при необходимости заранее выбрать ведущего/фасилитатора встречи.

Если такая подготовка не проведена, встречи обычно проходят непродуктивно. Вместо того, чтобы прийти подготовленными, участники прямо во время встречи начинают лихорадочно собирать необходимую информацию, называть сроки выполнения работ «от балды» и так далее. Поэтому некоторые инженеры-менеджеры не только наладили в командах подготовку ко встречам, но и отменяют встречу, если оказывается, что участники к ней не готовы, и переносят на другое время. Это позволяет не только не потерять время на кое-как проведённую встречу, но и не создать конфликт из-за кое-как заключенных договорённостей. Вы получите результат быстрее (то есть, скорость до результата будет выше), если перенесёте встречу на завтра, зато завтра договоритесь точнее.

При принятии решения тоже обычно нужна предварительная подготовка. Часто требуется описать, какие методы создатель вообще может применить, чтобы привести объект в нужное состояние. Если ни один из известных методов не подходит, то можно попробовать составить «конструктор методов»: описать, какой именно объект в каком состоянии нужно создать/получить «на выходе», какую цепочку превращений проходит этот объект (то есть, как он меняет свои состояния по мере применения метода(ов)), какие ещё объекты должны сменить своё состояние. После описать, что может делать создатель, чтобы объект пришёл в это состояние. Например, по итогам встречи обычно нужно получить описание принятых решений (чтобы потом можно было проверить, как решения исполняются). Эти решения можно зафиксировать в файле «Протокол встреч» во время встречи; можно написать сообщение или электронное письмо участникам после встречи; можно вести запись встречи и затем сделать при помощи экзокортекса-транскрибатора вроде Teamlogs транскрипт встречи и вытащить договорённости оттуда. Методов обычно много, не один и не два, и они дают сопоставимый результат. После описания объекта, его состояний и возможных методов приведения объекта в нужное состояние можно описать, какие агенты заинтересованы в каком результате. Например, если вы не можете выбрать метод завершения проекта, потому что мнения разделились (половина команды отстаивает один метод, вторая – другой), то можно прямо на встрече или после неё определить роль и ролевой способ выделять объекты/viewpoint, который отстаивает конкретный человек. Какие роли играют отстаивающие одну точку зрения? Какие – другую? Какие у них объекты внимания, как они смотрят на мир? Что им важно с точки зрения последствий, а что – нет? Составьте два таких описания и попробуйте принести их на встречу для обсуждения.