Взгляд на управление: Научные практики для инженерии — публичные артефакты en ru

В прошлом эссе мы обсудили, что инженерия и наука близки, а значит, могут заимствовать практики друг у друга.

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

Здесь и далее под инженерией имеется в виду инженерия в IT / разработке ПО. Я уверен, что идеи из поста применимы и к инженерии в целом, но это эпически разнообразная и обширная область. Формат блога и врождённая скромность не позволяет мне высказывать столь смелые утверждения.

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

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

Мы обсудим следующие темы:

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

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

Оговорки

Уровень абстракции

Рассматриваемые практики я считаю сложными. За каждой из них стоит не только врождённая «техническая» сложность, но и сложность культурного сдвига, который потребовался для её формирования и внедрения в науке — за каждой практикой стоит долгий исторический путь.

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

Я буду опускать такие вопросы, как:

• Экономические аспекты внедрения практик для бизнеса.
• Минимальный уровень компетенции и зрелости сотрудников, необходимый для внедрения практик.
• Социальное сопротивление к внедрению практик.
• Проблемы с приватностью и безопасностью, которые могут возникать при внедрении практик.
• etc.

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

Иными словами, обсуждать будем «идеальные практики в вакууме», а не «конкретные практики в конкретной компании».

Проблемы науки

Современная наука поражена множеством болезней (а когда было иначе?). Не всегда и не везде всё работает как должно.

На мой взгляд, это не свидетельство неэффективности её практик, а свидетельство продолжающегося её развития. И природы человечества, конечно.

Часть практик уже используется

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

Публичные артефакты

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

Под артефактом я имею в виду любой «физически зафиксированный» результат труда. Наука формализовала часть подобных артефактов: публикации в журналах, открытые наборы данных, постеры и презентации на конференциях, etc. Но таким артефактом может считаться и пост в блоге, open source код, видео на YouTube, зарегистрированное сообщение об ошибке, RFC, документация и многое другое.

Не вся наука строится на публичности. Корпорации, армия, может быть, спецслужбы держат часть разработок в секрете. Но:

• Это меньшая доля научной активности.
• Со временем все ключевые работы становятся открытыми или дублируются в открытом виде.

Два типа публичности

Более корректно будет рассматривать два типа публичности:

1. Внутренняя публичность — открытие артефактов внутри компании, между командами, отделами, etc.
2. Глобальная публичность — открытие артефактов для всего мира — для всех, кто может быть заинтересован в них.

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

Однако, в контексте идей этого текста, разница между ними не так существенна:

• Для малых компаний внутренняя публичность отсутствует как явление — слишком мало людей в сообществе компании.
• Для крупных компаний внутренняя публичность может быть концептуально близка к глобальной, так как разница между размерами сообществ как между «много людей» и «очень много людей».
• Существенные отличия в эффектах могут проявиться только в компаниях среднего размера.

Верифицируемость артефактов

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

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

Оба подхода имеют одинаковые следствия:

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

Тем самым замыкается обратная связь, которая обеспечивает эволюцию области.

Публичные артефакты как свидетельства компетенции

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

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

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

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

Как и в науке, у инженеров есть возможность публиковать артефакты в пафосных местах, например, в виде отправки патча в крупный open source проект, выступления на значимой конференции, создания «предложения по улучшению» в виде RFC, PEP или аналогов. Даже простой пост в блоге может набрать достаточно социального капитала в виде лайков, репостов и комментариев, чтобы стать весомым артефактом.

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

• По резюме можно только создать список поверхностных вопросов к обсуждению.
• Тестовые задания оторваны от реальности, оттого бессмысленны, особенно с развитием LLM.
• После нескольких часов разговора можно составить только первое представление о человеке, проверить его на самые красные флаги.
• Программирование на собеседовании не показывает ни одного реального рабочего навыка.

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

Публичные артефакты позволяют частично решить обе эти проблемы за счёт верификации сообществом. Для примера, если ваш патч в ядро Linux приняли, то что-то в Linux вы наверняка понимаете.

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

Моё крайне предвзятое мнение: глобальная переплата за найм больше возможных потерь от выделения доли рабочего времени на подготовку публичных артефактов.

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

Публичные артефакты как критерий квалификации

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

Грубая аналогия между научной степенью и квалификацией в IT по уровню самостоятельности:

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

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

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

На мой взгляд, это бы на порядок сократило сложность найма как для работодателя, так и для соискателя.

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

Оценка высококвалифицированных специалистов, конечно, сложнее. В науке она, в основном, происходит через оценку последних опубликованных статей, а также через оценку их цитируемости. В IT она никак не происходит: мы собеседуем человека и отправляем его на испытательный срок в надежде, что мы не ошиблись. Поэтому даже для топовых специалистов возможность оценки их квалификации через публичные артефакты была бы крайне полезной.

Публичные артефакты как ось оценки сотрудников

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

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

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

Мало что может демотивировать инженера больше, чем бессмысленные годовые цели и нерелевантная оценка его работы.

