Сколько стоит разработка: 5 мифов о затратах на IT-продукт

«IT-разработка – это слишком дорого», «Невозможно оценить эффективность IT-системы» – это лишь некоторые утверждения, которые говорят о недоверии бизнеса к технологиям. Однако изменения на рынке подтолкнули компании к усилению цифровизации. Мы более 20 лет разрабатываем ПО и сейчас получаем много запросов как на адаптацию готовых IT-систем, так и на разработку собственных уникальных продуктов. Исследуем пять популярных мифов о финансовой стороне IT-разработки и поделимся наблюдениями со всеми, кто планирует создание IT-продукта.

Миф 1. IT-разработка – это всегда сложно, дорого и долго

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

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

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

Другими словами, можно запустить систему, используя 20-30% от общего бюджета. Продажи начнут «отбивать» часть потраченных средств и финансировать следующие этапы разработки. Например, в нашем портфолио есть медицинский проект для сети клиник Великобритании, который мы развиваем более 10 лет. При этом его первый релиз вышел через 8 месяцев после старта. Также был опыт запуска MVP продукта для дистанционного банковского обслуживания крупного сетевого банка за 100 дней. К слову, этот продукт мы продолжаем дорабатывать и дополнять новыми современными фичами.

Миф 2. Можно сэкономить, передав задачи разработки No-Сode-системам

No-Code – это способ реализации IT-продуктов при помощи специальных платформ, без написания кода вручную. Его можно использовать для создания сайта компании, корпоративного портала, интернет-магазина, игрового приложения и других IT-решений. Таким путем родилось немало сервисов и приложений, в основном, зарубежных – Tavalo, Reachr, Look App, Comet и другие.

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

Проведите эксперимент – сделайте прототип или MVP нового продукта на No-Code-платформе. Потом покажите результат своим клиентам или инвесторам, протестируйте вместе с ними, получите обратную связь. Если все устраивает, можно думать, как это развивать.

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

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

Миф 3. Можно «собрать» IT-систему из доступных продуктов

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

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

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

  • Имеют разные возможности кастомизации и интеграции. Некоторые конструкторы, готовые решения, No-Code-платформы никогда не смогут полноценно взаимодействовать между собой. Например, сайт компании интегрирован с платежной системой X, а вендор учетной системы и не планирует такую интеграцию.
  • Отличаются по качеству технической и клиентской поддержки, графику обновлений и т.п. В частности, для конечного клиента, как правило, не имеет значения, что у поддержки сайтов, созданных на разных платформах, разный SLA, и что сервер был недоступен в момент, когда он оплатил заказ. В следующий раз покупатель просто уйдет и не вернется.

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

  • Отвечать текущим и будущим техническим и бизнес-требованиям.
  • Обеспечивать производительность, безопасность и управляемость.
  • Адаптироваться к новым требованиям.

Миф 4. Не нужно переплачивать, соберите команду из джунов

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

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

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

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

  • Требования заказчика: насколько качественно они проработаны, детализированы и сформулированы в окончательной редакции – не планирует ли заказчик их менять.
  • Сложности проекта, его размер и объем задач, помимо кодинга: аналитика, дизайн, различные виды тестирования, CI/CD...
  • Технологический стек.
  • Наличие у специалистов опыта реализации подобных проектов.

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

Миф 5. Нет смысла тратиться на аналитику проекта

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

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

Какие задачи помогает решать Discovery-фаза

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

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

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

3. Стартап-изобретатель – человек из цифровой сферы, который увидел возможность уберизации сложившейся бизнес-модели. В этом случае подрядчик вместе с заказчиком погружается в предметную область, в некоторых случаях – с привлечением научной экспертизы. Далее проводит Customer Development, составляет перечень нужных пользователю функциональностей, определяет приоритеты и описывает наиболее удобные сценарии для пользователей. В итоге, быстро выпускает минимальный жизнеспособный продукт (MVP) для проверки возможности уберизации бизнес-модели в боевых условиях.

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

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

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

Читайте также:

Расскажите коллегам:
Комментарии
CIO, Магнитогорск
Евгений Равич пишет:
Не смог понять отсылку к front end / back end. Есть несколько рабочих подходов к  сокращению бюджета проекта, которые могут помочь заказчмку оценить сложность и риски. Можно поговорить об этом.

Евгений, я пытался пояснить, что когда клиент (ещё не заказчик) выдвигает требования - он мыслит как правило визуальным представлением (экран, форма, картинка, кнопочка), при этом на этапе требований уже часто не знает какая логика реализуется, чтобы две цифры оказались рядом абсолютно разного бизненс-уровня. Как пример приведу: Клиент говорит, хочу видеть в online затраты на материалы, которые цех потратил. Штуки мы оперативно получаем, а стоимость на другом уровне инф.модели. Надо принять некое бизнес-правило. Если это производственное предприятие и длинная производственно-технологическая цепь, то и данные надо "уметь" преобразовать. Всё это и решается не на фронте, а на бэке (уровень СУБД).

И на этапе - "Сколько стоит" - это может от рубля и до бесконечности.

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

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

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

А потом ...опс.... черный лебедь приземлися. 

И тут без посредника (РП -который называется, ну ни как....). Главное, чтобы умел коммуникации настроить и риски проработать.

Генеральный директор, Москва
Юрий Волщуков пишет:
Евгений Равич пишет:
Не смог понять отсылку к front end / back end. Есть несколько рабочих подходов к  сокращению бюджета проекта, которые могут помочь заказчмку оценить сложность и риски. Можно поговорить об этом.

