Agile для дедушки: гибкие методологии на простом примере

Маркетолог Наталья Бабаева об интуитивности Agile и ситуациях, когда необходим Scrum.

В закладки

Когда что-то нельзя объяснить просто, невольно начинаешь подозревать неладное. Особенно если для того, чтобы понять что-то, нужно изобрести это заново.

Если при работе с Agile у меня возникал бытовой вопрос, а в голову приходил ответ на него, то каждый раз я останавливала себя. А если была уверена, то это делали члены команды.

Стоп, Наташа. Не надо думать. Ты прочитала три книги на эту тему, послушала пару двухдневных семинаров, прошла Agile-курс, посмотрела несколько видео и провела несколько стратегических сессий с Agile-тренерами. И пару лет поработала в Scrum-процессе (и это не был настоящий Scrum). Да что ты можешь понимать. Не смей искать ответ на свой вопрос. Записывайся и жди консультации с Agile-тренером.

Мне не нравится, когда нельзя думать. Принцип «су-ха-ри» негласно запрещает использовать здравый смысл. Прямо как в советской школе — думать не нужно, учи. Это выглядит подозрительно.

Присоединиться к лагерю противников Agile — не мой вариант. Все внутри меня принимает принципы Agile. Я меняющийся человек, и без гибкости никак.

Agile и Scrum — довольно интуитивные вещи, которые важно включать. И вовремя выключать.

Зовите дедушку и поехали.

Объясняем дедушке Agile

Дедушка, представь. Ты молод, недавно женился. Кто-то приютил вас с женой на лето. Но скоро зима, нужно успеть построить дом. Что бы ты сделал?

Построил бы маленький дом, но с хорошим фундаментом, лишь бы въехать до зимы. Накрыл бы крышу просто, чтобы перезимовать.

А потом?

На следующее лето сделал бы пристройку, поставил хорошую крышу. На третий год построил бы веранду. На четвертый — может, и второй этаж. Вместе с женой мы решили бы, что делать в первую очередь.

Молодец, дедушка. Теперь запоминай:

  • Дом мы будем называть «продуктом». Да, не смейся.
  • Твой домик «лишь бы въехать» — это MVP, «минимальный жизнеспособный продукт». Дом с пристройкой, дом с верандой — это инкременты, новые функции.
  • Ты — Product Owner, отвечаешь за то, каким именно будет дом. Жена — стейкхолдер, заинтересованная сторона. Ее мнение важно, в этом доме ей придется жить.
  • Список будущих функций (пристройка, веранда, второй этаж, хорошая крыша и все, что вам нужно) —  это бэклог, описание необходимой работы.
  • Когда вы с женой решаете, что делать дальше, вы проводите бэклог-груминг, заботитесь о том, чтобы спланировать работу.

А теперь расскажи, как ты строил бы дом.

Я плохой строитель, зато хороший наладчик, поэтому остался бы работать на заводе. Строить дом я позвал бы брата и дядю Вову. У брата золотые руки, а сосед умный — нарисует, рассчитает. Оба работяги. Соседку попросил бы кормить их три раза в день. И мирить, если поругаются.

Отлично, пиши:

  • ​Твой брат и дядя Вова — команда разработчиков дома-продукта. Их сила в том, что они могут заменять друг друга. Они —  «Т-образные люди», то есть что-то умеют хорошо, а в остальном готовы помогать друг другу.
  • Ваша соседка — Scrum-мастер. Ее задача — поддерживать работоспособность команды.

А как бы ты следил, чтобы они делали все правильно? Как узнавал бы, какие стройматериалы им нужны?

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

Так вот, дедушка:

  • Разговор в начале недели — это планинг, определение и оценка предстоящей работы.
  • Ваш утренний кофе — это стендап, ежедневная планерка.
  • Напиться и поругать друг друга значит провести ретроспективу, оценить, что и как было сделано.

А как же жена? Ей тоже интересно поучаствовать в строительстве дома.

Я привозил бы жену раз в две недели. Вдруг и вправду что-то не так.

Cмотри, что получается:

  • Двухнедельные промежутки между приездами жены — это длина спринта, периода вашей работы над домом-продуктом.
  • Приезд жены — это показы. Лучше планировать работу в спринте так, чтобы каждый раз было что показать.
  • Новоселье — запуск продукта.

Дедушка, ты только что заново изобрел Agile и большую часть Scrum. Когда нужно сделать что-то быстро и дешево, люди интуитивно изобретают гибкие вещи и методы. Так часто происходило и в прошлом.

Историческая справка для дедушки

Во времена колонизации Америки переселенцы отправлялись на запад, далеко от цивилизации. Они были ограничены в материалах и времени — нужно было успеть до зимы.

