{"id":9280,"title":"\u0422\u0435\u043b\u0435\u043f\u043e\u0440\u0442\u0430\u0446\u0438\u044f \u0440\u0435\u043a\u043b\u0430\u043c\u043d\u044b\u0445 \u043a\u0430\u043c\u043f\u0430\u043d\u0438\u0439 \u0438\u0437 \u00ab\u042f\u043d\u0434\u0435\u043a\u0441\u0430\u00bb \u0432 Google","url":"\/redirect?component=advertising&id=9280&url=https:\/\/vc.ru\/promo\/321806-kak-ne-zamorachivatsya-s-reklamnoy-kampaniey-i-bystro-nastroit-ee-v-google-obyasnyaem-v-5-50-i-500-slovah&placeBit=1&hash=99a73b9041aba100376a41bce39d118cf714c283ce1c8288a963bcb51cdcdade","isPaidAndBannersEnabled":false}

Impact mapping, юнит-экономика и PDCA: грамотное управление разработкой ecommerce

Я Андрей Путин, генеральный директор kt.team. Наша компания занимается разработкой сложных ИТ-решений (высоконагруженные интернет-магазины, b2b- и b2g-порталы, продукты с машинным обучением, дополненной и виртуальной реальностью и многое другое).

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

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

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

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

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

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

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

Движение маленькими шагами и цикл Деминга

Эдвард Деминг сформулировал модель непрерывного управления качеством PDCA: plan — do — check — act («планирование — действие — проверка — корректировка»). Цикл PDCA тесно связан с философией agile и также призывает нас действовать короткими итерациями, находиться в тесной связи с реальностью и каждый раз проверять, идём ли мы в нужную сторону.

Чтобы разработка продукта была эффективной, необходимо:

  1. Чётко сформулировать цель, наметить план (plan).
  2. Совершить нужные действия в соответствии с планом и целями (do).
  3. При каждом обороте колеса (каждом цикле разработки) регулярно проверять, в правильном ли направлении мы движемся (check).
  4. Если наши действия не приближают нас к цели, скорректировать их в нужную сторону (act).

Похоже на принципы разработки MVP, правда?

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

Но есть эффективные способы, которые помогут добавить ясности и упорядочить работу. Давайте подробно рассмотрим методику Impact Mapping и юнит-калькулятор как один из прикладных инструментов DDDM (принятие решений на основе данных, data-driven decision making).

Impact Mapping

Метод Impact Mapping помогает чётко формулировать цели проекта в соответствии с целями всего бизнеса. Для этого нужно построить интеллект-карту с ответами на четыре главных вопроса.

  1. Why? Зачем нужен этот продукт? Какую задачу бизнеса он должен решить?
  2. Who? Кто может влиять на достижение этой цели?
  3. How? Что он может сделать?
  4. What? Какие конкретные шаги должен сделать ответственный в рамках своих задач?

Пример работы метода Impact Mapping

Типичные проблемы в управлении разработкой, от которых спасает Impact Mapping

  1. Излишняя функциональность
    C Impact Mapping на виду ценность каждого действия. Если ценности нет, значит, решение избыточное, нужно от него отказаться.
  2. Несогласованность действий, отсутствие контроля и координации внутри компании-заказчика
    Для ответа на вопрос «кто» нужно определить всех, кто влияет на решение проблемы. Руководители производственного отдела и отдела продаж, маркетологи и логисты, любые другие сотрудники, которые могут влиять на продукт разработки и итоговое достижение целей, должны как минимум встретиться и обсудить все задачи. Зона ответственности каждого будет записана в карту влияния (impact map). Это упрощает контроль над выполнением решений.Что бывает, если пропустить этот шаг, рассказываем в следующем кейсе. Мы делали b2b-портал для оптового поставщика продуктов питания. Заказчик описал нужную функциональность, но оказалось, что в жизни всё работает не так, как в его мечтах. Узнать об этом удалось только при тестировании продукта одним из департаментов, который никто не посчитал нужным привлечь к созданию технического задания (отдельный вопрос, зачем им вообще понадобилось техническое задание). Запуск проекта пришлось отодвинуть.
  3. Трудно сравнивать варианты выбора
    Для каждой цели в Impact Mapping группируются все возможные варианты достижения этой цели. После проведения анализа и сравнения их эффективности на конкретных KPI и OKR можем быть уверены в правильности своего решения (и никаких мук выбора).
  4. Сложно планировать время и бюджет на разработку
    Пожалуй, это самый распространённый страх заказчиков перед гибкими методологиями в разработке. Но когда все действия разбиты на шаги, планировать гораздо легче, правда? Если выполнять работы короткими итерациями (например, в две недели), соблюдать цикл PDCA, регулярно сверять свои действия с целями, быстро вносить корректировки при отклонениях, согласитесь, будет легче добиться успеха, чем при горизонте планирования в год или пятилетку.

