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

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

Важность способности объяснять сложные технические аспекты простым языком обусловлена необходимостью эффективной коммуникации между IT и бизнесом. Опытные разработчики (миддл и сеньор) должны уметь излагать смысл своей деятельности, трудности, с которыми они сталкиваются, и обосновывать выбор решений, потому что: 1) это помогает бизнесу понимать ценность и стоимость технических решений; 2) предотвращает накопление технического долга из-за непонимания логической структуры системы; 3) современное программирование становится более верхнеуровневым и близким к человекопонятному языку, поэтому это должно быть проще. В тексте прямо указано, что это «the must», особенно учитывая, что части технического долга возникают из-за несостыковок в логической продуманности системы.

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

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

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

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

Показатель SPI (Schedule Performance Index) из методики EVM не подходит для оценки соблюдения сроков завершённых проектов, так как по окончании проекта, даже с большим запозданием, весь первоначальный объём считается освоенным, и значение SPI автоматически становится равным единице. Это приводит к тому, что SPI не отражает реальное отставание по срокам выполнения проекта. Например, при измерении проекта рытья канавы, когда работы завершаются с задержкой, SPI в конце проекта станет 100%, несмотря на то, что работа была выполнена дольше запланированного срока.

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

При создании новой услуги запускаются потоки, связанные с этапами Offer и Agree путешествия заказчика. В рамках этапа Offer происходит сбор требований к услуге, который осуществляется в виде деятельности потока Engage. На этапе Agree происходит согласование и фиксация новых условий услуги и требований к уровню обслуживания в соглашении (SLA). Эти потоки запускаются в ответ на спрос, предъявляемый заказчиком, который определяет требования к новой услуге или изменению существующей.