[1/2] Behavioral Interview Discussion with Ex-Meta Hiring Committee Member (Рубрика #Management)

Интересное обсуждение поведенческих интервью в бигтех компаниях. Оно само выполнено в виде интервью, которое берет Stefan Mai у Austen McDonald, бывшего senior engineering manager в Meta, а также члена комитета по найму там же. Собственно, в этом интервью Остин делится своим опытом и рассказывает свои мысли относительно поведенческих интервью. Мне эта запись понравилась, так как я часто сам провожу интервью инженеров и руководителей и знаю о чем речь не понаслышке.
Вот что я вынес для себя из этого интервью
1) Остин считает, что поведенческие интервью требуют тщательной подготовки, причем подготовка дает возможность стать лучшим инженером в будущем из-за глубокой рефлексии об опыте и достижениях в прошлых проектах. Мне кажется, что навыки рефлексии - это ключ к ежедневному росту над собой, но это обычно не слишком приятно, поэтому люди избегают таких размышлений, а подготовка к интервью помогает им найти силы для этого дела
2) Поведенческие интервью важных для высоких грейдов, как инженерных, так и менеджерских. Компании оценивают прошлые успехи и поведение и используют это как экстраполяцию будущих результатов кандидата
3) Поведенческие интервью варьируются в зависимости от грейда, в приведенном видео Остин приводит примеры таких различий
4) У компаний есть критерии для оценки кандидатов, например, инициативность, настойчивость, ...
5) Крупные компании стремятся уйти от субъективных решений, поэтому формализуют критерии оценки
6) Как и всегда первое впечатление очень важно, поэтому важно правильно начать интервью и не обосраться. Автор рекомендует подготовить ответы на вопросы, которые с большой вероятностью будут заданы в начале интервью: "Расскажи о себе", "Расскажи о своем любимом проекте". Ответы на эти вопросы позволят задать првильный тон всей встрече.
7) Часто для проведения интервью используют стандартные схемы, например, STAR (Situation - Tasks - Actions - Results) или CARL (Context - Actions - Results - Learning), причем Остину нравится CARL больше STAR за счет последнего пункта про извлеченные уроки, а также он рекомендует меньше тратить времени на рассказ о контексте и больше на само действие и результаты
8 ) Стандартизированный подход (STAR / CARL / ваш любимый) может мешать непринужденной беседе и выглядеть неестественно, это решается тренировкой интервьюеров

Продолжение рассказа во втором посте.

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

[2/2] Behavioral Interview Discussion with Ex-Meta Hiring Committee Member (Рубрика #Management)

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

9) Кандидатам важно уметь правильно презентовать свой опыт, а для этого важно понимать свои достижения и проекты, а также соотнести свои проекты с ценностями компании
10) Важно правильно выбирать проекты для рассказа. Например, автор рекомендует делить проекты по личному участию, влиянию на бизнес и масштабу. Важно, чтобы о выбранных проектах можно было интересно рассказать (рассказ об унылом проекте вгоняет интервьюера в депрессию)
11) На интервью часто задают вопросы об совершенных ошибках. Не стоит отвечать, что их не было - все люди ошибаются, но хорошие кандидаты признают ошибки и учаться на них (а лучшие учатся еще и на чужих ошибка)
12) Помимо ошибок интервьюер может спросить про слабости кандидата. Не стоит отвечать на них, что их нет или "Я - трудоголик", важно признавать свои слабости, а если еще рассказать про извлеченные из них уроки, то будет еще лучше. Но для интервьера важна честность и искренность, наигранные рассказы не принесут вистов
13) При подготовке к интервью важно подумать о том, а как показать, что вы подходите команде и решаете похожие задачи и сможете принести пользу новой компании. Лучше всего показать это через то, чтобы показать как вы добились реальных результатов на прошлом месте и принесли пользу бизнесу
14) При подготовке к интервью будьте готовы рассказать о себе, любимом проекте, а также конфликтной ситуации. В принципе, можно подготовить еще набор историй, привязанных к ценностям компании, а также отсортированных по масштабу, личному участию и импакту. Это поможет вам на интервью проще подбирать примеры из своего опыта под вопросы интервьюера
15) В конце интервью часто есть время на то, чтобы задать вопросы интервьюеру - это важный момент для того, чтобы продемонстировать интересе к компании и команде (если вас смотрят в конкретную команду), например можно задать вопросы про
- О развитии отдела и технологий
- О стиле управления нанимающего менеджера и динамике команды

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

