Если стартует девелопер, то его цель - красивый продукт в портфолио. Он:

- решает свою личную задачу;

- пишет так, чтобы его код максимально высоко оценили;

- пишет "по фану" т.е. использует то, что любит;

- пишет чтобы "было круто".

В итоге такие продукты получаются в целом хорошими, но их эффективность крайне низкая. Потому что целью эффективность кода у нас сегодня разве что в HighLoad заморачиваются... И причины этого мы рассмотрим на варианте 2 - когда Продукт создает менеджер. Менеджер продукт написать не может, поэтому накопив Х денег он ищет девелопера, который ему пишет продукт. R&D в разработке продукта идёт лесом, потому что разработчиков мало и Продукт пишет тот, кто попался под руку на том, что умеет. Но пишет он не за идею, а за деньги т.е. лишь бы заплатили.

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

Это конечно плохо... Но почему именно так происходит? В ИТ очень много технологий. Каждая технология, как и в реальном мире, имеет области где она лучшая, а так же области, где она полное УГ. Аллегория - молоток, отвертка и ключ. Молоток забивает гвозди, отвертка вкручивает саморезы, ключ закручивает болты. Всё ОК, всё правильно - каждая задача решается наиболее подходящим инструментом. В ИТ набор инструментов... ОЧЕНЬ большой, жизнь далеко не бесконечна, а с учётом скорость изменений в области из всего разнообразия инструментов можно взять буквально несколько штук. Потому что каждый "инструмент" как правило имеет "Инструкцию для чайников" на 1000+ страниц. А для нормальной работы таких инструментов нужно 3 - 5 - 7 штук и для их практического освоения нужно хотя бы 6 - 7 месяцев на каждый. Красноглазики, которые освоив инструмент идут осваивать следующий есть, но как и в случае с "педагог - это призвание" их - единицы. А у нас сегодня даже с "лицами называющими себя ИТ-специалистами" пиздец какой дефицит кадров.

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

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

Если абстрагироваться от реальности то любой проект должен пройти стадии:

- постановка технического задания на основе маркетингового исследования. ТЗ в лучшем случае просто есть и это мнение одного человека "как мне будет удобно", но не редко его нет вообще.

- R&D. Каждый продукт - уникальный, поэтому ключевые решения должны быть отработаны заранее. Чтобы понимать какие "инструменты" и как именно должны быть использованы. В реальности что-то похожее на R&D в компаниях иногда бывает, но больше в порядке частной инициативы сотрудников.

- проектирование Продукта. ВНЕЗАПНО, как и любое другое решение ИТ-продукт нужно проектировать. Как дом. На практике на это забивают чуть чаще, чем всегда.

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

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

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

- бета-тестирование. Это когда не стыдно показать друзьям/знакомым.

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

- выпуск Продукта. Начало продаж.

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

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

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

А как же тестирование? Тестирование это обязательная часть любого действия начиная со стадии MVP.

И теперь вооружившись суровой правдой мы переходим к основному вопросу поста. Пойдём так же по стадиям.

- техническое задание. Которое может в итоговом виде писаться годами уже готово. И даже есть все ключевые показатели проекта и вся готовая маркетинговая информация. Итоговая стоимость ТЗ проекта веб-портала уровня ОЗОН это минимум 5 - 7 млн. руб. Которые нам уже не надо тратить.

- R&D. В отличии от команды ОЗОНА / ВБ все ключевые параметры проекта уже опять же известны. Можно спокойно и быстро программировать стенд и отрабатывать решения под конкретные условия. Экономия здесь, для масштабного продукта - десятки миллионов.

- проектирование. Опять же - копировать всегда проще, чем придумывать "с нуля". По факту нужно просто натянуть результаты R&D на ТЗ. Основной бонус проектирования в том, что из-за большого разброса инструментов и того факта, что у каждого из них есть свои + и -, угадать сразу нужный стэк почти невозможно. Поэтому до 80% бюджета ИТ продукта может уходить на затыкание деньгами дырок в ошибках проектирования.

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

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

- сопровождение продукта. На практике 99 % работы техподдержки, это результат того, что делали сперва ежа, потом начали делать ужа, а продаём 2 метра колючей проволки (как я уже писал, это обусловлено объективными причинами). Поскольку у копии большая часть вопросов решена на более ранних стадиях, то и этот этап будет гораздо дешевле.

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

Итак, кто-то решил построить "доходный дом". То есть дом, который он будет сдавать. Денег у него есть, допустим на 1 этаж и 40 кв.м. Построил. Сдает. Накопились деньги, пристроил ещё 40 кв.м. Потом ещё. Потом ещё. Участок кончился. Надстриваем 2 этаж. Хотим 3, но фундамент уже трескается. Укрепляем фундамент, надстраиваем 3 этаж...

