Комментарии 108
Серьезная тема. Подобный софт сам по себе штука суровая, про работу с заказчиками вообще страшно подумать :)
На самом деле это не такая уж суровая и сложная штука, это всеж не банковское ПО.
На счет работы с заказчиками — пока не напишут реальную стори по взаимодействию и решению серьезных проблем, склонен думать, что там обкатаный не особо изменяемый код, а на все другое «это не поддерживается нашей системой».
На счет работы с заказчиками — пока не напишут реальную стори по взаимодействию и решению серьезных проблем, склонен думать, что там обкатаный не особо изменяемый код, а на все другое «это не поддерживается нашей системой».
Мы уже пишем как раз такие материалы, так что скоро фактуры для выводов у вас будет больше. Но все же было бы интересно услышать, что нужно реализовать в системе чтобы она не была «не особо изменяемой»?
>в системе чтобы она не была «не особо изменяемой»
Я не про систему, а про то что код, возможно не особо и меняется. Т.е. написали некий функционал, который покрывает все популярные задачи и все. Такое ощущения возникает из вашей же статьи.
Вот как раз и интересно от вас было бы почитать, какие реальные кейсы и как решаете, еслиб вы начали с этого, а не с того, что разработчики, которые работают в провайдере и пишут биллинг плохие — было бы намнго лучше, имхо.
Я не про систему, а про то что код, возможно не особо и меняется. Т.е. написали некий функционал, который покрывает все популярные задачи и все. Такое ощущения возникает из вашей же статьи.
Вот как раз и интересно от вас было бы почитать, какие реальные кейсы и как решаете, еслиб вы начали с этого, а не с того, что разработчики, которые работают в провайдере и пишут биллинг плохие — было бы намнго лучше, имхо.
Ни в коем разе мы не говорили о том, что разработчики плохие (хотя и некоторым из них, понятно, выгоднее продавить вариант с самописным софтом, чтобы компания потом без них уже никуда не делась, хотя таких все же меньшинство). Нет, просто сама идея самописного биллинга крайне часто приводит к проблемам.
Окей. Идея самописного биллинга вещь спорная, соглашусь. Но ведь она имеет право на жизнь, хотя бы потому что кто-то так делает и доволен, верно? Идея коробочной версии имеет свои проблемы, верно? Так почему вы в статье, в которой рекламируете свой продукт не проводите честное сравнение обоих подходов, а пишите только про плюсы своего и минусы другого?
Если честно, мы не журналисты, чтобы давать в своем блоге слово «всем сторонам конфликта», в конце концов все имеют право высказаться в комментариях (а тут есть как наши противники, так и сторонники, то есть представлены обе позиции). Мы высказываем свое мнение — идея спорная, право на существование имеет, но могут быть проблемы.
Одна вода. Самописный софт имеет лишь минусы в том случае, если его писал непрофессионал, а так — это более мощьное средство нежели купленный, хотябы потому, что нужный инструмент можно дописать именно так, как надо, а нужную проблему (или сбой) исправить в считанные минуты…
И много вы видели хороших самописных биллингов, к примеру?
К примеру, на моем опыте 2 биллинга (работал на нескольких работах), которых я видел сам, и они сугубо индивидуальные для четких целей. Их вы не найдете на прилавке. Вот только с переездом на коммерческие версии от «профессионалов» начиналась клоунада.
А ваш он не самописный? Он сам по себе из калькулятора эволюционировал?
Ну доводить до абсурда все же не стоит. Есть специализированный продукт и команда, которая уже много лет занимается его развитием. С вероятностью 100% такой команды с опытом внедрений конкретного такого продукта нет ни у одного потенциального покупателя подобной системы, потому что провайдер, например, профессионально обеспечивает связь, а не разрабатывает биллинги.
Вы написали только про минусы, когда оператор сам пишет. И вы не написали про минусы со своей стороны.
Рекламы? Ок. Но рекламировать себя унижая других это нехорошо, есть много удачных хороших, решаюших свои задачи биллингов, которые написала сама организация.
Рекламы? Ок. Но рекламировать себя унижая других это нехорошо, есть много удачных хороших, решаюших свои задачи биллингов, которые написала сама организация.
Видели и даже писали сами. Но статья явно ни о чём, поэтому хочется реальных кейсов и проблем.
P.S.
Причем я выбрал и внедрил ваш биллинг будучи тех-диром одного из операторов в Азии. Имхо, ваш биллинг был лучшим на момент выбора.
P.S.
Причем я выбрал и внедрил ваш биллинг будучи тех-диром одного из операторов в Азии. Имхо, ваш биллинг был лучшим на момент выбора.
Вода немного окращенная самолюбованием и саморекламой. Самописный плохо, потому что есть «Фатальный недостаток» (с) — его писали не мы. Профессионалы только у них, ну да, конечно.
Не знаю как сейчас у провайдеров, но обычно развитие происходит строго наоборот — сначала покупное решение с поддержкой, далее свои специалисты и своя разработка. Т.к. у коробочных решений есть реальный недостаток — конкретных необходимых изменений для бизнеса либо ждать будешь вечность, либо денег заплатишь столько, что проще с нуля написать. И да, я такое видел неоднократно на практике.
Не знаю как сейчас у провайдеров, но обычно развитие происходит строго наоборот — сначала покупное решение с поддержкой, далее свои специалисты и своя разработка. Т.к. у коробочных решений есть реальный недостаток — конкретных необходимых изменений для бизнеса либо ждать будешь вечность, либо денег заплатишь столько, что проще с нуля написать. И да, я такое видел неоднократно на практике.
Мне вот как человеку не совсем в теме тут как раз хочется понять, в итоге-то такие самописные решения они оказываются лучше коробок или нет? То, что иногда проще самому написать, чем отвалить кучу денег, это факт, но интересно какой результат получается, в среднем по больнице.
В целом напоминает ситуацию «хабр vs облака», конечно :)
В целом напоминает ситуацию «хабр vs облака», конечно :)
В общей ситуации все всегда зависит от людей. Так же могут быть мега профи, которые запилят то что будет работать годами, так есть и фиговые конторы с коробочным решением, которые внезапно, например вообще закроются. В среднем по больнице успешные компании все равно имеют отдел разработки.
А так же тут можно вспомнить про один момент, который автор статьи как-то немного недоговаривает — Никто не пишет просто так коробочное решение, ну нереал его так абстрактно написать без практического применения, так что как бы и их софт он изначально был «самописным».
А так же тут можно вспомнить про один момент, который автор статьи как-то немного недоговаривает — Никто не пишет просто так коробочное решение, ну нереал его так абстрактно написать без практического применения, так что как бы и их софт он изначально был «самописным».
В самописном варианте вы получаете полный котроль над своим ПО, нежели в коробочном черном ящике (это только при наличии профессиональных програмистов). А сторонние разработчики Вам скажут, что вот это невозможно, а это нельзя, а над этим мы еще работаем и сами же не можем найди у себя ошибок и исправить, а у Вас в это время ничего не работает и Вы ждете, пока исправят (а у них, как Вы таких еще много и они не успевают все). Если у Вас нет толковых программистов, то тогда — коробочное решение (как по мне, то за те деньги можно найти толковых программистов).
Ну вот тут я зашла на сайт автора поста и посмотрела цены. Цифры конечно не маленькие, но так если подумать то полтора толковых программиста будут стоить дороже. Короче ясно, что ничего не ясно все сложно здесь. Нам на один проект тут просто тоже сейчас предлагают серьезную коробочную систему, но есть в команде и сторонники собственной разработки, вот и пытаемся понять, как это вообще анализировать
Так посчитайте во сколько вам обойдется допилка коробки и ее дальнейшая поддержка с учетом вашего желаемого развития на пару лет вперед.
Риски посчитайте, как со стороны надежности продавца коробки так и надежности сторонников своего.
Не забывайте только, что почти на каждое платное коробочное решение есть бесплатный опенсорсный аналог.
Риски посчитайте, как со стороны надежности продавца коробки так и надежности сторонников своего.
Не забывайте только, что почти на каждое платное коробочное решение есть бесплатный опенсорсный аналог.
Опенсорс иногда по изначальным условиям проекта не подходит, тут у нас как раз такой вариант. Но за советы спасибо!
Ну вы опишите, хоть в кратце, тут много толковых людей, может что и подскажут.
И почему не подходит по изначальным условиям?
И почему не подходит по изначальным условиям?
Особо распространяться нельзя, ибо NDA, к сожалению. Если вкратце, то для одного крупного (и что важно совместного с крупной компанией) проекта нужна своя CRM-система, но такая, довольно мощная с разными штуками вплоть до Field Management Control (приглядывать за выездными сотрудниками). По условиям партнера опенсорс не подходит, а это бы все упростило. Вот в итоге и пытаемся понять, инвестировать ли в разработку под себя, или все же стоит поискать что-то на рынке.
> Если вкратце, то для одного крупного (и что важно совместного с крупной компанией)
В таком случае, чтобы прикрыть зад, лучше взять коробку(если есть подходящая) и согласовать ее с парнером, так чтобы он четко понимал что может коробка.
> По условиям партнера опенсорс не подходит
Странный партнер, еще один плюс в сторону коробки.
>стоит поискать что-то на рынке.
Поискать всегда точно стоит.
Вообще как показывает практика всякие CRM системы тема очень мутная, там всегда хочет кто-то «куда-то подвинуть зеленую кнопку и сделать красной», с одной стороны коробочная версия ограничивает таких хотителей, а с другой если хочет высокое начальство то кто-то все равно огребет при невозможности исполнения.
Ну и как с любой коробкой — она будет вам говорить каким должен быть ваш бизнес, а не наоборот.
В таком случае, чтобы прикрыть зад, лучше взять коробку(если есть подходящая) и согласовать ее с парнером, так чтобы он четко понимал что может коробка.
> По условиям партнера опенсорс не подходит
Странный партнер, еще один плюс в сторону коробки.
>стоит поискать что-то на рынке.
Поискать всегда точно стоит.
Вообще как показывает практика всякие CRM системы тема очень мутная, там всегда хочет кто-то «куда-то подвинуть зеленую кнопку и сделать красной», с одной стороны коробочная версия ограничивает таких хотителей, а с другой если хочет высокое начальство то кто-то все равно огребет при невозможности исполнения.
Ну и как с любой коробкой — она будет вам говорить каким должен быть ваш бизнес, а не наоборот.
Field Service Management Software (например, planado.ru), это не CRM, это отдельная софтина, которая интегрируется с CRM.
Разрабатывать самим всю экосистему это очень дорого и очень долго. И все будет убогое и глючное. Да, будут галочки прямо под свой бизнес, но рано или поздно все придется снести нахрен и купить все готовое.
Разрабатывать самим всю экосистему это очень дорого и очень долго. И все будет убогое и глючное. Да, будут галочки прямо под свой бизнес, но рано или поздно все придется снести нахрен и купить все готовое.
Не подходит, потому как в схему распил-откат не вмещается ?)) знакомо по гос-заказчикам. Ну так возьмите опенсорс с платной поддержкой разработчика.
Сейчас развитие как раз идет в сторону коробочных продуктов. Ну, насколько понятие «коробка» вообще для энтерпрайза применимо. Скорее это фреймворки-конструкторы, которые изначально содержат возможности для кастомизации.
Что касается конкретно биллинговых систем, то все «допиливание» даже простеньких биллингов обычно заключается в разработке фич, которые там либо не предусмотрены изначально (те же возможности CRM или планирование выездных работ) и должны делаться отдельной специализированной системой, либо в использовании базовых возможностей биллинга, например, для построения более сложного тарифного плана.
Самый главный момент — разработчики сейчас стали слишком дорогими. Содержать их ради своего уникального продукта экономически невыгодно. А разработать с нуля свое решение займет минимум год. За это время та крайне нужная фича, ради которой все затевалось, может стать уже неактуальной.
Что касается конкретно биллинговых систем, то все «допиливание» даже простеньких биллингов обычно заключается в разработке фич, которые там либо не предусмотрены изначально (те же возможности CRM или планирование выездных работ) и должны делаться отдельной специализированной системой, либо в использовании базовых возможностей биллинга, например, для построения более сложного тарифного плана.
Самый главный момент — разработчики сейчас стали слишком дорогими. Содержать их ради своего уникального продукта экономически невыгодно. А разработать с нуля свое решение займет минимум год. За это время та крайне нужная фича, ради которой все затевалось, может стать уже неактуальной.
Тут надо все считать. В долгосрочном периоде может вполне оказаться, что своя разработка будет не просто выгоднее, а будет единственным реальным шансом обеспечить себе необходимую скорость изменений в бизнесе чтобы получить конкурентное при имущество или вообще выжить.
Не зря же всякие сбертехи и альфалабы появилась даже в таких кондовых структурах, как банки.
С Биллингами может оказаться все также.
Не зря же всякие сбертехи и альфалабы появилась даже в таких кондовых структурах, как банки.
С Биллингами может оказаться все также.
Все видели картинку про BGBilling? Думаю тут все аналогично.
Ни один коробочный продукт не способен удовлетворить требования реального бизнеса с кучей людей, которые постоянно что-то придумывают.
Ни один коробочный продукт не способен удовлетворить требования реального бизнеса с кучей людей, которые постоянно что-то придумывают.
Почему же тогда покупают коробки? Вопрос без подкола, мне правда интересно
Предлагаю читать «реальный бизнес» как «крупная компания», например, присутствующая в нескольких городах.
Когда нужно быстро запуститься с нуля — тут без вариантов нужно какое-то решение.
Или когда изначально все делали через одно место, но каким то чудом стали резко расти.
Или когда IT это не профильное направление бизнеса, ну это не про провайдеры.
Но обычно выбирают все-таки что-то опенсорсное, коробка обычно подрузмевает собой черный ящик, который сам не допилишь.
Или когда изначально все делали через одно место, но каким то чудом стали резко расти.
Или когда IT это не профильное направление бизнеса, ну это не про провайдеры.
Но обычно выбирают все-таки что-то опенсорсное, коробка обычно подрузмевает собой черный ящик, который сам не допилишь.
Сейчас концепция сильно поменялась. Коробки идут уже с хорошими возможностями по доработкам. И код никто не скрывает и всякие API делают.
Но проблема в другом – в экономике этих доработок. Программисты очень дорогие. Ну возьмете вы программиста, во-первых, ему одному скучно у вас сидеть. Во-вторых, программист кушает много денег. Сначала он сделает важные фичи, а потом начнет делать всякую фигню и жрать деньги за фичи, без которых можно было бы обойтись (что-то же ему надо делать на фул тайме).
Потом он свалит, не оставив за собой ни доков, ни тестов, в какую-нибудь другую софтверную контору, где ему будет интересно.
И не проще ли было 1 раз заказать доработку фичи у производителя биллинга/CRM, чем содержать программиста?
Нормальный программист не пойдет работать в непрофильную компанию. Там и процессы разработки будут колхозные и тим лид это директор с такой постановкой задачи (очень абстрактной), что скорее он мешает, чем помогает.
Но проблема в другом – в экономике этих доработок. Программисты очень дорогие. Ну возьмете вы программиста, во-первых, ему одному скучно у вас сидеть. Во-вторых, программист кушает много денег. Сначала он сделает важные фичи, а потом начнет делать всякую фигню и жрать деньги за фичи, без которых можно было бы обойтись (что-то же ему надо делать на фул тайме).
Потом он свалит, не оставив за собой ни доков, ни тестов, в какую-нибудь другую софтверную контору, где ему будет интересно.
И не проще ли было 1 раз заказать доработку фичи у производителя биллинга/CRM, чем содержать программиста?
Нормальный программист не пойдет работать в непрофильную компанию. Там и процессы разработки будут колхозные и тим лид это директор с такой постановкой задачи (очень абстрактной), что скорее он мешает, чем помогает.
Ребята, не надо обсирать самописный софт, только что бы продать свой. Вы его не видели, врят-ли увидите (именно хороший самописный софт), так как к Вам никто не обратиться имея таковой…
Надеюсь проблемы с русским языком не мешают вам писать хороший самописный софт. В противном случае его действительно лучше не видеть.
Вы, случайно, не преподаватель русского языка? Может, Вам и не стоит видеть написанные мной программы, потому что я не пишу их на русском. Обычно я китайский интерфейс делаю, а китайцы уже локализируют на остальные языки, в том числе и на русский.
>Надеюсь проблемы с русским языком не мешают вам писать хороший самописный софт.
Многие программисты в работе даже устным русским почти не пользуются, не говоря уж про письменный, непонятно зачем вы так неумно наехали на человека.
Многие программисты в работе даже устным русским почти не пользуются, не говоря уж про письменный, непонятно зачем вы так неумно наехали на человека.
Практика показывает, что зачастую это связанные вещи. Ну, то есть одно дело пара опечаток, другое — общая неграмотность. Ну и, конечно, мы же все-таки на сайте в зоне.ру.
Вы случайно не такой, как те менеджеры, которые вместо того чтобы понять, принять и решить проблему, выдумывают какие-то тренинги, тестирования, внешние показатели эффективности и веруют во влияния фаз Луны на качество кода?
Мимо, я разработчик. И код у меня на английском.
А наезжаете прям как менеджер, по мелочам) Человек так-то годную мысль в целом написал.
Общались, знаем. Но смотрите в чем проблема. Вы долго и упорно вкладывали в разработку решения, которое вас полностью устраивает. Но со временем к продукту начинают предъявляться новые требования, а команды к тому времени может уже и не быть. Либо все это выходит не так уж дешево. И вот вы думаете о том, чтобы перейти на коробочное решение, но уже поздно. Ваша система настолько хорошо написана и так хорошо отрабатывает ваши бизнес-процессы, что ни одно коробочное решение вас не устраивает. И простого выхода нету, это реально тупик. Либо вам придется всерьез занимать непрофильным направлением, либо ломать все/почти все бизнес процессы.
Именно так и происходит.
Свои продукты получаются круче по натягиванию на сложившиеся бизнес-процессы (часто тоже с элементами своего уникального пути). Но в итоге это все поддерживать становится все сложнее и дороже. Нужна новая фича и придется ждать ее год.
Я люблю аналогии, могу привести пример. Я вот сделал тюнинг фонарей на своей машине. Они такие стали офигенские и светодиодные, вместо штатных простых галогенок, предусмотренных производителем. И все круто, пока не случилось ДТП и одна фара расхреначилась. Дальше начинается нереальный гемморой найти одну такую уникальную и заменить.
Свои продукты получаются круче по натягиванию на сложившиеся бизнес-процессы (часто тоже с элементами своего уникального пути). Но в итоге это все поддерживать становится все сложнее и дороже. Нужна новая фича и придется ждать ее год.
Я люблю аналогии, могу привести пример. Я вот сделал тюнинг фонарей на своей машине. Они такие стали офигенские и светодиодные, вместо штатных простых галогенок, предусмотренных производителем. И все круто, пока не случилось ДТП и одна фара расхреначилась. Дальше начинается нереальный гемморой найти одну такую уникальную и заменить.
Жалко, что проблемы так скупо описаны, но сама проблема отнюдь не надуманная. Действительно, операторы с маниакальным упорством пытаются писать биллинг «на коленке», а потом сильно удивляются, в чём проблема. А проблема вот в чём.
А так, конечно, софт лучше называть не самописным, а самопальным. А тем гениям, которые считают, что написали свой отлично работающий биллинг, совет — срочно перепрофилируйтесь и продавайте его как готовое решение — рынок этого хочет.
- Профессиональный софт пишется людьми, которые соединяют в себе знания по программированию, архитектуре и нюансам работы с БД (а это в биллинге — один из самых важных скиллов), навыки связиста и понимание сути, а лучше и экономики связи. Это комплексное видение.
- Решения апробированы и за баги отвечает разработчик — деньгами, головой, репутацией
- Разработчик биллинга умело собирает техническое задание со всех подразделений заказчика. Дело в том, что биллинг — основа работы и инженеров, и коммерсов — каждый в процессе тянет одеяло на себя и внутренний исполнитель иногда неспособен грамотно решить проблему. Перед внешним разработчиком компания резко становится «купно за едино» и перестаёт драть схемы и UML-диаграммы на кусочки, причём в буквальном смысле.
- Если на рынке появляется современный игрок, миграция с профессионального биллинга происходит более безболезненно, так как бизнес-логика однородна, меняются лишь технологии.
- Если нужна интеграция с CRM и/или ERP, то это также проходит мирно, без краха и дальнейших потерь данных. Конечно, CRM тоже можно самописную сделать. Но хорошие пока в этом классе не встречались.
А так, конечно, софт лучше называть не самописным, а самопальным. А тем гениям, которые считают, что написали свой отлично работающий биллинг, совет — срочно перепрофилируйтесь и продавайте его как готовое решение — рынок этого хочет.
Компании, в которых такое пишут платят за это и условие нераспространения уникального софта, который был для них написан, почти всегда, обязательное (не видел желающих его продавать). Они за это заплатили и имеют право не раздавать этот софт. К тому же, его нужно написать с копирайтами, куча документов для продажи, встроить защиту от копирования, уж на это никто не тратит ресурсов. И самое важное — такой биллинг слижком уникален, что бы кому-то еще подойти.
Погодите-погодите. Давайте разделим мир на ровные части: есть софт, который пишется «под заказ» у стороннего разработчика, но не покупается готовый из, как говорится, коробки. Есть софт, который пишут программисты внутри компании — вот он лажает нещадно, потому что им реально не хватает квалификации. А покупать свою команду разработчиков-биллингистов — часто гораздо дороже покупки готового решения и его допиливания. Насчёт запрета на распространение — знаю, это был жёсткий сарказм.
>Погодите-погодите. Давайте разделим мир на ровные части
Да давайте ничего делить не будем, в среднем программисты могут быть везде любые.
>есть софт, который пишется «под заказ» у стороннего разработчика
А стороннему разработчику пофакту глубоко насрать, он за исправление багов еще и бабло попытается выбить.
А что никто так тут не делал никогда? :)
>Есть софт, который пишут программисты внутри компании — вот он лажает нещадно, потому что им реально не хватает квалификации.
Очешуеть. У них там рядом люди, которые знают все про свой бизнес и у них можно как раз всегда спросить как и что должно выглядеть.
Или вы про качество кода? С чего такое мнение, обоснуйте.
Да давайте ничего делить не будем, в среднем программисты могут быть везде любые.
>есть софт, который пишется «под заказ» у стороннего разработчика
А стороннему разработчику пофакту глубоко насрать, он за исправление багов еще и бабло попытается выбить.
А что никто так тут не делал никогда? :)
>Есть софт, который пишут программисты внутри компании — вот он лажает нещадно, потому что им реально не хватает квалификации.
Очешуеть. У них там рядом люди, которые знают все про свой бизнес и у них можно как раз всегда спросить как и что должно выглядеть.
Или вы про качество кода? С чего такое мнение, обоснуйте.
Речь не о качестве кода, конечно. О нём — отдельный долгий разговор. Речь, прежде всего, о непонимании разработчиками бизнес-логики и процессов. Это есть. Речь о том, что во время тестирования выясняется, что бэкенд не дружит с фронтэндом и валятся critical. А насчёт спросить — не всегда. Я сейчас не говорю обо всех, я говорю о тех случаях, которые встречаются. Если я вас чем-то задел — простите, исключения бывают везде.
Вы меня не задели :)
Просто я описываю как я себе это вижу, исходя из своей практики. Так вот на моей практике, обычно местные разработчики лажали не больше, а временами и меньше. Т.к. например могли подойти к менеджеру, который будет пользоваться интерфейсом и спросить, как должны себя вести какие-то контролы. Или наоборот, если появлялся баг — то все решалось очень быстро.
Другое дело, если компания только начинается и никто вообще не понимает бизнес процессов, у программистов мало опыта и тд и тп — ну понятное дело тот кто опытнее тот и круче :)
>Речь о том, что во время тестирования выясняется, что бэкенд не дружит с фронтэндом и валятся critical.
>А насчёт спросить — не всегда.
Гавно случается, но если случается постоянно и везде — то кто-то быстро учится говорить «свободная касса» :)
Конечно, у коробочников, такие штуки редки, но они все же случаются — и тут главный минус, скорость реакции по-любому меньше.
Просто я описываю как я себе это вижу, исходя из своей практики. Так вот на моей практике, обычно местные разработчики лажали не больше, а временами и меньше. Т.к. например могли подойти к менеджеру, который будет пользоваться интерфейсом и спросить, как должны себя вести какие-то контролы. Или наоборот, если появлялся баг — то все решалось очень быстро.
Другое дело, если компания только начинается и никто вообще не понимает бизнес процессов, у программистов мало опыта и тд и тп — ну понятное дело тот кто опытнее тот и круче :)
>Речь о том, что во время тестирования выясняется, что бэкенд не дружит с фронтэндом и валятся critical.
>А насчёт спросить — не всегда.
Гавно случается, но если случается постоянно и везде — то кто-то быстро учится говорить «свободная касса» :)
Конечно, у коробочников, такие штуки редки, но они все же случаются — и тут главный минус, скорость реакции по-любому меньше.
Простите за мои 5 копеек, но у «коробочников» тоже есть баги длинной в десятки лет, тот же баг в блокноте в винде, который тянется со времен как бы не 3.11.
из более приземлённых примеров — баги того же Plesk'а. Ну, или комменты кода со смыслом «Этот кусок надо бы исправить, ибо говно» в коде, подписанные лохматыми годами.
из более приземлённых примеров — баги того же Plesk'а. Ну, или комменты кода со смыслом «Этот кусок надо бы исправить, ибо говно» в коде, подписанные лохматыми годами.
>Профессиональный софт пишется людьми, которые соединяют
>в себе знания по программированию, архитектуре и нюансам работы с БД (а это в биллинге — один из самых важных скиллов),
Почему вы считаете что у операторов нет профессионалов?
>с БД (а это в биллинге — один из самых важных скиллов)
Почему вы кстати так считаете? Что в биллинге такого особого и какие нужны нюансы? Знать про транзакции?
>навыки связиста и понимание сути, а лучше и экономики связи.
У оператора связи такие люди как бы полюбому должны быть.
>Если на рынке появляется современный игрок, миграция с профессионального биллинга происходит
>более безболезненно, так как бизнес-логика однородна, меняются лишь технологии.
Бизнес-логика однородна? Да фиг там был, не на практике, либо не под этим солнцем.
>Конечно, CRM тоже можно самописную сделать. Но хорошие пока в этом классе не встречались.
Хорошие — это как? Какой-то мега эксперт должен понюхать код и сказать что он хороший?
Оно должно выполнять свою бизнес задачу, вам не встречались те которые так делали?
>А тем гениям, которые считают, что написали свой отлично работающий биллинг,
>совет — срочно перепрофилируйтесь и продавайте его как готовое решение
Этакая странная ирония? А вы на практике то кстати сталкивались с разработкой биллингов?
>в себе знания по программированию, архитектуре и нюансам работы с БД (а это в биллинге — один из самых важных скиллов),
Почему вы считаете что у операторов нет профессионалов?
>с БД (а это в биллинге — один из самых важных скиллов)
Почему вы кстати так считаете? Что в биллинге такого особого и какие нужны нюансы? Знать про транзакции?
>навыки связиста и понимание сути, а лучше и экономики связи.
У оператора связи такие люди как бы полюбому должны быть.
>Если на рынке появляется современный игрок, миграция с профессионального биллинга происходит
>более безболезненно, так как бизнес-логика однородна, меняются лишь технологии.
Бизнес-логика однородна? Да фиг там был, не на практике, либо не под этим солнцем.
>Конечно, CRM тоже можно самописную сделать. Но хорошие пока в этом классе не встречались.
Хорошие — это как? Какой-то мега эксперт должен понюхать код и сказать что он хороший?
Оно должно выполнять свою бизнес задачу, вам не встречались те которые так делали?
>А тем гениям, которые считают, что написали свой отлично работающий биллинг,
>совет — срочно перепрофилируйтесь и продавайте его как готовое решение
Этакая странная ирония? А вы на практике то кстати сталкивались с разработкой биллингов?
1. У операторов есть профессионалы: профессионалы SQL, администраторы, программисты, боги продаж и т.д. Но вместе они неспособны зачастую создать жизнеспособную систему. Потому что начинаются трения с совместимостью всех требований.
2. Вы видели схему БД оператора? Там пи***ц как много таблиц и связей.
3. Но они не могут соотнести свои блестящие знания с архитектурой биллинга. Им нужна кнопочка, а что в коробочке под кнопочкой — наплевать.
4. So-so, тут мы с вами можем до стирания клавиш спорить. Слишком много стало потребителей биллинговых систем, соглашусь, что однородность подрастворилась.
5. Например, история такая — в течение трёх дней не писались некоторые данные CDR в базу. Лажа программиста-самописца.
6. Ирония-сарказм, да. Я серьёзно. Сталкивался, иначе зачем мне сейчас горевать и сопереживать автору поста?
2. Вы видели схему БД оператора? Там пи***ц как много таблиц и связей.
3. Но они не могут соотнести свои блестящие знания с архитектурой биллинга. Им нужна кнопочка, а что в коробочке под кнопочкой — наплевать.
4. So-so, тут мы с вами можем до стирания клавиш спорить. Слишком много стало потребителей биллинговых систем, соглашусь, что однородность подрастворилась.
5. Например, история такая — в течение трёх дней не писались некоторые данные CDR в базу. Лажа программиста-самописца.
6. Ирония-сарказм, да. Я серьёзно. Сталкивался, иначе зачем мне сейчас горевать и сопереживать автору поста?
>Но вместе они неспособны зачастую создать жизнеспособную систему.
>Потому что начинаются трения с совместимостью всех требований.
У вас был такой печальный опыт, у других был позитивный опыт.
>2. Вы видели схему БД оператора? Там пи***ц как много таблиц и связей.
Видел, двух. Одного крупного, другого нет. В чем ваш страх перед количеством таблиц, если это обосновано количеством сущностей?
В чем проблема в количестве связей, если они необходимы?
>3. Но они не могут соотнести свои блестящие знания с архитектурой биллинга.
>Им нужна кнопочка, а что в коробочке под кнопочкой — наплевать.
Это вы про кого вообще? Про какую-то контору где работали? Поделитесь где такие плохие, чтобы мы туда не ходили :)
>5. Например, история такая — в течение трёх дней не писались некоторые данные CDR в базу. Лажа программиста-самописца
Гавно случается. Я наверное неделю без перерыва смогу рассказывать про то как кто и где накосячил, при этом про «коробочников» тоже.
>Потому что начинаются трения с совместимостью всех требований.
У вас был такой печальный опыт, у других был позитивный опыт.
>2. Вы видели схему БД оператора? Там пи***ц как много таблиц и связей.
Видел, двух. Одного крупного, другого нет. В чем ваш страх перед количеством таблиц, если это обосновано количеством сущностей?
В чем проблема в количестве связей, если они необходимы?
>3. Но они не могут соотнести свои блестящие знания с архитектурой биллинга.
>Им нужна кнопочка, а что в коробочке под кнопочкой — наплевать.
Это вы про кого вообще? Про какую-то контору где работали? Поделитесь где такие плохие, чтобы мы туда не ходили :)
>5. Например, история такая — в течение трёх дней не писались некоторые данные CDR в базу. Лажа программиста-самописца
Гавно случается. Я наверное неделю без перерыва смогу рассказывать про то как кто и где накосячил, при этом про «коробочников» тоже.
>с БД (а это в биллинге — один из самых важных скиллов)
Почему вы кстати так считаете? Что в биллинге такого особого и какие нужны нюансы? Знать про транзакции?
Для начала они должны быть в БД. И как это не смешно, но мало кто из программистов про транзакции знает и умеет ими пользоваться.
Ого какая тема, что там нужно =). Например, уметь пользоваться правильно индексами, оптимизировать запросы, анализировать планы выборок. Для больших partitioning нужен, параллельная обработка для provisioning и быстрой тарификации.
Так можно сказать про любые системы, почему тут так биллинг выпятили?
Про индексы, оптимальные запросы — ну банально не смешно уже, 2015 год, любой школьник уже навреное знает.
Про индексы, оптимальные запросы — ну банально не смешно уже, 2015 год, любой школьник уже навреное знает.
Потому что в биллинге того же оператора связи много мелких транзакций (тарификация CDR, списания по дням и тд). Потом все это еще обрабатывается с учетом скидок, бандлов и тд. То есть логика не простая и как правило народ хочет требует, чтобы все тарифицировалось в онлайне. Происходит много корректировок.
Если сравнить с данными по какой-нибудь статистике или мониторингу, то требуется разная точность. В финансовых транзакциях – без потерь и абсолютная точность.
Грубо говоря, если в статистике что-то проимеется или чуть-чуть неточно посчитается, то это не критично. В деньгах — очень критично.
Если сравнить с данными по какой-нибудь статистике или мониторингу, то требуется разная точность. В финансовых транзакциях – без потерь и абсолютная точность.
Грубо говоря, если в статистике что-то проимеется или чуть-чуть неточно посчитается, то это не критично. В деньгах — очень критично.
Критичность определяется необходимостью критичности. Есть и другие системы, типы проектов и т.д. где есть подобные задачи, а также еще более сложные. Непонятно чем выделяется так биллинг, деньги или информация от которой зависят деньги в том или ином виде присутствуют во всех коммерческих проектах.
В медицине или атомной энергетике ещё более критично. Почему про них не сказали?
Каждый свою область считает самой-важной, а остальные — так, ерунда. Но это-то неверно. И деньги, объективно говоря, действительно не самое важное и не самое сложное. К тому же, инструменты разработчика в основном заточены именно для работы в конечном счёте с деньгами, а значит, задача написания биллинга ещё упрощается.
Каждый свою область считает самой-важной, а остальные — так, ерунда. Но это-то неверно. И деньги, объективно говоря, действительно не самое важное и не самое сложное. К тому же, инструменты разработчика в основном заточены именно для работы в конечном счёте с деньгами, а значит, задача написания биллинга ещё упрощается.
jrip, merlin-vrn, ни в коем случае я бы не утверждал, что биллинг это центр вселенной. Много каких систем с критическими данными в БД. В медицине вообще можно убить пациента кодом, страшно подумать =(.
И убивали, вон, печально известная история ru.wikipedia.org/wiki/Therac-25
Не нужно считать, что все некоробочные БС пишутся тремя с половиной программистами и на коленке. Есть и такие, над которыми работают крупные команды, и в которых все перечисленные вами характеристики сочетаются.
Верно то, что небольшим операторам, лучше воспользоваться готовым решением, чем пытаться делать свое. Крупным — отнюдь не стоит.
Верно то, что небольшим операторам, лучше воспользоваться готовым решением, чем пытаться делать свое. Крупным — отнюдь не стоит.
Практически все крупные как раз сидят на серийных биллингах. Почему? Потому что а) умеют считать деньги, б) умеют считать время, в) у них нет запросов на экзотические фичи, потому что им нужно тупо зарабатывать деньги акционерам, а не устраивать шапито.
>Практически все крупные как раз сидят на серийных биллингах.
А еслиб вы еще и знаниями поделились, на каких сидят, в чем особенности и т.д. то это было бы неплохим дополнением к подобной статье)
А еслиб вы еще и знаниями поделились, на каких сидят, в чем особенности и т.д. то это было бы неплохим дополнением к подобной статье)
Я за всех не скажу, но Amdocs Ensemble у Вымпелкома очень сложно назвать серийным биллингом. Начать можно хотя бы с того, что у самого Вымпелкома есть команда, которая в этот самый биллинг код пишет. Но, правда, совместно с командой из Amdocs, так что тут некий гибрид. Только слово «серийный» применительно к Ensemble вызывает у меня улыбку :)
При этом в мире есть успешные операторы связи, которые очень много платят вендорам (за биллинг там, за OSS/BSS, за поддержку железа), и весь штат оператора по сути сводится к менеджерам среднего звена и продуктологам/аналитикам. Если что-то нужно сделать — вендор сделает. Если что-то ломается — вендор крайне оперативно чинит. На счетах такого оператора денег остаётся не слишком много, зато и зарплатный фонд небольшой.
При этом в мире есть успешные операторы связи, которые очень много платят вендорам (за биллинг там, за OSS/BSS, за поддержку железа), и весь штат оператора по сути сводится к менеджерам среднего звена и продуктологам/аналитикам. Если что-то нужно сделать — вендор сделает. Если что-то ломается — вендор крайне оперативно чинит. На счетах такого оператора денег остаётся не слишком много, зато и зарплатный фонд небольшой.
Как показала моя практика — не умеют. Вы видели биллинги билайна где-нить в регионе? Никак нельзя сказать, что они их выбрали по каким-то разумным поводам. А вот факт, что им кто-то из совета директоров заставил это внедрить — да.
Мда, название статьи чересчур громкое.
Зачастую авторы самописных решений держат контору за яйца. Это, конечно, не сразу происходит, со временем, но не удивительно, что бизнесу такая ситуация не нравится. Bus factor у одного-двух сумрачных гениев все-таки куда выше, чем у конторы, которая уже много лет работает на рынке.
Принципиально ли, держит за яйца контор автор самописного биллинга или вендор лок покупного?
И я не удивлюсь, если крупные сейчас сидят на серийном из-за того, что когда-то некий условный биг босс «посчитал деньги» и купил, а сейчас уже он понимает, что просчитался тогда и свой-то был лучше, но теперь отказ обойдётся во много раз дороже, чем продолжать мучиться. То есть, теряет он деньги на коробочном большие, чем терял на самописном, но обратный переход дороже.
И я не удивлюсь, если крупные сейчас сидят на серийном из-за того, что когда-то некий условный биг босс «посчитал деньги» и купил, а сейчас уже он понимает, что просчитался тогда и свой-то был лучше, но теперь отказ обойдётся во много раз дороже, чем продолжать мучиться. То есть, теряет он деньги на коробочном большие, чем терял на самописном, но обратный переход дороже.
Боже, вы о чем вообще? Хотите, чтобы какой-то хрен с горы диктовал вам условия? Отношения между компаниями носят как правило деловой характер (репутация и прочее). Отношения с сумрачными гениями могут быть какими угодно, я говорю по опыту. Ставить бизнес в зависимость от прихотей разработчика — ставить компанию под угрозу, потому что ему может в любой момент придти в голову что угодно (например, копье). В зависимости от того кто и как оценивает эти риски, так и принимается решение об отказе от идеально заточенной системы в пользу более универсального решения. Чем крупнее оператор, тем более вероятно, что эти риски он уже оценил и выбрал коробку.
Э… чёрт, вы ни разу не сталкивались с vendor lock-in? Во повезло…
И плевать хотели HP на ваше мнение об их репутации, продавая вам жёсткие диски для своих серверов и беспроводные адаптеры для своих ноутбуков по тройной цене. А другие, не их, поставить нельзя: для жёстких дисков просто нет конструктива, а адаптеры проверяются по белому списку при старте машины.
В мире софта: хочешь писать софт для устройств Apple — покупай их среду для разработки (хотя очевидно, что технических проблем разработки, например, в другой IDE или в другой OC особых нет, такие проблемы человечество давно научилось решать). А хочешь писать для новой версии — правильно, покупай новую версию среды.
И то, и другое они делают именно с целью «покупайте только у нас». Другими словами, диктуют условия, как вы выразились. Не захочет Apple — и не продаст вам среду (точнее, Apple ID), и вы окажетесь с носом.
И плевать хотели HP на ваше мнение об их репутации, продавая вам жёсткие диски для своих серверов и беспроводные адаптеры для своих ноутбуков по тройной цене. А другие, не их, поставить нельзя: для жёстких дисков просто нет конструктива, а адаптеры проверяются по белому списку при старте машины.
В мире софта: хочешь писать софт для устройств Apple — покупай их среду для разработки (хотя очевидно, что технических проблем разработки, например, в другой IDE или в другой OC особых нет, такие проблемы человечество давно научилось решать). А хочешь писать для новой версии — правильно, покупай новую версию среды.
И то, и другое они делают именно с целью «покупайте только у нас». Другими словами, диктуют условия, как вы выразились. Не захочет Apple — и не продаст вам среду (точнее, Apple ID), и вы окажетесь с носом.
Понятно, но сравнение все же не совсем адекватное. Поймите, тут рынок меньше, количество сделок тоже меньше. Вот, например, если вы купите решение от Amdocs, то да, тут все как вы описали. Только имейте в виду, что это уровень большой тройки. Тут речь идет про самописные наколеночные решения, наколеночных хардов не делают :)
Создатель софта, критичного для фирмы, пишущий его с самого начала как бы делает для бизнеса очень многое. И оставлять его просто безправным сотрудником так, что ему приходится «держать контору за яйца» это не очень умное решение. Если некий менеджер думает, что он пуп земли, а все остальные гавно, ему даже «носят как правило деловой характер (репутация и прочее)» не поможет.
Если же там на самом деле «сумрачный гений», возникает вопрос, а зачем изначально работали с «сумрачными гениями»? Почему не нашли нормальных адекватных людей, сэкономить хотели? Ну так сами себе буратины.
Если же там на самом деле «сумрачный гений», возникает вопрос, а зачем изначально работали с «сумрачными гениями»? Почему не нашли нормальных адекватных людей, сэкономить хотели? Ну так сами себе буратины.
Ну ведь я о том и говорю. Если бы все работало изначально как планировали, то большинства проблем не было бы, так? И менеджеры бы не были нужны, ведь и так все ок.
Я что-то потерял нить ваших умозаключений. Но видимо мы с вами говорим о чем-то одном, только по разному.
Ну смотрите, я же не могу спорить с собой:
У нас же за МКАДом жизнь не заканчивается. Зачастую история была такова, что в глубинке нашелся программист-самородок, которого взяли на работу, он написал (предположительно) отличное решение, которое решило задачи на тот момент, а потом началось всякое-разное с байками про паяльник.
Если же там на самом деле «сумрачный гений», возникает вопрос, а зачем изначально работали с «сумрачными гениями»? Почему не нашли нормальных адекватных людей, сэкономить хотели? Ну так сами себе буратины.
У нас же за МКАДом жизнь не заканчивается. Зачастую история была такова, что в глубинке нашелся программист-самородок, которого взяли на работу, он написал (предположительно) отличное решение, которое решило задачи на тот момент, а потом началось всякое-разное с байками про паяльник.
Продать то такое, а вот если потом залочит аккаунт с парой тысяч кровно заработанных, как любят делать некоторые поисковые монстры…
И объясни им, что ты не баран.
И объясни им, что ты не баран.
Мне тут рассказали, как возили разработчика на УЗИ проверить, все ли у него ок со здоровьем. =)
vendor lock-in — не нужно связываться с нашими интеграторами, ой не нужно.
vendor lock-in — не нужно связываться с нашими интеграторами, ой не нужно.
Прочитал статью и коментарии автора и его колег. И возник вопрос:
Вы сравниваете свой продукт с вариантами которые описываются как «курсовая работа на троечку» или «результат работы подростка за еду». Я сомневаюсь, что ваш проект выглядит качественным, только по сравнению с ними. Так почему вместо нормального технического сравнения/критики вы постите маркетологическую фигню?
Вы сравниваете свой продукт с вариантами которые описываются как «курсовая работа на троечку» или «результат работы подростка за еду». Я сомневаюсь, что ваш проект выглядит качественным, только по сравнению с ними. Так почему вместо нормального технического сравнения/критики вы постите маркетологическую фигню?
Вы пост-то почитайте сначала. Марктологической фигни там нет, есть рассказ о проблемах, которые встречаются с самописным софтом (в данном случае, с системами биллинга). Какое вообще сравнение вы хотели бы видеть и как оно должно выглядеть с отлично работающим самописным софтом, который, как тут выше сказали, мы не увидим, потому что с ним нет проблем и к нам никто в таком случае не пойдет?
Дальше мы опубликуем посты о том, как и что устроено в нашей системе, но это не на один топик тема, так что ваша претензии непонятны.
Дальше мы опубликуем посты о том, как и что устроено в нашей системе, но это не на один топик тема, так что ваша претензии непонятны.
Напишем сами, будет лучше (на самом деле нет)
Очень сложно вносить изменения
Технологический клубок
Костыли вечны
А на ссмом деле как напишут так и будет, если плохо напишут — будет плохо, а если хорошо напишут — будет хорошо.
Ну и дальше в коментариях: вы одни дартаньяны, а все остальные…
Мы, кстати, не собираемся никого переубеждать. Вот если вы, например, уверены, что самописный софт — лучший выход, то и хорошо. Мы рассказали о том, что узнали из многолетного опыта разработки биллинга. При этом нашими клиентами по большей части являются компании, которые _почему-то_ и _внезапно_ перешли с самописного на серийный. Но это уже совсем другая история, конечно
Мы, кстати, не собираемся никого переубеждать. Вот если вы, например, уверены, что самописный софт — лучший выход, то и хорошо.
Я например уверен, что всё зависит от деталей. Вы здесь сравнивали только отстой со своей системой, удивительно было бы если бы выиграл отстой. Есть множество ситуаций, когда коробочные решения — это всё что нужно компании. Но есть и такие ситуации, когда или достаточен, или необходим самописный софт.
Мы рассказали о том, что узнали из многолетного опыта разработки биллинга.
Наверно, вы несколько перестарались и статья и ваши комментарии звучат не так, что «возможны(или характерны) следующие проблемы», а так «весь самописный софт отстой и содержит такие ошибки а программисты, не работающие в софтверных компаниях — дураки».
При этом нашими клиентами по большей части являются компании, которые _почему-то_ и _внезапно_ перешли с самописного на серийный.
Именно отсутствие у вас опыта общения с теми компаниями, которые совершенно спокойно и успешно работают на своём биллинге и привело к гиперболизированному описанию проблем самописок.
Все же вы невнимательно читали пост — нигде в нем не сказано, что самописный софт не нужен и никогда не годится. Сказано, что разработка своего биллинга может вести к проблемам, которые далее перечислены. Все споры, собственно, вытекают из этого — в нашем блоге высказано наше мнение, основанное на нашем опыте, но оно «неправильное, потому что может быть и не так». Ну ок, что делать, мы останемся при своих.
>> Очень сложно вносить изменения
> Решение, которое разрабатывалось для работы в формате «здесь и сейчас», крайне сложно изменить.
Так-то оно да.
Действительно, в свой софт изменения вносить сложно.
Проблема в том, что в чужой софт изменения вносить просто невозможно [в разумные сроки за разумные деньги].
> Решение, которое разрабатывалось для работы в формате «здесь и сейчас», крайне сложно изменить.
Так-то оно да.
Действительно, в свой софт изменения вносить сложно.
Проблема в том, что в чужой софт изменения вносить просто невозможно [в разумные сроки за разумные деньги].
[в разумные сроки за разумные деньги] — чем не аргумент против внесения изменений в самописный софт? :) Все почему-то норовят опустить тему нынешней дороговизны качественных разработчиков и других возможных неэффективностей в процессе разработки непрофильных для бизнеса продуктов
Все почему-то норовят опустить тему нынешней дороговизны качественных разработчиков
Ну ведь, и ваши тоже не бесплатны.
других возможных неэффективностей в процессе разработки
Ну ведь, и при доработке у вас тоже возможны неэффективности.
Не экстраполируйте ситуацию на противостояние «отстой» vs «ваша система»
И в мыслях подобного не было, более того во всем тексте везде говорится о «возможных» проблемах, о существовании которых мы знаем. При этом никто не ставит под сомнение реальность ситуации, при которой провайдер сам разработал себе биллинг, и его все устраивает. Ну есть так, то это только здорово же.
Давайте посчитаем. Минимальная команда (бюджетно для Москвы):
1 тимлид — на руки 120 000 руб.
1 разработчик — на руки 80 000 руб.
1 QA — на руки 80 000 руб.
280 000 руб в месяц + налоги и административные расходы коэффициент 1,5 = 420 000 руб в месяц.
Это без конференций, смузи-машины и электрических самокатов в офисе.
Еще на них нужно тратить драгоценное время руководства, чтобы они не сбились с пути и не начали программировать то, что не нужно бизнесу.
Еще иногда разработчики говорят, что им надоело программировать и они хотят пожить на ГОА. Или заявляют, что хотят работать в другой стране, где ЗП не падает в 2 раза в цене за год =(
1 тимлид — на руки 120 000 руб.
1 разработчик — на руки 80 000 руб.
1 QA — на руки 80 000 руб.
280 000 руб в месяц + налоги и административные расходы коэффициент 1,5 = 420 000 руб в месяц.
Это без конференций, смузи-машины и электрических самокатов в офисе.
Еще на них нужно тратить драгоценное время руководства, чтобы они не сбились с пути и не начали программировать то, что не нужно бизнесу.
Еще иногда разработчики говорят, что им надоело программировать и они хотят пожить на ГОА. Или заявляют, что хотят работать в другой стране, где ЗП не падает в 2 раза в цене за год =(
За МКАДом жизни нет?
А цена разработки за МКАДом будет существенно ниже (можно делить на 1,5-2 полагаю).
А цена разработки за МКАДом будет существенно ниже (можно делить на 1,5-2 полагаю).
Можно и на 4 поделить. Но время идет вперед и дефицит по разработчикам сокращает халяву. Кроме того в регионах огромная проблема с поиском кадров. То есть если вы попробуете просто так собрать эту комнаду, пусть даже за меньшие деньги, то это очень непростая задача.
За МКАДом рассуждают примерно так: работаю на Москву, работаю не хуже и приношу прибыли не меньше, чем московские разработчики — по какой это причине мне будут платить в 1.5-2 раза меньше? Платите столько же. Единственное, на чём может быть «скидка» — на удалённой работе, то есть, платите как минимум наравне с московским удалёнщиком (и тут ещё спорный момент: на удалёнщиков и затраты меньше — не надо обеспечивать пространством, оборудованием, некоторым софтом, электричеством и т. д., так что не факт, что это будет действительно «скидка»).
А то, что жизнь там дороже или в таком духе — ну никто не заставлял вас там жить.
А то, что жизнь там дороже или в таком духе — ну никто не заставлял вас там жить.
В моем случае, оператор просто был вынужден выкупить исходники у авторов коробочного решения, которые решили прекратить разработку. И биллинг в качестве самописного решения продолжил успешно развиваться внутренним отделом разработки, который все-равно оператору необходим. Обрастал фичами и интегрировался со всей остальной инфраструктурой этого самого оператора — от сервисов и бизнес-процессов до взаимодействия с конкретным железом.
Ключевой момент — выкуп исходников. Тут сумма может быть шестизначная и в баксах. Я не шучу, реальный случай.
Не хочу называть одного крупного московского оператора, но его все знают. Их разработчики свалили ВНЕЗАПНО в Чехию. Дальше был и выкуп исходников и сопровождение за нереальные деньги. Не знаю, удалось ли им полностью перейти на новый биллинг сейчас. Но с 2013 года они начали этот процесс и переходили они на тиражируемое не самописное решение.
По поводу разработчиков в штате крупного оператора вы совершенно правы. Какое-то их количество нужно. Вопрос чем они будут заниматься. Развитием ИТ-инфраструктуры и допиливанием плагинов, виджетов и алгоритмом стыковок различных готовых продуктов. Или написанием базовых алгоритмов, которые давно решены.
Аналогию можно привести с машиной. Можно делать свою уникальную коробку автомат. А можно взять готовую и заниматься созданием продукта с уникальными характеристиками по компоновке и дизайну.
Не хочу называть одного крупного московского оператора, но его все знают. Их разработчики свалили ВНЕЗАПНО в Чехию. Дальше был и выкуп исходников и сопровождение за нереальные деньги. Не знаю, удалось ли им полностью перейти на новый биллинг сейчас. Но с 2013 года они начали этот процесс и переходили они на тиражируемое не самописное решение.
По поводу разработчиков в штате крупного оператора вы совершенно правы. Какое-то их количество нужно. Вопрос чем они будут заниматься. Развитием ИТ-инфраструктуры и допиливанием плагинов, виджетов и алгоритмом стыковок различных готовых продуктов. Или написанием базовых алгоритмов, которые давно решены.
Аналогию можно привести с машиной. Можно делать свою уникальную коробку автомат. А можно взять готовую и заниматься созданием продукта с уникальными характеристиками по компоновке и дизайну.
Один крупный московский оператор ССЗБ. Их разработчики — из их штата? — свалили в Чехию. Даже если это была заказная разработка у сторонней компании, то права (исходники, документы) должны были остаться у того самого крупного оператора, стоять на учете в бухгалтерии (НМА). Если компания таки лажанулись (лоханулись) и уже выкупила исходники за шестизначную сумму, которые им и так принадлежат (если все документы были оформлены), то зачем платить дорого за поддержку ребятам, у которых всё это купили? Можно посадить 2-3х разрабов на поддержку в штат, если есть исходники и документация.
Пффф… Маркетинг буллшит.
Когда я работал руководителем в одной русской CMS, мы такое тоннами писали.
Когда я работал руководителем в веб-студии, мы писали ровно то же самое, но наоборот, про самописный продукт.
А когда я работал в энтерпрайзе, и мы выбирали между коробкой или наймом команды, на нас лилось такое с обоих строн.
Хотите правды? Вообще по**й, самописный софт или коробочный, — если его пишут и внедряют дураки, которыми руководят м**аки, то жопа будет абсолютно одинаковая в обоих случаях.
Когда я работал руководителем в одной русской CMS, мы такое тоннами писали.
Когда я работал руководителем в веб-студии, мы писали ровно то же самое, но наоборот, про самописный продукт.
А когда я работал в энтерпрайзе, и мы выбирали между коробкой или наймом команды, на нас лилось такое с обоих строн.
Хотите правды? Вообще по**й, самописный софт или коробочный, — если его пишут и внедряют дураки, которыми руководят м**аки, то жопа будет абсолютно одинаковая в обоих случаях.
Ммм, а давайте я расскажу одну интересную историю.
Жил да был институт МИЭТ, что в Зеленограде. И была в общежитии этого института сеть под названием «Swamp».
Подключение в 2006-м году стоило 1000 р, 120 руб\месяц абонентка, 1.2р — 1 мегабайт интернета. Это во времена анлимов по 400 руб.
С такими ценами на подключение, естественно, сеть яростно натили. Админы носились по общежитию, детектили роутеры по ttl\стандартным макам\вроде как даже по нескольким одновременным сессиям в CS.
Именно таким было первое коммерческое применение АИС Гидра. На оборудовании, купленном за гос. деньги и добровольно-обязательных «пожертвованиях» в «некоммерческое студенческое сообщество».
Такое вот позорище имело место быть.
Жил да был институт МИЭТ, что в Зеленограде. И была в общежитии этого института сеть под названием «Swamp».
Подключение в 2006-м году стоило 1000 р, 120 руб\месяц абонентка, 1.2р — 1 мегабайт интернета. Это во времена анлимов по 400 руб.
С такими ценами на подключение, естественно, сеть яростно натили. Админы носились по общежитию, детектили роутеры по ttl\стандартным макам\вроде как даже по нескольким одновременным сессиям в CS.
Именно таким было первое коммерческое применение АИС Гидра. На оборудовании, купленном за гос. деньги и добровольно-обязательных «пожертвованиях» в «некоммерческое студенческое сообщество».
Такое вот позорище имело место быть.
Как вы классифицируете, например, Форис? Это покупной или самописный софт? )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы биллинга: Что может пойти не так с самописным софтом