Comments 70
Исходя из слабого знакомства с 1с разработкой, попеременно возникает то дежавю с концепцией питона, при том что 1с в общем не молодая компания, это выглядит прогрессивно. То впечатление что эта компания застряла в 90х и уже копит деньги на красивый гроб.
В данном варианте действует схема - Мыши плакали, кололись, но продолжали грызть кактус.
Продукт от 1С - массовый, относительно не дорогой по стоимости лицензии-внедрения-владения. При этом позволяет закрыть конкретные учетные задачи. Конкурентов в сегменте СМБ крайне мало, решения конкурентов сложно поддерживать в силу их слабого распространения, как следствие - малого количества разработчиков, а иногда, и закрытости.
В связи с этим до гроба крайне далеко.
del
Если разработчик получает деньги от Ваших ребят за продажу продукта, то что Вам не нравится?
Могу ошибиться в том, что имел в виду автор, но могу привести пример не из 1С, хотя и не факт, что это тоже несправедливо.
Разработчик написал коннектор для какого-то фасовочного аппарата (вроде как тротиловые шашки или пиропатроны паковать - я не помню уже). Он же по проекту должен был развивать его дальше, так как после фасовки (!) есть ещё технологические процессы, которые управляются уже новым оборудованием. Оценили, что работы там было года на три. О зарплате договорились на 110 т. р. (в то время просто космос).
Через какое-то время пришёл внешний интегратор, который убедил, что без него с этим проектом не справятся и проект вместе с разработчиком отдали ему. Для сотрудника остались те же 110 т. р. и тот же срок по контракту. Завод же стал платить примерно вдвое больше. Детали рассказывать не буду, но спустя годы пришли к выводу, что это была напрасная переплата. Зато интегратору три года было чем кормиться.
А вы как думаете?
Да, вы правы. Я тогда маленький был, на разные детали внимание не обращал, но ещё одну отвратную причину помню: банально не верили в то, что сами справятся. Вместе с директором даже рядовой персонал был счастлив, что теперь их "кто-то" ведёт. Появилось чувство "безопасности", хотя по факту тот же разработчик, тот же стек и даже рабочий кабинет
Ну так это проблемы (или нет) конкретного предприятия. Разработчику же, наоборот, даже проще стало, т.к. над ним появился кто-то, кто отвечает. А какая там по бухгалтерии схема, какие откаты и прочее — это бизнес. Если готовы платить — почему нет?
Ха. Ха. Ха.
В таких сферах увеличение количества менеджеров над головой обыкновенно приводит к кратному увеличению проблем, так как:
а) всю ответственность скидывают на исполнителя, в т.ч. за свои решения;
б) толпа молодых амбициозных менеджеров заколебет со своими "гениальными" проектами по модернизации и оптимизации, исполнение которых ясное дело будет сброшено на исполнителя.
С первого взгляда кажется, что банк правильно поступил. Когда человек один - это опасно, мало ли чего с ним плохого может случиться.
А болезненный переход на новое решение был, или обошлось легко?
Это ещё удачный расклад, что только в отпуск, и на месяц. Была ситуация, когда разработчик, к сожалению, просто умер. Клиенты были в шоке - пришлось срочно переходить на другой продукт и каким-то образом ещё и данные перекидывать.
Вы же сами написали что у компании/разработчика дела начинают идти не очень после выпуска продукта фирмой 1с. Единственное, это "не очень" может идти немного дольше в свободном плаванье.
А так описано агрессивное поглощение ИТ компании более крупной, со всеми плюсами и минусами. Минусов обычно больше для пользователей и обычных разработчиков.
Тут уйма статей как гигант купил стартап/продукт/технологию и потом забросил.
Я так скромно думал, что на рынке 1С стоимость самого продукта относительно стоимости внедрения исчезающе мала.
Соответственно если у тебя есть свой продукт и ты умеешь его внедрять, то для клиента ты всяко лучше чем коробка от 1С с которой непонятно что делать.
Да, я понимаю что ключевое здесь "умеешь внедрять".
Стоимость продукта исчезающе мала при тираже обеспечиваемым фирмой 1С.
А для сторонней разработки это совсем не так.
На моей практике обычно 1 к 1. Но это для "небольших предприятий" (до 200-500 пк), больших предприятий одному разрабу не светит. И неважно даже что. 1с, АТС, сеть сделать, сервер купить...
Придерживаюсь такого же мнения. И искренне не понимаю почему 1С все ещё продолжают использовать. Старая почти не развивающая коробка застревая в 90-ых.
Разве можно так обобщать?
1С - это прежде всего плаформа и плюс куча всяких разных полностью типовых, адаптированных отраслевых и даже самописных конфигураций.
А вот даже интересно стало, когда Вы 1С последний раз видели? В 99-м появилась 7.7 - это было уже неплохо. В 00-х 8.0, потом 8.1, потом 8.2 с управляемым интерфейсом, который матерые 1С-неги до сих пор освоить не могут толком. Потом 8.3 в середине 10-х, потом новый интерфейс "Такси", на который даже новые разработчики с некоторым трудом переходят, хотя он особо от управляемого и не отличается. Ну и все эти веб-сервисы, рест-апи, оДата, реад комиттед снапшот, боты, что там еще? Все искаропки, можно хоть в своем клиенте юзать, хоть в браузере. Мобильное приложение для телефонов импортного и отечественного производства запилить за условно полчаса можно - функционала будет достаточно для инвентаризации на складе. Так что все развивается, растет. Но да, язык хоть и получил асинхронные функции, но остался паскалеподобным без ООП, хотя с инкапсуляцией и полиморфизмом. А вот наследования нет...
Всё верно.
А высказанное выше мнение совершенно не отражает актуального состояния и платформы и конфигураций.
Мобилка для меня вообще оказалась боль. Слишком долго и муторно разобиратся в сборке apk. Как под ios собрать, вообще не понятно.
И самой главное, что бы собрать конфигурацию нужно иметь специальную конфигурацию для сбора мобилок.
Ну и плюсом к моему плохому отношению добавилось то, что всю мою учебную программу на "программиста" резко в 2021 изменили под 1С по непонятным причинам и все резко через не хочу начали восхвалять 1С, без какого-либо повода на то. Убрали почти все языки и поставили 1С, на три года.
Ну мобилка теперь собирается через обработку на сервере 1С (фирмы 1С, а не просто сервер с платформой). Обработка эта в любой 1С-ине есть начиная с 8.3.20. Там и для iOS, и для андройда. Но писать приложуху на 1С для телефона - это такое, конечно, если это не касается склада или другого производственного контура.
А то, что у вас там только 1с, то самообразование никто не отменял. Ща институт и колледж не лучше курсов, а после курсов не стать мидлом.
Ну а у чего нет недостатков? У всего они есть. Но бизнесу, если говорить именно о нем, все эти UI/UX - это в части юзабилити, а не красоты. Вот народ MES-системы на производстве внедряет по полгода, а я, например, в одной конторе ее на 1С с БСП (считай, с нуля) за три месяца написал. При том это MES на десктопе с кучей оборудования сопряжена, с редактором этикеток, с уникальными этикетками под отдельный продукт + заказчик, весы крановые, автомобильные, наполтные, фасовочные - все работает и все настраивается бнз программирования на процесс. Принтеры такие и этакие, ТСД с мобильным приложением, интеграция с ERP, включая поиск документов по оригинальным штрихкодам при возвратах. На этикетку хоть EAN13 по шаблону, хоть QR - все, что только можно. И все вполне юзабельно. Более того, уже год практически без поддержки работает. Правили настройку по весам, т.к были с ними проблемы какие-то в части производственного брака, но изменение весов - это изменение одного поля одной таблицы, т.е. 10 минут заняло на то, чтобы документацию открыть и посмотреть, куда что писать, а новые весы были засунуты в интерфейс за минуту - достаточно было ip прописать в настройках.
При всем том система работает через публикацию на апаче, мобильное приложение через soap с ней общается, она через soap общается с ЕРП. При том время разработки вебсервиса в MES или ERP составляет от 10 минут, если это список остатков, например, или вес с весов. Ну между ERP и MES - да, там заказы ездят и производственные дркументы с распределением затрат по цене, с отходами производства. Планирование производственной смены, интерфейс рабочего места упаковщика (заккз/склад - разные этикетки), серийный учет, все эти PlLU, кванты, упаковочные листы, усушки/утряски/прочие потери, ограничения по выходу продукции из сырья, ... Блин, там вроде бы лвер дофига всего, но я, например, с трудом представляю, как бы я это все к питону цеплял и вытряхивал в интерфейс на HTML + какой нить VUE+BOOTSTRAP. На 1С на интерфейс ушло реально 40 часов, больше на этикетки ушло, хотя в 1С уже есть редактор этих этикеток, только его пришлось слегонца поправить методом Сережи)))
Для бизнеса важно, чтобы было быстро от проекта до результата. А если еще бы кто сказал, что делать - вообще цены нет. И это основная проблема, что мало кто знает, как должно быть. Мы знаем, поэтому и три месяца, с нуля а большинство не знают, поэтому полгода внедрение готового решения.
Писать с нуля большую полноценную систему на 1с — это боль. Говорю как человек что в одном из франчей участвовал в разработке коробки 1С: Совместно.
З.Ы. На питоне такое тоже писать так себе, хоть и получше. Тайп хинтинг оно неплохо, но недостаточно для комфортной разработки чего то крупного.
использует коробки с небольшими доработками
Да, коробки - наше все. Но есть проблема - даже коробку нужно уметь готовить. Это вообще ко всему относится.
Писать с нуля большую полноценную систему на 1с — это боль
Основная проблема - это непонимание того, что надо делать. Вот, например, есть все эти ERP. Они покупаются бизнесом для планирования, бюджетирования, казначейства, хорошего управленческого учета. Но от 1С ERP - это конструктор. И периодически у меня складывается ощущение, что этим конструктором никто толком пользоваться не умеет. Чтобы там приличное планирование сделать - это сдохнуть можно. А если делать выпуск, который нормрован +/- (из коровы куски мяса, которые могут получиться совершенно разной массы, при том из любого куска мяса - и не только - можно накрутить фарш, из которого будут сделаны котлеты для гамбургеров и куча всего того, что делается из фарша, который делается по большому счету из триминга - читай, оставшегося жира и срезанных с костей остатков, которые будут переморожены и потом пойдут на колбасу, т.к. их не получилось продать - да, колбаса даже в части мяса состоит из говна и палок), то количество кликов улетает в космос и без отдельной MES вообще делать нечего.
В общем ERP от 1С - система большая, при том решает она проблемы, которые до начала внедрения этой системы не существовали )))
недостаточно для комфортной разработки чего то крупного.
Если четко понимать, что надо, то на чем угодно можно написать что-то крупное. Но на 1С многое, что упирается в интерфейс, например, делается быстрее. Там же все четко разделено: события хозяйственной деятельности = документы, объекты этой деятельности = справочники, результат деятельности = регистры бухгалтерии (все эти ОСВ, карточки счета и прочее) или регистры накопления/оборотов (все эти отчеты по производству и прочему). И если пытаться события отражать в справочнике, а объект в документе, то получается хрень, с которой потом кому-то приходится как-то жить и мириться, добавляя кучу проверок от пользователя-дурака. А в питоне, например, нет методологии разработки учетных систем - это язык программирования общего назначения. В предметно-ориентированной среде, которая заточена под учетные системы, понимая в методологии их разработки и разбираясь в предметной области, запилить даже большое решение - это просто процесс, которому надо следовать.
С другой стороны, 1С - это медленная штуковина. И вроде бы распределение сумм затрат на статьи и перенос этого всего с производственных счетов в результаты деятельности - это тривиальная операция, которая и является основным механизмом учета, но так, как это сделано в 1С - это, конечно, трындец. Это все можно решить в памяти, но архитектурно 1С все это делает пооперационно, тратя огромные ресурсы на отражение в учете сотен тысяч операций. И если потребовалось изменение исторических данных, то система будет требовать "перепроведения" моря документов, при том изменится могла одна лишь сумма и "перепроводить" эти тысячи документов ни к чему. Но, опять же, это не проблема платформы, а проблема архитектуры прикладных решений, которые писались без должного понимания методологии.
на чем угодно можно написать что-то крупное
Можно и операцию на гландах делать через одно место, вопрос в удобстве и поддержке последующей.
Для крупных проектов критически важна строгая статическая типизация, хорошо развитые средства разработки, модульность, и много других вещей которых в 1с нет и не предвидится.
А можете про все эти "статические типизации" и прочее более подробно рассказать? А то похоже, что Вы что-то такое где-то от кого-то услышали, но не поняли, а приняли на веру.
Ну вот что такое "хорошо развитые средства разработки"? Подсветка синтаксиса, автодополнение, анализ кода? Что там еще? Все это есть в 1С. Код-ревью? А в чем проблема? В 1С помимо штатного конфигуратора есть EDT, который был запилен на базе эклипса, в качестве хранилища используется GIT, есть все эти мерджи и все такое прочее (оркестраторы, сборщики, ...).
Модульность? Что конкретно под этим именно Вами понимается? Разделение кода на модули? Или выделение отдельных сервисов в отдельные контейнеры? Так никто не мешает в 1С и второе делать, а первое никто не отнимает.
Ну и про много других вещей - это, на мой взгляд, просто сотрясание воздуха. Хотите предметного разговора? Потрудитесь сформулировать аргументы более развернуто, чтобы было точно понятно, что вот именно этого в 1С нет и именно без этого она действительно не может представлять из себя приличную систему разработки больших решений для бизнеса.
Можно ведь и отсутствие в большинстве других систем "предметной ориентированности" привести как невосполнимую их проблему, сказать, что без этого любая другая система не может считаться средством разработки, а в 1С, мол, это есть. Но это будет аргумент Вашего уровня, который к разработке производственных систем вообще никак не относится, ибо любая предметная ориентированность - это лишь набор модулей, реализующих нужный функционал.
Нормальная статическая типизация с поддержкой от IDE очень упрощает жизнь. Дает уверенность в соблюдении контрактов (насколько надежную — зависит от языка, где то просто наличие определенных полей у объекта, а где то то что массив определенной длинны будет и значения в нем в определенном диапазоне). Можно реализовать нормальный DI. Автоматический рефакторинг позволяет очень просто выделять абстракции либо отделять фрагменты реализации.
Эклипс конечно то еще, в сравнении со средствами от JetBrains отстает очень сильно. Как во встроенных фичах и скорости работы, так и в работе плагинов.
Под модульностью понимаю нормальное переиспользование кода в виде библиотек. А так же возможность обособить в модуле большие объемы кода вынеся во вне в качестве интерфейса только важные для внешнего пользователя вещи, снизив таким образом сложность использования модуля. Это как раз важно для большого проекта, когда можешь кусок логики/предметной области загнать в модуль, а вовне выставить только интерфейс. Там еще нюансов хватает, но это слишком долго расписывать. Например у нас проект на котлине небольшой, меньше 100к строк (надо правда учесть что код на котлине куда менее многословен, я бы сказал эквивалентно 300к на 1с, правда в моем случае много именно UI кода, но это требования предметной области), при этом разбит примерно на 50+ модулей. Тут обычно контраргументируют что базу разделять идея не очень — но вообще это не обязательно, есть несколько вариантов как можно совместить единую базу и абстрагирование кода по модулям. Начиная от варианта когда все модули бизнес функций зависят от модуля с бд, заканчивая вариантом более красивым, когда бизнес модули описывают интерфейсы для конечной работы с базой, а реализация этих интерфейсов (в виде sql запросов) либо в отдельном модуле который зависит как от бизнес модулей так и от модуля с бд, либо просто в модуле с бд. Можно и другие варианты рассмотреть обособления.
В 1с это все нереально, чуваки что пилят БСП конечно стараются — но выходит так себе из за ограничений языка и платформы.
Вещи вроде отсутствия поддержки многих удобных вещей вроде лямбд, ооп, алгебраических типов данных, нормальной многопоточности и прочего — особо даже не вижу смысла упоминать.
Статическая типизация упрощает жизнь в том случае, когда типы важны. Вот я прям вот так с трудом представляю кейс, когда типы вот так уж прям важны для 1с.
По поводу эклипса, то это лишь вариант IDE. Писать код можно как в нем, так и в vscode, и в конфигураторе. Это лишь инструмент. А с учетом того, что сборку можно наладить из git, то совершенно нет разницы, в чем писать код. Это лишь инмтрумент.
По поводу модульности, то БСП - это, считай, фреймворк. Но часто в качестве фреймворка используют как раз коробку - ERP, БП, УТ
С точки зрения бизнеса важно получить поддерживаемое решение за небольшое время. Стоимость владения часто для 1С ниже, чем для альтернатив, при том и ROI тоже выше. Да, для клиентской витрины 1С - это такое, а вот для бэкофиса вполне себе. Даже я бы сказал безальтернативно.
Статическая типизация упрощает жизнь в том случае, когда типы важны. Вот я прям вот так с трудом представляю кейс, когда типы вот так уж прям важны для 1с.
Типы важны всегда. Ибо постоянно смотреть по коду/документации что там передается параметрами и что может вернуть функция + держать это все в голове — это боль. А ведь можно себя избавить от этого и прекрасно жить. Вон в том же котлине у нас даже разделение есть на то что может null принимать/возвращать, а что не может.
По поводу эклипса, то это лишь вариант IDE. Писать код можно как в нем, так и в vscode, и в конфигураторе. Это лишь инструмент. А с учетом того, что сборку можно наладить из git, то совершенно нет разницы, в чем писать код. Это лишь инмтрумент.
vs code это тоже то еще. Спасибо что не vim или notepad предложили. Ребята конечно поддержку lsp пилят для 1с (автор onescript кажется), но это все коммьюнити, а не вендор. Потому полноценной поддержки не дождетесь. Впрочем редакторы с поддержкой lsp один черт уступает полноценным IDE. Я когда на dart пишу после котлина — сильно плююсь, ибо для него гугл как раз через lsp поддержку пилит. Иногда ощущение бывает что действительно между vim и vs code разницы не будет.
По поводу модульности, то БСП — это, считай, фреймворк. Но часто в качестве фреймворка используют как раз коробку — ERP, БП, УТ
БСП в 1с это наиболее близкое к модульности из того что есть, и то очень и очень далеко.
С точки зрения бизнеса важно получить поддерживаемое решение за небольшое время.
Вот тут как раз и возникают проблемы если вести речь не о покупателях коробок, а об их разработчиках. Тот же 1С: ТОИР 2 мы пилили года 3 блин, при том что у нас 1.3 версия была под рукой, и по сути надо было выкинуть легаси местами, перевести на управляемые формы, да новых фич добавить. Плюс поддержка таких решений без мной указанных вещей тоже боль, ибо надо поддерживать не как конечным потребителям, доработки печатных форм, управляемых форм, небольшие доработки бизнес процессов и т.п., а надо поддерживать все решение целиком.
Типы важны всегда. Ибо постоянно смотреть по коду/документации что там передается параметрами и что может вернуть функция + держать это все в голове — это боль. А ведь можно себя избавить от этого и прекрасно жить.
Ну с учетом того, что передается в большинстве своем объект произвольного типа, то не сильно понимаю, как это поможет? В С++ была боль с типами, в итоге сначала появилось auto, потом auto&& в лямбдах - и никто не жалуется. Хотя...
По поводу разработки на 1С, то мне конфигуратора за глаза и за уши хватает. Я просто умею программировать, а кто не умеет - тому всегда инструменты жмут.
БСП в 1с это наиболее близкое к модульности из того что есть, и то очень и очень далеко.
Ну БСП - это писанное 1С что-то, тем более этому чему-то уже сто лет в обед, версий этого чего-то дофига и больше уже вышло. Да, удобная штуковина. Я на ее основе XBRL и MES написал "с нуля".
Вот тут как раз и возникают проблемы если вести речь не о покупателях коробок, а об их разработчиках.
Ну тот же ТОИР вряд ли только на БСП был основан. Хотя и не в курсе, что это за штука такая, но читал о нем на инфостарте. И авторы там отписались, что групповой сбор данных с агрегатов у них не на 1С-е. И это нормально - фронт роботам на джаве/шарпах/плюсах, а бэк вполне может и на 1С-е быть. Снять показания с датчиков - это не проблема для скрипта даже на PS, а вот тащить это в регламенты 1С-а - это такое.
в большинстве своем объект произвольного типа
Хорошо я такого говнокода давно не видел. Даже в языках с динамической типизацией сейчас стараются не допускать такого.
В С++ была боль с типами, в итоге сначала появилось auto
Вы путаете вывод типов с динамической типизацией. Это очень разные вещи.
По поводу разработки на 1С, то мне конфигуратора за глаза и за уши хватает. Я просто умею программировать, а кто не умеет — тому всегда инструменты жмут.
Ну т.е. принцип что можно не страдать а писать в удовольствие — не про вас. И упрощение работы вам не надо. Ну ок, хотя неясно зачем на 1с тогда писать, пишите сразу на асме тогда.
читал о нем на инфостарте. И авторы там отписались, что групповой сбор данных с агрегатов у них не на 1С-е
Видимо читали об одном из внедрений где была реализована интеграция со scada. Обычно это очень маленькая часть. А остальное на 1с, на базе бсп. Меньше ляма строк если не путаю ничего, т.е. проект средний вполне. Но на современном языке его написать и поддерживать было бы проще, быстрее и дешевле.
Хорошо я такого говнокода давно не видел. Даже в языках с динамической типизацией сейчас стараются не допускать такого.
Т.е. если у вас есть какая-то функция, в которую передается некий объект (произвольный документ 1С - та же ситуация с переоценкой валюты, например), то это сразу говнокод? Нужно городить сто функций для переоценки? А как же переиспользование кода и все такое? Вы вот сейчас кукую-то пургу несете, ну или просто не поняли, о чем я говорил.
В большинстве своем функции и процедуры по стандарту в 1С принимают структуру параметров в качестве входящих данных. И дальше происходит проверка, что тип данных - это структура, а дальше через Структура.Свойство("ХХХ") проверяется, что в этой структуре есть нужные параметры. Это решает проблему типизации, но в большинстве языков общего назначения также передается ссылка на структуру - тот же *FILE в С/С++ при вводе/выводе, *ZFILE в функциях lzip, ... Как это помогает "защититься" от проблем с типами? В 1С ты вполне можешь проверить, что тебе пришло, а какой-нить тайпкаст в строго типизированных языках сводит на нет все эти усилия, ибо в переменной, которую кастанули, может содержаться почти что угодно. Количество одинаковых физически типов, отличающихся именами, вводит езе больше неразберихи и приведение типов используется вообще везде. Так что одно не лучше другого.
Вы путаете вывод типов с динамической типизацией. Это очень разные вещи.
Вывод? Т.е. Вы про auto x = getX(&somedata)? А про [&](auto&& x]**{...}? **Вторая скобка - тоже круглая, а не квадратная, просто хабр это все меняет на &, я не знаю, почему.
Вообще, все эти ссылки и константные ссылки, и ссылки на константы и приведение типов всего ко всему - да, некоторым образом запутывает. Но в общем и целом это дает огромные возможности, но при этом если и не сводит на нет весь этот замысел со статический типизацией, то эффект от него снижает колоссально.
А тот же принцип подстановки Liskov: "функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом". Т.е. функция получает объект, который был унаследован от базового класса, да? Или Вы такого кода давно уже не видели? Или мы опять о разном?
В общем не все так однозначно, как Вам кажется.
Т.е. если у вас есть какая-то функция, в которую передается некий объект (произвольный документ 1С — та же ситуация с переоценкой валюты, например), то это сразу говнокод? Нужно городить сто функций для переоценки? А как же переиспользование кода и все такое? Вы вот сейчас кукую-то пургу несете, ну или просто не поняли, о чем я говорил.
В большинстве своем функции и процедуры по стандарту в 1С принимают структуру параметров в качестве входящих данных. И дальше происходит проверка, что тип данных — это структура, а дальше через Структура.Свойство(«ХХХ») проверяется, что в этой структуре есть нужные параметры.
Именно это и есть ужас. В данном случае метод должен принимать в качестве параметра интерфейс/тип сумму(в части случаев). Таким образом описывается контракт что нужно реализовать документам/другим объектам чтобы метод с ними мог работать единообразно. И все это проверяется на этапе компиляции, не надо после каждого рефакторинга выискивать все места где метод вызывается и проверять что нужное свойство/метод есть у передаваемых значений.
З.Ы. Приведения типов и касты давно уже в современной разработке считаются злом и пахнущим кодом. Даже не помню когда последний раз видел вживую.
Ну так для интерпретируемых языков компиляция весьма условна. А передача как раз объекта с одинаковыми свойствами - фактически унаследованного от одного и того же базового класса (документ) - это и есть принцип Liskov, когда функция просто генерирует коллекцию проводок переоценки по коллекции проводок, выбирая из них те, у которых валюта отличается от валюты системы. И для нее нет никакой разницы, какой конкретно документ пришел в аргументе - она работает с одной из коллекций этого документа "движения".
Глупость. Видимо у вас продолжают использовать 7.7?
Ну если обобщить - в глазах большинства только 1С совместима с налоговой.
В статье описан какой-то "единичный" и "уникальный" случай, не понятно как называемого действа. В одном временном континууме должен быть и пугливый "разработчик-сердце", и наглые и прошаренные "акулы-бизнеса", и еще сам вендор должен отсветить своими планами в этих ребят.
В реальности, как раз таки все наоборот: "разработчик-сердце" перестает "тащить" свое детище: долго закрывает таски по суппорту, долго добавляет востребованный функционал, все - долго, все завязано на одного-двух разработчиков, которые, внезапно, люди со своими проблемами/планами и т.д. На него начинают прилетать жалобы к вендору, даже если он с ним вообще никак не связан и него нет лычки "совместимо". Если бизнес-тема очень быстро растущая, то естественно, сам мониторит рынок и "свято место пустым не бывает" (с). Если к этому совокупить еще и хорошую денежную отдачу, то вполне может выйти на рынок какое-то либо "совместное" решение, либо вендорское. Но опять же, это не отжим, не попытка как-то "разработчика-сердце" персонально прокинуть и т.д. Это обычный рынок - кто быстрее и качественнее выкатывает продукт и его также суппортит, тот там и заберет его небольшой кусочек.
Ну и в целом, рынок "совместных" решений, автор про это не упомянул - весьма и весьма обширен на данный момент, и пугливый "разработчик-сердце" мог и продается как правило не пугающим "ребятам", а самому вендору. Но, на данный момент, найти именно какую-то такую, хорошую нишу, еще не автоматизированную - задача не из простых. Уже все написано, скорее всего, не по одному разу, разными ребятами, т.е. даже выбор будет. Грубо говоря с середины нулевых и по текущий период, все сильно денежные нишы уже заняты. Если вы просто навскидку сейчас начнете перечислять знакомые вам какие-то направления бизнесов, очень высока вероятность что для нее уже продается готовое 1С решение, типа - управление "SPA-салоном", управление фитнес-центром, 1С гостиница и т.д. и т.п. Сейчас основной тренд - это расширения для типовых, которые что-то улучшают, упрощают для конкретных каких-то пластов клиентов. Такого много и как раз таки там, можно найти много тем. Если вендор когда-нибудь выпустит такой типовой функционал, к этому времени еще можно наклепать подобных с десяток.
Позволю себе не согласиться. Нормальная схема. У вас есть на примете компания с продуктом, который скоро вытеснят с рынка, но пока он работает. Вы, по сути, решаете проблему владельца продукта: даете ему возможность за известную сумму уйти в сторону сейчас, вместо того, чтобы напрягаться и пытаться выжить или угасать, постепенно теряя деньги.
Для себя, вы, опять-таки за известную сумму получаете готовый и востребованный прямо сейчас продукт, докидываете в продвижение и доите его до упора. Ключевое слово "известная сумма", как для изначального владельца, так и для вас. По-моему, вполне типовой вин-вин.
Изначальному разработчику неинтересно вдруг становится агрессивным маркетологом, чтобы додавить прибыль, маркетологу неинтересно вкладываться в создание нового продукта, с большей степенью неопределенности.
Автор статьи не привел именно что конкретных данных. Что за продукт, кто его купил. Без этого, все остальные рассуждения бессмысленны. Разработка/поддержка/продвижение конфигурации на платформе 1С - это нет ни взрывных взлетов, ни оглушительных падений. Автор утверждает, что как только сам вендор что-то там у себя сделает, то все - разработчик-сердце - реально нищий. Ага. А вы задайтесь вопросом, ну что - все побежали "переезжать" с решения разработчика на вендорское? Такое может быть в случае, если там много регламентного учета, и разработчик какое-то совместимое решение как аддон продавал. Тогда да, вариантов нет. А во всех других случаях, конторы будут до последнего сидеть на "нетленках" разработчика-сердца, т.к. скорее всего, оно уже даже допилено до них. Да, может быть новых продаж не будет. Но старая база будет вас кормить еще долго, а за это время, своим зорким взглядом, увидите какие-то минусы "большого" решения, быстро запилите свой какой-то "улучшатор" в виде расширения, и будете, как и раньше, продавать уже его. На инфостарте таких примеров масса.
Т.е., я верю в единичные случаи, описанные автором. Но однозначно я уверен и в том, что эта история ну никак даже на хоть какую-то массовость претендует. Скорее всего, именно единичные случаи совпадения в одной точки всех Сережь. Но Автор именно преподносит это - что да, вендор, прям массово обращает разработчиков-сердец в пыль, выпуская свои тиражные решения. Это не соотстветствует истине в масштабе. Да, единичные случае, допускаю - теория вероятности - это не только скучные учебники. Но массово - ну это не история вендора, и не то направление автоматизации, где акулы скупают мелких рыбешек, их доедают и быстрее бегут за новыми. Этот рынок очень статичный, и повторюсь, там уже все мыслимые и немыслимые направления - автоматизированны даже не один раз.
P.S. Не то, чтобы выдуманные истории про ИТ это что-то плохое, но стоит учитывать, что это художественная литература, советы из которой стоит использовать очень аккуратно.
тут вот как пойдет... Кто-то захочет такое, а кто-то скажет: старый дизайн лучше...
Ничего удивительного не написано, всё так и должно быть: Проект развивается пока нет конкурентов, появится конкурент и всем плохо пока один из двух проектов не умрёт :-)
А потом приходит Серёжа
Сам давно такой пост хотел написать. Кроме последнего пункта "дичи", так и есть. Все знакомые уже сбежали с 1С, в ERP ошибка на ошибке, которые уже пару лет меняются и приходится с этим работать. В 1С работают грамотные менеджеры, которые разводят клиентов, общая "чудо".
Нигде не написано, что за "доработку" придётся вечно платить. Сначала доработки несколько лет переносили с 7.7 на 8.х, потом с обычных форм на "управляемые", потом выйдет 9 и снова "перенос".
Нигде не написано, что даже если ты нашёл ошибку, надо доказать, (предоставить чистую базу, со всеми настройками (больше сотни) с актуальным релизом (раз в две недели выходящим).
Из-за низкого порога вхождения франчайзи набирают студентов, и вам может достаться такой "специалист" за реальные деньги!
Из 1С скопировать в другую ваши данные может только программист, за ваши деньги (причём не малые и с ошибками). То есть если вы купили 1С Молокозавод, и его перестали поддерживать, то вам опять платить. Кстати, доработки могут делаться в последние дни перед сдачей отчетности, а в отраслевой (например, молокозавод) ещё позже.
Говорить о минусах 1С можно вечно, но у кактуса всё меньше конкурентов: Домино, Бэст, Парус и прочего.
P.S. Никому не рекомендую пользоваться 1С дальше бухгалтерии, написал бы на каждом столбе. Это только моё мнение.
В целом согласен, но можете уточнить куда сбежали все ваши знакомые? И есть ли на текущий момент альтернатива 1C ERP в России?
А еще прикол в том, что ваши знакомые с большой вероятностью сбежали из одного продукта 1С в другой, так как фирма 1С владеет долей нескольких успешных в России CRM продуктов - Bitrix, AmoCRM, UMI и может что-то еще подобное
В целом согласен, но можете уточнить куда сбежали все ваши знакомые? И есть ли на текущий момент альтернатива 1C ERP в России?
Альтернатива ERP - УПП. 1С практически монополист.
А еще прикол в том, что ваши знакомые с большой вероятностью сбежали из одного продукта 1С в другой
Сбежали не на другие проекты, а на другие языки.
То что нет альтернативы, от этого 1С лучше не становится. Кто не в курсе, 2022 год, а в 1С не везде работает групповое выделение. (Например, есть места, где нельзя выделить несколько элементов и удалить).
Есть три причины почему Иван Белокаменцев продолжает писать всякую херню:
Сознательная. Он понимает что тупой и по этому пошёл в первый бит и пишет херню, так как ничего больше не умеет
Стечение обстоятельств. Антон Долгов очень редко посещает с проверками офис Ивана, и по этому Ивана ещё не уволили за разгильдяйство. Чай не в Москве офис, Антону далеко
Не сознательная. Иван тупой и не знает об этом
Так бывают и обратные кейсы.
Франч разработал конфу, которую через некоторое время выкупила сама 1С, чтобы продавать от своего имени, покупая у франча услуги по поддержке и обновлению.
Через какое-то время 1С выпустила свою конфу (или даже несколько), которая якобы покрывает функционал этой. Соответственно эту конфу пустили под нож.
Что сделал франч?
Правильно, снова выпустил ту же самую конфу, только опять под своим именем.
Но без обратной совместимости с предыдущей (хотя легко мог это сделать).
И опять продаёт, да еще и берет деньги за переход с предыдущей конфы.
Откуда берётся «песок»? Ответ прозаически прост - деньги. Разрабатывать всё для всех, а потом ещё и поддерживать такой зоопарк - тупо дорого. А значит цена продукта будет выше, чем польза. Клиент не будет платить сверхвысокую цену за набор функций, которыми он не будет пользоваться. Поэтому каждая продуктовая компания ищёт минимум, который купят. Тот самый набор камней, который заполнит банку. И никакого заговора маркетологов, многоходовчек или тупости.
Читал, местами сильно смеялся, сравнивая это с SAP. Если в 1С есть хотя бы камни, которые можно наложить в банку, то в SAP одна вода ))))) Ну, может ещё песочка добавят)))
Если 1С делает ооооооооочень медленно, то SAP - годы, десятилетия или никогда ))) По крайне мере в РФ. И из-за санкций теперь уже точно никогда.
Давай, пока мама не видит?