...

Через Х времени у нас 120 этажный небоскрёб из 1000 разных кусочков, который держится исключительно на говне и палках. И тут у нас как раз текущая ситуация.

Мы знаем уже готовый результат, мы знаем практику эксплуатации, у нас есть готовые клиенты. И мы вполне можем просто построить точно такой же небоскрёб, но в десятки, а то и сотни раз дешевле. Фундамент сразу на 120 этажей, а не на 1 и 120 укреплений, стены сразу как надо без пристроек и т.д. и т.п.

И к вопросу о переводе в "общественное достояние"... Вы бы хотели отдавать в публичное пользование "120 этажный небоскрёб из 1000 разных кусочков" зная, что вам потом будут косточки перемывать и называть рукожопом? Нахрен надо.

Почему сразу не делают нормально? По одной простой причине. Когда начинается новый проект никто не знает каким он будет через год, 5 - 10 лет. Делать сразу "под 120 этажей" это безумно дорого. По факту проект под высокие нагрузки стоит как минимум в 10 раз дороже. Если проект станет мегапопулярным, то эти х10 довольно быстро окупятся, а если нет?

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

Во-первых на время перехода прекращается добавление новых фишек, а это могут быть годы. Совмещать два проекта, это полный п%здец, почитайте, например, про переход с Python 2 на 3 .

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

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

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

В-пятых это в целом ни разу не дешевое удовольствие.

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

Если же всё сделано как надо, то это огромный плюс для бизнеса. Например, был в практике переход сравнительно небольшого проекта. Переход занял 4 месяца, обошелся заказчику в миллион. Старый проект работал на 6 серверах стоимостью 1,5 млн., новый на 1 стоимостью в 200к, для пользователей 1 в 1, сам переход никто не ощутил (его не афишировали). Вроде бы миллион по деньгам, это много, но при нормальном сроке службы серверов под постоянной нагрузкой в 3 года это экономия от перехода составила порядка 2,8 миллиона в год. То есть экономически проект окупается за 4 с небольшим месяца.

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

Так что по совокупности факторов "переписать" Озон (без складов, логистики и т.д. и т.п.) вполне можно за 9 млн. По сути, не упарываясь в высокие нагрузки его можно переписать гораздо дешевле и быстрее - взять открытую CMS магазина и переписать админку не под одного продавца, а под многих. А это может сделать меньше чем за миллион любая приличная студия, да и делают. Лично видел, когда несколько компаний, не пересекающихся по регионам продаж, запилили подобный проект. Была 1 компания в одном регионе, когда стало много звонков из других регионов нашли компании в той же сфере из других регионов (это явное исключение т.к. у них доставка очень не простая) и предложили объединиться. Насколько мне известно с них взяли около 150к за модификацию CMS и это заняло порядка 2-х месяцев.

Точки выдачи заказов. Есть три пути:

1. Обойтись вообще без них. Алик высылает практически всё Почтой России и в целом это работает.

2. Организовывать коллегиально точки выдачи и привозить товар туда. Гораздо меньше по количеству.

3. Опять же скидываться в "кубышку" и из неё платить точкам выдачи.

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

На первый взгляд если сложиться по 4 500 руб. то достаточно будет 1% (2к) продавцов с ВБ, но всё гораздо лучше, потому что 1% продавцов не создадут столько же нагрузки, сколько 100%. Да, работы по созданию сайта не зависят от количества пользователей, но вот аренда железа - вполне.

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

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

Приём платежей - он-лайн кассы / сервисы. Полный онлайн чуть больше 2к в месяц, эквайринг в районе 4%.

Как убив дракона не стать новым драконом? Очень просто - фиксированный платеж. Не % от продаж, а небольшой, экономически обоснованный, ежемесячный платеж. При 2к магазинов он будет в районе 2 - 3к. С учётом озвучиваемых расценок маркетплейсов выходит гораздо дешевле.

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

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

P.S. Цифры по организации и сопровождению площадки вполне реальные.

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

И т.д. и т.п.

Почему? Потому что до мозгов людей не доходит, что каждый день мы голосуем за завтра. Рублём.

Если бы после начала дичи с ВБ заметный % клиентов и продавцов ушли бы с площадки, то ВБ либо сам очень быстро извинился и сделал "как было" или по рыночным механизмам пошел бы в банкротство. И то и другое, это однозначный сигнал на весь рынок "так делать нельзя".

Сигнала "нельзя" нет? Значит можно. А почему мы тогда ещё прибыль теряем?

Вот и всё. Поэтому извините, но в нашем суровом мире есть ровно 2 варианта в бизнесе:

1. Если контрагент (любой) творит дичь, то вы его посылаете нахер.

2. Если не п. 1, то варежку захлопните и жрите свой кактус молча.

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