Оффтоп Albert Khabibrakhimov
8 626

«Почти всегда есть способ проверить идею без кода»: что нужно знать о разработке продукта в стартапе

Опыт основателя сообщества разработчиков DOU и сервиса по поиску работы для программистов Djinni Максима Ищенко.

В закладки
Что я узнал о разработке продукта в стартапе:

1/ Опасайтесь хороших инженеров.
2/ Пока у вас нет product-market fit, у разработки одна задача – проверка гипотез и быстрые итерации. Хорошие инжен… https://t.co/Ao3KKIUi7H
3/ Фичи зло. Каждая фича – это время на разработку, неизбежные баги, усложнение продукта. Пока нет product-market f… https://t.co/zORBItPPF3
4/ Лучший код – это код, которого нет. Почти всегда есть способ проверить идею без кода: интервью с пользователями,… https://t.co/PH3lo2Sq98
5/ Если можно не нанимать, надо не нанимать. Ваше понимание продукта и пользователей меняется быстрее, чем вы успев… https://t.co/21rlQNJc5f
6/ Все, что можно купить, надо покупать. Емейл рассылки, аналитика, у нас даже была подписка на сервис для загрузки… https://t.co/rk9lVisQGL
7/ Итерации надо делать после релиза, а не до. "Проверка" идей без живых пользователей это самообман.

https://t.co/o19nhaFkln
8/ Everybody lies, включая пользователей. Пользователи говорят то, что по их мнению вы хотите услышать. Мне когда-т… https://t.co/WbWP5lcLq8
9/ Еще лучше не спрашивать, а смотреть метрики и что пользователи реально делают в продукте. Это тема для отдельного поста.
10/ Когда я искал бизнес-модель Джинна, пользователи мне говорили, что готовы платить за отправленные сообщения и н… https://t.co/9osXeluQ2F
11/ Для проверки гипотезы с оплатой бонуса я сделал поп-ап для некоторых профилей "начиная общение с этим кандидато… https://t.co/gd7jxUJ1x0
12/ После нахождения product-market fit нужно разгребать технический долг. Приводить в порядок код, инвестировать в… https://t.co/VDN0dzfv21
13/ Даже самый лучший продукт не взлетит, если о нем никто не знает. Дистрибуция (маркетинг) >> продукта, нельзя об… https://t.co/EK4qE3lBqX
14/ End. Предыдущая серия:

https://t.co/dD0Stxl67I
{ "author_name": "Albert Khabibrakhimov", "author_type": "editor", "tags": [], "comments": 48, "likes": 45, "favorites": 104, "is_advertisement": false, "subsite_label": "flood", "id": 38327, "is_wide": false, "is_ugc": false, "date": "Sat, 19 May 2018 13:05:57 +0300" }
{ "id": 38327, "author_id": 53259, "diff_limit": 1000, "urls": {"diff":"\/comments\/38327\/get","add":"\/comments\/38327\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/38327"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199791 }

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

Популярные

По порядку

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

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

Ответить
7

Увы, для многих (тех кто не из ИТ но хочет туда) это совсем-совсем не очевидные вещи.

Ответить
0

Зря вы так - в подборке известных фактов есть определенная ценность! Даже авторское право защищает сборщиков БД

Ответить
23

1/ Опасайтесь хороших инженеров.

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

Ответить
0

Ну вот я такой инженер. Я радостно и незамутнённо, воззрев, внедрял TDD, BDD, Docker, CI, ELK, DevOps, микросервисы, бессерверную архитектуру, impact mapping, в самые неподходящие проекты на самых неподходящих стадиях. Разработчиков проектов было чаще всего... 1.

С Docker-ом я бегал еще во время версии 1.5, kubernetes раскопал когда он еще только вылупился из Гугла, docker cloud разворачивал, когда он еще был tutum.

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

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

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

Ответить
1

А с чего Вы взяли, что можете называть себя "хорошим инженером"? ;)
Вас же самого смущают результаты. Что же тут "хорошего"?

Ответить
0

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

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

Так что мы сравниваем мягкое с теплым

Ответить
1