P.S.
Я как-то рассказывл про то, как мы нанимаем
- Технических руководителей
- Staff+ инженеров
В принципе, многие советы Остина полезны и для подготовки к нашим интервью.

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

Digital Nudge (Рубрика #Management)

Полгода назад мне подарили эту книгу, но прочитал я ее на днях. В ней Fabio Pereira рассказывает про базовые принципы поведенческой экономики, которые могут быть применены в цифровом миру для тонкого влияния на решения и поведение пользователей. Автор вводит концепцию digital nudging или цифрового подталкивания, которая представляет собой использование тонких элементов дизайна, информации и взаимодействия в цифровой среде для управления поведением пользователей без ограничения их свободы выбора. По-факту, это адаптация nudge theory Ричарда Талера и Касса Састейна из книги "Nudge". Правда, digital nudge адаптирован к цифровому контексту, например, веб-сайтам, приложениям или онлайн-платформам, и используют элементы интерфейса, такие как настройки по умолчанию, визуальные подсказки, персонализированные рекомендации и своевременные уведомления для влияния на принятие решений.

Оснонвые идеи книги
1) Choice architecture (архитектура выбора): То, как представлены варианты выбора в цифровой среде, может существенно влиять на поведение пользователей. Например, настройки по умолчанию (например, автоматическое продление подписок) часто направляют пользователей к определенным действиям.
2) Behavioral triggers (психологические триггеры): Цифровые "подталкивания" опираются на психологические принципы, такие как социальное доказательство (например, отзывы пользователей), дефицит (например, "Осталось всего 3 товара") и избегание потерь для стимулирования желаемого поведения.
3) Personalization (персонализация): "Подталкивания" могут быть адаптированы на основе данных о пользователях, таких как предпочтения или действия в реальном времени, для повышения их эффективности.
4) Low-cost interventions (дешевые интервенции): Цифровые "подталкивания" недороги и минимально навязчивы, что делает их масштабируемым решением для влияния на поведение в разных областях

Автор приводит большой список примеров использования digital nudges
- Электронная коммерция: Выделение ограниченных по времени предложений или персонализированных рекомендаций для увеличения продаж.
- Здоровье и фитнес: Стимулирование более здорового образа жизни или регулярных тренировок через напоминания и элементы геймификации.
- Продуктивность на работе: Подталкивание сотрудников к выполнению задач или освоению новых инструментов с помощью целевых уведомлений.
- Образование: Повышение вовлеченности студентов с помощью интерактивных учебных материалов и функций отслеживания прогресса.

Эта книга связана с другими
- "Nudge: Improving Decisions About Health, Wealth, and Happiness" Ричарда Талера и Касса Санстейна — основополагающая работа о теории "подталкивания".
- "Hooked: How to Build Habit-Forming Products" ("На крючке") - эта книга Нира Эяля о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. Я про нее уже рассказывал
- "Thinking, Fast and Slow" ("Думай медленно... решай быстро") Даниэля Канемана — исследует психологические системы принятия решений. Я про нее уже рассказывал
- "Predictably Irrational" ("Предсказуемая иррациональность") Дэна Ариели — объясняет, почему люди принимают иррациональные решения и как на них можно влиять.Я про нее уже рассказывал
- "Inside the Nudge Unit" Дэвида Хэлперна — о практическом применении теории "подталкивания" в государственной политике.
- "Misbehaving: The Making of Behavioral Economics" Ричарда Талера — рассказывает о развитии поведенческой экономики как научной дисциплины.
Эти книги предоставляют более глубокое понимание поведенческой экономики и науки о принятии решений, дополняя темы из Digital Nudge.
А вообще, сама книга "Digital nudge" очень простая и легкая, а поэтому хорошо подходит для того, чтобы познакомиться с этой темой.