Главное последствие использования карт влияния — чёткое решение бизнес-задач заказчика, а не функциональность ради функциональности.

Пример Impact Mapping для интернет-магазина одежды и обуви

Допустим, в ИТ-компанию приходит заказчик — владелец крупного интернет-магазина одежды и обуви с запросом на срочный редизайн сайта.

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

Сначала нужно спросить зачем и определить цель проекта, затем оцифровать её, записать в числовом выражении. Иначе будет невозможно оценить результаты и сделать выводы («мы молодцы, достигли цели» или «мы не смогли достичь цели, давайте думать, почему и как это исправить»).

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

Проектным менеджерам необходимо сделать Impact Mapping вместе с заказчиком, и картина может получиться такой: добиться увеличения продаж на 1,5% можно четырьмя способами.

Метод Impact Mapping можно применять и для b2b-проектов, например оценивать процент использования портала при заказах (в идеале — 100 %). Для CRM- или BPM-системы целевым показателем может быть процент пользователей, работающих в CRM, от общего количества сотрудников.

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

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

Юнит-калькулятор

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

Юнит-экономика наглядно показывает рентабельность каждого изменения в проекте или проекта целиком: сколько зарабатывает (или теряет) бизнес с каждого заказа, с каждого пользователя, каждого конечного покупателя.

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

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

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

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

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

Свежий пример

Сейчас мы работаем над ecommerce-проектом для крупного ювелирного бренда. Оплата заказов в их интернет-магазине ведётся на сайте банка. Клиент хочет переделать чекаут и сделать форму оплаты прямо на сайте.

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

Основной проблемой может стать отсутствие аналитики. Что делать, если никто никогда не отслеживал, какой процент потенциальных покупателей «отваливается» на шаге оплаты? Действительно ли оплата через сайт банка плохо влияет на продажи?

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

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

Что делать после оценки и сравнения всех способов достижения цели?

  1. Если у фичи, предлагаемой клиентом, нет значимой роли,
    наличие этих сведений может помочь клиенту изменить приоритеты бэклога.
  2. Если юнит-калькулятор показывает, что изменение конверсии даже на 0,01 % даст значимый финансовый результат,
    начинать улучшения стоит с самых узких мест воронки продаж. Но далеко не всегда конверсия — главный фактор. Иногда лучше сначала поработать с retention (удержанием) или обеспечить проект качественным трафиком, и только после этого возвращаться к разработке фич.

Вывод

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

После работы с ФРИИ (Фондом развития интернет-инициатив) мы твёрдо усвоили, что составлять Impact Mapping и считать юнит-экономику каждого проекта необходимо до старта работ. И потом при внедрении любых новшеств постоянно их пересматривать и пересчитывать.

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

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

0
31 комментарий
Популярные
По порядку
Написать комментарий...

 Я Андрей Путин

это сразу звучит гордо, впечатляюще и  масштабно! ред.

11

ну вот. Я про PDCA и запутанные среды, а вы опять про Путина! ;)

3

Моль

0

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

2

все интернет-магазины с оффлайновой сетью могут позволить.

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

3

Чтобы посчитать юнит-экономику, не нужно быть ни математическим гением, ни ярдовой компанией.

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

Для этого есть огромное количество практик для этого (тактические: юнит-экономика, Матрица Эйзенхауэра, Scrum Planning Poker, стратегические: Impact Mapping, юнит-экономика).

Часто клиенты убеждены, что разработка сама по себе без нормального целеполагания даст экономический эффект (вот эти вот все "Лишь бы сделать правильную архитектуру", "Сделать UX дизайн", "Реализовать фич больше чем у конкурента"). Не удивительно, что этого не происходит. И чтобы решить эту проблему, клиенты начинают использовать методики упорядоченных систем (техническое задание например).

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

3

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

0

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

Если мы говорим про e-commerce, то:
весь сайт разделяется на этапы воронки (страница - этап, сложные страницы - много этапов. Например, оформление заказа можно разбить с детализацией по каждому заполненному полю, но для старта подойдет и просто понимание конверсии в чекауте)

Определяем конверсию по разным сегментам. Интересуют два: C1, CN (первый покупатель, последующие покупки).

Всё, данные настроены.
Мы часто сталкиваемся с запросами о том, что клиентам нужна аналитика более серьёзная. Иногда это оправдано, часто - нет, потому что слабая аналитическая культура при любом, самом продвинутом инструменте (AA, OWOX, etc) всегда остаётся слабой культурой. Так что если сейчас никакие данные не используются, начните с самых простых инструментов и далее можно усложнять.

Очень частая ошибка в измерениях C1/CN. Это легко исправляется)