В первый год они строили себе маленькое жилище из дерна ( слоя почвы с корнями растений) с печкой из камней и грязи. Это был их минимально жизнеспособный продукт (MVP). На второй год они сооружали себе домик из грубо отесанных бревен (вторая версия продукта). И только на третий год обычно начиналось строительство настоящего дома.

1883 год, штат Небраска. Дом из дерна, бык вместо собаки

У жителей фавел в Латинской Америке времени побольше, зимой тепло. Но они крайне ограничены в деньгах.

Они строят свою комнату из больших кирпичей почти по Agile. На сколько хватит купленных кирпичей — столько стен и ставят. Потом достраивают, ставят окна, накрывают крышу, а иногда штукатурят и красят. Когда семья растет, пристраивают следующую комнату.

Фавелы как иллюстрация интуитивности гибких методологий

Когда у программистов было мало времени и средств, они тоже пришли к гибкости и назвали такой подход Agile («гибкий», «подвижный»).

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

Scrum — это набор взаимодействий, процедур и ролей, необходимых для гибкости.

Зачем это нужно

Дедушка, представь, если бы у тебя было достаточно денег и времени на строительство большого дома?

Тогда зачем мне так напрягаться. Я нанял бы строительную компанию и заказал дом «под ключ». Мы разработали бы проект, подписали договор. Я приезжал бы на стройку больше из любопытства, ведь большое строительство идет точно по плану.

Но ведь строить большой дом нужно дольше. Тогда ты не смог бы поселиться в сентябре.

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

А если бы ты не был уверен, что хочешь жить в доме, а не в квартире?

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

Выводы для внука

Дедушка все понял. А внук?

  1. Принципы Agile интуитивны. Если ресурсы ограничены, все мы становимся более гибкими. Я бы добавила к Agile-манифесту один пункт: «Включая Agile, сохраняйте здравый смысл».
  2. Экспериментальному проекту нужен Agile-подход. Если мы не знаем, нужен ли нам продукт или какой он должен быть, лучше строить его по принципам Agile. Даже если есть ресурсы.
  3. Если ресурсов достаточно, а мы точно знаем, чего хотим, то нужно забыть про MVP и Agile и просто строить по рецептам хорошего проектного менеджмента. В таких условиях мы будем переплачивать за Agile, а не экономить. Мы не сможем оптимизировать сроки и расходы по проекту: будем строить три года вместо шести месяцев и заплатим за две крыши вместо одной.

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

