Оффтоп Konstantin Panphilov
11 014

«Мы факапим, и это вина клиентов»

Гендиректор агентства Greensight об ошибках клиентов, которые затягивают сдачу проекта

В закладки

Егор Волков, сооснователь и гендиректор компании Greensight, написал для vc.ru колонку о пяти типичных ошибках, которые совершают клиенты и которые затягивают срок сдачи проекта. Среди них — туманные цели, избыточная креативность, утечка дисциплины, фокус на инструменты и пренебрежение деталями.

Мама и папа с детства учили меня держать слово. Вас, наверное, тоже. Сказал — сделай. Обещал — выполни. Золотые слова! И, ей-богу, я очень старался им соответствовать.

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

Сорванный дедлайн — это ведь и есть невыполненное обещание. И в нашем деле никто этих обещаний не выполняет. И это вроде как считается нормальным.

Наше агентство факапит. Конкуренты факапят. Факапят подрядчики. Факапят те, кто стоит дешево. Факапят те, кто стоит дорого. Все кругом факапят, даже те, кто очень старается не факапить!

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

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

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

1. Туманные цели

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

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

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

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

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

2. Избыточная креативность

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

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

Особенно вредно вдохновение. Например, оно может появиться в результате прочтения в интернете статьи «10 трендов в мировом дизайне» (сочиненной за полчаса студентом «Британской школы дизайна», который подрабатывает внештатным корреспондентом). Чтение стимулирует креативность, сразу хочется пустить почерпнутые идеи в дело, чтобы быть «на волне».

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

3. Утечка дисциплины

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

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

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

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

4. Инструменты вместо задач

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

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

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

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

5. Пренебрежение деталями

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

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

***

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

Если этого в вашем проекте нет, значит сорванный дедлайн — это и ваша вина. Все эти условия соблюдены, а сроки все равно горят? Можете с чистой совестью считать нас лоботрясами и разгильдяями.

#Колонка

{ "author_name": "Konstantin Panphilov", "author_type": "editor", "tags": ["\u043a\u043e\u043b\u043e\u043d\u043a\u0430"], "comments": 48, "likes": 20, "favorites": 1, "is_advertisement": false, "subsite_label": "flood", "id": 10650, "is_wide": true }
{ "id": 10650, "author_id": 3, "diff_limit": 1000, "urls": {"diff":"\/comments\/10650\/get","add":"\/comments\/10650\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/10650"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199791 }

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

Популярные

По порядку

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

Факапите значит вы, а вина на клиентах. Вы не охуели?

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

Очень странно слышать от руководителя крупной студии такую дичь.

Ответить
12

Человек хотел сказать о другом.

При заключении договора на создание сайта обозначили дедлайн через 4 месяца, например.

И клиента не ебет:

1. Сколько итерацией правок было сделано на стадии дизайна

2. Сколько раз меняли цвет

3. Сколько раз пробовали разные иконки

4. Сколько раз меняли баннер в слайдере

5. Сколько раз клиенту наебывал ПМ на мобильные и городские телефоны, чтобы тот утвердил макет, который у него на почте лежит уже 2-ую неделю

6. Сколько раз он был был в отпуске в течение этих 4-х месяцев

7. Сколько раз ответственный со стороны заказчика решился поиграть в дизайнера

8. Продолжать дальше?

Не все клиенты понимают, что это увеличение сроков! Хоть обосрись - простите.

Всем похуй на договор. На кону отношения.

Ответить
0

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

Ответить
0

Нах такие отношения, если на договор похуй? То есть факапят обе стороны и это выгодное сотрудничество?

Ответить
0

Вы предлагаете разрывать договор, когда идёт факап независимо от того кто виноват?

Ответить
0

Почему независимо? Заказчик нарушает условия договора, вы это знаете, но идёте у него на поводу т.к. вам нужны деньги. Виноваты обе стороны.
На кону не отношения, а бабло, которое исполнитель потеряет, если начнёт качать права со своим договором)

Ответить
0

Да, есть и такие ситуации и их не мало, но есть ситуации, когда 100% предоплата и мы стараемся сохранить отношения и дать то, что устроит и нас и заказчика.

Ответить
6

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

сроки - вечны. бюджет - резиновый. простор для проб и ошибок - бесконечность.

Ответить
9

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

