Все статьи
Стандартизируй это! Как провести трансформацию и не стать новой Вавилонской башней
Дата: 13.02.2021
История Сбера про минимально-жизнеспособную бюрократию на службе Agile на масштабе крупнейшего банка.
Доклад на конференции Enterprise Agile Russia 30 ноября 2020 года.
Ольга Захарова (модератор конференции): А мы продолжаем, и следующий наш спикер, которого я сейчас приглашу, это представитель тоже банка. Это Лилия Алексеева. Лилия является специалистом по масштабируемым гибким практикам в больших корпорациях, занимается методологией и инструментами для продуктовых команд. Доклад, который, я думаю, многие представители больших компаний очень ждут, это доклад о том, как соединить то, что некоторым кажется несоединимым, наверное, да, Лиль? С одной стороны, гибкость, свобода принятия решений и так далее, а с другой стороны, огромная компания, которая не может жить без правил, без здоровой бюрократии, без каких-то договоренностей, которые будут объединять это все. Про этот баланс, я надеюсь, ты нам сейчас тоже расскажешь.
Лилия Алексеева: Возможно с некоторой необычной точки зрения.
Ольга Захарова: Отлично, спасибо. Тебе слово.
Лилия Алексеева: Ага, спасибо большое. Меня действительно зовут Лилия Алексеева, я действительно работаю в Сбере, отвечаю за методологию и инструменты Product Development. Так вышло, что года три назад я отменила толстую-толстую пачку регламентов, объявила абсолютную свободу, и перевела 20 тысяч человек в Agile. А полтора года назад я ввела новые стандарты. Здесь, конечно, можно пошутить про «убить дракона», знаете, да, эту притчу, что нельзя убить дракона, потому что любой, убивший дракона, сам становится новым драконом. Но, тем не менее, на самом деле, мне сегодня хочется поговорить именно об этом, как мы прошли этот путь, и почему это оказалось важно.
Действительно, в чем вообще здесь может быть проблема? На первый взгляд, кажется, что «стандарты» звучит как нечто взаимоисключающее самоорганизующиеся команды, и наоборот, потому что ведь мы же верим в то, что не нужно указывать людям, как им работать, они это знают лучше всех на свете, потому что только они знают весь свой личный контекст. Но, тем не менее, давайте сделаем два допущения, и начнем.
Допущение первое. Мы будем говорить про классический Enterprise, то есть не про тот, который уже прошел весь возможный путь и теперь находится где-то в абсолютном космосе с розовыми единорогами, а про такой обычный, добротный, где много сложного ландшафта, legacy и новые системы, очень много команд, очень много связей между ними, и это нельзя просто взять и перепрыгнуть.
Второе допущение очень важное: мы помним про то, что люди и взаимодействия – это основа всего, то есть мы не пытаемся лечить дисфункции в коммуникациях процессами и инструментами, мы строим фундамент на ценностях манифеста.
С этими допущениями начнем.
Давайте вспомним, как обычно вообще движется история про изменения. Обычно мы движемся по трем линиям. Мы запускаем команды, мы пытаемся выстроить какое-то предсказуемое, управляемое delivery, и пытаемся растить культуру продуктового менеджмента. Что здесь важно? Все три истории про коммуникации, про сложность, про неопределенность и очень много взаимодействий. По-хорошему, везде там очень важны метрики.
А теперь давайте представим. Вспомните или представьте, что вы Product Manager, у вас уже как будто бы в корпорации Agile, но все еще сложно. У вас порядка 20 команд, может быть, больше, может быть, чуть меньше. Вам нужно спланировать дату нового релиза. У вас есть 20 релизных политик. Или, допустим даже, что 10 команд – это один продукт, и у них все выровнено, но еще есть 10 интеграций. Это задачка не из легких. Или, что еще хуже, через месяц вы хотите понять прогресс, и вы смотрите в JIRA, и вы видите много разных задач в разных статусах, и как будто бы они даже похожи, но вы не можете быть однозначно уверены, потому что каждая команда независима, каждая настроила свой процесс, сделать какой-то единообразный вывод вы не можете.
Вы будете, безусловно, снова со всеми взаимодействовать, уточнять, что же именно значит такой-то статус, чтобы понять, что же в целом с новым релизом.
Или давайте представим, что вы СЕО, или вы еще, упаси Господи, лидер всей этой трансформационной истории. Самый частый вопрос, который вам задают, звучит так: «А эффект вообще есть? А он в чем?» Безусловно, что эффект может выражаться в очень разных вещах. Например, когда мы переехали в наш новый Agile Home на Кутузовском, мы заметили, что несмотря на то, что в нем специально предусмотрели очень много переговорок, в этих переговорках нет людей. В первые несколько месяцев люди продолжали сидеть на своих местах и общаться по телефону. Мы поняли, что лед тронулся, когда через несколько месяцев стало невозможно найти свободную переговорную просто так, пришлось вводить систему бронирования. Это действительно эффект, который ни с чем не спутаешь, ты видишь, что люди начали уже взаимодействовать, люди начали разговаривать.
Но, тем ни менее, скорее всего, вы захотите каких-то еще объективных фактов и цифр, а что еще более важно, вы, скорее всего, захотите помогать, да? Вам будет важно понять, где действительно системная проблема, а где просто кто-то кричит очень громко.
Иными словами, я хочу сказать, что если у вас есть 200 команд, 200 или 300, или 2000, как в нашем случае, и если даже это огромный масштаб, но каждая из них независима, то, в принципе, вы можете выдать каждой из них Scrum Guide, и сказать: Do your best. В принципе, это будет работать. Но если, это как допущение один, если это классический Enterprise, где много legacy, много взаимосвязей, то вы рискуете превратиться в новую вавилонскую башню. Я помню, как в одной компании только создавали практику аналитики, и туда пришли люди из очень разных компаний, там были люди из коммерческих банков, были люди из госов, и это было так, что один звонит своему коллеге и говорит ему: «Ты видел мое ТЗ?» — а он ему отвечает: «Какое ТЗ? Я ждал от тебя BRD (Business Requirement Document)», потому что один пришел из госов, второй из «Альфы». Это история про общий язык.
На самом деле, проблема которую мы хотим решить, заключается в том, а насколько людям вообще удобно взаимодействовать. Здесь я бы хотела вспомнить нашего классика Хенрика Книберга, который еще много-много лет назад сформулировал эту дилемму: любая организация всегда будет клониться либо в сторону бюрократии, либо в сторону хаоса. Он сам здесь призывал к тому, чтобы при прочих равных клониться в сторону хаоса, почему? Потому что в хаосе может зародиться жизнь. Это абсолютно верно. Но я задумалась, а какой хаос способствует зарождению жизни, а с каким хаосом мы пытаемся бороться, тем не менее. Мне понравился такой ответ, что хаос – это когда система не может ничего рассказать себе о себе же. Это парадоксальный эффект, правда, одна из ключевых причин, по которым люди идут в историю с Agile, номер два после ускорения и Time-to-Market, обычно звучит «мы хотим больше прозрачности, мы хотим больше управляемости» и, тем не менее, на масштабе крупных компаний это очень часто приводит к тому, что мы не можем ответить на вопрос, что же у нас происходит.
Из этого есть еще один интересный момент. Если мы определили «плохой» хаос, с которым мы боремся, то что же тогда такое «хорошая» бюрократия, термин, который ввел Книберг, Minimum Viable Bureaucracy? Парадоксальным образом минимально жизнеспособная бюрократия – это когда стандарты, которые вы вводите, увеличивают ценность и уменьшают ту самую «плохую» бюрократию. Они должны снижать издержки на неэффективные коммуникации.
Для решения этой задачи мы для себя придумали концепцию базовых требований, о которой я сегодня собственно хочу рассказать, как мы это делали, и что нам это дало.
Итак, что же такое базовое требование? Скучное определение: базовым требованием мы назвали требование, соблюдение которого обеспечит нам корректное функционирование и корректный мониторинг процесса.
Здесь важно сказать о том, что такое корректное функционирование. Мы здесь выделили для себя пять критериев.
- Первое – это удобство взаимодействия команд. Если мы вводим требование, то людям действительно становится удобнее и понятнее, и проще взаимодействовать, это обеспечивает им общий язык, это дает им прозрачность.
- Что значит прозрачность? Это как раз те самые статусы, те самые банальные статусы, когда вы смотрите и видите статус «In Progress», он для всех означает одно и то же.
- Это измеримость, то есть возможность собирать те самые заветные метрики, которые в принципе в эпоху digital – необходимый драйвер для принятия решений.
- Это надежность, вещи, которые нам критичны с точки зрения защиты данных клиентов, надежности прома и так далее.
- Это эффективность, под эффективностью мы здесь имеем в виду в чистом виде деньги, что, например, нам дешевле иметь один централизованный Jenkins, чем если у каждой команды будет свой подстольный, и она будет тратить время на поддержку его работоспособности.
Как мы их определяли? Мы их построили вокруг наших ключевых объектов управления. Здесь, может быть, на первый взгляд страшненькая схемка, на самом деле, она очень простая. Мы говорим следующее. У нас есть какие-то продукты в проме, мы их предоставляем клиентам, они реализуются на базе какого-то программного обеспечения, на каком-то железе. По сути, все, что делает наша команда, это change, то есть развитие этих продуктов, и она строится в следующий логике. У вас есть требования, это фичи, они могут быть декомпозированы на истории, к ним пишется какой-то код, этот код мы собираем в дистрибутивы, выпускаем в релизах, и грустим, когда приходит обратная связь в виде дефектов. Что здесь важно? Мы именно поэтому зовем их базовыми, что эта история про фундамент, и я к этому буду еще неоднократно возвращаться дальше. Но это тот минимальный уровень, на котором нам и нужны эти атомарные требования, чтобы обеспечить прозрачность и общий язык, потому что это, по сути, кровеносная система производства – требования, код, тесты, релиз и так далее.
Далее мы выделили следующие параметры:
- Тип сущности. Если мы говорим «история», то это конкретная сущность Story в JIRA.
- Жизненный цикл, то есть та самая прозрачность.
- Типы связей. Почему это важно? Потому что вы захотите потом считать какие-то метрики автоматически, а значит вам нужны какие-то единообразные правила, какие типы связей как учитывать и трактовать.
- Какие-то ключевые атрибуты этих сущностей. Например, для тех же требований нам критично знать, в каких системах они реализуются.
- Использование каких-то самых важных, на наш взгляд, практик, которые мы действительно считаем must, например, декомпозиция. Декомпозиция требований – это фундамент для инкрементальной разработки, поэтому мы правда смотрим, что у нас в бэклогах все крупные задачи разбиты на минимальные истории, или это может быть что-нибудь из инженерных практик, типа статанализа кода или чего-то еще.
Ниже, собственно, примеры, которые я уже привела, это прямо скриншот с нашего методологического портала. Каждое требование мы описываем в единой логике: почему это важно, как его соблюдать и алгоритм расчета проверки соблюдения.
Что здесь еще важно? Опять же, в стандартизации всегда есть риск увлечься, тут же хочется осчастливить всех, и поэтому очень важно вводить ограничения для самих себя. Мы для себя их выделили пять.
- Любой стандарт должен быть актуален на текущем уровне зрелости, то есть, если вы начали только строить DevOps-конвейер, то объявлять на этой стадии зрелости стандартом для всех контейнеры будет странным, потому что просто не доросли еще. Это должна быть очень трезвая оценка того, где вы сейчас, и что на текущем уровне можно правда объявить обязательным требованием для всех.
- Требование должно быть выполнимо. Если для него требуются какие-то настройки или действия в системах, то вы должна сначала все это обеспечить, и только после этого вводить это как некий стандарт.
- Требования ставятся на «что», а не на «как», это к слову о гибкости. Мы очень тщательно подходим к тому, чтобы стандарты не нарушали ответственности команд за эффективность своего процесса. Например, когда мы унифицировали статусные модели объектов в JIRA, мы не стали делать один жизненный цикл для всех, мы сделали их, во-первых, несколько, а во-вторых, унифицировали их только со стадии «готово к интеграционному тестированию», потому что здесь нам уже важно, здесь уже прозрачность их взаимодействия, а до этого момента каждая команда может сама решать, хочет она выделять аналитику с проектированием, кодированием, системным тестированием в отдельные этапы, или ей достаточно статуса in progress или еще что-то. Унификация должна быть очень аккуратной. По большому счету мы ставим требования к цифровым следам, которые мы хотим, чтобы оставались в процессе работы команды. Мы не даем инструкции, как именно они должны работать, какие должны быть шаги, потому что это уже будет та самая бюрократия, когда мы не знаем, что происходит и просто пишем инструкции на все подряд в надежде, что хоть что-нибудь сработает. Чтобы этого не было, очень важно определять требования к тому, что должно быть результатом, а не к тому, как это должно быть сделано.
- Каждое требование мы делаем атомарным, это позволяет нам обеспечивать мониторинг актуальности и ценности каждого, чтобы не было так, что вокруг одной здравой идеи появилось много-много безумных «бантиков», и потом оно так живет годами, потому что, дескать, всегда так было.
- Пятое, особенно важное, это то, что требования контролируются автоматически. Это было, возможно, то, что нам было сложнее всего принять самим, потому что, я думаю, каждому знакома история про внутренние нормативные документы, которые описываются, согласуются и считаются как будто бы законами. Самое важное изменение, через которое прошли мы сами, это признать, что, если мы не можем независимо и объективно узнать про каждое правило, соблюдается оно или нет, это не правило. Это может быть рекомендацией, это может быть лучшей практикой, это может быть чем угодно. Но мы для себя приняли как свой личный закон, что мы зовем что-то стандартом, только если можем объективно оценивать его исполнение.
Так у нас появился Dashboard BARS. BARS – это basic requirement sensor. Дэш очень простой. В нем в разрезах трайба, команды и системы можно увидеть результаты выполнения каждого из требований, и в агрегированном виде, и в детальном виде. Помимо этого, там есть отдельные кабинеты для команд, где они могут увидеть все свои отклонения и легко их исправить.
Что здесь важно? Вы видите, это реальный скриншот, и здесь нет красивых цифр типа 100%, там есть 92%, есть 77%, и это дает очень честное приземление для всех, кто вводит какие-либо правила. У тебя больше нет иллюзий о том, как эта штука работает, ты это знаешь объективно, и ты знаешь при этом, каким цифрам ты можешь доверять, а каким нет. Мы стремимся к метрическому управлению, и благодаря тому, что мы знаем, как именно соблюдаются базовые требования, мы понимаем, цифрам по каким командам мы доверять можем, а по каким нет.
Что мне хочется сказать здесь, наверное, самого важного? Две вещи.
Первое. Стандарты вводятся людьми для людей. Может прозвучать очень и пафосно, и банально, но, тем не менее, это самое важное, и я сейчас объясню, что значит этот лозунг в действии. Но перед этим еще один.
Второе самое важное. Любой стандарт в начале – это гипотеза, и должен проверяться как гипотеза. Даже если у вас есть самая прекрасная на свете команда методологов или Agile-коучей, все равно в крупной компании вы никогда не учтете специфику каждого. Поэтому самая прекрасная ваша мысль – это все равно гипотеза. Мы с вами, как ребята, которые внедряют какие-то еще и продуктовые практики, должны об этом помнить, и помнить, что даже стандарты – это тоже продукты, и это тоже гипотезы, и их нужно проверять соответствующим образом.
Как это сделали мы? Мы для себя определили следующую историю, как мы вводим любой новый стандарт.
Во-первых, стандарты разрабатываются сразу людьми из команд. Безусловно, там будет какой-нибудь ведущий методолог от моей команды, но туда обязательно входит как минимум человек двадцать людей, которые живут в этом каждый день, и они сначала решают, а нужно ли это вообще или нет, и если верят, что нужно, они вместе определяют, как это будет работать, какие могут быть why not, какие могут быть способы измерения этого, что может пойти не так. Когда эти ребята договорились, устраиваются публичные слушания. В нашей еженедельной рассылке есть рубрика «стандарты, готовящиеся к утверждению», где делается анонс. Мы даем ссылку на наш Confluence, и любой желающий может высказаться. Если тема была особенно бурной, в конце будет даже серия митапов, чтобы можно было обсудить это вживую, если нет, то следующий шаг – мы выносим это на кворум IT-лидеров. На картинке есть как раз фотография с одного из заседаний, это отдельная история, потому что у нас очень много команд, и IT-лидеров очень много, поэтому в какой-то момент мы их попросили провести выборы. Мы сказали, что мы не можем обходить каждый раз каждого, и мы провели прямо честные выборы, чтобы из 80 выбрать 10, которым будут доверять все остальные, и делегируют им право принятия решений за всех. Плюс туда же вошли централизованные службы типа архитектуры, надежности, безопасности. Этот кворум принимает решения.
Но почему я говорю о гипотезах? Даже после всех этих прекрасных людей мы все равно каждое требование сначала вводим в режиме Grace-периода, потому что когда у вас очень большой масштаб, никакой пилотный периметр не покажет вам всю сложность. Поэтому мы используем, скорее, пилотный период, мы даем до трех месяцев для того, чтобы каждый мог проверить на себе, дать нам обратную связь, и только если по итогам трех месяцев мы видим, что эта штука действительно заработала, мы ее оттюнили, проверили, только после этого эта штука утверждается.
Для того, чтобы как-то сделать повеселее скучную тему стандартов, мы обернули все это еще в игру, и это идет как такое соревнование, game of reqs. Одни из самых приятных моментов, когда мы видим, что это все не зря, это когда на каких-нибудь крупных квартальных обзорах результатов трайбов бизнес-лидеры трайбов среди главных достижений за период называют победу в этом соревновании. Они могут одновременно, например, нарисовать цифры revenue и сказать: «А еще мы выиграли в game of reqs».
К слову, о revenue, что нам все это дало? Для чего мы это делали, и что мы получили? Самое главное – это сокращение издержек. Коммуницировать стало дешевле и, соответственно, из этого это и сокращение издержек на отчетность, на управляемость, на прозрачность и, наконец, самая секси-штука, то, ради чего мы вообще в эту историю пошли (а началась она с того, что мы однажды захотели посчитать метрики)… Ладно, не буду преувеличивать, но один из ключевых мотивов действительно был в желании управлять развитием процесса на основе данных, а они оказались очень неоднородными. Тут важно отметить, что процессные метрики в нашем случае также являются продуктовыми метриками для команд, которые создают инструменты и сервисы для команд разработки. Теперь, когда у нас есть объективные цифры, мы можем, с одной стороны, объективно анализировать проникновение практик и инструментов, то есть анализировать их значения как свои продуктовые метрики, а с другой стороны, это еще и механизм масштабирования экспертизы агентов изменений, потому что даже если у вас их много, но команд, допустим, 2000, то все равно, пока вы обойдете каждую и посоветуете именно ей, чего делать ей, времени уйдет очень много. А эта штука позволяет нам скейлить экспертизу и выдавать командам предиктивные рекомендации о том, как нам кажется, где у них чего западает, и чего им стоило бы развивать, чтобы это улучшить, с учетом того, на какой стадии зрелости они сейчас.
В заключение мне бы хотелось показать такую, на первый взгляд, жуткую картинку. Это гравюра Дюрера, она называется «Меланхолия». Перед тем, как рассказать о ней, я бы хотела напомнить вам о концепции сю-ха-ри. ,Я думаю, любой, кто так или иначе сталкивался с Agile, слышал про эту концепцию трех ступеней обучения в японских боевых искусствах. Сю – вы делаете все ровно так, как вам показывает мастер, Ха – вы можете начинать импровизировать с комбинациями типовых ударов, и Ри – когда ученик сам становится мастером и может создать свое учение и открыть свою школу. Agile-коучи любят использовать этот пример, говоря, что когда вы только берете Scrum, вам сначала нужно просто взять его как он есть и не пытаться ничего в нем менять.
На этой гравюре тоже зашифрованы три уровня. Мне очень нравится трактовка одного искусствоведа, который говорит, что это три уровня познания. На нижнем уровне мы видим шар и инструменты, такие как рубанок, стамеска и прочие. Это первая ступень, ремесленная, потому что в средние века подмастерье становился мастером, когда мог выточить шар. На втором уровне многогранник, это из пифагорейства, и на третьем лестница, которая уходит а небо, потому что предела познания нет.
Но я про что? Я все про первый уровень, я про Сю и про этот шар. Стандарты – это не rocket science, и это не что-то такое прям как бы вау, да? Но хороший, умный стандарт – это то, что дает свободу, это та самая способность выточить шар, это та самая легкость, когда вы освоили первую ступень в боевых искусствах, как сделать так, чтобы для вас каждое движение стало естественным, чтобы его не нужно было больше вспоминать. Если мы говорим, что гибкие методологии успешны потому что вытаскивают из людей все самое лучшее, что это такой empowerment, мы даем людям возможность ощутить владение своим продуктом в небольшой команде, и верим, что именно в их взаимодействии родится все самое лучшее, то мы же с вами, как те, кто затевает изменения, будь то топ-менеджмент или агенты изменений любого уровня, мы с вами ответственны за то, чтобы создать среду, в которой взаимодействия людей и команд будут эффективны. Люди не должны выяснять, что значит тот или иной статус в JIRA, они должны обсуждать архитектуру, они должны обсуждать требования, они должны выяснять, что же нужно клиенту и получать удовольствие от полезной, осмысленной работы.
Собственно, сегодня я попыталась рассказать про один из способов, как, нам кажется, это можно сделать, каким путем пошли мы, и я буду рада, если он окажется вам полезным или вдохновит на какой-то свой метод. Спасибо.
Вопрос-ответ
Ольга Захарова: Лиля, спасибо огромное, потому что доклад действительно вдохновляющий, и докладчица очень вдохновляющая. Такая тема, про методологию, которая многим, наверное, покажется не очень развлекательной, не очень интересной, представлена очень здорово.
Лиль, я хотела бы задать вопрос про инициаторов. Ты говоришь, что есть какой-то момент, когда идет, собирается рабочая группа. А вот кто инициирует, кто изначально определяет, что надо бы об этом подумать?
Лилия Алексеева: На самом деле, все очень по-разному. Первые стандарты мы придумывали сами, просто потому что увидели боль и потребность. Причем, на самом деле, мы все равно не жалеем о том, что мы дали сначала абсолютную свободу, потому что это было очень важно с точки зрения того, чтобы люди действительно почувствовали свою ответственность за то, что это их процесс. Поэтому, если бы мы делали заново, эту стадию первозданного хаоса все равно нужно было бы пройти.
Сейчас же, мне кажется, процентов 70, чтобы не соврать, мы все равно придумываем сами, анализируя все так же потребности, жалобы, узкие места, различные показатели процесса в цифрах. Но процентов 30 уже, наверное, это могут быть какие-то другие подразделения, которые хотят интегрироваться в процесс в цифровом виде, и иногда могут быть даже сами команды, которые приходят, говорят: «Мы придумали классную штуку, давайте мы ее тиражируем для всех».
Это, в общем-то, такая история, которая вовлекла всех, так или иначе.
Ольга Захарова: Да, очень интересно. Скажи, а как работает ваша команда? Сами методологи, они как работают?
Лилия Алексеева: Возможно, это мое упущение, что я не рассказала об этом сразу. Я работаю в трайбе SberWorks, то есть мы сами продуктовая структура, наш продукт – это клиентский путь разработчика, и мы стараемся eat your own dog food. Я выступаю в роли Chief Product Owner, у меня есть продуктовые команды, которые отвечают за инструменты управления требованиями, релизами и еще несколько сервисов. Каждая команда end-to-end кросс-функциональна: владелец продукта, методолог, аналитики, разработчики. Если они предлагают какой-то стандарт, то они за него отвечают тоже целиком, они должны его придумать, утвердить, автоматизировать возможность его соблюдения, они должны его внедрить, они должны его поддерживать, они должны его развивать. Мы сами продуктовые команды, только наши клиенты – это другие продуктовые команды.
Ольга Захарова: Слушай, здорово, да, потому что это, мне кажется, либо не услышала, либо пропустила. Скажи, пожалуйста, последний вопрос, есть все равно люди, кто говорит, что очень много бюрократии?
Лилия Алексеева: Конечно. Причем, здесь даже забавнее. Поскольку мы, как я уже сказала, сами продуктовая команда, у нас две ключевые метрики, это Adoption Ratio, то есть мы смотрим, насколько люди используют то, что мы делаем, потому что, понятное дело, что есть какие-то практики обязательные, но много чего, что мы делаем именно как сервис, и потом смотрим, насколько он востребован.
Вторая ключевая метрика – это удовлетворенность, это CSI. Помимо регулярных замеров раз год мы делаем большое расширенное UX-исследование. Например, два года назад нам написали, что «все стало непонятно, вообще невозможно жить, непонятно, куда идти и что делать, вы все развалили». Нет, большая часть была рада, но были те, кто писал, что «вы все развалили, жить стало сложно, трудно». А в этом году они пишут: «Нет, с одной стороны, стало понятно, а с другой стороны, чего-то как-то много стандартов». Это будет всегда.
Ольга Захарова: Конечно. Люди, наверное, всегда такие, всегда чем-то недовольны, и это хорошо, значит, мы можем что-то улучшать и меняться дальше.
Лилия Алексеева: Это стимул для изменений.
Ольга Захарова: Да-да. Лиля, спасибо огромное, очень интересный доклад, очень здорово было послушать.
