Место Agile-команд в компании

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

В закладки

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

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

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

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

  1. Если вы в компании собираетесь сделать новый проект или организовать деятельность, и у вас есть компетентные сотрудники для этого – пусть они организуют работу известным им способом и придут к успеху.
  2. Если в индустрии известны способы, которым можно достичь успеха в новом деле, но у вас нет компетентных в нем сотрудников – попробуйте их найти.
  3. А вот если нет ни способа работы, ни компетентных сотрудников, то сделайте ставку на самоорганизующуюся вовлеченную команду и используйте Agile-методы или другие способы самоорганизации для организации ее работ.

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

Если надо сделать что-то новое, и у вас нет компетентных сотрудников, и вы не можете их найти – используйте Agile. Или откажитесь от дела.

Кеневин-фреймворк – можно ли найти компетентных сотрудников

Если с компетентностью собственных сотрудников более-менее понятно, то со вторым способом могут быть проблемы. Компания решила начать новую деятельность или сделать проект – как узнать, есть ли в индустрии способы ее успешной организации? Помимо поиска информации об аналогичных проектов есть обобщенный способ получения ответа на этот вопрос – Кеневин-фреймворк (Cynefin framework) из теории сложности.

Кеневин-фреймворк. Из моих презентаций​

Он говорит о том, что устройство мира можно разделить на четыре области.

  • Простая (simple), в которой есть понятные связи и законы.
  • Сложная (complicated), в которой причины и следствия могут быть выявлены исследованием и поняты могучим разумом.
  • Запутанная (complex), в которой объектов и связей настолько много, что хотя по-отдельности они понятны, поведение системы в целом пониманию не поддается.
  • Хаотическая (chaos), в которой поведение системы не предсказуемо.

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

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

Для каждой области есть свой оптимальный образ действий.

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

Замечу, что этот список примерно соответствует трем классам проектов Дэвида Майстера: Мозги, Седина и Процедуры.

  • Процедуры – то, что компании знакомо, является рутиной и может выполняться с гарантированным результатом. Это соответствует простой области.
  • Седина – в этих проектах результат не гарантирован, но может быть достигнут за счет опыта. Это сложная область.
  • А Мозги – это принципиально новый проект, в котором опоры на опыт недостаточно для успеха. Здесь мы говорим о действиях в запутанной области.

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

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

Классификация по сложности зависит от компетентности специалистов: простое для одних является сложным для других и запутанным для третьих.

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

Области использования Agile

Теперь попробуем указать на конкретные области применения Agile-методов. Как легко увидеть из описания способов работы в разных областях, место регулярного менеджмента – простая и сложная области. Специальные люди – бизнес-технологи делают и совершенствуют регламенты и процедуры, а все остальные по ним действуют. Разница лишь в том, что для простой области процедуры известны, а в сложной надо вести исследования. А место Agile-методов – запутанная и хаотическая области, где надо двигаться с постоянными экспериментами и коррекцией курса.

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

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

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

Основываясь на этом, можно сформулировать следующие условия, при которых стоит применять Agile-методы в операционной деятельности:

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

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

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

  • Сначала команду учим поставлять каждую итерацию что-нибудь.
  • Потом учим делать нужное – поставлять ценность.
  • Потому учим быть предсказуемыми – поставлять запланированное на итерацию количество ценности.
  • Потом учим самоорганизации – умение оценивать свои процессы и улучшать их.

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

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