Ответить
3

Уже лет 10 хоронят-хоронят, все никак не закопают.

Ответить
0

Полностью согласен, вы все правильно написали.
Придраться можно разве только к фразе "бюджет - резиновый".

Ответить

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

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

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

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

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

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

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

4

Присоединяюсь к Алексею Костину.
Чувак 15 лет выполняет заказы клиентов (хочется подчеркнуть, "15 лет, Карл!"), и до сих пор не придумал добавить в договор с клиентом фразу типа:
- При каждом изменении ТЗ срок сдачи проекта сдвигается на ХХХ дней.
(ларчик просто открывался)

Ответить

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

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

3

Шутка, повторенная два-три раза, становится несмешной.
Шутка "Лев, а что Морейнис рекомендует в таких случаях?))" повторялась тут чуть менее чем дохрена раз. Щенин в своих комментариях про Морейниса уже и не вспоминает, но нет - кто-нибудь всё равно заявится и повторит этот образчик фантастически искрометного юмора.
Потому и минус.

Ответить

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

0

Благодарю Вас, Артём Гапченко!
Спасли меня от коварных троллей...
( с меня - пиво от "Пивной сетевой компании")

Ответить
0

Да уж, и не говорите!

Ответить

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

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

2

Не было опыта внедрения agile? Может это решит часть проблем? Если был опыт, интересно послушать. Если нет, то интересно почему не пробуете?

Ответить
7

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

Ответить
0

У таких клиентов не один проект, а портфели взаимосвязанных проектов. У них нет пространства для маневра.

Ответить
0

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

Ответить
0

К agile сами клиенты обычно не готовы.
Но та система, по которой работаем является миксом разных подходов.

Ответить

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

2

Константин, проекты (любые сложные) это системы с количеством зависимостей стремящимся к бесконечности, а раз так, то целый проект точно эстимировать малореально.
Вот посмотрите строительную отрасль. На что уж стандартизированная область, все равно факапят сроки даже на типовых проектах. Уж про индивидуальные я вообще молчу, увеличение сроков в 3 раза по ходу строительства - стандартная ситуация.

Ответить
1

Пока одни придумывают себе оправдания, ссылаются на чужой негативный опыт и проводят параллели, другие планируют, делают, анализируют и улучшают свои результаты :)

Но успешного опыта, конечно, намного меньше, чем неуспешного. В целом в мире и в любой из отраслей.

Ответить
0

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

Ответить
0

ГОСТ 34 - все четко, по-военному :)
Если будет не достаточно стандартизации процессов, еще ГОСТ 19.

Надо просто брать в команду суровых профессионалов - все будет отлично, без факапов :)

Ответить

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

2

Сделайте дедлайны прозрачно-подвижными. День просрочки на стороне клиента +2 дня к дедлайну. Если клиент может тупить он будет тупить, но ответственность на вас

Ответить
1

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

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

Ответить
2

да, какая разница!!! аванс бог контракта!желательно 70% сразу и 30% через 15мин. Ну если че, то клиент, ссука во всем виноват!

Ответить
2

Факапите, потому что набираете проектов, а рабочих рук не хватает. Возьмите людей, не жмотитесь.

Ответить
1

Я в договоре всю разработку делю на этапы (получается примерно 15) и прописываю сроки каждого этапа, в т.ч. тех, за которые отвечает заказчик (согласование макетов, предоставление материалов).
Не было ни одного острого конфликта по срокам, все все понятно и прозрачно.

За примерно 3-4 года, был всего один клиент, который со своей стороны все делал согласно договору - в прошлом он военный.

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

Ответить
1

Что если относительные сроки по этапам зависят от результата более ранних этапов?
Иными словами, вы можете на этапе дизайна придумать такое, что вёрстка и прочий фронтенд будет в три раза сложнее обычного.
Я уже не говорю о том, что делать, если первый этап - это проектирование и разработка ТЗ. Все остальные оценки тогда превращаются в угадайку, либо это заведомо перезаложенные даты и бюджеты.

Ответить
0

ТЗ- часть договора

Ответить
0

Чудесно, и конечно при каждом новом небольшом изменении требований вы выпускаете допник?
А пока заключаете договор, делаете работы на 50 часов, пока пропишете требования на всё-всё?

Ответить
0

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

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

Ответить
0

