Оффтоп Лена Очкова
54 980

Письмо в редакцию: Забудьте об Agile и вспомните о людях

В редакцию vc.ru пришло письмо совладельца компании-разработчика AIC-Qsoft и сервиса amoCRM Михаила Токовинина, который критикует популярные методологии управления проектами и призывает обращать больше внимания на производительность сотрудников.

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

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

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

Самое страшное, что все методологии опускают одну фундаментальную переменную — производительность специалиста.

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

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

Знаете эти веселые тесты на IQ, где сначала кажется, что задача нерешаема, но стоит посмотреть на нее под другим углом — и все получается? А теперь представьте, что уверенности в наличии решения нет. Вы легко потратите сотню часов, доказывая невыполнимость задачи, вместо того чтобы все-таки поискать. Попытайтесь поставить дедлайн или назначить премию за найденное решение — и все станет только хуже. Это отлично доказал в 1935 году тест Карла Данкера.

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

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

Цель и радость достижения цели мотивируют. Стабильная и равномерная нагрузка убивает.

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

Хотите вывести команду на пик ее возможностей? Дайте ей цель, победу и, самое главное, возможность отдохнуть. Рывок, победа, отдых; рывок, победа, отдых — вот цикл, при котором мы максимально эффективны.

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

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

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

Не стоит забывать, что мы работаем не с проектом, а с людьми.

#управление_проектами #scrum #amoCRM #письмо_в_редакцию #михаил_токовинин #Agile

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

Написать
{ "author_name": "Лена Очкова", "author_type": "self", "tags": ["\u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435_\u043f\u0440\u043e\u0435\u043a\u0442\u0430\u043c\u0438","\u043f\u0438\u0441\u044c\u043c\u043e_\u0432_\u0440\u0435\u0434\u0430\u043a\u0446\u0438\u044e","\u043c\u0438\u0445\u0430\u0438\u043b_\u0442\u043e\u043a\u043e\u0432\u0438\u043d\u0438\u043d","scrum","amocrm","agile"], "comments": 46, "likes": 63, "favorites": 1, "is_advertisement": false, "subsite_label": "flood", "id": 15984, "is_wide": true }
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('15388' + '59599') - 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": 15984, "author_id": 32927, "diff_limit": 1000, "urls": {"diff":"\/comments\/15984\/get","add":"\/comments\/15984\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/15984"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199791 }

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

Популярные

По порядку

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

Михаил какой-то свой Agile критикует, честное слово.

Ответить
39

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

Почему фанаты Agile цепляются за идею недельных или двухнедельных спринтов?

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

Уберите большие релизы, замените их маленькими спринтами

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

но абсолютно пренебрегают разработчиком.

"Люди и их взаимодействие важнее инструментов и процессов" - ценность Agile.

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

Основной способ оценивания, который используют вдумчивые Agile команды, - оценка сравнительной сложности задач, служит в том числе для учета непостоянности производительности специалиста и команды.

Ответить
1

Люто плюсую каждое слово! Хотел написать подобный коммент, но нет смысла. Тут все четко и по делу сказано

Ответить
12

Agile нет, но вы держитесь. Хорошей вам штурмовщины, здоровья.

Ответить
9

Всю статью можно заменить двумя предложениями.

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

Ответить
8

Сначала люди думают, что Agile - это спринты, а потом его критикуют. Ну ок, чо.
Не нужно делать из Agile священную корову, вот и всё.

Ответить
9

Михаил просто глаза открыл.

Ответить
7

вся суть методологий

Ответить

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

6

ну как же, священную корову обидели.

Ответить
6

"Даже каноническое сравнение «водопада» и итерационного подхода — это, по сути, лишь спор о размере итерации."

Ну наконец-то хоть кто-то сказал это вслух !

Ответить
5