На этом я завершаю статью. Следующая будет посвящена созданию Agile-команд и связанной с этим перестройке цепочек создания ценности в процессе Agile-трансформации компании. Продолжение следует…

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Максим Цепков", "author_type": "self", "tags": [], "comments": 12, "likes": 7, "favorites": 38, "is_advertisement": false, "subsite_label": "hr", "id": 99523, "is_wide": false, "is_ugc": true, "date": "Sat, 28 Dec 2019 12:34:26 +0300", "is_special": false }
0
{ "id": 99523, "author_id": 364500, "diff_limit": 1000, "urls": {"diff":"\/comments\/99523\/get","add":"\/comments\/99523\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/99523"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199121, "last_count_and_date": null }
12 комментариев
Популярные
По порядку
Написать комментарий...
1

Все проходит и помешательство Agile тоже пройдет.

Ответить
3

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

Ответить
2

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

Ответить
1

Да, такая практика есть, не только между отраслями, но и между компаниями в одной отрасли - безумно тиражировать методы, не смотря на принципиальную разницу в деятельности. Но не все люди действуют столь бездумно, большинство все-таки обращают внимание на разницу условий и адаптируют методы. Успешных адаптаций и кейсов применения Agile в самых разных отраслях сейчас много, в банках их применяют давно, а на последних конференциях AgileDays и AgileBusiness рассказывали о самых  разных предприятиях - литейный завод, Северсталь, производство коллекций одежды, школы и много других. И люди ответственно подходят к адаптации. Можно почитать мои обзоры с этих конференций. http://mtsepkov.org/AgileDays-2018 http://mtsepkov.org/AgileDays-2019 http://mtsepkov.org/AgileBusiness-2018 

Ответить
0

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

Ответить
0

Да, пожалуй так будет правильнее.

Ответить
0

Нет, Agile-методы успешно работают в IT-отрасли и уже лет пять являются там стандартом дефакто, во всяком случае в западных компаниях - после того, как Microsoft и IBM поняли, что без перестройки они просто станутся без способных сотрудников. Особый путь России и постсоветского пространства в целом объясняется тем, что после развала оборонки в IT оказалось много инженеров из военных институтов, что обеспечило развитие за счет их потенциала. Но сейчас это уже влияет слабо, а в России Agile-методы тоже применяются повсеместно.

Ответить
–1

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

А позвольте такой вопрос, а почему вы сравнили Agile c " достижениями человеческого прогресса" которые реально проверяются и научно подтверждаются, те экспериментальным путем повторяются если соблюдаются условия эксперимента. Те если следовать четкой инструкции по созданию автомобиля или конвейера, то результат будет 100% автомобиль или конвейер.
И насчет останется , вы немного забегаете вперед, например как евгеника имели гораздо больше последователей и даже внедрялись как гос. политика, что не помешало в конце концов уйти в небытие. 

Ответить
2

Это не социальный метод, это метод организации умственного труда. Задача массовой его организации впервые появилась в IT, и как ответ на эту задачу там возник Agile. Регулярный менеджмент не умеет эффективно организовывать умственный труд вообще и труд разработчика софта в частности, об этом у меня были статьи https://vc.ru/future/94043-cifrovoy-mir-ot-fizicheskogo-truda-k-umstvennomu и https://vc.ru/hr/95754-razvitie-i-proval-regulyarnogo-menedzhmenta-v-it, и там вскрыты причины. А у Agile - получилось и эффективно. И свидетельство этой эффективности - как раз распространение Agile по миру.

Что касается экспериментальной проверки, то теория сложности как раз говорит о том, что в запутанной (complex) области экспериментальная проверка невозможна, поскольку из-за множественной связи между объектами невозможно строго воспроизвести условия эксперимента. Хотя статистическая вероятность успеха - достигается. Статистика сравнительной эффективности Agile и классического менеджмента в IT - есть, я ее недавно публиковал на своем сайте http://mtsepkov.org/AgileStatistics 

Ответить
–1

1. Любой метод организации умственного труда, есть социальный метод,  так первое есть частное от второго, прежде чем спорить потрудитесь посмотреть определение слова "социальный".

2. Массовая организация умственного труда существовала и до появления IT,  утверждая обратное, вы ставите под сомнение успешную деятельность ученых  и  их реальные достижения, которые появились задолго до Agile.
3.  Эффективность распространения не является  свидетельством эффективности для тех кто использует этот метод, для тех кто на распространяет и пропагандирует, возможно является. Социалистические идеи, или к примеру религии,  были гораздо шире распространены чем Agile, а их эффективность сомнительна.
4. Современная наука признает явление любое научное утверждение только когда оно может быть доказано, а следовательно экспериментальным  путем повторено путем воспроизведения. 
Ваши заявления о том что экспериментальная проверка невозможна из-за  сложности, просто несерьезна,  для любого реального разумного человека с техническим образованием. 
  Поэтому ваш Agile это лишь пока один из регулярно появляющихся,  методологий,   целью которых является заработать, на  попытке придать системность   работе  , требующей нестандартной но высокой  квалификации от сотрудников, но это точно не научный метод  и точно еще "достижение человеческого прогресса".
 Пройдут годы и появится  какой нибудь другой метод,  а про Agile скорее всего забудут, хотя конечно есть небольшая вероятность, повторить успех какой нибудь из мировой религии.

Ответить
1

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

2. Организация умственного труда ранее была НЕ массовая, она основывалась на достаточно жестком отборе в университеты и другие научные учреждения способных людей, и далее - на их тщательном обучении. Развитие потребности в автоматизации бизнеса, последовавшее за появлением персоналок, потребовало много больше разработчиков, чем обеспечивал выпуск ВУЗов. В России эту дыру закрыл развал оборонки: в IT пришло громадное количество инженеров, а на Западе этого не было, и это обусловило успех Agile - он оказался способен достигать результата даже в условиях недостатка компетенций. А быстрое развитие технологий в IT хоронит надежду на то, что этот недостаток компетенций получится закрыть традиционными подходами, потому что цикл подготовки качественного учебника по новой дисциплине - 7-10 лет (об этом есть много историй), а технологии принципиально меняются каждые год-два.

3. Эффективность распространения метода среди коммерческих компаний, которые оценивают и следят за своей эффективностью безусловно является свидетельством эффективности метода. Более того, рассказывая свои кейсы внедрения Agile-методов многие компании указывают, как именно измерилась их работа, используя при этом ту же систему показателей, которыми измеряли эффективность работы до внедрения. То есть тут мы имеем достоверные результаты. Понятна позиция противников метода, говорящая, что "все это - исключительно пропаганда адептов, а на самом деле у них культ или просто зарабатывание денег" - люди защищают свою картину мира. Но у них нет даже такой статистики, которую приводят сторонники, а есть только отрицание.

4. Да, я знаю про это ограничение естественных наук - только экспериментальная проверка. Замечу, что для социальных наук это неверно, многие утверждения экономики, психологии, социологии и других наук НЕ прошли экспериментальной проверки, однако всерьез обсуждаются и признаются в соответствующих научных сообществах. Более того, периодически какие-либо старые догматы и модели оказываются опровергнутыми экспериментально, а их адепты продолжают с ними работать, как произошло с экономикой после того, как предположения о рациональности поведения человека при принятии экономических решений были экспериментально опровергнуты. Часть ученых это приняли и начали развивать новые ветви экономики, а часть - продолжают работать в старых моделях, выступать на конференциях, писать диссертации :) Впрочем, я нигде не пишу, что Agile-менеджмент - научный менеджмент. Как и любой другой менеджмент. Именно потому, что мне близка концепция именно естественных наук, а не гуманитарных. Но надо трезво понимать ее ограниченность и неприменимость к социальной сфере и не требовать подтверждений там, где их и быть не может.

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

В целом Agile-методы успешно развиваются уже 20 лет, за это время успешно завоевали IT-отрасль и сейчас идут в другие, вслед за развитием цифрового мира. При этом сами они развиваются и усложняются, и новые методы приходят в развитие старых, а не в их отмену. И да, паровые двигатели сменили двигатели внутреннего сгорания и электродвигатели (для разных целей - в паровозах и пароходах - одни, на фабриках - другие), но их вклад в прогресс остался. Так же с менеджментом - организация фабрик вместо надомного труда, организация научно-исследовательских институтов вместо кустарных лабораторий, НОТ Тейлора и конвейер Форда, проектный подход, теперь вот Agile-менеджмент и бирюзовые организации - все это ступени развития человечества. Продолжение следует.

Ответить
0

Del

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } }, { "id": 20, "label": "Кнопка в сайдбаре", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cgxmr", "p2": "gnwc" } } } ] { "page_type": "default" }