Вы совсем не подходите под хорошего инженера, сорри)) хороший инженер - это не инженер , стремящийся напихать в резюме кучу модных названий , это не инженер который херачит от забора и до обеда kubernetes, docker , ci , tdd ,agile, scrum, data driven Прости Господи . Хороший инженер это инженер который умеет грамотно применить нужные технологии для скорейшего решения конкретных продуктовых зпдач, работая в коллаборации с продуктологами и делая полезные вещи, а не кульные сорян)

Ответить
0

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

Ответить
0

ха, с какого перепуга ты решил что ты хороший инженер?

Ответить
12

> 1/ Опасайтесь хороших инженеров.

Опасайтесь инженеров с мышлением "крупной компании" — на любой стадии работы над стартапом. Такие люди нужны уже когда компания вырастает из понятия стартап, т.е. когда найден пресловутый product-market fit и нужно закладывать надёжный каркас.

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

Ответить
6

Фишка в том, что до поиска product/market fit программировать бы вообще надо по минимуму. Это очень сложно было в себе отдирать, но не надо. Надо быстро проверять гипотезы и разговаривать с клиентами, и научиться доставать клиентов

Ответить
0

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

Ответить
1

Согласен. Хорошие идеи взлетают при сборке даже из говна и палок, зато своевременно

Ответить
14

А я поклонник MVP про который здесь речь.
В тему можно почитать статью (Законы Акина) законы космической инженерии и одно из лучших правил:
40. (Закон Мак-Брайена) Не надо улучшать то что ещё не заработало.

Ответить
9

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

Ответить
10

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

Ответить
3

Эта статья - про стартапы, то есть про проекты, в которых нет доказанной ценности для потребителя и бизнес-модели.

Все что перечислено - это не стартапы.

Ответить
0

Особенно яркий пример — рабочая группа NASA, отвечающая за космический софт (забыл, как называется). Вот где водопадная инженерия)

Ответить
11

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

Ответить

1

Везде баланс нужен.

Аминь. Всё хорошо в меру.

Ответить
5

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

Ответить
4

Какие это "лучшие практики", которые позволяют "легко менять архитектуру"? Очень интересно, расскажите. Единственная "best practice", которая ускоряет разработку - это проект на основе готового и настроенного шаблона, у которого сразу будет хорошая архитектура под однотипные проекты, потому что только хорошая позволяет "легко добавлять фичи", во всех остальных случаях каждая новая фича приводит ко всё большему бардаку и замедлению разработки, и каждому прогрессивному манагеру придётся молиться, чтобы стопорящей оказалась не та фича, которая этот бардак окончательно разрушит за день до финального релиза. Сколько я уже таких проектов и повидал, и наслушался, и навиделся слёз труманагеров. Не одна студия от этого развалилась.
Автор был абсолютно прав, что после нахождения "минимально рабочего прототипа", его код надо сразу же даже не просто привести в порядок, а полностью переписать большую его часть, т.к. на быстрых прототипах продукта не построишь. И так же верно, что люди, делающие прототипы и реальные продукты - абсолютно разные люди даже просто по психотипу.

Ответить
2

Принцип модульности а также такие шаблоны проектирования как Singlton, MVVP, VIPER, MVC, REdux/Flux и другие, которые при правильном и грамотном использовании где нужно, дают хороший способ адаптироваться к изменяемым требованиям, а методики управления проектом, а не говорю про agile, кроме ещё и другие есть.
А вот использование шаблона путь вникуда, прямой проигрыш.

Ответить
9

Господи, ты хоть понимаешь, что всё перечисленное и является частями шаблона поверх фреймворка и просто принципами хорошего прогинга? Это вообще не архитектура конкретного приложения и перегруз начинается не из-за того что ты не разделишь на модель и представление лол. Точнее если этого не сделаешь, то конечно запаришься, но ни один минимально адекватный прогер не будет этим пренебрегать, а фреймворки делают большую часть перечисленного автоматом, речь не об этом вообще. Аналогично с комментариями, тестами итд, о чём написал Valery Fv - всё это просто хорошие подходы, без которых стыдно лезть в дело, но они никак не помогут "легко менять архитектуру", и не помогут даже очень хорошим и умным парням писать нормальные продукты.

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

Есть такая штука: "обратная совместимость версий АПИ". Хз можно ли что-то по теме нагуглить, но те кто апишками занимаются понимают, что это практически чистое воплощение проблем возникающего бардака, о котором я говорю.

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