P.S.
Я уже рассказывал про пару выступлений Фабио конференциях, из которых можно сложить отличное представление о самой концепции digital nudge
- The Psychology of UX
- Infobesity - How to Cope with the Overload of Information

#Thinking #PopularScience #SelfDevelopment #Brain #Economics #Psychology

Research Insights Made Simple #8 "Measuring developer goals" (Рубрика #DevEx)

В этом выпуске подкаста про инсайты ко мне в гости пришел Александр Кусургашев для того, чтобы поговорить про гугловую статью "Measuring developer goals":) Александр работает в Т-Банке в подразделении Core Tech и занимается развитием нашей внутренней платформы разработки. Он верит в законы физики, платформизацию и пользу от переиспользования. Для него важно, чтобы IT системы Т-Банка работали эффективно - от уровня физической инфраструктуры до конечных сервисов для потребителей. Большую часть своей IT карьеры Саша провел разрабатывая платформенные решения для low latency и ultra low latency electronic trading.

За время подкаста мы обсудили темы:
- Опыт работы Саши и его зона ответственности в Т-Банке
- Обсуждение critical user journeys для определения измеримых и объективных целей инженеров
- Гранулярность и декомпозиция целей
- Комплексный подход к оптимизации
- Важность систематического процесса выделения целей
- Эволюция обратной связи в опросах Engineering Satisfaction Survey
- Переход от инструментов к целям
- Измерение метрик и мониторинг процессов
- Вариативность инструментов и сложность стандартизации
- Научный подход к улучшению процессов

Выпуск доступен на Youtube, VK, Podster.fm, Ya Music

P.S.
Я уже разбирал этот whitepaper полгода назад.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Как я чувствую себя, когда иду на работу ... А вообще это обычный поход моего младшего сына в сад.

10 Developer Productivity Boosts from Generative AI (Рубрика #DevEx)

Глянул очередное интересное и короткое видео от Martin Keen, IBM Fellow, который за много лет в IBM проявил себя как изобретатель (больше 400 патентов), технический руководитель, исследователь в AI, а также создатель контента на канале IBM Technology. В этом видео Мартин рассказывает про то, как Gen AI может помочь повысить продуктивность разработчиков, а я про эту тему рассказывал много и подробно раньше, например, в последнем докладе про то, как и зачем мерить developer productivity. Но давайте вернемся к мыслям Мартина

1) Elemenating repetitive tasks. Генеративный ИИ может помочь исключить повторяющиеся задачи, ускоряя рутинную работу.
2) Natural language interface. Интерфейс на естественном языке позволяет запрашивать генерацию кода и контроль версий.
3) Code suggestions. Подсказки помогают начать работу с незнакомыми библиотеками и пакетами.
4) Code improvements. Это улучшения для устранения избыточных и неэффективных частей кода, почти как при pair programming, но где пару составляет AI ассистент
5) Code translation. Трансляции кода с одного языка на другой, которая может быть полезна для масшабной миграции, например, со Scala на Java/Kotlin
6) Code testing. ИИ может создавать тестовые сценарии и оценивать результаты.
7) Bug detection. Автоматическая идентификация и даже исправление багов
😍 Personalized dev environment. Как я понял это история про тюнинг IDE и других инструментов под стиль разработчика
9) Generation documentation. Генерация документации на основе кода

В конце автор говорит о том, что сейчас Gen AI скорее не замена разработчика, а помощь для расширения его возможностей. Это хорошо перекликается с мыслями из статьи "What Do Developers Want From AI?", про которую я рассказывал раньше.

P.S.
Автор не забыл про десятый пункт - он предложил зрителем самим написать в комментах:)

P.P.S.
У Мартина есть интересное видео про тренды AI в 2025 году, про которое я уже писал в канале.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

