Разберем, почему попытки оцифровать интеллект через нормо-часы и коммиты ведут к деградации продукта, и как на самом деле устроена невидимая зона создания ИТ-решений, где ценность рождается из исследования и анализа, а не из скорости стука по клавишам.
Хотелось бы начать сегодняшнюю тему со знаменитой фразы Фреда Брукса, выдающегося ученого и отца IBM System/360.
“Деторождение занимает девять месяцев, независимо от того, сколько женщин к нему привлечено.
В логике работы завода есть предсказуемость – через заданные промежутки времени по конвейеру проходит готовое изделие, и если мы хотим увеличить выпуск продукции на определенное количество, достаточно добавить ещё смен или поставить новые станки. Модель «затраты-результаты» сформировал менеджмент XX века, по которому мы привыкли замерять эффективность труда.
Работа айтишника серьезно отличается от конвейерности, и создание кода (основного продукта) как таковое занимает далеко не основную часть времени кодера. Попытки измерить эффективность разработки через количество коммитов или отработанных часов как минимум математически ошибочна, и не применима в мире ИТ.
На заводе время проведенное без стука по клавишам воспринималось бы как простой или низкое КПД. Однако самый большой труд айтишники производят не в момент написания кода, а при анализе, чтении контекста и поисков оптимального решения. Каждая задача в ИТ по своей сути уникальна, и если даже разработчику нужно сделать одну и ту же работу дважды, он просто автоматизирует процесс: превратит его в скрипт или библиотеку. А значит любую задачу в бэклоге можно отнести к микроисследованиям (R&D).
Промышленность против информации
Большинство кабинетов класса обществознания в школах оборудованы баннерами с отображением трёх эпох: аграрной, индустриальной и постиндустриальной. Последняя относится к информационной эпохе, в которой мы сейчас и находимся, и подход к труду внутри неё разительно отличается от индустриального, где правят станки.
Если у нас есть 10 токарей, которые точат одинаковые болты, они способны работать с максимальной степенью автономности: им не нужно обсуждать архитектуру каждого болта или проверять, не конфликтует ли их резьба с резьбой соседа, и в этом индустриальному подходу к производству нет равных.
“В случае работы с информацией каждый работник и плоды
его труда – часть экосистемы, и действия любого члена команды влияют на весь «организм» проекта.
Условное изменение в одном модуле разработки неизбежно повлияет на десятки других модулей. Ещё сложнее ситуация когда в команду приходит новый разработчик: вместо того, чтобы стать дополнительным станком, он замедляет весь процесс из-за онбординга и вникания в контекст. Очень часто меняются сами условия задачи по ходу её выполнения, сами задачи не до конца ясны на старте, а результаты уточняются в процессе. И тут уже не получится считать обычные меры продуктивности.
Исторически замер человеко-часов ввёл Фредерик Тейлор*: грубо говоря примерно сто лет назад он придумал разделять сложные задачи на простейшие движения, регламентировать их и замерять секундомером: на практике его идеи идеально реализовал Генри Форд, который показал всему миру как должно работать конвейерное производство.
Через полвека, появился Питер Друкер**, который ввёл понятие работника интеллектуального труда: у него, в отличие от Тейлоровских работяг, вместо станков есть собственные средства производства – в его же голове.
Проще говоря на заводе менеджер говорит сотруднику что делать, а в интеллектуальном труде сам работник должен определять в чем заключается его задача и каков наиболее эффективный путь к достижению цели.
Основной конфликт ИТ-проектов в том, что сетку Тейлора натягивают на мир Друкера. Когда руководство требует график сгорания задач или измеряет продуктивность количеством строк кода, оно неосознанно ведет разработчика к станку. При этом программный код не физический объект, а буквально формализованная мысль. Замерять мысль в единицах объема – не самая лучшая идея.
Можно без конца оптимизировать и экономить на производстве, но чаще всего в разработке попытки поднажать и ускорить написание кода ведут к падению качества продукта – неделя экономии может обернуться месяцами исправлений: в отличие от брака токаря (который можно выкинуть в урну и выточить нормальную деталь), брак в архитектурных решениях может ударить по работе всей системы.
Невидимая зона
Jira, GitHub или даже Agile-метрики не могут зафиксировать основную часть работы айтишника – в среднем разработчик тратит примерно 20% на написание самого кода. Что же тогда делает айтишник остальное время?
Читает контекст
Код нельзя сравнить с текстом этой статьи – изолированным и понятным самим по себе. Код это плотное переплетение зависимостей, и прежде чем внести изменение в одну функцию нужно понять десятки смежных модулей: т.е. чтобы внедрить новую фичу нужно потратить немало времени чтобы понять, как не нарушить целостности экосистемы.
Проверяет гипотезы / ментальное моделирование
Разработке не чужды готовые решения, и очень часто их поиск и удачные внедрения экономят недели, а то и месяцы разработки. Кроме того, чтобы внести изменения в проект приходится постоянно прогонять потенциальные последствия: «Что если отключится сеть» или «Если пользователь введет отрицательное число».
Держит когнитивный поток
Существует довольно известное исследование Глории Марк о взаимодействии с технологиями: согласно ему после любого внешнего прерывания контекста мозгу требуется порядка 23 минут, чтобы восстановить сложную ментальную конструкцию (что и представляет из себя разработка). Выходит, что в ИТ даже быстрый вопрос в мессенджере может стоит пары часов реальной работы.
Ценность работы айтишника рождается в периоды глубокой концентрации, когда перед его головой открыта вся картина разработки.
Исследовательская суть рутины
Разработку можно назвать балансом между использованием готовых решений (exploitation) и поиском новых путей (exploration). Когда заказчик требует «сделать так же, как в прошлый раз», он не учитывает, что контекст продукта изменился: старое решение вполне может конфликтовать с новыми модулями, требовать иных мощностей сервера или не соответствовать обновленным протоколам безопасности.
Поэтому разработчик тратит время на рутинное изучение документации, чтобы снизить энтропию системы, предотвращая превращение продукта в хаотичный набор костылей.
Рутина как термин в контексте ИТ глубоко обманчивое определение.
Любое, даже типовое изменение в коде почти всегда содержит в себе элемент разведки. Разработчику нужно в первую очередь выявить первопричину дефекта, восстановить в голове логику работы конкретного участка системы, и как говорилось ранее – просчитать возможные побочные эффекты.
“Здесь мы можем вывести ещё одну слабо измеримую ценность ИТ-сотрудника: умение быстро ориентироваться в неизвестном.
Хороший айтишник может собрать рабочую карту системы там, где документация устарела или вовсе отсутствует. В зрелых командах любой процесс – от отладки до расследования инцидентов – строится не как механическое устранение симптомов, а как цикл научного исследования: выдвижение гипотезы, её проверка в изолированной среде и анализ данных.
Исследовательский характер ИТ вытекает из природы цифровой среды, потому что в мире информации всё постоянно меняется, притом с завидной скоростью. Требования бизнеса непрерывно уточняются, приоритеты смещаются в зависимости от рынка, а данные ведут себя непредсказуемо при масштабировании. Получается своего рода управление неопределенностью, где каждый закрытый тикет – результат успешно проведенной экспедиции вглубь сложной системы.
Попытки измерить эффективность
У менеджмента внушительный арсенал учета производительности. Замерить KPI по ним несложно, и попробуем рассмотреть наиболее популярные метрики, которые отлично сработали бы на заводе:
Метрика | Ожидаемый результат | Реальный эффект |
Количество строк кода (LOC) | Высокая производительность | Раздутый, нечитаемый код (bloatware) и рост технического долга. |
Количество коммитов | Высокая активность | Дробление мелких правок на десятки бессмысленных микро-коммитов. |
Скорость (Velocity / Story Points) | Быстрое закрытие задач | Инфляция поинтов: команда начинает оценивать простые задачи как сложные, чтобы выполнить норму. |
Количество закрытых багов | Качественный продукт | Создание простых багов для их последующего героического исправления. |
В левом столбце хорошие бизнес-метрики, но их проблема в том, что они измеряют объем выработки вместо бизнес-ценности, на которую в первую очередь опирается заказчик. Для бизнеса нет особого значения, столько тысяч строк кода написано – главное работает или не работает то, для чего написан код. Ну а привязка по часам бьёт в первую очередь по невидимой зоне, где происходит самый ценный и важный процесс исследования перед написанием кода.
Есть хорошая новость – существует адекватная методология измерения DORA (DevOps Research and Assessment). Вместо контроля за количественными действиями рук программиста, она предлагает оценивать здоровье процесса через четыре показателя: частота деплоя, время докатки изменений (Lead Time), частоту отказов при деплое и время восстановления системы. Эти метрики в совокупности дают представление о конечной способности системы поставлять ценность. Всё, что находится «до» этого момента – сложный творческий процесс, и попытка ускорить его через микроменеджмент приводит только к росту энтропии и последующему уходу талантов.
Итого
В индустриальную эпоху ценность производства задавали минимальные отклонения от стандарта. В эпоху же информационную, напротив, ценность создается через способность разработчика ориентироваться в условиях высоких переменных.
Плохая метрика почти всегда порождает не рост качества, а рост имитации.
В ИТ это особенно заметно, потому что здесь очень легко подменить ценность видимой активностью. Ещё десятилетие назад продуктивность разработчиков пытались считать по строкам кода, и критика этого подхода появилась не вчера: Эдсгер Дейкстра прямо писал, что измерение программиста скоростью производства строк поощряет слабые решения и раздувание кода. Логика примитивна, но работает безотказно: как только объём объявляют мерой пользы, система начинает производить объём. Не лучшее решение, не более устойчивую архитектуру, не более понятный продукт, а просто больше текста, коммитов и формальных следов активности.
С современными agile-метриками происходит то же самое, только вместо строк кода на сцену выходят velocity, burndown и правильная динамика спринта. Как пример есть кейс одного российского крупного банка: на телевизор в офисе вывели диаграмму сгорания по каждой команде командами, чтобы руководство могло вечером проходить мимо и видеть уровень продуктивности. Кончилось это предсказуемо: команды начали дробить задачи на более мелкие, а затем написали скрипт для создания и списание тикетов, чтобы график выглядел красиво. Метрика осталась зелёной, а связь с реальной продуктивностью – исчезла.
Если менеджмент фокусируется на видимых атрибутах активности, будь то объем кода или часы, возникнут условия для создания инфомусора от самих айтишников, чтобы соответствовать требованиям начальства. Оттуда появляется дополнительный техдолг, скрытые дефекты и самое страшное – выгорание самих сотрудников.
Желание повысить эффективность работы закономерно и понятно всем, однако в ИТ один из лучших способов сохранить темп развития проекта в долгосрочной перспективе – это признать, что качественная разработка требует времени на раздумья, которое невозможно сократить никакими методами промышленного принуждения.
Помните, что некоторые процессы невозможно сжать во времени, просто добавив больше ресурсов, потому что их суть не в физическом труде, а в созревании концепции и связей.
Фредерик Тейлор – Научная организация труда
* Питер Друкер – Ориентиры завтрашнего дня