Написать
{ "author_name": "Сергей Разумов", "author_type": "self", "tags": [], "comments": 27, "likes": 49, "favorites": 1, "is_advertisement": false, "subsite_label": "flood", "id": 25972, "is_wide": false }
00
дни
00
часы
00
мин
00
сек
(function(){ var banner = document.querySelector('.teaserSberbank'); var isAdsDisabled = document.querySelector('noad'); if (!isAdsDisabled){ var countdownTimer = null; var timerItem = document.querySelectorAll('[data-sber-timer]'); var seconds = parseInt('15395' + '50799') - now(); function now(){ return Math.round(new Date().getTime()/1000.0); } function timer() { var days = Math.floor(seconds / 24 / 60 / 60); var hoursLeft = Math.floor((seconds) - (days * 86400)); var hours = Math.floor(hoursLeft / 3600); var minutesLeft = Math.floor((hoursLeft) - (hours * 3600)); var minutes = Math.floor(minutesLeft / 60); var remainingSeconds = seconds % 60; if (days < 10) days = '0' + days; if (hours < 10) hours = '0' + hours; if (minutes < 10) minutes = '0' + minutes; if (remainingSeconds < 10) remainingSeconds = '0' + remainingSeconds; if (seconds <= 0) { clearInterval(countdownTimer); } else { timerItem[0].textContent = days; timerItem[1].textContent = hours; timerItem[2].textContent = minutes; timerItem[3].textContent = remainingSeconds; seconds -= 1; } } timer(); countdownTimer = setInterval(timer, 1000); } else { banner.style.display = 'none'; } })();
{ "id": 25972, "author_id": 99615, "diff_limit": 1000, "urls": {"diff":"\/comments\/25972\/get","add":"\/comments\/25972\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/25972"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199791 }

27 комментариев 27 комм.

Популярные

По порядку

Написать комментарий...

Комментарий удален

Комментарий удален

2

Вровень или выпирать решает либо дизайнер/архитектор, либо заказчик. Только долбоебы спорят о всякой фигне и не идут на компромисс, никакого отношения это к agile или waterfall не имеет.

Ответить

Комментарий удален

–3

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

Ответить

Комментарий удален

0

Моя компания и не является самой лучшей. У нас набрали juniors и сделали их всех leads или seniors,а опыта у них было мало. Моя работа заключалась не в том чтобы с ними спорить или учить, поэтому работой над attitude занимался менеджер.
Тот кого уволили - он просто вдобавок еще мало работы делал, то есть это была не единственная причина. В штате New York employment at will, поэтому уволить людей легко. Умные люди стараются не напрашиваться.
Зато после разговоров о поведении у нас проекты стали двигаться быстрее и отношения в команде стали лучше, потому что люди занимаются делом, а не доказывают у кого интуиция лучше.
По поводу увольнения токсичных работников давно велись споры, и все таки пришли к заключению что лучше их увольнять, так как компания теряет на них деньги. А если учесть что в НЙ платят от 100 и выше инженерам, то это еще более оправдано.
http://www.fin24.com/BizNews/Toxic-employees-more-reason-to-fire-the-jerk-at-work-20150401

Ответить
0

Возьмите меня джуном

Ответить
4

Жду материал "Варим борщ по Agile" для девули-маркетолога.

Ответить
4

У меня с Аджайлом проблема.
Всю жизнь делали проекты (как оказалось по Аджайлу), просто из здравого смысла не понимаю, а как оно может по-другому строиться?

Подскажите плс, а что я пропустил и как по-другому то делать проекты если у тебя свои деньги, а не анлимит от Газпрома какого-то?

Ответить

Комментарий удален

2

Я не особо силен в Аджайл или Скрам. Все это интересно, но чересчур заморочено и называют казалось бы обыкновенные вещи новыми терминами, указывая на то что ранее все делалось через ж*пу, а тут "по-новому" с заправленными штанами.

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

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

Мой принцип: найди проблему и накидай несколько вариантов решения. Выбери оптимальное к проблеме и тестируй. По ходу дела, возникают новые решения.

Таким образом я вывел производство приборов с 50 штук/месяц до 300 штук. Сроки производства варьировались от 6 месяцев до максимально двухнедельных.

Во всем есть сложности и недостатки, но если это цепляется за твердые принципы и правила, то порой становится закостенелым и неудобным.

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

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

Агил/Скрам надо пробовать и брать лучшее и эффективное под свой проект.

Ответить
0

Agile и Scrum просты, я не знаю чего народ прицепился.
Судя по всему что вы написали - вы прирожденный менеджер (в западном значении этого слова).

Ответить
0

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

Пробует каждый в меру заинтересованности и потребности.

Ответить
0

У нас в компании например была проблема что scrum teams пытались пропускать фазу разработки когда разрабатывается архитектура и обсуждаются многие значимые детали с product team. Они считали что это не нужно. Мы же сказали что один спринт надо уделить просто обсуждению деталей и составлению будущей архитектуры. Да, на Production ничего не идет, но так и user stories можно написать соответствующие - разработать документацию, согласовать и тд и тп.
Вы уже написали, что самое главное это эффективная коммуникация. Она позволяет решать все проблемы. Все эти user stories и standups тд просто инструменты.

Ответить
2

У меня который год стойкое ощущение, что в России компании и команды вводят Agile просто потому что это модно, можно много классных слов говорить и водить руками. На деле же он им или не нужен, или они совершенно не умеют им пользоваться. У меня даже стойкое отвращение к Agile выработалось, стараюсь избегать предложений от компаний, использующих Agile

Ответить
0

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

Ответить
1

@Голь на выдумки хитра. Вы предпочтете, чтобы вам загородный дом построили за год и сто денег, или попросите копать пока фундамент на сколько денег хватило?

Ответить

Комментарий удален

0

Хороший пример полного непонимания сути и фактического его понимание в рф - аджайл это по понятиям.

Важнее != отсутсвие документации. То есть - нехер ссылаться на заведомо тупую запись требования которая фактически противоречива или блокирует/портит/замедляет работу/искажает рабочий продукт, что выявляется на "регулярных проверках" (ретроспективах) где идет моментальная корректировка докумнтации в верную сторону и работа от точки проявления дефекта реальностью в этой документации.

Именно поэтому тех бизнесов кто не знал что такое "эджайл" и узнал по факту работы с подрядчиком что это "работа по понятиям" которые форулируются по ходу настроения творческого исполнителя - вот эти вот все ваши эти все аджайлы и заебали народ.

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

Именно в этом и заключается слово "важнее" - то есть приоритетнее, но не отсутсвие живых докуменов по - а) концепции б) архитектурынм требованиям в) рабочим проектированиям г) отчетам по факту прорерок (Это было норм, это хуйня - выпиливаем, потому то и потому то, число подпись) д) фактом "ввода в эксплуатацию" релиза актами / церемониями и прочими формальностями.