Публичные артефакты позволяют бороться с этими проблемами и даже больше.

Традиционные цели мы выносим на уровень команды, потому что именно команда, как статистически значимая единица, может быть объективно (более-менее) оценена и управляема. В конце концов, с точки зрения продукта не важно кто конкретно что сделает и за что будет отвечать, важно чтобы это было сделано. Конкретное распределение работы между сотрудниками должно быть результатом саморегуляции команды, а не внешнего воздействия.

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

Подобное разделение несёт ряд преимуществ.

Во-первых, вы переключаете оценку сотрудника со статистически недостоверной оценки его работы парой человек, на более достоверную оценку коллегами (публичная работа видна всей компании, а не только команде; люди значительно активнее реагируют на неё) и профессиональным сообществом.

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

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

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

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

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

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

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

Публичные артефакты как метрики здоровья

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

Что может быть сигналом:

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

Примеры:

• Команда стала создавать значительно меньше артефактов — возможно она перегружена работой.
• Скачок в количестве патчей в open source может свидетельствовать о том, что продукт упирается в архитектурные ограничения, которые приводят к использованию сторонних библиотек «на максимуме их возможностей».
• Реакция на демо новых фич может быть критерием правильности выбранного направления развития продукта.
• Частое участие в подкастах и круглых столах может свидетельствовать о том, что продукт и компания становятся более заметными в профессиональном сообществе.
• Популярность утилит, которые вы открываете, может свидетельствовать о том, что ваши процессы разработки близки к лучшим практикам.

Сложности перевода разработки на публичные артефакты

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

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

Есть несколько сложностей.

Страшно

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

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

За свою карьеру я могу вспомнить всего пару случаев, которые с большой натяжкой можно было бы отнести к «секретной» технологии или «тайному» знанию, которые являлись реальным конкурентным преимуществом.

Зато такими преимуществами неизменно были конкретные люди, команды и инфраструктура в целом. Ведь продукт — это не код и прочие артефакты, а 4D-система, которая включает в себя не только код, но и его конкретные запущенные экземпляры, инфраструктуру разработки и поддержки, процессы, культуру и, конечно же, людей.

Продукт имеет временное измерение, за которое отвечают именно люди, и именно эти люди являются реальным конкурентным преимуществом.

Утрируя, на примере игр:

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

Поскольку открытие артефактов идёт на пользу сотрудникам, продвигая его, мы усиливаем компанию.

Дорого

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

Открытие артефактов — это инвестиция в:

• Качество продукта — люди более ответственно относятся к качеству публичной работы, особенно если она явно связана с ними.
• Обмен знаниями — публичные разборы кейсов, выступления на конференции будут с большей вероятностью изучены коллегами и в любом случае станут референсом для решения конкретных задач.
• Репутацию компании и найм — при прочих равных именно репутация определяет выбор работы для многих специалистов, особенно для топовых.
• Инфраструктуру, её надёжность и безопасность. Например, патч в используемый вами open source проект однозначно вернётся к вам.

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

Непонятно

На мой взгляд, это самая сложная проблема и самый большой вызов.

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

Схожие соображения касаются и прочих типов артефактов.

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

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

С чего начать

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

1. Определить перечень типов артефактов, которые устраивают вашу компанию.
2. Выбрать группу людей, согласных переключить своё годовое ревью на оценку публичных артефактов и начать с них.
3. После первого ревью провести ретроспективу: изучить созданные артефакты, их влияние на компанию, впечатления создателей артефактов и их коллег.
4. На основе ретроспективы расширять и корректировать практику.

С каких типов артефактов может быть удобно начать, от простого к сложному:

1. Записи выступлений на митапах и конференциях — всегда есть активные люди, которые с удовольствием в этом участвуют, даже без мотивации со стороны компании. Не составит большого труда определить их и поддержать их в этом.
2. Патчи в open source проекты. Со стороны это может звучать сложным занятием — надо ещё найти, что исправлять. Но по моему опыту, в процессе активной работы над более-менее сложным проектом в год вы будете находить 5-10 проблем разного масштаба в open source. Их обычно обходят, а не исправляют, сугубо из-за того, что эта активность не вписана в рабочий процесс и люди боятся, что их «наругают» за отвлечение от работы над продуктом.
3. Публикация документов архитектурного уровня. Это могут быть как формальные спецификации, так и детальные посты в блоге. В публичном поле всегда не хватает подобной информации и она с благодарностью воспринимается профессиональным сообществом. Кроме того, это повод для ваших лидов/архитекторов наконец-то переварить и осознать чего же они такое делают.
4. Демо фич. Демки работают не для всех продуктов, но в некоторых случаях очень полезны. Например, в разработке игр.
5. Открытие внутренних наработок: библиотек, утилит. Сложность с этим не в опасности раскрыть «секреты», которых обычно нет, а в том, что мало людей умеют быстро оформлять open source проекты и поддерживать их. Это отдельный навык, который нужно развивать.