Евгений, я пытался пояснить, что когда клиент (ещё не заказчик) выдвигает требования - он мыслит как правило визуальным представлением (экран, форма, картинка, кнопочка), при этом на этапе требований уже часто не знает какая логика реализуется, чтобы две цифры оказались рядом абсолютно разного бизненс-уровня. Как пример приведу: Клиент говорит, хочу видеть в online затраты на материалы, которые цех потратил. Штуки мы оперативно получаем, а стоимость на другом уровне инф.модели. Надо принять некое бизнес-правило. Если это производственное предприятие и длинная производственно-технологическая цепь, то и данные надо "уметь" преобразовать. Всё это и решается не на фронте, а на бэке (уровень СУБД).

И на этапе - "Сколько стоит" - это может от рубля и до бесконечности.

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

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

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

А потом ...опс.... черный лебедь приземлися. 

И тут без посредника (РП -который называется, ну ни как....). Главное, чтобы умел коммуникации настроить и риски проработать.

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

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

Но именно опытный менеджер проекта должен собрать всё воедино (а исходных данных может быть осень много) и довести проект до желаемого результата. Есть у него шансы - есть. Гарантирован успех - конечно, нет, проектов без рисков не бывает. Знаем ли мы, как сделать лучше, быстрее или дешевле - обычно такие варианты можно найти и обсудить.  Согласны?

CIO, Магнитогорск
Евгений Равич пишет:
Знаем ли мы, как сделать лучше, быстрее или дешевле - обычно такие варианты можно найти и обсудить.  Согласны?

Евгений, однозначно.

Главное - чтобы обе стороны (Заказчик и Исполнитель) смотрели в одну сторону.

Директор по развитию, Москва
Миф 1. IT-разработка – это всегда сложно, дорого и долго

Это не миф. Это факт, по крайней мере в части "дорого" с учетом текущей стоимости человекочаса разработчика.

Также был опыт запуска MVP продукта для дистанционного банковского обслуживания крупного сетевого банка за 100 дней.

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

Кстати, 100 дней, это сколько в фактических человеко днях? Одно дело, когда половина стажера работает 100 дней, другое дело, когда команда из 20 разработчиков по рейту 5000 руб/час. Тогда и увидим как это всё "недорого".

IT-менеджер, Красноярск

Безусловно, это не все мифы, которыми полон мир IT. 

Конечно. Еще можно взять отрицание от ваших 5-и утверждений и написать еще одну подобную статью. 

Инженер, Омск

Теперь настала моя очередь. Для начала цитата:

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

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

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

Сюда же цитата:

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

Как показывает практика, только 5% проектов выходят из "раннего доступа".

При этом его первый релиз вышел через 8 месяцев после старта. 

На заметку автору: Стандартный срок разработки проекта средней сложности занимает от 3 до 6 месяцев. Прикладной программы - не более 3 месяцев. 

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

Инженер, Омск

Далее о No-Code в целом, но сначала цитата: 

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

Идиотское название, если честно, для прикладного софта, который позволяет автоматически сделать те вещи. которые обычно программисты делают в XML, таблицах CSS или набором параметров объектов. 

Делать полигональные модели в 3Ds Max тоже не больно сложная задача, я бы даже назвал её медитативной. 

Рисовать в Photoshop или другом инструменте визуальные компоненты и макеты дизайнеру - тоже не супер сложная задача. 

Более того, даже "рисовать" визуальное окно прикладного приложения тоже не требует написания большого кода. 

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

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

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

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

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

Проведите эксперимент – сделайте прототип или MVP нового продукта на No-Code-платформе. 

На заметку автору: MVP и прототип - это одно и тоже. 

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

А знаете где ограниченний нет? У Лобстера. Я хоть и читал больше мемуары тех, кто сайты писал в обычном блокноте, но был приятно удивлён тому, что есть адекватная IDE для веба. 

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

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

Инженер, Омск

Об кастомизируемых CRM:

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

  • Отвечать текущим и будущим техническим и бизнес-требованиям.
  • Обеспечивать производительность, безопасность и управляемость.
  • Адаптироваться к новым требованиям.

Вообще-то есть вполне себе кастомизируемые СRM, как зарубежные, так и отечественные

Если я не ошибаюсь, то компания Валерия Овсия как раз предоставляет CRM с интеграциями своих модулей на C#. 

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

Партнер, Москва
Александр Ковалёв пишет: Вообще-то есть вполне себе кастомизируемые СRM,

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

Адаптироваться к новым требованиям

Это уже был ответ на ваш текст. А что касается No-Code, то он успешно использовался и раньше при разработке прототипов десктопных приложений. А в инете будет преобладать уже года через 2-3, и займет, скорее всего, 70-80% рынка разработки готовых приложений.

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

Партнер, Москва

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

Хотя меня не убедили некоторые аргументы, но стоит поставить лайки автору за такую дискуссию. Это было полезно ещё раз взглянуть на текущие перспективы и проблемы отрасли. 

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Mini dsc 0050 3 sq 2
Сергей Средний
Забейте тогда.А я научился, понял и оценил концепцию. И просто кайфую от качества ресурса и возм...
Все дискуссии
HR-новости
Самые странные корпоративные правила: итоги опроса россиян

Общий поход на обед отделом, пение корпоративного гимна и кормление животных в офисе – попали в топ странных офисных правил и традиций.

Россияне назвали самые престижные и доходные профессии

В лидерах – работники сферы IT и государственные служащие. 

Владелец «Л’Этуаль» полностью выкупил сеть магазинов косметики «Подружка»

В России работает 287 магазинов сети «Подружка».

Стать предпринимателем пробовал каждый третий в мире

Доля заинтересованных в развитии своего бизнеса выше в странах Латинской Америки и в Индии, ниже — в Японии, Нидерландах, Бельгии, Швеции.