Взгляд на управление: Нет инструкций для инженерии en ru

Лет 5 хотел написать этот пост и всё ещё не до конца понимаю, почему его надо писать — на мой взгляд эти вещи очевидны.

Но я также не понимаю некоторых явлений из рабочей практики и теории, например.

Почему все большинство теорий о менеджменте выводится из опыта физического регламентированного производства, а не из опыта инженерных и научных коллективов? Регламентированного — в смысле, что работа заключается в следовании инструкциям.

Конечно, написано много книг с наборами конкретных практик в духе «Как я был Engineering Manager» или «Как мы в Google делаем менеджмент», но это не теории — это наборы практик для частных случаев — для разумного применения этих практик надо иметь в голове соответствующую теорию.

Почему в управление творческими коллективами постоянно протекают практики из управления регламентированными коллективами? От попыток зафиксировать норму выработки до использования velocity команды как KPI. От попыток загрузить 100% времени инженера, до (неявного) требования подписываться кровью под каждой эстимацией. Не говоря уже об отказе в самостоятельном принятии решений, навязывании жёсткого расписания и работы в офисе.

Оба вопроса, конечно, риторические.

Ответ на первый вопрос: «так исторически сложилось» — до 1980-х годов действительно имело смысл выводить менеджмент, утрируя, из управления ручным трудом на фабриках. И то не всегда: хорошо, что в той же NASA пошли другим путём. Но это было полвека назад; сейчас мы живём буквально в будущем по отношению к тому времени, но продолжаем опираться на его концепции — и это ответ на второй вопрос.

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

Поэтому в этом и паре следующих постов я хочу обсудить роль творчества в инженерной работе: почему оно критически важно и где искать вдохновение для управления творческими коллективами.

Инженеры производят новую информацию

Даже во времена кульманов сутью инженерной работы было не копирование чертежа один к одному, а привнесение нового или создание нового с нуля. Существовала даже отдельная роль «чертёжник-копировщик», чтобы снять повторяющуюся работу с инженера.

В наше время наличие специализированного софта позволяет устранить множество рутинных операций и сосредоточиться на сути инженерной работы — создании нового.

Процесс создания нового невозможно воспроизвести следуя детальной инструкции.

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

Мы получим бессмысленный и дорогой процесс копирования уже существующей информации, который не создаст новую ценность.

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

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

Для инженера не может быть детальных инструкций

Итак, детальные инструкции не подходят для инженерной работы, так как они не приведут к созданию новой информации, а значит не создадут ценность.

Поэтому.

Инженеры действуют в рамках рекомендаций и ограничений, а не в рамках инструкций.

Рекомендации — это эвристики о том, как (скорее всего) может быть выгодно действовать в конкретной ситуации. Хорошим примером рекомендаций могут быть ТРИЗ, шаблоны проектирования или всевозможные циклы обратной связи.

Ограничения — это рамки, которые нельзя пересекать. Например, не выпускать лекарство без проведения клинических испытаний, использовать только сертифицированные компоненты, рассчитывать конструкцию на заданную максимальную нагрузку, придерживаться стандартов и регуляций, etc.

Чек-листы, обязательные процедуры в критических областях деятельности и прочие штуки, на мой взгляд, тоже попадают в область ограничений и рекомендаций.

Работу инженера нельзя сложно измерить на индивидуальном уровне

Поскольку каждый инженер:

• Работает в уникальном контексте (пространстве решений) — создаёт конкретное новое.
• Исследует пространство решений по-своему — выполняет уникальные операции в уникальном порядке.

Сложно объективно сравнивать работу двух инженеров.

Для примера, опустим тривиальный классический случай подсчёта строк кода на человека, давайте сравнивать количество ошибок, которые программист вносит в продукт в единицу времени. Если программист А вносит X ошибок в месяц, а программист Б — 2X, при одном и том же количестве закрытых задач. Значит ли это, что программист Б в 2 раза хуже программиста А?

Нет, конечно, потому что программист Б мог работать с более сложным кодом, или под большим давлением сроков, или с менее зрелым стеком технологий, или с новым для него фреймворком, или в менее зрелой команде, или QA проще работать с функциональностью, над которой работает Б.

Эффект всех упомянутых нюансов, как и многих других, не измерим количественно. Нет метрики, которая позволит осмысленно количественно сравнивать сложность кода, зрелость стеков технологий, уровень владения фреймворком и прочие подобные штуки.

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

Мы можем преобразовать качественную оценку в статистически значимую количественную, например:

• Собрав множество экспертов, которые независимо друг от друга оценят контекст и работу инженера.
• Попросив команду качественно оценить работу друг друга.

Но это будет дорого и долго:

• Если мы собрали команду экспертов для оценки команды инженеров, то теперь у нас есть две команды — будет дешевле оставить одну команду экспертов работать над оригинальным продуктом.
• Чтобы команда могла оценивать друг друга, она должна быть достаточно зрелой и каждый член команды должен обладать знаниями контекста всех остальных членов команды — то есть должно быть достигнуто почти 100% перекрытие знаний. Это возможно, но тоже дорого и сильно замедляет работу. Кроме того, у нас появляются этические и культурные риски.

Мы даже не можем сравнить работу одного и того же человека в разные периоды.

Попробуйте, для примера, собрать данные по эффективности работы одного fullstack разработчика, когда он в первую неделю пишет кнопочки для фронта; во вторую — микросервис; в третью — настраивает репликацию базы и оптимизирует запросы к ней; а всю четвёртую занимается код-ревью и разговорами со стейкхолдерами.

Поэтому.

Фокус управления инженерными коллективами смещается с персонального уровня на уровень команды и продукта.

Мы оптимизируем не людей, а рабочие процессы (в рамках которых действуют люди), потоки информации (между людьми и процессами) и метрики продукта (частью которого является наша команда).

Это позволяет нам оперировать в рамках более-менее объективных метрик и, тем самым, принимать более осмысленные решения.

Именно про это такие штуки, как Kanban, Teal Organizations, Lean Startup. Стоит отметить, что эти наборы практик также вышли из опыта регламентированных производств — так что не всё там зло для инженера — как я говорил, надо знать меру и выбирать практики с умом.

Перефразируя.

Мы оптимизируем рекомендации и ограничения для нашей команды.

Практические следствия

Необходимо понимать, какой тип работ выполняет команда и практики для какого типа работ мы пытаемся использовать. Если эти типы работ разные — мы делаем что-то не так и, скорее всего, вредим команде, компании и продукту.

Для работы с известным фиксированным результатом мы создаём и оптимизируем инструкции. Мы можем количественно измерять эффективность работы на индивидуальном уровне для оптимизации инструкций и развития профессиональных навыков людей.

Для творческой работы мы задаём ограничения исходя из желаемых метрик продукта и нарабатываем базу рекомендаций на основе практики. Мы оптимизируем продукт и его команду, а не конкретных людей. Для развития профессиональных навыков людей мы используем качественную экспертную оценку.

Теоретические следствия

На мой взгляд, необходимо разворачивать базовые концепции управления в сторону управления творческими коллективами и на основе нового базиса формировать концептуально новые наборы практик.

Сейчас происходит глобальный сдвиг распределения типов работ/профессий/ролей в сторону творческих, со временем их доля будет только возрастать. Массовая автоматизация, внедрение ИИ и робототехники этому отлично способствует. Направляя новый мир старыми методами, мы будем не только тратить ресурсы впустую, но и плодить страдания среди работников и клиентов.

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