CTO Conf X (Рубрика #Management)

В этом году пройдет CTO Conf X, первая профессиональная конференция для технических директоров, от компании "Онтико". Я много выступал на других конференциях этой компании, например, Highload++, Teamlead Conf, Teachlead Conf, а теперь вошел в программный комитет этой новой конференции. Мы в программном комитете долго обсуждали какие доклады будут полезны посетителям конференции и получилось следующее
- Как CTO быть партнером бизнесу, а не просто исполнителем
- Как CTO создавать и актуализировать технологическую стратегию
- Как не утонуть в операционке и уделять еще время стратегии и тактике
- Как управлять командами разработки на масштабе (когда помнить все про всех уже не возможно)
- Как и зачем появляются внутренние платформы разработки (IDP) внутри компаний
- Как CTO смотрят на использование AI в SDLC (Software Development Life Cycle)

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

P.S.
Интересно, что еще до появления этой конференции я часто сам рассказывал доклады, которые могли бы присутствовать на ней:
- Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - Highload++ 2021
- Как нанимать технических руководителей - Teamlead Conf 2023
- Эволюция роли технического руководителя от инженера до CTO - SouthHub 2022
- Как формировать структуру команд под запросы бизнеса - YaTalks 2023
- Как и зачем измерять инженерную продуктивность в крупной компании - MTS True Tech Days 2024

#Management #Leadership #Strategy #PlatformEngineering #Engineering #Software #Architecture

Gartner 2024 Hype Cycle for Emerging Technologies (Рубрика #Management)

Недавно столкнулся с картинкой из отчета "Gartner Hype Cycle™ for Emerging Technologies", что вышел летом прошлого года. Несмотря на то, что это по большей части маркетинг Gartner как тренд сеттера в технологиях, часто бывает интересно глянуть отчет и посмотреть, а что в нем есть кроме красивой картинки. Конкретно в этом отчете перечислены 25 прорывных технологий, сгруппированных в самые хайповые темы Autonomous AI (автономный ИИ), Developer Productivity (продуктивность разработчиков), Total Experience (общий опыт), and Human-Centric Security and Privacy (ориентированная на человека безопасность и конфиденциальность). Именно эти темы будут определять будущее бизнеса и технологий в ближайшие годы по мнению Gartner

1. Autonomous AI (автономный ИИ)
Здесь фокус на развитии ИИ-систем, способных выполнять задачи с минимальным участием человека. Эта тема включает в себя такие технологии, как мультиагентные системы, обучение с подкреплением, гуманоидные роботы и machine customers. Для бизнес это означает переход к системам ИИ, которые могут динамически взаимодействовать с окружающей средой и принимать решения в сложных сценариях.

2. Developer Productivity (продуктивность разработчиков)
Здесь объединены инструменты и подходы для повышения эффективности работы разработчиков. Основные технологии: ИИ для поддержки разработки ПО, GitOps, prompt engineering и внутренние порталы для разработчиков. Цель — создать условия для "потока" в работе разработчиков, улучшая их удовлетворенность, сотрудничество и качество результатов. Я на эту тему много уже писал на канале, например, "Как и зачем измерять инженерную продуктивность в крупной компании"

3. Total Experience (общий опыт)
Этот пункт объединяет стратегии клиентского опыта (CX), опыта сотрудников (EX), пользовательского опыта (UX) и многоканального взаимодействия (MX). Здесь авторы говорят про такие технологии, как цифровые двойники клиентов, пространственные вычисления, суперприложения и 6G. Здесь цель в том, чтобы обеспечить бесшовное взаимодействие на всех точках контакта для повышения удовлетворенности, лояльности и вовлеченности.

4. Human-Centric Security and Privacy (ориентированная на человека безопасность и конфиденциальность)
Эта тема направлена на создание доверия за счет мер безопасности, которые учитывают пользовательский опыт и совместное управление рисками. Конкретные технологии такие: AI TRISM (управление доверием, рисками и безопасностью ИИ), цифровые иммунные системы и архитектура сетевой безопасности. Здесь поощряется прозрачность, этичность и проактивное выявление угроз для повышения устойчивости организаций.

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

#Strategy #Management #Leadership

Картинка с самим Gartner 2024 Hype Cycle for Emerging Technologies

[1/2] The Mythical Man-Month (Мифический человеко-месяц) (Рубрика #Management)

Эта книга Фредерика Брукса была впервые издана 50 лет назад, в 1975 года, но она до сих пор переиздается, а цитаты из нее стали классическими. Я решил вспомнить про нее к юбилею и посмотреть насколько она еще актуальна.

В заглавие книги вынесена идея о том, что "добавление сотрудников в отстающий проект только увеличивает задержки" из-за роста коммуникационных издержек, времени на адаптацию новых членов команды и неделимости некоторых задач. Брукс критикует ошибочное предположение, что труд (измеряемый в "человеко-месяцах") можно масштабировать линейно, сравнивая это с невозможностью девяти женщин родить ребенка за один месяц. Это относится к области управления проектом/продуктом и так же актуально, как было 50 лет назад. Еще он подчеркивает важность концептуальной целостности - согласованной архитектуры системы под руководством единого видения - для предотвращения хаоса, вызванного "проектированием при помощи комитетов". Этот тезис относится к проектированию софта. Следующая ключевая идея относится к "эффекту второй системы" (перегрузка сложностью при создании следующей версии). Вот эта проблема кажется уже решена, так как продукты часто сейчас строятся итеративно и понятие версии системы вообще размывается:) Ну и последняя идея, которую стоит отметить - это различие между essential complexity (существенной сложностью, что присуща задаче) и accidental complexity (случайной сложностью, которая возникает из-за неэффективных инструментов или процессов).

Если провести параллели между разработкой во времена Брукса (1970-е годы и засилье мейнфреймов), то мы получим следующее

1) Закон Брукса vs Agile и гибридной работы
- Agile подходы снижают риск неожиданностей и даже работая проектно мы на поздних стадиях получаем меньше рисков, это соответствует мыслям Брукса о важности прототипирования в больших проектах
- Гибридная работа - современные инструменты (GitHub, Jira, Slack) снижают барьеры для коммуникаций, но правило про квадратичный рост затрат на коммуникацию от роста команды никуда не девается (помним, что в полном графе n*(n-1)/2 связей)
- Брукс рекомендовал использовать локализованные "хирургические команды", а у нас теперь есть two-pizza teams
2) Модульность и мокросервисы
- У Брукса вызывала опасения монолитная система, что они делали для мейнфрейма, но в наше время у нас пронеслись перед глазами SOA, микросервисы, FaaS и теперь людям монолит уже не кажется таким плохим вариантом для старта
- По-факту, нам нужна модульность нашего кода, а как он разворачивается можно решить потом (условно модульный монолит можно нормально разделить на отдельные микросервисы при необходимости)
3) Инструменты против человеческого фактора
- Одна из ключевых мыслей Брукса была про то, что серебрянной пули для повышения производительности разработки нет
- Но мы видим, что хорошие инженерные практики постепенно повышали продуктивность инженеров - речь про CI/CD и всю автоматизацию
- А сейчас мы живем во время, когда щепотка AI, добавленная в SDLC (software development life cycle) навроде GitHub Copilot обещает в будущем грандиозный эффект (если LLM продолжат также прогрессировать)
- Но пока мы все еще видим AI в качестве ассистента, а значит нам нужно обращать внимание на человеческий фактор, тут есть классная колонка про "Human approach to developer productivity" от Google, про которую я уже рассказывал раньше

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

#Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps

Предпоказ спектакля «Лукич» в Мельник центре (Рубрика #ForKids)

Вчера днем мы были на детской постановке "Лукич" на сцене "Мельников". Это было новое прочтение «Чиполлино» для детей 6+, но мы взяли с собой четерехлетного и девятилетнего сына - обоим понравилось. Нам с женой постановка тоже показалась интересной, так как юмор был двухуровневым - детишки смеялись над гэгами и поведением героев, а взрослые на отсылки к окружающей реальности или намеки на романтические взаимоотношения овощей. Сам спектакль был в двух частях. В первом акте принц Лимон и рыцарь Помидор захватили власть в саду, а остальные овощи с переменным успехом боролись с ними. Второй акт начинается с того, что Лукич и другие овощи оказались за решеткой, но Черешенка, замотивированный Клубничкой, отправился их спасать ... В общем, постановка была авангардной, включала музыку, шутки и вообще смотрелась бодро и динамично. Главное, что детишки были в восторге и классно провели время, а родители тоже не скучали.

#ForKids #ForParents #Culture

[2/2] The Mythical Man-Month (Мифический человеко-месяц)

Продолжая рассказ про классическую книгу Брукса (1 и 2), расскажу про то, в какую сторону его идеи можно развивать сейчас

1) Для профилактики задержек в графике сдачи проекта
- Не стоит копить техдолг, который выстрелит ближе к сдаче проекта
- Не стоит использовать мифические человеко-месяцы, а взять метрики реальной производительности: cycle time, throughput и другие
2) Архитектурные принципы
- Стоит поддерживать концептуальную целостность с самого начала проекта - я бы тут предложил использовать RFC (request for comments) для обсуждения архитектурных вопросов, решения фиксировать в ADR (architecture decision records). Я про это как-то рассказывал в докладе про масштабирование архитектурных процессов лет 5 назад
- Также стоит инвестировать в документацию, положить ее поближе к коду и максимально автоматизировать
3) Коммуникации
- Желательно сократить по максимуму встреча, а те что исчезли перевести в асинхронный режим, а значить писать больше документов и комментить их асинхронно
- Выделять сфокусированное время для работы - это позволит не рвать поток работа (flow state)
4) Масштабирование команд
- Здесь я просто рекомендую глянуть подход из Team Topologies, который хорошо описывать типа команд и форматы их взаимодействия. Про эту книгу я много рассказывал и даже разбирал в первой серии подкаста Code of Leadership вместе со Стасом Халупом, моим бывшим коллегой
- По-факту, тут получается 2 основных типа команд: stream-aligned и platform. Первая наносит бизнесовую пользу, а вторая делает платформенные инструменты, что используют stream-aligned команды
- Ну и важно учитывать числа Донбара для понимания границ масштабирования из-за накладных расходов на коммуникации