Можно либо сделать прототип, либо сделать нормальную версию. И даже нормальную версию когда-нибудь придётся переписать. Так происходило со всеми мало-мальски долгоживущими проектами.

> а также такие шаблоны проектирования

> А вот использование шаблона путь вникуда

Лишь бы поспорить.

Ответить
0

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

Ответить
0

Что за мода везде Вайпер пихать-то?? Даже в MVP из трёх сцен! Нуёмаё! ;) Чуть речь зашла о структуре, так сразу кто-нибудь да и напишет ;) извините. Наболело.

Ответить
0

Да кто сказал использовать Вайпер в прототипе? Мой ответ на предмет, что любую можно выстроить гибкой, грамотно и правильно примененяя нужны ШАБЛОНЫ ПРОЕКТИРОВАНИЯ. Это не принцип хорошего кода) А ответ к тому, что использование шаблонов тупо кода на том codecanyon, быстро да, дёшево, но с орагнизаццией кода там полная лажа.

Ответить
0

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

Ответить
1

Ну, это я в курсе, все ему есть своё место) Вот как раз таких инженеров, кто простые вещи делает сложно и надо опасаться.

Ответить
1

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

Ответить
0

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

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

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

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

Ответить
2

На стадии "поиска product/market fit" рановато иметь команду разработки

Ответить
0

Во! А что это бы это была за команда? Каковы ее компетенции? А каковы ее инструменты?

Это в преддверии замены собственно программистов интеллектуальными машинами ;)

Ответить

1

Идеальное решение по ТРИЗу — ничего не создано/сделано/добавлено, а проблема решена ;)

Ответить
5

Забавно слышать, что хорошие инженеров думают о тестах, архитектуре и тп. И таких людей ни надо.
Такой дилетантский взгляд хочу сказать. Хороший инженер думают об этом как раз чтобы сократить время разработки, сделать продукт гибким и масштабируемым как раз ко всем фичам, ну и естественно, чтобы отладку и нормальную работу хоть как то можно было гарантировать.
А вот ебашить неповоротливое говнокодище, вот это да, быстро и непонятно что с этим делать, из-за чего сначала легко, а потом не знаешь как простейшие изменения внести, чтобы это не наелось пирогом.
Далее, говорим про маркетинг, но сколько можно считать пользователей сервиса, скопищем идиотом, которые будут работать с прототипом. MVP нормальное сделайте и народ к вам подтянется.
А сделать MVP за меньшие деньги и качественно, если думать головой и хнами, что предлагать своим пртенциональным клиентам.
Большинство стариаперов того, что выше начинаются и начинают лепить все подряд, не понимая, зачем оно вообще нужно, по принципу главное Продать, а потом посмотрим.

Ответить
6

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

Ответить
0

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

Ответить
0

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

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

Ответить
0

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

Наваял из говна и палок - и на рынок. Если взлетело - переписал уже по феншую: TDD/CI, Docker, microservices и прочий DevOps

Ответить

1

я бы сказал: не слушайте тех, кто не делает то же, что и вы

Ответить
3

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

Ответить

0

хороший инженер == кодер
не хороший инженер == кастдевщик
Так? Или, если не так, то как же?
Какую-же изумительно богатую почву для бесконечной полемики даёт расплывчатое начальное утверждение! А если ещё и в самой полемике использовать расплывчатые понятия (ну, всем же известна чёткая грань между кастдевщиками и кодерами, ага), то беседа обретает невиданные краски! ;)

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

Ответить

0

Правильный ответ: и то, и другое, в зависимости от приоритетов бизнеса. Хороший инженер должен уметь в оба варианта.

Ответить

0

Вот так появляется вал никому не нужных продуктов со средней функциональностью. Особенно порадовал пост про тестирование, похоже maxua не знает про unit и instrumental тестирование, не говоря уже об a/b тестов

Ответить
0

Эм. WAT? Какое нафиг unit тестирование на этапе прототипа и пробного выхода на рынок? Тестируют тут не код, а проект на предмет востребованности! Код тут вообще не важен, лишь бы прототип работал.

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

Ответить
0

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

Ответить

0
{ "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": "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-уведомления
{ "page_type": "default" }