0

Я имею в виду, что повышение конверсии формы на 10%, допустим, со 100 до 110 заказов, может быть связано как с изменением формы, так и с изменением ценности предложения (у других сейчас дешевле/нет/плохие условия доставки и т.п.), суточной/недельной и выше динамикой спроса, погодой, праздниками, новостями, изменением характера трафика или вообще входить в стандартный разброс.

А у небольших ИМ сегодня 30 заказов, завтра 50, послезавтра 10. А/B тестирование на таких величинах не сможет подтвердить эффективность решения, а при расширении времени теста до, скажем, 1 мес. на измеряемый показатель начинает оказывать влияние целый набор переменных (в нач. месяца товар стоил А, сейчас А+А*10%; в нач. месяца оставалась зп, сейчас - нет, да и трафик стали получать с нового канала и т.п.) К тому же мы не имеем оснований сравнивать этот месяц ни с прошлым, ни с прошлогодним, потому что это совершенно другие периоды со своими условиями. 

Словом, малые выборки показательны только на периодах, когда они становятся большими, однако на больших периодах возрастает количество и роль неизвестных факторов. Ведь так? ред.

2

Это да. На маленьких цифрах (маленький трафик, малое количество заказов, маленькая история измерения) сложно делать выводы на причины.

Несколько соображений конкретно по интернет-магазинам:

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

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

Не станем говорить про A/A/B тесты потому что у маленьких проектов нет денег на поддержание сложной инфраструктуры с тремя версиями проекта (мы же говорим про целеполагание в разработке, с маркетингом можно обойтись только GTM+Google Experiments)

1

Комментарий удален по просьбе пользователя

2

Более 142 млрд евро ЕС за 2004 год потратил денег на разработку, которая не привела ни к каким целям. Как видите, это не только в России происходит. Почитайте Сазерленда - он начинает с неудачного кейса в ФБР, которые десять лет разрабатывали софт. Миллиарды долларов потрачены. Цели расписаны не то чтобы на 2 листа - тома бумаги исписаны. А результата не было. В запутанных средах конвейер не работает.

1

Комментарий удален по просьбе пользователя

2

Эх, буквально позавчера смотрел ваш сайт и типовой расчет проекта, увидел 1+ млн в ценнике и вспомнил, что хорошее стоит дорого. Но data driven - это круто.

1

5млн стоит у них интернет-магазин на Magento))

КП просто смех, без обид.

2

Не помню чтобы мы с вами работали..

Не удалось мне в статье донести мысль о том, что "интернет-магазин на Magento" - это не столько разработка, сколько целеполагание. Будем стараться больше.

1

Это не беда, деньги - вторичны.

Убежден, что практики IM/UE можно и вовсе без денег внедрять. Если есть желание - всё будет. Ни деньги, ни количество разработки само по себе к результату ведь не ведет.

0

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

0

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

0

Хорошо, что врачи не работают по методам, которые вы предлагаете.

Иначе бы это было примерно так:
- Доктор, у меня зуб болит, что делать?
- На методы лечения вы сами налегайте, а я могу дырку просверлить. Говорите какую, где.

1

Согласен.
Я думаю к лечению 99% бизнес принципов не применимы. К админ управлению мед средой - да, можно, но лечение в целом это своя вселенная.
Хотя уже пытаются дистанционно лечить...

0

Impact mapping, юнит-экономика и PDCA

Эйджаил, скрам и САУ
Теперь твоя очередь называть ещё три нерабочих технологии

–2

"крэкс, пэкс, фэкс"

Кстати, иногда работает, у фокусников

1

Если оно у вас не работает, значит вы не в том культурном пласте находитесь, или нарушаете техники. Чаще - всё вместе.

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

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

1

У меня диплом есть по TPS, по секрету скажу - там всё куда сложнее, чем ты думаешь. Даже супер азы, которые я за жалкие 40 часов обучения получил - и то выше всяких этих Эйджайлов. 

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

Но это никак не подтверждает ценность перечисленных мной "бесполезных практик" 

0

Цветовая градация придумана не нами, а мистером Грейвзом.

Есть в вики, оттуда взял эту ссылку https://romankalugin.com/teoriya-spiralnoj-dinamki-razvitiya-lichnosti-i-chelovechestva-ot-klera-grejvza/

0

Заказчик: Нам нужно выполнить заказ, вы готовы?

Путин: А давай - те подумаем ....

0

Не совсем так ))

Заказ в запутанной среде (разработка ПО) и упорядоченной (простой, типа производства гамбургера, или сложной, типа производства моста), требуют разной квалификации.