Если подводить итоги, то книга Брукса до сих пор не устарела и может быть применена к современным проблемам. Несмотря на то что Agile и DevOps решают проблемы *случайной сложности*, его предупреждения о перегрузке ресурсами и фрагментации дизайна остаются актуальными. Команды достигают устойчивой продуктивности благодаря балансу автоматизации и процессов, ориентированных на людей — подтверждая взгляд Брукса на разработку ПО как на процесс, прежде всего зависящий от человеческого фактора. В условиях роста масштабов распределенных систем возвращение к идеям *Мифического человеко-месяца* предлагает как предостережения, так и вдохновение: инструменты меняются, но динамика команд определяет успех проекта.

#Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps

#60 – Agile Metrics (Рубрика #Management)

Наткнулся тут на очередной комикс от Comic Agile на этот раз на тему метрик, которая является очень интересной. Авторы комикса заслуженно иронизируют над velocity, burndown, predictability, lead time и business value, обыгрывая стандартные способы покраски этот метрик в зеленый. Дальше они отмечают, что эти метрики могут помогать с идентификацией зон для улучшений, но по их скромному мнению есть 2 метрики, что стоит мерить
- NPS (net promoter score) - удовлетверенность клиентов
- The hapiness of team members - удовлетворенность членов команды
Забавно, что NPS - это супер-общая метрика, которую сейчас берут все и используют по принципу "не знаешь что показывать по продукту - покажи NPS". А вторую метрику авторы предлагают мерить при помощи Spotify Squad Health Check, про который я рассказывал раньше (1 и 2). Интересно, что эти метрики как и остальные приведенные в обсуждении могут быть испорчены, например, продукт есть и пользователи им довольны, команда тоже довольна своей работой, только фичи не катятся - а смысл напрягаться, когда NPS высокий:) Но дальше авторы говорят коронную фразу про outcome

We must remember that working agile is a means to an end and not the goal, itself. Therefore, thinking about what outcome we want by working agile is what we should measure.

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

#Management #Leadership #Engineering #Software #Metrics