Управление техническим качеством в базе кода.

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

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

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

Проблема

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

Так же, как планка технического качества вашей компании со временем изменится, ваш подход к управлению техническим качеством будет развиваться параллельно:

1. исправить горячие точки которые вызывают немедленные проблемы
2. применять передовой опыт который, как известно, улучшает качество
3. расставьте приоритеты точки воздействия которые сохранят качество при изменении вашего программного обеспечения
4. согласовать технические векторы в том, как ваша организация меняет программное обеспечение
5. измерение технического качества для направления более глубоких инвестиций
6. создать группу технического качества для создания систем и инструментов для обеспечения качества
7. запустить программу качества для измерения, отслеживания и создания отчетности

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

Подъем по лестнице

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

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

Итак, сначала сделайте что-нибудь по-быстрому!

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

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

Горячие точки

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

Есть старая шутка о Сарбаннесе-Оксли: он не снижает риск; он просто проясняет, кого винить, когда что-то идет не так. К сожалению, эта шутка без юмора относится к тому, сколько организаций внедряют процессы. Подотчетность играет свою роль, но гораздо важнее понять существующую проблему и попытаться исправить ее напрямую, чем создавать подотчетность на основе процессов.

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

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

Если у вас есть проблема со скоростью разработки, это может быть оптимизация времени выполнения тестов, перенос этапа компиляции Docker на RAM-диск или использование методов, описанных в Software Design X-Rays, для поиска конкретных файлов, которые нужно улучшить.

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

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

Передовой опыт

Однажды я работал в компании, в которой не было процесса группового планирования. Со временем руководитель отдела разработки был все больше разочарован неспособностью спроектировать целевые сроки и потребовал, чтобы мы использовали Scrum. После получения мандата менеджер написал процесс Scrum в вики. Было объявлено, что мы используем Scrum. Менеджеры посоветовали своим командам использовать Scrum. Миссия выполнена!

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

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

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

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

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

Хотя все рекомендации Accelerate основаны на данных и довольно хороши, некоторые из тех, что я нашел наиболее полезными для раннего внедрения, — это контроль версий, разработка на основе магистрали, CI / CD и возможность наблюдения за производством (включая разработчиков по вызову для систем, которые они пишут), и работая с небольшими атомарными изменениями. Есть много других практик, за которые я хотел бы отстаивать, кто не провел эру карьеры, выступая за улучшение внутренней документации, но я не доверяю своей интуиции, как когда-то.

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

Точки плеча

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

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

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

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

Государство — это самая сложная часть любой системы для изменения, и это сопротивление изменениям делает системы с отслеживанием состояния еще одной важной точкой воздействия. Инерция государства обусловлена ​​его масштабом. Из-за его тенденции к увеличению сложности за счет свойств доступности, надежности и соответствия. Из-за того, что правильность описывается вероятностями, а не теоремами. (Или, в случае распределенного состояния, и вероятности, и теоремы.)

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

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

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

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

Технические векторы

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

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

Ваши основные инструменты для совмещения технических векторов:

• Оставьте прямой отзыв. Когда люди сталкиваются с несогласованностью, первым ответом часто бывает изменение процесса, но вместо этого начните с простой обратной связи с людьми, которые, по вашему мнению, не согласуются. Как бы они не упускали из виду ваш контекст, вы упускаете из виду их, и добрый, ясный разговор часто может предотвратить годы ненужного процесса.
• Излагайте свои видения и стратегии в ясном и полезном документе. (Это обширная тема, которую я расскажу отдельно. TODO: Добавьте ссылку на раздел написания технических стратегий, как только он будет написан .)
• Инкапсулируйте ваш подход в свои рабочие процессы и инструменты. Документирование четкого видения полезно, но некоторые люди просто не будут изучать ваш документ. Преднамеренные инструменты создают рабочие процессы, которые способствуют формированию привычек гораздо лучше, чем обучение и документация. Например, для подготовки новой службы может потребоваться перейти на веб-сайт, на котором вам потребуется добавить ссылку на техническую спецификацию этой службы. Другой подход может заключаться в блокировании развертываний в производственной среде, если для службы не настроена дежурная связь с кем-то, кто в данный момент находится на связи, и у этого человека также должны быть включены push-уведомления.
• Обучайте новых членов команды во время их адаптации. Изменить привычки людей после того, как они сформировались, довольно сложно, и это неприятно, если вы пытаетесь заставить людей принять новые методы. Однако, если вы укажете людям правильное направление, когда они присоединятся, то эта привычка-импульс будет работать в пользу сохранения единства.
• Используйте закон Конвея. Закон Конвея утверждает, что организации создают программное обеспечение, которое отражает их структуру. Если ваша организация плохо структурирована, это приведет к сильно связанному или запутанному программному обеспечению. Однако это также фактор качества, если дизайн вашей организации эффективен.
• Курирование технологических изменений с использованием анализа архитектуры, инвестиционных стратегий и структурированного процесса внедрения новых инструментов. В большинстве случаев несоответствие происходит из-за отсутствия контекста, и это точки воздействия организации, позволяющие внести контекст в процесс принятия решений. Многие организации начинают с этого места, но это последний набор инструментов, который я рекомендую открыть. Как вы можете проводить последовательные обзоры архитектуры без четкого видения? Зачем рассказывать людям свою стратегию после того, как они что-то разработали, а не в процессе адаптации?

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

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