Офис.
С утра офисные сотрудники в спешке передвигают мебель с места на место, выравнивают все по сантиметру, компасу и т.д.
Посредине всего этого хаотичного движения стоит старенькая уборщица в обнимку со шваброй, испуганно смотрит на все это действо.
Бормочет про себя: «Только помыла, сейчас все опять затопчут, ироды и т. д.»
Стояла долго смотрела на все это, потом спрашивает:
— Милые, а что вы тут делаете? Переезжаете?
— Да нет, бабуля, мы сейчас мебель по фен-шую передвинем и у нас сразу продажи взлетят до небес.
— Сынки, я тут давно уже работаю, еще до революции полы в этом здании мыла. Так вот, до революции тут публичный дом был. Так там, когда выручка падала, кровати не двигали. Там сразу бл***й меняли.

Ответить

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

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

0

Михаил, если когда-нибудь познакомимся - буду долго жать руку за данную статью!

Ответить
12

Представляете, как усталость одолеет после достижения цели?

Ответить
–1

ОМГ, вы меня раскусили! Возьмите пирожок, знаете где

Ответить
3

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

Ответить
2

С точки зрения программиста
http://programming-motherfucker.com/

Ответить
2

Я прочел заметку Михаила и согласился, просто потому что весь мой более чем 20-ти летний опыт разработки тоже согласился :) Я прочел комментаторов-защитников scrum/agile и, знаете что, тоже согласился :)

Как так?

Уважаемые адепты scrum/agile написали про молоток с ножовкой, которые и под то заточены и под это и под конкретную руку настраиваются и по углу регулируются и вообще! учите матчасть и читайте инструкцию :)

Михаил написал про плотника. Для меня мысль о том, что бестолкового плотника каким молотком не вооружи он все равно все испортит, является самоочевидной. Так же как мысль, что стиль плотника (ок, здесь аналогия истончается, но еще не рвется :) связан с особенностями проекта/продукта.

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

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

Ответить
–1

У популярных гибких методологий (скрам, ХР) есть одна большая червоточина - то, что они расчитаны на кросс-функциональных специалистов в одной команде. И ориентированы прежде всего на кодинг, то есть они очень узкоспециализированы. Исключением можно назвать КАНБАН.

Ответить
6

Вот что же вы все придумываете. Они расчитаны на кросс-функциональные команды. КОМАНДЫ!!!

Ответить
0

Это вы про НЕКСУС пишите. Читайте скрам-гайд, там все написано, есть на русском языке

Ответить
0

Это я про скрам пишу. Покажите пожалуйста где в скрам-гайде написано про кросс-функционального члена команды.

Ответить
2

Так, каюсь. Перечитал, я не прав. Прошу простить

Ответить
0

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

Ответить
1

скрам-гайд, страница 6, второй элемент списка

Ответить
0

Scrum recognizes no sub-teams in the Development Team, regardless of particular domains
that need to be addressed like testing or business analysis; there are no exceptions to this
rule;

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

Ответить
2

Уже ответил выше, я ошибся, я не прав. Давайте жить дружно.

Ответить

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

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

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

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

1

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

Ответить
0

не в методологиях, а в голове

Ответить
1

По неведомой причине в основе всех методологий лежит гипотеза, что >собственная производительность специалиста — величина постоянная.

Откуда такое утверждение? В "водопаде" например активно используются понятия "ресурсы" и "риск", кто мешает прикинуть производительность и заложить больше "ресурсов" - трудовых для реализации проекта?

Ответить
1

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

Ответить
0

Гибкие методологии вообще создавались как ответ на быстро меняющиеся условия (любые) с целью оптимального ими управления. ТО есть правильно внедренные они помогают работать с меняющимися условиями наилучшим для команды и бизнеса образом. В 21 веке идея, что требования могут не меняться, - утопична.

Ответить

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

0

Никакая методология не спасиет от идиотов

Ответить
0

чтобы это мир делал без идиотов

Ответить
0

И никакая - от разработчиков, которые считают, что знают, что нужно клиенту, лучше самого клиента

Ответить

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

0

А откуда у вас такие данные про большинство случаев? Говорят, что мир меняется, поэтому и требования меняются..

Ответить

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

1