Поэтому когда мы обсуждаем заказ, мы начинаем ориентироваться на важные цели клиента, составляя Impact Mapping (иногда мы его составляем, но клиент с этим не работает - часто встречается с крупными компаниями). Я считаю, что все-равно успех проекта должен обеспечиваться разработчиками. Иначе через год разработчики отползают от проекта: "мы просто делали ваши задачи. Откуда же нам было знать, что вы не зарабатывали на этих решениях". Вы же к врачу не приходите со списком: "прооперируйте мне тут и вот тут, и еще промывание желудка сделайте"? Вы приходите с задачей, а он обеспечивает решение. Так же должно быть и с инженерами, если они не хотят носить звание "кодер".

0

Не читал статью, но с бюджетом в 50к запустил за 5 дней магазин детских игрушек, причем база в 1С (уже была там)и нужно было ее интегрировать.

В декабре с маркета конверсия 12%, дрр 2%, заказов было чуть меньше 1000 (когда вышел сегодня из офиса было 983) это с учётом, что номенклатура меньше 50 позиций, если не ошибаюсь в пик было одновременно 47 товаров в наличии.

0

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

0

15-25% чистая прибыль с учетом логистики. Но такой фурор легко списать на новый год. Я именно про сам факт того, что возможно творить волшебство, если что я "маркетолог" наемный рабочий.

0

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

Читать все 31 комментарий
Глава американской компании Better.com уволил 900 сотрудников одним видеозвонком Статьи редакции

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

Я пришёл к вам с плохой новостью. Рынок изменился, как вы знаете, и мы должны двигаться за ним вперёд, чтобы выжить, процветать и исполнять нашу миссию. [...] Я делаю это второй раз в своей карьере и не хочу повторять. В последний раз, я плакал, но на этот раз надеюсь быть сильнее. [...] Если вы сейчас смотрите это, значит вы в той невезучей группе, которую увольняют.

Вишал Гарг
SkillFactory раздает подарки: повышенная ставка и новогодний марафон для вебмастеров

В преддверии Нового года мы решили порадовать своих настоящих и будущих партнеров — участников партнерской программы школ Skillfactory, Contented и Product LIVE. Это возможность получить денежный бонус и заодно увеличить прибыль от продажи наших курсов.

Агрегатор "Яндекс.Еда" не возвращают оплату за заказ, которого не было

Здравствуйте! Ситуация следующая, 22.10.2021 г. я сделала заказ у агрегатора доставки "Яндекс.Еда". Доставка из Магазина "Магнит". В момент списания оплаты с банковской карты за заказ заметила, что адрес доставки товара указан с ошибкой. В заказ проставился рабочий адрес, а не домашний, ехать на автомобиле от дома до работы мне 10 минут, пешком…

И сотрудников тоже касается: кибербуллинг на рабочем месте
Design vector created by pikisuperstar - www.freepik.com
«Неслучайная случайность», или как рождаются крипто стартапы на примере Freya

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

re:Store продал Macbook Pro с раскладкой azerty и серийный номер ноутбка не совпадает с серийным номером на коробке
Яндекс плюс снимают деньги и не оформляют возврат.Сотрудники компании не отвечают

Произошла неприятная ситуация с Яндекс плюс,причём во второй раз.С банковского счёта было списано 299₽,в самом профиле никакой подписки нет,тогда вопрос,за что снимали?Обратилась в поддержку ,заполнила форму-отказ ,хотя я приложила все доказательства и чек.Написала в чат ,попросили выслать номер карты,со второго числа никто не отвечает,писала уже…

Продавец eBay из Кургана стала победителем в финале Всероссийского конкурса «Молодой предприниматель России 2021»

27 ноября в Москве состоялся финал ежегодного конкурса «Молодой предприниматель России 2021». В нём приняли участие предприниматели и самозанятые в возрасте до 35 лет. Всего было подано более 300 заявок из 43 регионов страны.

Дайджест новостей Сбера: сайт Digital Пётр, сценарии для умного дома и платина от Forbes

Прошлый дайджест мы целиком посвятили 180-летию Сбера, поэтому новостей накопилось много. Среди них — запуск сайта по распознаванию рукописей Петра I, большое обновление на платформе умного дома Sber и другие. Рассказываем всё самое интересное.

Картинка, сгенерированная ruDALL-E по запросу «рыжий котик»
Хоум кредит про меня забыли. Долг с 2009года

Решил я значит проверить свою кредитную историю на одном из известных ресурсах. И что я обнаружил? Действующий долг в #хоум_кредит с 2009 года и как следствие краснющую историю! Я конечно же позвонил в эту контору, говорю каким образом банк забыл про меня? - а вы знаете? Мы вам звонили звонили... но не дозвонились ... Так же как и вашим…

Доказал, что миллиардеры не видят разницы между вином за $500 и $10 тысяч: история Руди Курниавана Статьи редакции

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

Руди Курниаван LA Times
null