Измерение технического качества

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

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

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

Некоторые репрезентативные компоненты, которые следует учитывать в определении качества:

• Какой процент кода набирается статически?
• Сколько файлов имеют связанные тесты?
• Каково покрытие тестами в вашей кодовой базе?
• Насколько узки общедоступные интерфейсы между модулями?
• Какой процент файлов использует предпочитаемую библиотеку HTTP?
• Отвечают ли конечные точки на запросы в течение 500 мс после холодного запуска?
• Сколько функций имеют опасное поведение чтения после записи? Или выполнить ненужное чтение первичного экземпляра базы данных?
• Сколько конечных точек выполняют все изменения состояния в рамках одной транзакции?
• Сколько функций получают блокировки с низкой степенью детализации?
• Сколько существует горячих файлов, которые изменяются более чем в половине запросов на вытягивание?

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

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

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

Группа технического качества

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

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

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

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

При создании и управлении одной из этих команд некоторые основы успеха:

1. Доверяйте метрикам выше интуиции. У вас должен быть способ измерить каждый проект. Качество — это сложная система, в которой ваша интуиция легко может вас обмануть. Точно так же по мере того, как вы становитесь старше в своей компании, ваш опыт больше не будет отражать опыт большинства других людей. Вы уже знаете о острых углах и получите приоритетную помощь, если найдете новую, но большинство других людей не знают. Метрики сохраняют честность.
2. Сохраняйте свежую интуицию. Код и процессы со временем меняются, и ваша интуиция устаревает каждую неделю, когда вы перестаете создавать функции продукта. Большинство людей считает, что встраивание команды и ротация команды — лучший способ сохранить свои инстинкты актуальными. Другие следят за чатом на предмет проблем, а также за здоровым графиком дискуссий один на один с разработчиками продукта. Лучшие специалисты делают и то, и другое и держат под рукой свои панели показателей.

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

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

4. Делайте меньше дел, но делайте их лучше. Когда вы строите для всей инженерной организации, все, что вы делаете хорошо, ускоряет работу всей организации. Все, что вы делаете плохо, включая что-то почти отличное со слишком большим количеством шероховатостей, всех утащит. Хотя почти всегда верно, что выполнение нескольких самых важных вещей будет способствовать большему, чем многие посредственные проекты, это еще более верно в тех случаях, когда вы пытаетесь развернуть инструменты и рабочие процессы для всей организации (незавершенный организационный процесс здесь действуют ограничения!)

5. Не наносите ударов орды. Между централизованными командами по контролю качества и командами, которые они поддерживают, существует фундаментальное противоречие. Часто бывает, что существует глобально оптимальный подход, который предпочитает централизованная команда, которая сильно раздражает подмножество команд, которые работают над нетипичными доменами или рабочими нагрузками. Одним из характерных примеров является компания, пишущая свои серверы на JavaScript и не позволяющая своим инженерам по машинному обучению использовать экосистему Python, потому что они не хотят поддерживать две экосистемы. Другой случай — компания, стандартизированная для использования REST / HTTP2 / JSON для всех API, где конкретная команда хочет использовать вместо этого gRPC.

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

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

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

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

Программа качества

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

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

Операционные организационные программы — это обширная тема, о которой много написано, но основной подход таков:

