Мы в «Латере» занимаемся разработкой биллинга для операторов связи (провайдеры проводного и беспроводного интернета, ТВ и телефонии, магистральные и спутниковые провайдеры) уже 8 лет, и за это время поучаствовали более чем в 80 проектах внедрения.
По нашим оценкам, около половины российских операторов связи используют самописный (или переписанный до неузнаваемости простенький «покупной») софт. Сегодня мы поговорим о возможных минусах такого подхода.
Напишем сами, будет лучше (на самом деле нет)
Главный аргумент сторонников самописных решений заключается в возможности полной адаптации к требованиям бизнеса. «Мы лучше знаем, что нужно компании» — типичный ход мыслей.
На коротком временном промежутке такой ход действительно может оправдать себя, однако затем начинаются проблемы.
Очень сложно вносить изменения
При очередной смене широко применяемых технологий (например, переход с PPP на IPoE, внедрение BRAS) или появлении новых услуг, самописный биллинг, как правило, оказывается не готов к таким изменениям. Решение, которое разрабатывалось для работы в формате «здесь и сейчас», крайне сложно изменить. Все это приводит к снижению качества обслуживания абонентов и отставанию от конкурентов.
Технологический клубок
Программные решения собственной разработки часто бывают монолитными — это значит, что помимо собственно биллинга, в них может присутствовать и функциональность CRM, хелдпеск, система активации новых абонентов и даже инструмент для планирования монтажных работ.
Софт устаревает и его так или иначе приходится заменять. Распутать же клубок из переплетенных между собой разных систем сложно. Заменять приходится либо все сразу и во всех основных подразделениях компании, что крайне болезненно, либо выводить из эксплуатации старое решение постепенно. Этот путь сопряжен с огромными затратами времени, сил и средств, да и не всегда возможен в принципе — например, если в заменяемой системе нет модульности или отсутствует API.
Костыли вечны
Часто выбор в пользу самописного софта делают компании, обладающие «нестандартными» бизнес-процессами. Проблема в том, что экзотика в итоге приводит к созданию костылей, которые остаются в системе на годы и затрудняют работу пользователей.
Разработчики же серийных продуктов не могут себе позволить никакой экзотики, поскольку их решениями пользуются многие компании. Это значит, что они более предсказуемы и понятны для пользователей.
Что делать, если переезд назрел
Собственные разработчики — это дорого, а их наличие не гарантирует успеха (что иллюстрируют описанные выше проблемы). Поэтому все больше компаний задумываются о переходе на серийный биллинг.
Этот процесс можно сделать менее болезненным, если следовать нескольким простым рекомендациям:
- Прежде всего, не нужно тянуть с переходом. Чем дальше откладывается это решение, тем больше накопится труднорешаемых проблем.
- При выборе серийного решения нужно смотреть не только на его текущую функциональность, но и узнать у создателей планы по развитию (правильные разработчики никогда не станут утаивать их).
- Лучше мигрировать постепенно — это сложнее и дороже, однако позволит избежать сбоев и негатива, а репутация компании важнее денег.
- Нельзя экономить на тестировании — следует уделить внимание воссозданию «боевых» условий на тестовых стендах. Например, крупных клиентов мы просим переключать нагрузку с реальной сети на тестовую инсталляцию биллинга на короткое время ночью.
- Переехать самим невероятно сложно. Миграция на новый биллинг — трудоемкий проект, на выполнение которого мало у какой компании есть свободные человеческие ресурсы. Сотрудники заняты текущими задачами, поэтому лучше привлечь подрядчиков, которые уже провели много подобных внедрений.
На сегодня все, спасибо за внимание. В следующем топике мы расскажем о том, как занимались работами по повышению отказоустойчивости нашей системы.
Подписывайтесь на наш блог, чтобы не пропустить ничего интересного!
Комментарии (108)
horlon
28.08.2015 11:54+10Одна вода. Самописный софт имеет лишь минусы в том случае, если его писал непрофессионал, а так — это более мощьное средство нежели купленный, хотябы потому, что нужный инструмент можно дописать именно так, как надо, а нужную проблему (или сбой) исправить в считанные минуты…
BillingMan
28.08.2015 11:59+4И много вы видели хороших самописных биллингов, к примеру?
horlon
28.08.2015 13:15+1К примеру, на моем опыте 2 биллинга (работал на нескольких работах), которых я видел сам, и они сугубо индивидуальные для четких целей. Их вы не найдете на прилавке. Вот только с переездом на коммерческие версии от «профессионалов» начиналась клоунада.
jrip
28.08.2015 13:25+3А ваш он не самописный? Он сам по себе из калькулятора эволюционировал?
BillingMan
28.08.2015 13:56+4Ну доводить до абсурда все же не стоит. Есть специализированный продукт и команда, которая уже много лет занимается его развитием. С вероятностью 100% такой команды с опытом внедрений конкретного такого продукта нет ни у одного потенциального покупателя подобной системы, потому что провайдер, например, профессионально обеспечивает связь, а не разрабатывает биллинги.
jrip
28.08.2015 15:30+1Вы написали только про минусы, когда оператор сам пишет. И вы не написали про минусы со своей стороны.
Рекламы? Ок. Но рекламировать себя унижая других это нехорошо, есть много удачных хороших, решаюших свои задачи биллингов, которые написала сама организация.BillingMan
28.08.2015 17:26+1Мы никого не унижали, о чем речь вообще. Мы собираемся в ближайшем будущем опубликовать несколько материалов пусть не о минусах со своей стороны, но о проблемах, которые мы решаем. Это, наверное, вполне сойдет за ответ на ваш скептицизм :)
horlon
28.08.2015 17:32+1Давайте разберемся: «Проблемы биллинга: Что может пойти не так с самописным софтом», здесь не говорится о том, что «Что может пойти не так при написании софта», а именно с самописным софтом… Комментарии излишни…
BillingMan
28.08.2015 18:28То-то их так мало к посту :) Значит все же проблема есть, и есть что обсудить
homozavruss
30.08.2015 17:58+1Видели и даже писали сами. Но статья явно ни о чём, поэтому хочется реальных кейсов и проблем.
P.S.
Причем я выбрал и внедрил ваш биллинг будучи тех-диром одного из операторов в Азии. Имхо, ваш биллинг был лучшим на момент выбора.
jrip
28.08.2015 12:52+9Вода немного окращенная самолюбованием и саморекламой. Самописный плохо, потому что есть «Фатальный недостаток» (с) — его писали не мы. Профессионалы только у них, ну да, конечно.
Не знаю как сейчас у провайдеров, но обычно развитие происходит строго наоборот — сначала покупное решение с поддержкой, далее свои специалисты и своя разработка. Т.к. у коробочных решений есть реальный недостаток — конкретных необходимых изменений для бизнеса либо ждать будешь вечность, либо денег заплатишь столько, что проще с нуля написать. И да, я такое видел неоднократно на практике.
NatalyM
28.08.2015 13:12Мне вот как человеку не совсем в теме тут как раз хочется понять, в итоге-то такие самописные решения они оказываются лучше коробок или нет? То, что иногда проще самому написать, чем отвалить кучу денег, это факт, но интересно какой результат получается, в среднем по больнице.
В целом напоминает ситуацию «хабр vs облака», конечно :)jrip
28.08.2015 13:23+1В общей ситуации все всегда зависит от людей. Так же могут быть мега профи, которые запилят то что будет работать годами, так есть и фиговые конторы с коробочным решением, которые внезапно, например вообще закроются. В среднем по больнице успешные компании все равно имеют отдел разработки.
А так же тут можно вспомнить про один момент, который автор статьи как-то немного недоговаривает — Никто не пишет просто так коробочное решение, ну нереал его так абстрактно написать без практического применения, так что как бы и их софт он изначально был «самописным».
horlon
28.08.2015 13:24В самописном варианте вы получаете полный котроль над своим ПО, нежели в коробочном черном ящике (это только при наличии профессиональных програмистов). А сторонние разработчики Вам скажут, что вот это невозможно, а это нельзя, а над этим мы еще работаем и сами же не можем найди у себя ошибок и исправить, а у Вас в это время ничего не работает и Вы ждете, пока исправят (а у них, как Вы таких еще много и они не успевают все). Если у Вас нет толковых программистов, то тогда — коробочное решение (как по мне, то за те деньги можно найти толковых программистов).
NatalyM
28.08.2015 13:29+2Ну вот тут я зашла на сайт автора поста и посмотрела цены. Цифры конечно не маленькие, но так если подумать то полтора толковых программиста будут стоить дороже. Короче ясно, что
ничего не ясновсе сложно здесь. Нам на один проект тут просто тоже сейчас предлагают серьезную коробочную систему, но есть в команде и сторонники собственной разработки, вот и пытаемся понять, как это вообще анализироватьjrip
28.08.2015 13:38+1Так посчитайте во сколько вам обойдется допилка коробки и ее дальнейшая поддержка с учетом вашего желаемого развития на пару лет вперед.
Риски посчитайте, как со стороны надежности продавца коробки так и надежности сторонников своего.
Не забывайте только, что почти на каждое платное коробочное решение есть бесплатный опенсорсный аналог.NatalyM
28.08.2015 13:42Опенсорс иногда по изначальным условиям проекта не подходит, тут у нас как раз такой вариант. Но за советы спасибо!
jrip
28.08.2015 13:44Ну вы опишите, хоть в кратце, тут много толковых людей, может что и подскажут.
И почему не подходит по изначальным условиям?NatalyM
28.08.2015 14:00Особо распространяться нельзя, ибо NDA, к сожалению. Если вкратце, то для одного крупного (и что важно совместного с крупной компанией) проекта нужна своя CRM-система, но такая, довольно мощная с разными штуками вплоть до Field Management Control (приглядывать за выездными сотрудниками). По условиям партнера опенсорс не подходит, а это бы все упростило. Вот в итоге и пытаемся понять, инвестировать ли в разработку под себя, или все же стоит поискать что-то на рынке.
jrip
28.08.2015 15:02+1> Если вкратце, то для одного крупного (и что важно совместного с крупной компанией)
В таком случае, чтобы прикрыть зад, лучше взять коробку(если есть подходящая) и согласовать ее с парнером, так чтобы он четко понимал что может коробка.
> По условиям партнера опенсорс не подходит
Странный партнер, еще один плюс в сторону коробки.
>стоит поискать что-то на рынке.
Поискать всегда точно стоит.
Вообще как показывает практика всякие CRM системы тема очень мутная, там всегда хочет кто-то «куда-то подвинуть зеленую кнопку и сделать красной», с одной стороны коробочная версия ограничивает таких хотителей, а с другой если хочет высокое начальство то кто-то все равно огребет при невозможности исполнения.
Ну и как с любой коробкой — она будет вам говорить каким должен быть ваш бизнес, а не наоборот.
farangcap
28.08.2015 16:04Field Service Management Software (например, planado.ru), это не CRM, это отдельная софтина, которая интегрируется с CRM.
Разрабатывать самим всю экосистему это очень дорого и очень долго. И все будет убогое и глючное. Да, будут галочки прямо под свой бизнес, но рано или поздно все придется снести нахрен и купить все готовое.
homozavruss
30.08.2015 18:04+2Не подходит, потому как в схему распил-откат не вмещается ?)) знакомо по гос-заказчикам. Ну так возьмите опенсорс с платной поддержкой разработчика.
dkoplovich
28.08.2015 15:41+1Сейчас развитие как раз идет в сторону коробочных продуктов. Ну, насколько понятие «коробка» вообще для энтерпрайза применимо. Скорее это фреймворки-конструкторы, которые изначально содержат возможности для кастомизации.
Что касается конкретно биллинговых систем, то все «допиливание» даже простеньких биллингов обычно заключается в разработке фич, которые там либо не предусмотрены изначально (те же возможности CRM или планирование выездных работ) и должны делаться отдельной специализированной системой, либо в использовании базовых возможностей биллинга, например, для построения более сложного тарифного плана.
Самый главный момент — разработчики сейчас стали слишком дорогими. Содержать их ради своего уникального продукта экономически невыгодно. А разработать с нуля свое решение займет минимум год. За это время та крайне нужная фича, ради которой все затевалось, может стать уже неактуальной.homozavruss
30.08.2015 18:11+2Тут надо все считать. В долгосрочном периоде может вполне оказаться, что своя разработка будет не просто выгоднее, а будет единственным реальным шансом обеспечить себе необходимую скорость изменений в бизнесе чтобы получить конкурентное при имущество или вообще выжить.
Не зря же всякие сбертехи и альфалабы появилась даже в таких кондовых структурах, как банки.
С Биллингами может оказаться все также.
Edro
28.08.2015 13:17-3Все видели картинку про BGBilling? Думаю тут все аналогично.
Ни один коробочный продукт не способен удовлетворить требования реального бизнеса с кучей людей, которые постоянно что-то придумывают.NatalyM
28.08.2015 13:26Почему же тогда покупают коробки? Вопрос без подкола, мне правда интересно
Edro
28.08.2015 13:27Предлагаю читать «реальный бизнес» как «крупная компания», например, присутствующая в нескольких городах.
NatalyM
28.08.2015 13:30Ну и что условный провайдер телефонни с парой филиалов никогда не использует коробочные решения? Как-то не верится, право
horlon
28.08.2015 13:41Я Вас уверяю. Проблема еще — время на разработку нужно. Вот это проблема, действительно. Это, минимум несколько месяцев при наличии четкого задания.
NatalyM
28.08.2015 13:43Я раньше работала как раз в таком и там коробки были, так что все же не верится. Хотя может что изменилось за это время
jrip
28.08.2015 13:32Когда нужно быстро запуститься с нуля — тут без вариантов нужно какое-то решение.
Или когда изначально все делали через одно место, но каким то чудом стали резко расти.
Или когда IT это не профильное направление бизнеса, ну это не про провайдеры.
Но обычно выбирают все-таки что-то опенсорсное, коробка обычно подрузмевает собой черный ящик, который сам не допилишь.farangcap
28.08.2015 16:26+1Сейчас концепция сильно поменялась. Коробки идут уже с хорошими возможностями по доработкам. И код никто не скрывает и всякие API делают.
Но проблема в другом – в экономике этих доработок. Программисты очень дорогие. Ну возьмете вы программиста, во-первых, ему одному скучно у вас сидеть. Во-вторых, программист кушает много денег. Сначала он сделает важные фичи, а потом начнет делать всякую фигню и жрать деньги за фичи, без которых можно было бы обойтись (что-то же ему надо делать на фул тайме).
Потом он свалит, не оставив за собой ни доков, ни тестов, в какую-нибудь другую софтверную контору, где ему будет интересно.
И не проще ли было 1 раз заказать доработку фичи у производителя биллинга/CRM, чем содержать программиста?
Нормальный программист не пойдет работать в непрофильную компанию. Там и процессы разработки будут колхозные и тим лид это директор с такой постановкой задачи (очень абстрактной), что скорее он мешает, чем помогает.
horlon
28.08.2015 13:31+2Ребята, не надо обсирать самописный софт, только что бы продать свой. Вы его не видели, врят-ли увидите (именно хороший самописный софт), так как к Вам никто не обратиться имея таковой…
getElementById
28.08.2015 15:35-3Надеюсь проблемы с русским языком не мешают вам писать хороший самописный софт. В противном случае его действительно лучше не видеть.
horlon
28.08.2015 17:50Вы, случайно, не преподаватель русского языка? Может, Вам и не стоит видеть написанные мной программы, потому что я не пишу их на русском. Обычно я китайский интерфейс делаю, а китайцы уже локализируют на остальные языки, в том числе и на русский.
jrip
28.08.2015 18:56+1>Надеюсь проблемы с русским языком не мешают вам писать хороший самописный софт.
Многие программисты в работе даже устным русским почти не пользуются, не говоря уж про письменный, непонятно зачем вы так неумно наехали на человека.getElementById
28.08.2015 19:31Практика показывает, что зачастую это связанные вещи. Ну, то есть одно дело пара опечаток, другое — общая неграмотность. Ну и, конечно, мы же все-таки на сайте в зоне.ру.
jrip
28.08.2015 19:35Вы случайно не такой, как те менеджеры, которые вместо того чтобы понять, принять и решить проблему, выдумывают какие-то тренинги, тестирования, внешние показатели эффективности и веруют во влияния фаз Луны на качество кода?
getElementById
28.08.2015 19:37Мимо, я разработчик. И код у меня на английском.
jrip
28.08.2015 19:41+1А наезжаете прям как менеджер, по мелочам) Человек так-то годную мысль в целом написал.
getElementById
28.08.2015 19:49Общались, знаем. Но смотрите в чем проблема. Вы долго и упорно вкладывали в разработку решения, которое вас полностью устраивает. Но со временем к продукту начинают предъявляться новые требования, а команды к тому времени может уже и не быть. Либо все это выходит не так уж дешево. И вот вы думаете о том, чтобы перейти на коробочное решение, но уже поздно. Ваша система настолько хорошо написана и так хорошо отрабатывает ваши бизнес-процессы, что ни одно коробочное решение вас не устраивает. И простого выхода нету, это реально тупик. Либо вам придется всерьез занимать непрофильным направлением, либо ломать все/почти все бизнес процессы.
farangcap
29.08.2015 00:36-1Именно так и происходит.
Свои продукты получаются круче по натягиванию на сложившиеся бизнес-процессы (часто тоже с элементами своего уникального пути). Но в итоге это все поддерживать становится все сложнее и дороже. Нужна новая фича и придется ждать ее год.
Я люблю аналогии, могу привести пример. Я вот сделал тюнинг фонарей на своей машине. Они такие стали офигенские и светодиодные, вместо штатных простых галогенок, предусмотренных производителем. И все круто, пока не случилось ДТП и одна фара расхреначилась. Дальше начинается нереальный гемморой найти одну такую уникальную и заменить.
Analitik_Telecom
28.08.2015 14:03+4Жалко, что проблемы так скупо описаны, но сама проблема отнюдь не надуманная. Действительно, операторы с маниакальным упорством пытаются писать биллинг «на коленке», а потом сильно удивляются, в чём проблема. А проблема вот в чём.
- Профессиональный софт пишется людьми, которые соединяют в себе знания по программированию, архитектуре и нюансам работы с БД (а это в биллинге — один из самых важных скиллов), навыки связиста и понимание сути, а лучше и экономики связи. Это комплексное видение.
- Решения апробированы и за баги отвечает разработчик — деньгами, головой, репутацией
- Разработчик биллинга умело собирает техническое задание со всех подразделений заказчика. Дело в том, что биллинг — основа работы и инженеров, и коммерсов — каждый в процессе тянет одеяло на себя и внутренний исполнитель иногда неспособен грамотно решить проблему. Перед внешним разработчиком компания резко становится «купно за едино» и перестаёт драть схемы и UML-диаграммы на кусочки, причём в буквальном смысле.
- Если на рынке появляется современный игрок, миграция с профессионального биллинга происходит более безболезненно, так как бизнес-логика однородна, меняются лишь технологии.
- Если нужна интеграция с CRM и/или ERP, то это также проходит мирно, без краха и дальнейших потерь данных. Конечно, CRM тоже можно самописную сделать. Но хорошие пока в этом классе не встречались.
А так, конечно, софт лучше называть не самописным, а самопальным. А тем гениям, которые считают, что написали свой отлично работающий биллинг, совет — срочно перепрофилируйтесь и продавайте его как готовое решение — рынок этого хочет.horlon
28.08.2015 14:58-1Компании, в которых такое пишут платят за это и условие нераспространения уникального софта, который был для них написан, почти всегда, обязательное (не видел желающих его продавать). Они за это заплатили и имеют право не раздавать этот софт. К тому же, его нужно написать с копирайтами, куча документов для продажи, встроить защиту от копирования, уж на это никто не тратит ресурсов. И самое важное — такой биллинг слижком уникален, что бы кому-то еще подойти.
Analitik_Telecom
28.08.2015 15:59Погодите-погодите. Давайте разделим мир на ровные части: есть софт, который пишется «под заказ» у стороннего разработчика, но не покупается готовый из, как говорится, коробки. Есть софт, который пишут программисты внутри компании — вот он лажает нещадно, потому что им реально не хватает квалификации. А покупать свою команду разработчиков-биллингистов — часто гораздо дороже покупки готового решения и его допиливания. Насчёт запрета на распространение — знаю, это был жёсткий сарказм.
jrip
28.08.2015 16:19-1>Погодите-погодите. Давайте разделим мир на ровные части
Да давайте ничего делить не будем, в среднем программисты могут быть везде любые.
>есть софт, который пишется «под заказ» у стороннего разработчика
А стороннему разработчику пофакту глубоко насрать, он за исправление багов еще и бабло попытается выбить.
А что никто так тут не делал никогда? :)
>Есть софт, который пишут программисты внутри компании — вот он лажает нещадно, потому что им реально не хватает квалификации.
Очешуеть. У них там рядом люди, которые знают все про свой бизнес и у них можно как раз всегда спросить как и что должно выглядеть.
Или вы про качество кода? С чего такое мнение, обоснуйте.
Analitik_Telecom
28.08.2015 16:25+2Речь не о качестве кода, конечно. О нём — отдельный долгий разговор. Речь, прежде всего, о непонимании разработчиками бизнес-логики и процессов. Это есть. Речь о том, что во время тестирования выясняется, что бэкенд не дружит с фронтэндом и валятся critical. А насчёт спросить — не всегда. Я сейчас не говорю обо всех, я говорю о тех случаях, которые встречаются. Если я вас чем-то задел — простите, исключения бывают везде.
jrip
28.08.2015 17:16+2Вы меня не задели :)
Просто я описываю как я себе это вижу, исходя из своей практики. Так вот на моей практике, обычно местные разработчики лажали не больше, а временами и меньше. Т.к. например могли подойти к менеджеру, который будет пользоваться интерфейсом и спросить, как должны себя вести какие-то контролы. Или наоборот, если появлялся баг — то все решалось очень быстро.
Другое дело, если компания только начинается и никто вообще не понимает бизнес процессов, у программистов мало опыта и тд и тп — ну понятное дело тот кто опытнее тот и круче :)
>Речь о том, что во время тестирования выясняется, что бэкенд не дружит с фронтэндом и валятся critical.
>А насчёт спросить — не всегда.
Гавно случается, но если случается постоянно и везде — то кто-то быстро учится говорить «свободная касса» :)
Конечно, у коробочников, такие штуки редки, но они все же случаются — и тут главный минус, скорость реакции по-любому меньше.
foxmuldercp
29.08.2015 21:01+2Простите за мои 5 копеек, но у «коробочников» тоже есть баги длинной в десятки лет, тот же баг в блокноте в винде, который тянется со времен как бы не 3.11.
из более приземлённых примеров — баги того же Plesk'а. Ну, или комменты кода со смыслом «Этот кусок надо бы исправить, ибо говно» в коде, подписанные лохматыми годами.
jrip
28.08.2015 15:15+1>Профессиональный софт пишется людьми, которые соединяют
>в себе знания по программированию, архитектуре и нюансам работы с БД (а это в биллинге — один из самых важных скиллов),
Почему вы считаете что у операторов нет профессионалов?
>с БД (а это в биллинге — один из самых важных скиллов)
Почему вы кстати так считаете? Что в биллинге такого особого и какие нужны нюансы? Знать про транзакции?
>навыки связиста и понимание сути, а лучше и экономики связи.
У оператора связи такие люди как бы полюбому должны быть.
>Если на рынке появляется современный игрок, миграция с профессионального биллинга происходит
>более безболезненно, так как бизнес-логика однородна, меняются лишь технологии.
Бизнес-логика однородна? Да фиг там был, не на практике, либо не под этим солнцем.
>Конечно, CRM тоже можно самописную сделать. Но хорошие пока в этом классе не встречались.
Хорошие — это как? Какой-то мега эксперт должен понюхать код и сказать что он хороший?
Оно должно выполнять свою бизнес задачу, вам не встречались те которые так делали?
>А тем гениям, которые считают, что написали свой отлично работающий биллинг,
>совет — срочно перепрофилируйтесь и продавайте его как готовое решение
Этакая странная ирония? А вы на практике то кстати сталкивались с разработкой биллингов?Analitik_Telecom
28.08.2015 16:091. У операторов есть профессионалы: профессионалы SQL, администраторы, программисты, боги продаж и т.д. Но вместе они неспособны зачастую создать жизнеспособную систему. Потому что начинаются трения с совместимостью всех требований.
2. Вы видели схему БД оператора? Там пи***ц как много таблиц и связей.
3. Но они не могут соотнести свои блестящие знания с архитектурой биллинга. Им нужна кнопочка, а что в коробочке под кнопочкой — наплевать.
4. So-so, тут мы с вами можем до стирания клавиш спорить. Слишком много стало потребителей биллинговых систем, соглашусь, что однородность подрастворилась.
5. Например, история такая — в течение трёх дней не писались некоторые данные CDR в базу. Лажа программиста-самописца.
6. Ирония-сарказм, да. Я серьёзно. Сталкивался, иначе зачем мне сейчас горевать и сопереживать автору поста?jrip
28.08.2015 16:25>Но вместе они неспособны зачастую создать жизнеспособную систему.
>Потому что начинаются трения с совместимостью всех требований.
У вас был такой печальный опыт, у других был позитивный опыт.
>2. Вы видели схему БД оператора? Там пи***ц как много таблиц и связей.
Видел, двух. Одного крупного, другого нет. В чем ваш страх перед количеством таблиц, если это обосновано количеством сущностей?
В чем проблема в количестве связей, если они необходимы?
>3. Но они не могут соотнести свои блестящие знания с архитектурой биллинга.
>Им нужна кнопочка, а что в коробочке под кнопочкой — наплевать.
Это вы про кого вообще? Про какую-то контору где работали? Поделитесь где такие плохие, чтобы мы туда не ходили :)
>5. Например, история такая — в течение трёх дней не писались некоторые данные CDR в базу. Лажа программиста-самописца
Гавно случается. Я наверное неделю без перерыва смогу рассказывать про то как кто и где накосячил, при этом про «коробочников» тоже.
farangcap
28.08.2015 16:15>с БД (а это в биллинге — один из самых важных скиллов)
Почему вы кстати так считаете? Что в биллинге такого особого и какие нужны нюансы? Знать про транзакции?
Для начала они должны быть в БД. И как это не смешно, но мало кто из программистов про транзакции знает и умеет ими пользоваться.
Ого какая тема, что там нужно =). Например, уметь пользоваться правильно индексами, оптимизировать запросы, анализировать планы выборок. Для больших partitioning нужен, параллельная обработка для provisioning и быстрой тарификации.jrip
28.08.2015 16:27+2Так можно сказать про любые системы, почему тут так биллинг выпятили?
Про индексы, оптимальные запросы — ну банально не смешно уже, 2015 год, любой школьник уже навреное знает.farangcap
28.08.2015 16:35-1Потому что в биллинге того же оператора связи много мелких транзакций (тарификация CDR, списания по дням и тд). Потом все это еще обрабатывается с учетом скидок, бандлов и тд. То есть логика не простая и как правило народ хочет требует, чтобы все тарифицировалось в онлайне. Происходит много корректировок.
Если сравнить с данными по какой-нибудь статистике или мониторингу, то требуется разная точность. В финансовых транзакциях – без потерь и абсолютная точность.
Грубо говоря, если в статистике что-то проимеется или чуть-чуть неточно посчитается, то это не критично. В деньгах — очень критично.jrip
28.08.2015 17:22+1Критичность определяется необходимостью критичности. Есть и другие системы, типы проектов и т.д. где есть подобные задачи, а также еще более сложные. Непонятно чем выделяется так биллинг, деньги или информация от которой зависят деньги в том или ином виде присутствуют во всех коммерческих проектах.
merlin-vrn
28.08.2015 17:25+1В медицине или атомной энергетике ещё более критично. Почему про них не сказали?
Каждый свою область считает самой-важной, а остальные — так, ерунда. Но это-то неверно. И деньги, объективно говоря, действительно не самое важное и не самое сложное. К тому же, инструменты разработчика в основном заточены именно для работы в конечном счёте с деньгами, а значит, задача написания биллинга ещё упрощается.farangcap
28.08.2015 17:52+1jrip, merlin-vrn, ни в коем случае я бы не утверждал, что биллинг это центр вселенной. Много каких систем с критическими данными в БД. В медицине вообще можно убить пациента кодом, страшно подумать =(.
foxmuldercp
29.08.2015 21:05+1И убивали, вон, печально известная история ru.wikipedia.org/wiki/Therac-25
Edro
28.08.2015 15:26+1Не нужно считать, что все некоробочные БС пишутся тремя с половиной программистами и на коленке. Есть и такие, над которыми работают крупные команды, и в которых все перечисленные вами характеристики сочетаются.
Верно то, что небольшим операторам, лучше воспользоваться готовым решением, чем пытаться делать свое. Крупным — отнюдь не стоит.dkoplovich
28.08.2015 15:46+2Практически все крупные как раз сидят на серийных биллингах. Почему? Потому что а) умеют считать деньги, б) умеют считать время, в) у них нет запросов на экзотические фичи, потому что им нужно тупо зарабатывать деньги акционерам, а не устраивать шапито.
jrip
28.08.2015 15:55+1>Практически все крупные как раз сидят на серийных биллингах.
А еслиб вы еще и знаниями поделились, на каких сидят, в чем особенности и т.д. то это было бы неплохим дополнением к подобной статье)Analitik_Telecom
28.08.2015 16:03Oracle, CBOSS (да-да), Teradata, например. Дорогие, мощные, безотказные, с CRM и нормальным таким GUI для нужд подразделений.
farangcap
28.08.2015 16:48+1amDocs — это бентли в мире биллингов.
На нем и сидят очень крупные.
Свои биллинги тоже пишут. Но у богатых свои причуды, они могут себе это позволить.
ToSHiC
30.08.2015 00:26Я за всех не скажу, но Amdocs Ensemble у Вымпелкома очень сложно назвать серийным биллингом. Начать можно хотя бы с того, что у самого Вымпелкома есть команда, которая в этот самый биллинг код пишет. Но, правда, совместно с командой из Amdocs, так что тут некий гибрид. Только слово «серийный» применительно к Ensemble вызывает у меня улыбку :)
При этом в мире есть успешные операторы связи, которые очень много платят вендорам (за биллинг там, за OSS/BSS, за поддержку железа), и весь штат оператора по сути сводится к менеджерам среднего звена и продуктологам/аналитикам. Если что-то нужно сделать — вендор сделает. Если что-то ломается — вендор крайне оперативно чинит. На счетах такого оператора денег остаётся не слишком много, зато и зарплатный фонд небольшой.
homozavruss
30.08.2015 18:26+1Как показала моя практика — не умеют. Вы видели биллинги билайна где-нить в регионе? Никак нельзя сказать, что они их выбрали по каким-то разумным поводам. А вот факт, что им кто-то из совета директоров заставил это внедрить — да.
getElementById
28.08.2015 15:38Зачастую авторы самописных решений держат контору за яйца. Это, конечно, не сразу происходит, со временем, но не удивительно, что бизнесу такая ситуация не нравится. Bus factor у одного-двух сумрачных гениев все-таки куда выше, чем у конторы, которая уже много лет работает на рынке.
merlin-vrn
28.08.2015 16:45+1Принципиально ли, держит за яйца контор автор самописного биллинга или вендор лок покупного?
И я не удивлюсь, если крупные сейчас сидят на серийном из-за того, что когда-то некий условный биг босс «посчитал деньги» и купил, а сейчас уже он понимает, что просчитался тогда и свой-то был лучше, но теперь отказ обойдётся во много раз дороже, чем продолжать мучиться. То есть, теряет он деньги на коробочном большие, чем терял на самописном, но обратный переход дороже.getElementById
28.08.2015 17:01Боже, вы о чем вообще? Хотите, чтобы какой-то хрен с горы диктовал вам условия? Отношения между компаниями носят как правило деловой характер (репутация и прочее). Отношения с сумрачными гениями могут быть какими угодно, я говорю по опыту. Ставить бизнес в зависимость от прихотей разработчика — ставить компанию под угрозу, потому что ему может в любой момент придти в голову что угодно (например, копье). В зависимости от того кто и как оценивает эти риски, так и принимается решение об отказе от идеально заточенной системы в пользу более универсального решения. Чем крупнее оператор, тем более вероятно, что эти риски он уже оценил и выбрал коробку.
merlin-vrn
28.08.2015 17:12+1Э… чёрт, вы ни разу не сталкивались с vendor lock-in? Во повезло…
И плевать хотели HP на ваше мнение об их репутации, продавая вам жёсткие диски для своих серверов и беспроводные адаптеры для своих ноутбуков по тройной цене. А другие, не их, поставить нельзя: для жёстких дисков просто нет конструктива, а адаптеры проверяются по белому списку при старте машины.
В мире софта: хочешь писать софт для устройств Apple — покупай их среду для разработки (хотя очевидно, что технических проблем разработки, например, в другой IDE или в другой OC особых нет, такие проблемы человечество давно научилось решать). А хочешь писать для новой версии — правильно, покупай новую версию среды.
И то, и другое они делают именно с целью «покупайте только у нас». Другими словами, диктуют условия, как вы выразились. Не захочет Apple — и не продаст вам среду (точнее, Apple ID), и вы окажетесь с носом.getElementById
28.08.2015 17:59-1Понятно, но сравнение все же не совсем адекватное. Поймите, тут рынок меньше, количество сделок тоже меньше. Вот, например, если вы купите решение от Amdocs, то да, тут все как вы описали. Только имейте в виду, что это уровень большой тройки. Тут речь идет про самописные наколеночные решения, наколеночных хардов не делают :)
jrip
28.08.2015 19:05+1Создатель софта, критичного для фирмы, пишущий его с самого начала как бы делает для бизнеса очень многое. И оставлять его просто безправным сотрудником так, что ему приходится «держать контору за яйца» это не очень умное решение. Если некий менеджер думает, что он пуп земли, а все остальные гавно, ему даже «носят как правило деловой характер (репутация и прочее)» не поможет.
Если же там на самом деле «сумрачный гений», возникает вопрос, а зачем изначально работали с «сумрачными гениями»? Почему не нашли нормальных адекватных людей, сэкономить хотели? Ну так сами себе буратины.getElementById
28.08.2015 19:22Ну ведь я о том и говорю. Если бы все работало изначально как планировали, то большинства проблем не было бы, так? И менеджеры бы не были нужны, ведь и так все ок.
jrip
28.08.2015 19:38Я что-то потерял нить ваших умозаключений. Но видимо мы с вами говорим о чем-то одном, только по разному.
getElementById
28.08.2015 19:43Ну смотрите, я же не могу спорить с собой:
Если же там на самом деле «сумрачный гений», возникает вопрос, а зачем изначально работали с «сумрачными гениями»? Почему не нашли нормальных адекватных людей, сэкономить хотели? Ну так сами себе буратины.
У нас же за МКАДом жизнь не заканчивается. Зачастую история была такова, что в глубинке нашелся программист-самородок, которого взяли на работу, он написал (предположительно) отличное решение, которое решило задачи на тот момент, а потом началось всякое-разное с байками про паяльник.
foxmuldercp
29.08.2015 21:08+1Продать то такое, а вот если потом залочит аккаунт с парой тысяч кровно заработанных, как любят делать некоторые поисковые монстры…
И объясни им, что ты не баран.
farangcap
28.08.2015 17:12Мне тут рассказали, как возили разработчика на УЗИ проверить, все ли у него ок со здоровьем. =)
vendor lock-in — не нужно связываться с нашими интеграторами, ой не нужно.
4dmonster
28.08.2015 16:44Прочитал статью и коментарии автора и его колег. И возник вопрос:
Вы сравниваете свой продукт с вариантами которые описываются как «курсовая работа на троечку» или «результат работы подростка за еду». Я сомневаюсь, что ваш проект выглядит качественным, только по сравнению с ними. Так почему вместо нормального технического сравнения/критики вы постите маркетологическую фигню?BillingMan
28.08.2015 17:34Вы пост-то почитайте сначала. Марктологической фигни там нет, есть рассказ о проблемах, которые встречаются с самописным софтом (в данном случае, с системами биллинга). Какое вообще сравнение вы хотели бы видеть и как оно должно выглядеть с отлично работающим самописным софтом, который, как тут выше сказали, мы не увидим, потому что с ним нет проблем и к нам никто в таком случае не пойдет?
Дальше мы опубликуем посты о том, как и что устроено в нашей системе, но это не на один топик тема, так что ваша претензии непонятны.4dmonster
28.08.2015 17:41Напишем сами, будет лучше (на самом деле нет)
Очень сложно вносить изменения
Технологический клубок
Костыли вечны
А на ссмом деле как напишут так и будет, если плохо напишут — будет плохо, а если хорошо напишут — будет хорошо.
Ну и дальше в коментариях: вы одни дартаньяны, а все остальные…BillingMan
28.08.2015 17:47Мы, кстати, не собираемся никого переубеждать. Вот если вы, например, уверены, что самописный софт — лучший выход, то и хорошо. Мы рассказали о том, что узнали из многолетного опыта разработки биллинга. При этом нашими клиентами по большей части являются компании, которые _почему-то_ и _внезапно_ перешли с самописного на серийный. Но это уже совсем другая история, конечно
4dmonster
28.08.2015 18:09+1Мы, кстати, не собираемся никого переубеждать. Вот если вы, например, уверены, что самописный софт — лучший выход, то и хорошо.
Я например уверен, что всё зависит от деталей. Вы здесь сравнивали только отстой со своей системой, удивительно было бы если бы выиграл отстой. Есть множество ситуаций, когда коробочные решения — это всё что нужно компании. Но есть и такие ситуации, когда или достаточен, или необходим самописный софт.
Мы рассказали о том, что узнали из многолетного опыта разработки биллинга.
Наверно, вы несколько перестарались и статья и ваши комментарии звучат не так, что «возможны(или характерны) следующие проблемы», а так «весь самописный софт отстой и содержит такие ошибки а программисты, не работающие в софтверных компаниях — дураки».
При этом нашими клиентами по большей части являются компании, которые _почему-то_ и _внезапно_ перешли с самописного на серийный.
Именно отсутствие у вас опыта общения с теми компаниями, которые совершенно спокойно и успешно работают на своём биллинге и привело к гиперболизированному описанию проблем самописок.BillingMan
28.08.2015 20:59Все же вы невнимательно читали пост — нигде в нем не сказано, что самописный софт не нужен и никогда не годится. Сказано, что разработка своего биллинга может вести к проблемам, которые далее перечислены. Все споры, собственно, вытекают из этого — в нашем блоге высказано наше мнение, основанное на нашем опыте, но оно «неправильное, потому что может быть и не так». Ну ок, что делать, мы останемся при своих.
kaichou
28.08.2015 17:50+3>> Очень сложно вносить изменения
> Решение, которое разрабатывалось для работы в формате «здесь и сейчас», крайне сложно изменить.
Так-то оно да.
Действительно, в свой софт изменения вносить сложно.
Проблема в том, что в чужой софт изменения вносить просто невозможно [в разумные сроки за разумные деньги].BillingMan
28.08.2015 17:58[в разумные сроки за разумные деньги] — чем не аргумент против внесения изменений в самописный софт? :) Все почему-то норовят опустить тему нынешней дороговизны качественных разработчиков и других возможных неэффективностей в процессе разработки непрофильных для бизнеса продуктов
4dmonster
28.08.2015 18:14Все почему-то норовят опустить тему нынешней дороговизны качественных разработчиков
Ну ведь, и ваши тоже не бесплатны.
других возможных неэффективностей в процессе разработки
Ну ведь, и при доработке у вас тоже возможны неэффективности.
Не экстраполируйте ситуацию на противостояние «отстой» vs «ваша система»BillingMan
28.08.2015 18:27И в мыслях подобного не было, более того во всем тексте везде говорится о «возможных» проблемах, о существовании которых мы знаем. При этом никто не ставит под сомнение реальность ситуации, при которой провайдер сам разработал себе биллинг, и его все устраивает. Ну есть так, то это только здорово же.
farangcap
28.08.2015 19:26+1Давайте посчитаем. Минимальная команда (бюджетно для Москвы):
1 тимлид — на руки 120 000 руб.
1 разработчик — на руки 80 000 руб.
1 QA — на руки 80 000 руб.
280 000 руб в месяц + налоги и административные расходы коэффициент 1,5 = 420 000 руб в месяц.
Это без конференций, смузи-машины и электрических самокатов в офисе.
Еще на них нужно тратить драгоценное время руководства, чтобы они не сбились с пути и не начали программировать то, что не нужно бизнесу.
Еще иногда разработчики говорят, что им надоело программировать и они хотят пожить на ГОА. Или заявляют, что хотят работать в другой стране, где ЗП не падает в 2 раза в цене за год =(
Areso
29.08.2015 16:12За МКАДом жизни нет?
А цена разработки за МКАДом будет существенно ниже (можно делить на 1,5-2 полагаю).farangcap
29.08.2015 18:19Можно и на 4 поделить. Но время идет вперед и дефицит по разработчикам сокращает халяву. Кроме того в регионах огромная проблема с поиском кадров. То есть если вы попробуете просто так собрать эту комнаду, пусть даже за меньшие деньги, то это очень непростая задача.
merlin-vrn
30.08.2015 08:39За МКАДом рассуждают примерно так: работаю на Москву, работаю не хуже и приношу прибыли не меньше, чем московские разработчики — по какой это причине мне будут платить в 1.5-2 раза меньше? Платите столько же. Единственное, на чём может быть «скидка» — на удалённой работе, то есть, платите как минимум наравне с московским удалёнщиком (и тут ещё спорный момент: на удалёнщиков и затраты меньше — не надо обеспечивать пространством, оборудованием, некоторым софтом, электричеством и т. д., так что не факт, что это будет действительно «скидка»).
А то, что жизнь там дороже или в таком духе — ну никто не заставлял вас там жить.
fcoder
28.08.2015 22:22+2В моем случае, оператор просто был вынужден выкупить исходники у авторов коробочного решения, которые решили прекратить разработку. И биллинг в качестве самописного решения продолжил успешно развиваться внутренним отделом разработки, который все-равно оператору необходим. Обрастал фичами и интегрировался со всей остальной инфраструктурой этого самого оператора — от сервисов и бизнес-процессов до взаимодействия с конкретным железом.
farangcap
29.08.2015 00:29Ключевой момент — выкуп исходников. Тут сумма может быть шестизначная и в баксах. Я не шучу, реальный случай.
Не хочу называть одного крупного московского оператора, но его все знают. Их разработчики свалили ВНЕЗАПНО в Чехию. Дальше был и выкуп исходников и сопровождение за нереальные деньги. Не знаю, удалось ли им полностью перейти на новый биллинг сейчас. Но с 2013 года они начали этот процесс и переходили они на тиражируемое не самописное решение.
По поводу разработчиков в штате крупного оператора вы совершенно правы. Какое-то их количество нужно. Вопрос чем они будут заниматься. Развитием ИТ-инфраструктуры и допиливанием плагинов, виджетов и алгоритмом стыковок различных готовых продуктов. Или написанием базовых алгоритмов, которые давно решены.
Аналогию можно привести с машиной. Можно делать свою уникальную коробку автомат. А можно взять готовую и заниматься созданием продукта с уникальными характеристиками по компоновке и дизайну.Areso
29.08.2015 16:41Один крупный московский оператор ССЗБ. Их разработчики — из их штата? — свалили в Чехию. Даже если это была заказная разработка у сторонней компании, то права (исходники, документы) должны были остаться у того самого крупного оператора, стоять на учете в бухгалтерии (НМА). Если компания таки лажанулись (лоханулись) и уже выкупила исходники за шестизначную сумму, которые им и так принадлежат (если все документы были оформлены), то зачем платить дорого за поддержку ребятам, у которых всё это купили? Можно посадить 2-3х разрабов на поддержку в штат, если есть исходники и документация.
dgstudio
29.08.2015 16:03Пффф… Маркетинг буллшит.
Когда я работал руководителем в одной русской CMS, мы такое тоннами писали.
Когда я работал руководителем в веб-студии, мы писали ровно то же самое, но наоборот, про самописный продукт.
А когда я работал в энтерпрайзе, и мы выбирали между коробкой или наймом команды, на нас лилось такое с обоих строн.
Хотите правды? Вообще по**й, самописный софт или коробочный, — если его пишут и внедряют дураки, которыми руководят м**аки, то жопа будет абсолютно одинаковая в обоих случаях.
artemlight
29.08.2015 16:25+1Ммм, а давайте я расскажу одну интересную историю.
Жил да был институт МИЭТ, что в Зеленограде. И была в общежитии этого института сеть под названием «Swamp».
Подключение в 2006-м году стоило 1000 р, 120 руб\месяц абонентка, 1.2р — 1 мегабайт интернета. Это во времена анлимов по 400 руб.
С такими ценами на подключение, естественно, сеть яростно натили. Админы носились по общежитию, детектили роутеры по ttl\стандартным макам\вроде как даже по нескольким одновременным сессиям в CS.
Именно таким было первое коммерческое применение АИС Гидра. На оборудовании, купленном за гос. деньги и добровольно-обязательных «пожертвованиях» в «некоммерческое студенческое сообщество».
Такое вот позорище имело место быть.farangcap
29.08.2015 18:04Да да. Только забыли добавить, что инет продавало в те времена 2 интернет-провайдера On+ и NetByNet. МИЭТ не выделял денег на инфраструктуру вообще. А когда выделил, то построил свою сетку, выкинул Swamp и там остался один провайдер. Зачем там вообще была нужна Гидра, Swamp же не продавал инет?
alinatestova
Серьезная тема. Подобный софт сам по себе штука суровая, про работу с заказчиками вообще страшно подумать :)
jrip
На самом деле это не такая уж суровая и сложная штука, это всеж не банковское ПО.
На счет работы с заказчиками — пока не напишут реальную стори по взаимодействию и решению серьезных проблем, склонен думать, что там обкатаный не особо изменяемый код, а на все другое «это не поддерживается нашей системой».
BillingMan
Мы уже пишем как раз такие материалы, так что скоро фактуры для выводов у вас будет больше. Но все же было бы интересно услышать, что нужно реализовать в системе чтобы она не была «не особо изменяемой»?
jrip
>в системе чтобы она не была «не особо изменяемой»
Я не про систему, а про то что код, возможно не особо и меняется. Т.е. написали некий функционал, который покрывает все популярные задачи и все. Такое ощущения возникает из вашей же статьи.
Вот как раз и интересно от вас было бы почитать, какие реальные кейсы и как решаете, еслиб вы начали с этого, а не с того, что разработчики, которые работают в провайдере и пишут биллинг плохие — было бы намнго лучше, имхо.
BillingMan
Ни в коем разе мы не говорили о том, что разработчики плохие (хотя и некоторым из них, понятно, выгоднее продавить вариант с самописным софтом, чтобы компания потом без них уже никуда не делась, хотя таких все же меньшинство). Нет, просто сама идея самописного биллинга крайне часто приводит к проблемам.
jrip
Окей. Идея самописного биллинга вещь спорная, соглашусь. Но ведь она имеет право на жизнь, хотя бы потому что кто-то так делает и доволен, верно? Идея коробочной версии имеет свои проблемы, верно? Так почему вы в статье, в которой рекламируете свой продукт не проводите честное сравнение обоих подходов, а пишите только про плюсы своего и минусы другого?
BillingMan
Если честно, мы не журналисты, чтобы давать в своем блоге слово «всем сторонам конфликта», в конце концов все имеют право высказаться в комментариях (а тут есть как наши противники, так и сторонники, то есть представлены обе позиции). Мы высказываем свое мнение — идея спорная, право на существование имеет, но могут быть проблемы.
jrip
Окей, вот и я высказываю свое мнение — статья не очень, вам стоит реабилитироваться и написать еще, к тому же вы обещали «Мы собираемся в ближайшем будущем опубликовать несколько материалов пусть не о минусах со своей стороны, но о проблемах, которые мы решаем.» :)