Нахуй понятия - весь мир держится на бумагах и фиксациях информации вне голов людей у которых семь пятниц на неделе.

Ответить

Комментарий удален

0

В общем аджайл это когда работа идёт "по понятиям", а неаджайл это работа "по закону", "по бумажке".

бумажка - это документ.

Ваш ход коллега.

Ответить

Комментарий удален

2

у меня значит

Спасибо что приоткрыли свой личный тезаурус.

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

К этому в дополнение погуглите про управление требованиями.

Я с первой строчки вас ясно понял потому что это и есть ключевая идея которую вы отстаиваете - вы хотите за чужой счет заниматься неподотчетной активностью.

Где-то это прокатывает (много где) - и ваш аджайл (это вы так бардак и неорганизованные работы по созданию систем называете) встает в копейку не вам а тому кто это "заказывает".

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

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

То что вы называете "работать без них по понятиям" как вам в голову взбредет - это и называется бардак или дурдом от степени сложности.

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

Без бумажек как вы свою деятельность не называете - это неподотчетный бардак, я рекомендую это всегда оплачивать за счет отдыхающих, тогда острее начинает проявляется восприятие и измерения "результатов", как померять "сколько мы сделали и для чего, а хорошо ли это и нужно ли было" и все эти вопросы вас приведут в нужные места где вы переосознаете что такое на самом деле agile в его историческом контексте (и уже оттрубевшем свою партию на самом то деле), и что тут его особо нигде нет, потому что это то самое всеобщее желание получить "молоко без коровы".

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

А выдавать бардак и отсутствтие мыследеятельности и анализа (результатами которой всегда являюстя строгие документы как основы для начала и завершения любых работ) за agile (с вашим личным тезаурусом что такое документ) не стоит - не надо так ))

Ответить
1

Я поражаюсь вашему терпению.

Ответить
1

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

Ответить
0

Не зря часто пишут что Эджайл не нужен для крупных и ресурсодостаточных корпораций, там надо РМ.
Но тем не менее судя по прессе все от Сбера и т.п. ломанулись в Эджайл.
Хотя у некоторых топ банков и РМ-а то не было нормального, точнее никакого не было.... :-)
зы: у Сбера был..

Ответить
0

Про Agile всё понятно. Но не везде приживается... У меня в подразделении Kanban. Так мало того весь HR-блок на него перетащил. Красота. Как-нибудь напишу как)

Ответить
0

То чувство, когда люди( в том числе и комментаторы выше), вообще не понимаю что такое Agile.
Agile - это 4 ценности и 12 принципов. По сути, это культура. Скрам\Канбан - это фреймворки, которые накладываются на инкрементно-итерационную модель разработки. Теоретически, у Вас может быть в компании Скрам, но не быть Agile-культуры.

Ответить
0

А можно я попробую объяснить:
Чтобы было хорошо, нужно делать все правильно. это долго, заумно и дорого, но всем понятно.
Кто-то решил делать не сильно хорошо, но зато не надо соблюдать правила, учиться, да еще быстрее и дешевле получается.
Но кто смекалистый решил заверить, что те кто по правилам делают, на самом деле не все по правилам делают и получается у них не так и хорошо. Так что наше неплохо и дешево можно продавать задорого.
И вот смотрит теперь Заказчик и думает, что эти agile должны сделать так же все классно как и старые умные дорогие. Но только это не так. раньше заказчик понимал ответственность своего выбора. В примере про подоконник, он заранее подписывался что он будет выступать/вровень. А теперь его зачем-то убедили, что эту проблему можно решить потом.
А еще все страдают из-за MVP, потому что у любого продукта есть потолок функциональности. Но в сегодняшних рамках всем приходиться делать все новое и новое и говорить что мы тока в начале роста. Так и получаем новый мобильный скайп и прочее.
Потребитель всегда ждет полный готовый продукт за бесплатно. Остальное дело маркетинга в умении договориться с потребителем.

Ответить
0

Статья понравилась.
Одним предложением я бы это сказал так: "в неизвестных или непредсказуемо меняющихся условиях нужно отходить от жесткого PM и включать демократические модели управления".

Ответить
0

"Принцип «су-ха-ри» негласно запрещает использовать здравый смысл" это ведь верно только на первом этапе.

Ответить
–1

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

Ответить
–1

что вы бля все несете??? делайте свое дело качественно, и да прибудет с вами ваш дзен.

Ответить
0

Прямой эфир

[ { "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": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "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, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Голосовой помощник выкупил
компанию-создателя
Подписаться на push-уведомления