И еще, вы наверное не поняли - мы на этапе коммерческого предложения и ТЗ продумываем очень многое, с клиентом ведется объемная работа, и речь здесь не про бриф с 50 вопросами =)

Ответить
0

Я-то как раз понял. Очень хорошо, когда клиент давний и у вас с ним полное доверие и взаимопонимание. Но любой клиент когда-то бывает новым, про которого вам ничего неизвестно.
По вашей схеме на него ещё до заключения договора и каких-либо гарантий нужно потратить десятки часов, десятки тысяч рублей на аналитику, предварительное проектирование и прочие работы, чтобы сделать документацию (ТЗ), которая станет частью договора. А там в последний момент какой-нибудь директор передумает, и снова по кругу.

Ответить
0

Сначала идет плотное общение. Да, оно может заниматься десятки часов, но на практике, максимум одна-две встречи и переписка.

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

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

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

С первого раза КП никогда не утверждается.
Всегда что-то добавляется\убывает.

И уже после согласования КП делает техническое задание, которое ложится в договор.

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

Ответить
0

Послушайте, ну если клиенту уже нужен счёт на предоплату, значит он уже узнал цену. Это здорово, если вы обсудили вилку, только вот мой опыт показывает, что клиент всегда слышит её нижнюю границу.
Так вот, если речь уже идёт о предоплате, значит клиент знает цену. И эту цену и трудозатраты вы обсудили на основе встречи и КП.
Вопрос: если все что нужно для утверждения границ проекта (бюджет, сроки, ключевые условия) упаковано в КП, то какой смысл в прикладывании к договору ТЗ? Чтобы усложнить любые движения, которые остаются в рамках границ? Вы ведь даже не утверждаете у клиента это ТЗ, получается, просто подкладываете его к договору. Клиент просто надеется на вашу добросовестность, и хорошо если вам везёт с такими. Как правило люди все читают внимательно, либо не читают и потом отмахиваются, дескать, подумаешь бумаги какие-то, давайте делайте.

Ответить
1

А как же договор, этапы, права и ответственность сторон, пени, расторжение договора, дополнительные соглашения?
Или там все на устных договоренностях делается?

Ответить
0

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

Ответить
0

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

Ответить
0

Все примерно так и прописывается. Реальность расставляет всё на свои места.

Ответить
1

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

Ответить

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

0

Коллеги,

1 - любой сдвиг дедлайна должен увеличивать бюджет. В договорах это у всех прописано.
2 - дедлайн сдвигается выставляется счёт, который клиент оплачивает только в 2% случаев.
3 - за отсутствие оплаты клиент приглашается в суд.
4 - бывает даже суд выигрывается (клиент не всегда прав), но денег никто не получает. Посмотрите у топовых агентств сколько бумажно-выигранных судов и сколько денег по ним.
5 - Логично предложить - закладывайте риски в бюджет. Я смотрю прям вся отрасль по 50 000 000 руб за 6 месячный проект выкатывает)

Итого: добро пожаловать в отрасль!

Ответить
0

Вспоминается старый анекдот про гестапо и партизан:
- А потом пришёл лесник и выгнал всех из леса...
Я предсказываю ситуацию 2016 года:
компании InSales и StoreLand захватили 90% рынка веб-разработок России, потому что заказчики отказываются платить более 100 долларов США за разработку своего сайта и ждать более 6 часов, чтобы получить готовый результат.

Ответить
3

Рынок конструкторов и рынок веб-разработки - это разные рынки. Конструкторы существуют уже лет 10 и пока даже на фрилансеров особо не повлияли.

Ответить
0

Вспоминается старый анекдот про гестапо и партизан:
- А потом пришёл лесник и выгнал всех из леса...
Я предсказываю ситуацию 2016 года:
компании InSales и StoreLand захватили 90% рынка веб-разработок России, потому что заказчики отказываются платить более 100 долларов США за разработку своего сайта и ждать более 6 часов, чтобы получить готовый результат.

Ответить
0

Забейте. Это отсутствие компетенций + ментальность.
Отсутствие компетенций у исполнителей.
Ментальность у заказчиков.
Ядерная смесь при которой никогда вовремя ничего сделано не будет.

Ответить

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

–4

Ебаный насос, сколько хайпа вокруг такой постыдной дичи

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