Опыт подготовки к сертификации Professional Scrum Master II (Scrum.org)
Привет всем, хотел рассказать о материалах при подготовке к сертификации PSM II от Scrum.org. Буду очень рад, если поделитесь своим опытом тоже 🙂
Sidenote: если вы апологет движения «сертификаты потеряли свою ценность» — я с вами соглашусь. И в отношении PSM I всё довольно просто — сертификация говорит что вы понимаете как работает фреймворк в общих чертах. В PSM II уже идёт работа с набранным в бою опытом применения скрама, потому она (сертификация) серьёзнее. Но ничего сверхъестественного в этом экзамене тоже нет. Кстати, сейчас в мире 6793 PSM II обладателей.
Подготовка к PSM II
Как писал Denis Salnikov, хорошо будет пройти Scrum.org open assesments перед сдачей несколько раз на 100%
Какие-то другие тесты надо проходить осторожно. В интернете довольно много подготовительных тестов: некоторые из них несколько PMBoK уклона, что норм для PMI-ACP, но другие прям адово извращают саму суть скрама, вводят какие-то новые роли, занимаются всяческим саботажем того, что вы практикуете к моменту подготовки к PSM II — берегите себя.
Коучинг, книжки, тренерство
Lyssa Adkins: Coaching Agile Teams — довольно лёгкая и универсальная книга небольших рецептов, затрагивающая роль agile coach / scrum master’a как фасилитатора, коуча, учителя. Прекрасно ложится на ваш персональный опыт, дополняя его.
Есть небольшой раздел по конфликтам, тоже описано довольно просто. Кстати говоря, хорошо (я бы сказал отлично) идёт с тренингами ICAgile: ATF (Agile Team Facilitator), ICAgile: ACC (Certified Agile Coaching). Во многих отзывах кричат про воду в книге: на самом деле это не вода, а просто в контексте опыта работающие рецепты. Без опыта там действительно довольно водно читается.
Gunther Verheyen’s Scrum Pocket Guide — это просто must-книжка, к которой время от времени возвращаешься после прочтения, потому что она очень хорошо раскладывает agile принципы, scrum события, роли, артефакты. В сдаче PSM II обязательно понимание Scrum Values и Agile Principles. А еще у вас от зубов отскакивать должно понимание какие есть события и кто на них приходит, хоть ночью вас разбуди. Короче, карманный справочник на все случаи жизни.
Путь Scrum-мастера за авторством Зузанны Шоховой. МИФ перевод норм, но лучше в оргиниале 🙂 Векторы развития SM, разные ипостаси SM, сервис scrum-мастера для организации, всё это тут.
8 Ролей scrum-мастера (8 stances of scrum master, это брошюрка от Барри Овериима о том, какие роли играет (может играть) scrum-мастер — это прям кладезь косвенных ответов на вопросы в PSM II и в целом в вашей саморефлексирующейся scrum-мастер-карьере. Так как понимание того, кем является SM бывает правильное и неправильное. И при неправильном раскладе, ожидают от SM совсем не того, о чем написано в гайде.
Serious Scrum blog — коллективный блог от корифеев индустрии, с прояснениями нетривиальных ситуаций и разбором многих пониманий.
Actionable Agile Metrics — просто хорошо почитать про метрики книжку.
Тренинги — хотя бы на каком-то базовом уровне вы должны лично прощупать роль scrum-мастера как тренера на уровне команд, специалистов, или целой организации. Ведете ли вы воркшоп по визуализации потока, или сессию по парному дебаггингу у девопсов, или в течении нескольких часов рассказываете про основы скрама — не важно. Важно, что у вас копится опыт бытовых примеров проявления ценностей, поведения команд в разных условиях, и ускоряется цикл обратной связи.
Cynefin
Важно быть знакомой (-ым) с фрейворком Дейва Сноудена для принятия решений в разных типах систем. Серебряных пуль не бывает.
Long Story Short: есть алгоритм принятия решений в зависимости от запутанности системы. И разложил (всё еще раскладывает) по полочкам валлиец Дейв Сноуден. Когда допетрите более менее до основ, очень советую поискать его категоризацию внутри хаотичного квадранта. Это прям еще один микромир внутри 🙂
Technical Excellency Foundations
Возможно, такое количество литературы и не нужно. По факту, нужно понимать те или иные подходы (пусть и неглубоко) с точки зрения того, что они глубоко наследуют сами принципы Agile-манифеста. Опять же, необязательно знать все детали, надо понимать Agile-ценности, лежащие в основе.
DevOps
Нужно понимать mindset, понимать что автоматизация и упаковывание рутинных вещей в шаблоны, которые не зависят от потенциальной косолапости — это фактор митигации риска. Понимать что такое (да и к вашему опыту в IT это точно уже известно, если вы решили на PSM II придя из айти отрасли сдать) Continuous Delivery, Deployment, вот это всё.
Хочется заметить, что зачастую в организациях DevOps это специалист. Не забываем что это про mindset. И всегда связываем это с кросс-функциональностью в рамках команды. DevOps mindset у разработчиков (не зря же Dev+Ops) учит новому, формирует полезный опыт, позволяет команде покрывать весь бизнес-процесс для доставки клиенту целиком. Отдельные DevOps команды это скорее скатывание в функциональные колодцы (и компонентный отдел). Лучше встройте таких специалистов в каждую команду, или прокачивайте экспертизу у самой команды разработки.
^^ в целом как и с любой инженерной практикой, надо просто видеть исток самих принципов гибкого мышления, и эпирицизма. Не нужно много допетривать: любая итеративность, если потом делаются выводы и ситуация исправляется — всегда хорошо. Любая автоматизация рутины, с защитой от дурака — хорошо. Чем раньше видим проблемы — тем лучше.
Evidence-Based Management
На самом деле, скорее всего глубоких вопросов тут ждать не стоит, от scrum.org недавно относительно только вышел гайд по теме. Но, это работа с метриками и пониманием положения компании на рынке. Если вы проходили от ICAgile тренинги по Business Agility, или просто коучите / знакомы с темой, покажется всё довольно простым и логичным. По сути этот топик пытается ответить на вопросы как правильнее измерить улучшение результатов команды, скорость доставки, и увязать это с рыночными нишами и потенциально упущенной выгодой.
Maturity-модели
PALe maturity canvas конкретно зубрить точно не надо, не тот калибр. Но, к моменту сдачи PSM II / A-CSM круто в общих чертах понимать Maturity-модели (KMM, Scrum Maturity Model, Agile Leadership Maturity). Это поможет вам же сделать маппинг вашей организации на уровень взрослости. Всегда приятно порефлексировать 🙂 Если знакомы со спиральной динамикой — она тоже хорошо дополняет понимание уровней гибкости и выживаемости компаний.
Kanban-практики
Kanban for Scrum Teams (тут вот в позапрошлом году гайд подоспел), ну или в моём случае KMP II помог (спасибо Пикулеву и Пименову). Понимание принципов работы с потоком, смысла ограничений на работу в прогрессе, ценности завершения работ, вреда 100% утилизации.
Наметился тренд вовсю использовать системный подход, в канбане он чуть ли не в основе лежит, в скраме он менее явный (ибо в скраме как во фреймворке такие конкретные вещи не регламентируются). Так вот системное мышление, системный подход, теория ограничений, теория очередней (системы массового обслуживания, помним такое?), проблемы локальной оптимизации.
Ах, да. Канбан еще знакомит более формально с такими метриками как Cycle Time, Lead Time, а потом, CFD, Spectral Analysis Chart. На практике многие команды довольствуются только своими burndown и моляться только на них, безальтернативно — важно расширять используемые графики и инструменты.
Если вы играли в featureban / get kanban / changeban (кстати говоря ребята из reg.ru (Артур Нек) / setronica (Женя Степченко) шикарно проводят игры, если вы зарулите в Новосибушку) — то многие термины и графики для вас знакомы.
Масштабируемые фреймворки: Less, SAFe, Nexus (ну и для некоторых DaD :).
Nexus guide как минимум и материалы по нему от самого scrum.org. В целом Nexus понять проще всего, потому что этот тот же скрам, с небольшими масштабируемыми дополнениями.
SAFe — хотя бы посмотреть базовые видео с объяснениями, потому что это самый популярный Enterprise Agile фреймворк в мире.
LeSS / LeSS Huge — потому что это ощутимо более легковесный чем SAFe, но при этом намного более популярный (чем Nexus) и интуитивный фреймворк без миллиона ролей и с теми же ценностями, что и в простом Scrum.
DaD (Disciplined Agile Delivery) — если вы живете в PMBoK мире 🙂
Заметочка: масштабировать, судя по nexus, можно если у вас 2 или больше команд.
У меня большого опыта с масштабированием нет, поэтому больше не напишу.
Вдогонку, что не менее важно
Опыт и только опыт: приципы понимания и формирования Цели Спринта (Sprint Goal), Definition of Done, понимания что имеют ввиду когда говорят Definition of Ready (хоть это и неофициальный термин). Как работать с командой, чтобы сформировать эти вспомогательные для прозрачности артефактов сущности.
Туда же и относятся события скрама, зачем и как фасилитировать, кого можно звать, какой ивент даёт формальную возможность адаптироваться для тех или иных вещей.
Понимание способов упорядивания задач в Бэклоге. Именно упорядочивания (начиная с Scrum Guide 2017), а не приоретизации, как раньше. Потому что можно приоретизировать по ценности, но если будут какие-то блокеры, придётся перетасовать задачи в соответствии с разблокировкой следующей самой ценной задачи. Поэтому именно упорядочивание (ordering), а не приоретизация.
Про путь с сертифицированным тренингом (сдавать экзамен все равно надо, тренинг необязательный)
Если вам не хватает систематизации знаний, или вы просто хотите пообщаться с тренером по куче кейсов и понетворкать — велкам.
По сути тренинг к PSM II (Professional Scrum Master II / A-CSM, если вы любите Scrum Alliance) это систематизация того, с чем вы итак скорее всего столкнулись в работе. Если:
Соответственно, вы вспоминаете через призму своего опыта весь scrum guide, попутно затрагивая чуть сильнее метрики, Evidence Based Management, коучинг и фасилитацию, работу с конфликтами, правильные и неправильные образы scrum-мастера, и масштабируемые фреймворки. В случае хорошего тренера, вы еще поизучаете и поприменяете Liberating Structures, да и погрузитесь в основы Kanban’a.
Это проходит хорошо, весело и довольно продуктивно, потому что при хорошем тренере вы процентов 70-80 итак будете обсуждать практику и кейсы. Но тренинг сам по себе не является обязательным шагом к экзамену, главное — опыт и сам экзамен.
Сам экзамен
Времени более чем достаточно, тест с 2018 стал несколько легче, в итоге сам я сдал с одной ошибкой:
Фух, надеюсь кому-то это поможет 🙂 Удачи и стойкости! Повторяю что ничего прям-таки сложного в этом экзамене нет.
Что такое Evidence-Based Management™ (EBM)
Измеряйте ценность, чтобы ваша организация и команды смогли стать гибче и лучше.
Что такое Evidence-Based Management?
Фреймворк Evidence-Based Management (перев. менеджмент, основанный на доказательствах) помогает организациям измерять ценность, которую они извлекают из поставок продукта, управлять ею и увеличивать ее. EBM фокусируется на улучшении результатов, уменьшении рисков и оптимизации инвестиций.
Это относительно новая идея, которая активно развивается и поддерживается Кеном Швабером и сообществом Scrum.org.
Почему Evidence-Based Management?
Гибкие организации в курсе, что частое инспектирование результатов ограничивает риски и улучшает способность поставлять ценность. Их лидеры управляют инвестициями на базе ROI и ценности. В то же время, они пытаются помочь организации создать адаптивную культуру, которая позволяет раньше конкурентов извлекать преимущества из открывающихся возможностей.
Доказательный менеджмент (Evidence-Based Management) помогает организациям принимать правильные меры, чтобы инвестировать в правильные области, принимать более умные решения и уменьшать риск, применяя итеративный и инкрементальный подход. Этот эмпиричный метод вместе с гибкими принципами и ценностями позволяет организации успешно проходить трансформацию.
Начните с рассмотрения ценности
Организации инвестируют в гибкие процессы, инструменты, тренинги и коучинг, но сколько этих инвестиций возвращается? Улучшается ли поставка продукта? Становятся ли заказчики более счастливыми? Достаточно ли у сотрудников ресурсов и удовольствия от работы? Традиционные метрики могут дать вам информацию об улучшениях операционной эффективности, но ведь намного более важно — улучшить вашу способность создавать ценность для кастомеров и стейкхолдеров.
Путь к гибкости
EBM рассматривает четыре основные области ценности. Метрики варьируются в зависимости от организации, но все четыре области важны для формирования способности организации поставлять бизнес-ценность. Цели и примеры этих областей ценности глубже описываются в гиде по EBM.
Метрики в agile | EBM Guide
В условиях постоянных изменений все больше организаций стали применять Agile-практики. Зачастую, они фокусируются на постоянном улучшении процессов и активностях, забывая о реальных целях — увеличении ценности поставляемого продукта и бизнес результатах.
Введение
Agile – это всего лишь средство для достижения цели, а не сама цель. Когда организации забывают об этом, менеджеры начинают задавать вполне разумные вопросы, направленные на измерение процесса, а не результата. Примерами таких вопросов могут быть:
рис.1. Примеры вопросов
Но дело в том, что эти вопросы не помогают организации увеличить ее способность поставлять больше ценности. Например, отслеживание скорости работы команды разработки ничего не говорит о том насколько выполненные задачи полезны для пользователей.
Без измерения ценности результативность любой Agile-практики основана лишь на интуиции и предположении. В этой статье рассмотрен подход Evidence-Based Management (EBM), который позволяет измерить поставляемую ценность. Данный подход дает возможность организации принимать рациональные решения, основанные на фактах, и учитывает эмпирические данные и логику.
Подход, который основан на фактах, является эмпирическим. Он предоставляет организациям возможность измерять поставляемую ценность и ресурсы ее достижения для выявления потенциальных улучшений.
рис.2. Четыре сферы EBM
EBM состоит из четырех сфер. Каждая сфера либо фокусируется на текущей ценности, либо на возможности ее создать. Организации, которые не берут во внимание все четыре сферы, с малой долей вероятности могут поставлять долгосрочную ценность.
Текущая ценность – включает в себя поставляемую ценность, удовлетворение заинтересованных лиц и сотрудников.
Время реализации – своевременное удовлетворение рыночного спроса.
Готовность к инновациям – способность создавать и поддерживать высокотехнологичные решения.
Нереализованная ценность – ценность, которую может принести продукт спустя время.
Current Value/Текущая ценность
Показывает ценность, которую продукт поставляет пользователям на данный момент.
Целью определения данного показателя является максимизация ценности, которую организация поставляет конечным пользователям и заинтересованным лицам в настоящее время. Эта ценность касается только того, что есть прямо сейчас, а не того, что может быть в будущем.
Необходимо постоянно отвечать на следующие вопросы для измерения этого показателя:
Некоторые вещи могут увеличить текущую ценность: повышение usability, улучшение условий обслуживания и т.д. Важным аспектом являются сотрудники организации, которые знают как сохранять, поддерживать и повышать ценность. Поэтому так важно отслеживать уровень их счастья.
Определяет способность организации быстро поставлять новый функционал, сервисы или продукты.
Целью данного показателя является измерение времени, необходимого организации для поставки ценности. Время реализации позволяет понять частоту поставок.
Необходимо постоянно отвечать на следующие вопросы для измерения этого показателя:
Есть множество факторов, способных сократить время реализации. Например, совершенствование процесса автоматизации, устранение технического долга, все что сокращает время ожидания или время на исполнение работы.
Ability to Innovate/Готовность к инновациям
Определяет способность организации поставлять новый функционал, который в большей степени удовлетворяет потребности пользователей.
Целью определения Готовности к инновациям является максимизация возможности реализовывать новые инновационные решения.
Необходимо постоянно отвечать на следующие вопросы для измерения этого показателя:
Например, препятствием на пути к инновациям могут стать: большие временные затраты на исправление дефектов и устранение технического долга, необходимость поддерживать множество версий продукта, веток кода и запутанной монолитной архитектуры, тяжелый процесс разработки. Чем больше у нас подобного, тем больше тратится денег и времени на поддержку продукта. Следовательно, становится меньше ресурсов на реализацию инноваций. Все что мешает пользователям получать выгоду от инноваций также является серьезным препятствием.
Unrealized Value/Нереализованная ценность
Определяет потенциальную ценность, которую может принести продукт.
Целью определения данного показателя является максимизация нереализованной ценности.
Необходимо постоянно отвечать на следующие вопросы для измерения этого показателя:
Если у вас нет представления о всей деятельности компании, то ответить на эти вопросы довольно сложно. Так как ресурсы могут быть ограничены, инвестиции в один продукт подразумевают снижение доступных ресурсов для другого.
Организация должна учитывать не только реализованную ценность, но и нереализованную. Например, если продукт на данный момент приносит мало ценности, но имеет огромный потенциал на рынке, это не значит, что он невыгоден. При должных инвестициях его потенциал может раскрыться и продукт принесет значительную прибыль. Напротив, если у продукта большая нереализованная ценность, но низкий потенциал на рынке, то инвестиции в него не окупятся.
*Перечень основных метрик для каждой сферы приведен в приложении.
Ведущие и запаздывающие индикаторы
Ведущие индикаторы быстро реагируют на изменения в основных показателях, а запаздывающие индикаторы могут обнаружить изменения только спустя какое-то время. Многие индикаторы не являются ни ведущими, ни запаздывающими, но они становятся таковыми в зависимости от частоты измерения. Например, когда доход измеряется каждый день, он является ведущим индикатором. Как только измерения начинают проводиться ежемесячно или реже, доход становится запаздывающим индикатором.
Меры удовлетворенности сотрудников измеряются ведущими и запаздывающими индикаторами. Например, ведущим индикатором в таком случае может быть всплывающее окно с вопросом: как твоё настроение после рабочего дня?
С помощью ведущих индикаторов можно определить вероятный результат запаздывающих индикаторов. Успешная сборка и интеграция являются прогнозом стабильного релиза.
Запаздывающие индикаторы такие как доход на одного сотрудника, ROI, рентабельность продукта и другие в конечном отражают общую метрику: в какой степени продукт создаёт ценность.
Индикаторы не всегда корректно отражают реальную ситуацию. Необходимо понимать корневые причины изменений. Для этого следует провести анализ, в ходе которого могут появиться новые инсайты, эксперименты.
Как улучшить использование EBM
«Если вы не знаете куда идёте, то любая дорога сможет привести вас туда.» — Льюис Кэрролл
Измеряя все четыре сферы, можно сразу обнаружить возможности для улучшения. Использование более систематического подхода позволяет организациям постоянно повышать поставляемую ценность. Существует цикл обучения, чтобы производить настоящие и продолжительные улучшения.
Первым шагом является определение ценности с помощью основных метрик. Процесс определения и выравнивания основных метрик может быть ценным для организации, т.к. он может создавать прозрачность вокруг того, что оптимизируется.
Следующим шагом является установка начальных значений или базового показателя для интересующих метрик. Данный шаг обеспечивает первоначальное представление о жизнеспособности продукта и способности организации поставлять продукт. Это помогает выявить сильные и слабые стороны организации.
Компания выбирает сферы, где бы она хотела улучшать свои показатели.
Не пытайтесь влиять на большое количество сфер в рамках одного цикла. Выполнение небольших инкрементальных изменений лучше, чем отсрочка улучшения и измерение большого количества показателей. Одновременное изменение большого количества показателей может также вызвать проблемы при попытке установить причинно-следственную связь между результатами и деятельностью. Короткие циклы с небольшими изменениями являются наиболее эффективным способом поддержания общей гибкости организации.
Выбрав ключевые сферы для улучшения, определите несколько практик, которые по вашему мнению улучшат связанные с ними метрики. Проведите эксперимент. Например, организация, которая занимается разработкой ПО, хочет улучшить качество своего Продукта. Она может сфокусироваться на уменьшении дефектов. Практика: внедрение метода разработки через тестирование для увеличения покрытия тестами.
Как только будут получены результаты эксперимента, их необходимо сравнить со значениями метрик. Если результаты изменились в лучшую сторону — вносим изменения. Цикл повторяется до тех пор, пока ключевые сферы не начнут приносить желаемые результаты.
Заключение
«Если не можете что-либо измерить, то не можете этим управлять.» — Питер Друкер
Ключевые сферы EBM отражают целостную картину эффективности продукта. Текущая ценность имеет важное значение, поскольку продукт, который не несет ценности для пользователей, не проживет долго. Пользовательский опыт является лишь частью картины. Увеличение и поддержание количества пользователей невозможно без счастливых, вовлечённых сотрудников и без довольных инвесторов.
Быстрое повышение ценности продукта требует частой поставки нового функционала, что означает сокращение времени реализации продукта. Это значит больше чем просто работать быстрее. Обнаружение и устранение препятствий для более быстрой поставки необходимо для более короткого цикла.
Сокращение времени реализации это ещё не конец истории. Короткие циклы выпуска, которые обеспечивают поставку небольших улучшений, не позволяют быстро повысить ценность поставляемого продукта. Способность организации к инновациям также определяется ее возможностями поставлять существенные инновации в каждом релизе. Измерение этой способности даёт организации понимание какие препятствия нужно устранять.
Повышение эффективности также циклический, итеративный процесс. Измерение текущих условий, постановка целей эффективности, составление небольших экспериментов по улучшению, и затем оценка результатов повторяется непрерывно.
Приложение
Примеры основных метрик для каждой сферы.
Current Value/Текущая ценность
| Метрика | Описание |
| Revenue per Employee | Данный показатель считается как соотношение выручки к количеству сотрудников. Полученное значение индекса интерпретируется в зависимости от отрасли, в которой он измеряется. Для каждой отрасли существует свое стандартное значение. |
| Product Cost Ratio | Соотношение совокупности затрат на продукт (включая операционные расходы) к выручке. |
| Employee Satisfaction | Измерение вовлеченности сотрудников. Например, сбор обратной связи. |
| Customer Satisfaction | Измерение удовлетворенности пользователей. Например, NPS. |
| Usage Index | Выявление часто используемого и менее используемого функционала. Например, соотношение используемого функционала ко всему функционалу или время, затрачиваемое на использование функционала. |
Time-to-Market/Время реализации
| Метрика | Описание |
| Build and integration frequency | Количество билдов-сборок (внедренных и протестированных) за определенный период. |
| Release Frequency | Количество релизов за определенное время, например, непрерывно, ежедневно, ежеденедельно и т.д. Это помогает определить время, необходимое для поставки ценности клиенту. |
| Release Stabilization Period | Время, затрачиваемое на исправление проблем, с момента «да, все готово для релиза» до момента «релиз». |
| Mean Time to Repair | Среднее время с момента обнаружения ошибки до ее исправления. Это отражает насколько работа с дефектами эффективна. |
| Cycle time | Время с момента начала работы над функционалом до момента релиза. |
| Lead Time | Время от идеи до реализации. Если идеи пользователя быстро реализуются, то удовлетворенность увеличивается. |
| Time-to-Learn | Время от момента получения идеи до возможности измерить результаты реализации идеи. |
Ability to Innovate/Готовность к инновациям
| Метрика | Описание |
| Usage Index | Измерение функционала, который действительно используется пользователем. Фичи, которые используются редко, все равно нуждается в поддержке — на него уходят силы, это блокирует возможность использовать ресурсы на инновации. |
| Innovation Rate | Соотношение процента усилий и затрат, потраченных на новые возможности продукта, к общей сумме усилий или затрат. Это дает представление о способности организации поставлять новый фунционал. |
| Defect trends | Измерение изменений в дефектах с момента последнего измерения. Дефект — это, то что напрямую влияет на качество функционала и снижает ценность продукта для пользователя или организации. |
| On-Product Index | Процент общей базы пользователей, использующих текущую версию продукта. Низкие значения — могут быть связаны с проблемами установки или низкой информированности. |
| Installed Version Index | Количество версий продукта, которые поддерживаются. Чем больше значение — тем больше компания тратит на поддержку этих версий, и ресурсы не могут быть направлены на инновации. |
| Technical Debt | Технический долг — количество некачественных решений, которые в дальнейшем влияют на скорость работы, обработку запросов и т.д. |
| Production Incident Trends | Частота случаев, когда команда прерывает запланированную работу, чтобы решить проблему или поправить возникнувший дефект «СРОЧНО». Это помогает определить стабильность продукта. |
| Active code branches, time spent merging code between branches | Количество времени, затраченного на поддержку кода для разных версий продукта, слияние изменений и интеграцию продукта. |
| Time spent context switching | Частота прерываний члена команды, которые снижают его продуктивность, работая над новой возможностью. Количество встреч в день, количество раз когда необходима кому-то помощь вне команды. |
Unrealized Value/Нереализованная ценность
| Метрика | Описание |
| Market Share | Относительная доля рынка, контролируемая продуктом. |
| Customer or user satisfaction gap | Разница между ожиданиями пользователя и фактическим результатом. |
Статья переведена под ред. Делягиной Анастасии.