1. Определите спонсора программы. Вы не можете изменить поведение организации без уполномоченного спонсора. Организации ведут себя так, как они делают, потому что это оптимальное решение их текущих ограничений, и вы не можете преодолеть эти ограничения без поддержки кого-то могущественного.
2. Создание устойчивых воспроизводимых показателей. Часто люди, выполняющие программу, тратят четыре с лишним часа в неделю на поддержание набора данных вручную. Это не работает. В ваших данных будут дыры, вы не сможете интегрировать свои данные с автоматизацией на более поздних этапах, и у вас закончится энергия, чтобы выполнить работу, чтобы произвести реальные изменения; refreshing a metrics dashboard has no inherent value.
3. Identify program goals for every impacted team and a clear path for them to accomplish those goals. Your program has to identify specific goals for each impacted teamfor example, reducing test flakiness in their tests or closing incident remediations more quickly. However, it’s essential that you provide the map to success! So many programs make a demand of teams without providing direction on how to accomplish those goals. The program owner is the subject matter expert, don’t offload your strategy to every team to independently reinvent.
4. Build the tools and documentation to support teams towards their goals. Once you’ve identified a clear path for teams to accomplish towards your program goals, figure out how you can help them make those changes! This might be providing “golden examples” of what things ought to look like, or even better, an example pull request refactoring a challenging section of code into the new pattern. It might be providing a test script to verify the migration worked correctly. It might be auto-generated the conversion commit to test, verify, and merge without having to write it themselves. Do as much as you possibly can to avoid every team having to deeply understand the problem space you’re attempting to make progress in.

5. Create a goal dashboard and share it widely. Once you have your program goals communicated to each team, you have to provide dashboards that help them understand their current state, their goal, and give reinforcing feedback on their (hopeful) progress along the way. The best dashboard is going to be both a scorecard for each team’s work and also provide breadcrumbs for each team on where to focus their next efforts.

   There are three distinct zoom-levels that your dashboard should support. The fully zoomed-out level helps you evaluate your program’s impact. The fully zoomed-in level helps an individual team understand their remaining work. A third level between the two helps organizational leaders hold their teams accountable (and to support your program sponsor in making concrete, specific asks to hold those leaders accountable).

6. Send programmatic nudges for folks behind on their goals. Folks are busy. They won’t always prioritize your program’s goals. Alternatively, they might do an amazing job of making your requested improvements but backtrack later with deprecated practices. Use nudges to direct the attention of teams towards the next work they should take towards your program’s goals. Remember, attention is a scarce resource! If you waste folks times with a nudge email or ping, they won’t pay attention to the next one.
7. Periodically review program status with your sponsor. Programs are trying to make progress on an organizational priority that doesn’t naturally align with the teams’ goals. Many teams struggle to break from their local prioritization to accomplish global priorities. This is where it’s essential to review your overall progress with your sponsor and point them towards the teams that prioritize program work. Effectively leveraging your sponsor to bridge misaligned prioritization will be essential to your success.

In a lot of ways, a program is just an endless migration, and the techniques that apply to migrations work for programs as well.

If you get all of those steps right, you’re running a genuinely great program. This might feel like a lot of work, and wow, it is: a lot of programs go wrong. The three leading causes of failed programs are:

1. running it purely from a process perspective and becoming detached from how the reality of what you’re trying to accomplish,
2. running it purely from a technical perspective and thinking that you can skip the essential steps of advocating for your goal and listening to the folks you’re trying to motivate,
3. trying to cover both perspectives as a single person–don’t go it alone!

A bad program is a lot like an inefficient non-profit: the goal is right, but few funds reach the intended goal. No matter how you decide to measure technical quality, the most important thing to always remember when running your quality program is that the program isn’t the goal. The goal is creating technical quality. Organizational programs are massive and build so much momentum that inertia propels them forward long after they’ve stopped working. Keep your program lean enough to cancel, and remain self-critical enough to cancel it ceases driving quality creation.

Start small and add slowly

When you realize your actual technical quality has fallen considerably behind your target technical quality, the natural first reaction is to panic and start rolling out a vast array of techniques and solutions. Dumping all your ingredients into the pot, inevitably, doesn’t work well, and worse, you don’t even know which parts to keep.

If you find yourself struggling with technical quality–and we all do, frequently–then start with something small, and iterate on it until it works. Then add another technique, iterate on that too. Slowly build towards something that genuinely works, even if it means weathering accusations of not moving fast enough. When it comes to complex systems and interdependencies, moving quickly is just optics, it’s moving slowly that gets the job done.