Agile -- это как раз и есть про людей, а не про процессы и методологии.

Прочитайте манифест Agile от 2001 года, в нем всего 9 строк текста на русском:

http://agilemanifesto.org/iso/ru/

Ответить
1

Некоторые додумываются agile использовать в линейных процессах, а потом рассказывают, что это не работает. Аgile хорош там где много неизвестности, это такой способ 1) упорядочить неизвесность 2) сделать клиента счастливым

Ответить
1

Михаил - один из умнейших людей. Посмотрите его видео на Youtube

Ответить
1

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

Ответить

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

0

Совершенно верно замечено. Причем я бы дополнил- не просто дилетант, а ограниченный человек. не могущий понять и воспринять, что люди - разные, и мыслят по - разному. И задачи решают тоже разные.
У разработчиков и управленцев совершенно разные склады ума и образы мышления. Они обусловлены решаемыми ими задачами. Им трудно понять друг друга.
Управленец решает ЛИНЕЙНУЮ задачу. То есть есть исходная точка, есть цель, расстояние и направление до нее известно, ресурсы тоже. и главное- менеджер знает, что каждый шаг, каждое усилие однозначно ПРИБЛИЖАЕТ его к цели.
У разработчика так не получается, потому что его задачи- НЕЛИНЕЙНЫЕ. То есть сделав шаг, он не может однозначно сказать, приблизился ли он к цели, отошел вбок, или вообще пошел в обратную сторону. Образно- как поиск пути в лабиринте. Вроде дверь вот она, очевидна - но за ней тупик, и надо опять идти назад, и запомнить это место, чтобы не возвращаться. Систематизировать информацию, находить причинно-следственные связи, и так далее..
И просто смешно, когда собираются управленцы, которые умеют решать лишь линейные задачи - начинают выдумывать правила скоростного прохода лабиринтов :-) Прямой дрогой он от этого не станет, но послужит поводом, что по лабиринтам придется искать путь им самим.

Ответить
0

Трудности возникают, когда задача не дробится на более мелкие.

Да, мы должны декомпозировать задачи.

А?

Ответить
0

1. В гибкой разработке учитывается непостоянство производительности разработчика. Сделать её постоянной увеличив итерацию? Сомневаюсь. Это непостоянство есть у любого разработчика даже в течение дня. Как перелагается его на пике производительности неделями держать? В том то и дело, что он не на станке работает.

2. Гибкая разработка - это ответ на реальность. А реальность такова, что через полгода у заказчика уже все может поменяться, поэтому он меняет требования и ждать многого уже ненужного несколько месяцев не готов. То есть я просто не вижу возможности работать иначе. У меня ни один клиент ничего полгода ждать не будет.

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

Ответить
0

Говорю Agile, подразумеваю Scrum, говорю Scrum - подозреваю Agile. Вот тут собственно и ошибка.
Agile как раз о людях, работающем продукте и готовности к изменениям. А Швабер с Сазерлендом, формализировавшие и популяризировавшие Scrum задолго до появления понятия "Agile Software Development" позиционировали его как лучший инструмент, чтобы быть "гибче чем водопад". Он стал эдаким компромиссом - формальный и анализируемый людьми для людей из корпораций и обещающий относительное спокойствие разработчикам на протяжении итерации.
Недавно я сумбурно рассказывал что у Scrum, не так уж много общего с Agile, а это две отдельные сущности. Если кому интересно, вот презентация - www.slideshare.net/vabue/scrum-is-not-agile

Ответить
0

О наболевшем.

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

По сути же переживаем новый виток эволюцию ведению/создания проектов/продуктов и измерения эффективности команд разработки.

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

Agile манифест и другие гибкие методологии тоже научились "наеб...ть" (простите).

Ответить
0

Боюсь представить что сотворит с мотивацией программистов Continuous Integration ))

Ответить
0

Отличный разбор статьи Михаила:
http://www.cmsmagazine.ru/authors/zavertaylov/agile-those-mechanisms-and-trolls/

Ответить
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-уведомления