Почему нет отечественных программ для бизнеса?

[skmdeveloper]

Уже много лет интересуюсь, но никак не могу понять.

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

Интересно узнать, почему ни один из проектов не достиг стадии, что его можно просто использовать.

У меня есть варианты:

1. Никому это ПО не нужно.

2. Нет программистов способных это реализовать.

3. Некому это дело профинансировать - объем работы достаточный, на одном энтузиазме не уедешь.

Может те, кто пытался занимался разработкой поделятся опытом. Я не из простого любопытства. Уже два месяца вплотную сижу (после долгого перерыва) и пишу программу автоматизации учета. Для начала хотя бы сделать простую - автоматизация малого бизнеса. В принципе, как выяснилось, особенно неподъемного здесь ничего нет. Структура базы данных и формы создаются шаблонами на XML - на что то типа Кофигуратора 1С пока отвлекаться не хочется. Пока создание и редактирование пользовательских справочников только работает. Сам то я 1С 7.7 как пользователь использую лет 10, и программирование на ней немного знаю. Бухгалтерский учет в достаточной для этого мере тоже. Пока пишу на Qt4 + PostgreSQL. Если все будет идти по плану, то где то через месяц будут первые результаты в виде минимальной, но работоспособной версии.

[Mattic]

Меня тоже давно интересует этот вопрос. Я правда немного с другой стороны смотрю. Мне интересно, почему Linux не идёт повально в массы. По мимо прочего под Linux не хватает 3 видов наиболее востребованного(может кому-то кажется и больше) программного обеспечения:
1) Бухгалтерия и бизнес
2) САПР(но будем считать что это не обязательно, т.к. потребность не такая большая как в первом, да и сложность реализации очень большая)
3) Большого количества серьезных хороших игр(этот тоже аспект затрагивать не будем - это длинный и бесполезный разговор)
В итоге получается, что для того, чтобы Linux люди ставили в организациях(а ставить будут-бесплатно же) не хватает качественной бухгалтерии, хотя бы уровня до средних предприятий. А если эта самая бухгалтерия будет бесплатной, то народ однозначно потянется - уж очень у нас любят халяву...

[yaleks]

Уже два месяца вплотную сижу (после долгого перерыва) и пишу программу автоматизации учета. Для начала хотя бы сделать простую - автоматизация малого бизнеса. В принципе, как выяснилось, особенно неподъемного здесь ничего нет. Структура базы данных и формы создаются шаблонами на XML - на что то типа Кофигуратора 1С пока отвлекаться не хочется. Пока создание и редактирование пользовательских справочников только работает. Сам то я 1С 7.7 как пользователь использую лет 10, и программирование на ней немного знаю. Бухгалтерский учет в достаточной для этого мере тоже. Пока пишу на Qt4 + PostgreSQL. Если все будет идти по плану, то где то через месяц будут первые результаты в виде минимальной, но работоспособной версии.

Продолжение проекта 1L -> unNStudio что-то аналогичное.

На самом деле действительно не сильно надо, поскольку есть исходники конфигураций 1С при закрытой платформе

[trdm]

Пока пишу на Qt4 + PostgreSQL. Если все будет идти по плану, то где то через месяц будут первые результаты в виде минимальной, но работоспособной версии.

Не хочешь попробовать бетку?: unnstudioreport
Тока она простая как мыло..

[DenisPr]

Может одна из причин постоянные изменения в законодательстве?

[DSS]

Интересно узнать, почему ни один из проектов не достиг стадии, что его можно просто использовать.

У меня есть варианты:

1. Никому это ПО не нужно.

Именно так.

Вариант 1:
1С + wine. Пусть даже от Etersoft. Дешево и сердито. Программистов можно в каждой деревне найти. Отслеживание законодательства - на приемлемом уровне.

Вариант 2:
Не надо изобретать собственные велосипеды с квадратными колёсами. Вот обсуждение: Софт для малого бизнеса
Там есть ссылка на wikipedia - можно выбрать ERP по вкусу, локализовать, доработать.

[skmdeveloper]

Про постоянное отслеживание изменений в законодательстве не надо.
Там уже давным давно все утряслось. Раз в несколько лет меняют кое что в расчете зарплаты. Я 1С клиентам обновляю раз в несколько лет.

А про ERP и прочие. Есть у меня аксиома. Если подобный проект в течение некоторого времени (не больше года) не достиг степени функциональности, то это не произойдет никогда.

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

Я кроме 1С ничего не использовал. Но с 1С работаю лет 10 как уверенный пользователь и программист, так что все плюсы и минусы известны. Для 1С уже с десяток пользователей большая проблема, особенно не SQL.

У меня пока все идет по плану. Работают пользовательские справочники, их редактирование в GUI, интегрирован встроенный язык пограммирования - Ruby. Диалоговые формы пока задаются редактированием XML-файлов. На написание конфигуратора типа 1С пока нет времени, но после стабилизации библиотек будет поправлено . Нужно побыстрее выпустить что то работоспособное.

Никаких велосипедов нет - используются только распространенные технологии - Qt, Ruby, Postgres. Исходники не выкладываю, пока не получится более-менее работоспособное. Планы отнюдь не амбициозные - для малого бизнеса - учет товаров, материалов, реализация, банк касса. С их реализацией, в отличие от самой платформы трудностей нет - я конфигурации 1С Бухгалтерия и Зарплата 7.7 чуть ли не наизусть знаю, в том числе все используемые алгоритмы и возможности.

Если будет интерес, имеет смысл совершенствовать. Не хочется чтобы превращалось в очередной мыльный пузырь типа "Ананаса", 1L и тому подобное.

[trdm]

Руби блин, совсем не айс для меня, но дело вкуса...

[skmdeveloper]

Руби блин, совсем не айс для меня, но дело вкуса...

Python а тем более Perl показались уж слишком монстрообразными. А тут довольно простой, но настоящий объектно-ориентированный, довольно распространенный язык, в основном используемый для написания веб-приложений.

[trdm]

Руби блин, совсем не айс для меня, но дело вкуса...

Python а тем более Perl показались уж слишком монстрообразными. А тут довольно простой, но настоящий объектно-ориентированный, довольно распространенный язык, в основном используемый для написания веб-приложений.

Да я про синтаксис говорил. Вот он для меня жутковат. Сначала я думал, что перл - жуть невозможная, потом познакомился с синтаксисом руби и питона. И понял, что перл еще ничего....

[skmdeveloper]

Я честно говоря ни по этим языкам небольшой специалист. Но Ruby показался мне гораздо ближе к встроенному языку 1С плюс компактность и нормальное ООП.

[Doublespace]

А чего все-таки не C++? Qt позволяет творить очень компактные проги- в плане исходного текста, средства разработки удобные.Ананасовцы ,считаю,не зра его выбрали,главная ошибка была- что зацепились в реализации к QSA. От которого сейчас trolltech вообще отказался, рекомендовано все портировать на QScript, а каждая установка "Ананаса" превращалась в основном в танцы с бубном именно вокруг него.

[Voral]

я пока использую wine+BisnesPack.

Под Линукс глубоко не искал. Что то простого для ИПшника.


офтопик.

А чего все-таки не C++? Qt позволяет творить очень компактные проги- в плане исходного текста, средства разработки удобные.

А есть ли готовые генераторы отчетов под линукс?

[Doublespace]

Ну есть простенькие генераторы ncreport -http://sourceforge.net/projects/ncreport/
openrpt -http://www.xtuple.com/openrpt
И google щас проект запустил -http://code.google.com/p/exaro/
Кроме того jasper прикручивают

[Boboms]

...
Интересно узнать, почему ни один из проектов не достиг стадии, что его можно просто использовать.
У меня есть варианты:
1. Никому это ПО не нужно.
2. Нет программистов способных это реализовать.
3. Некому это дело профинансировать - объем работы достаточный, на одном энтузиазме не уедешь.
....

Ответ намного проще - дело в самом бизнесе, а точнее в его ведении. Невозможно сформулировать, что такое "малый бизнес" в принципе, неговоря уже о его автоматизации.
Часто решаются локальные задачи, первейшей из которых (за это дрючат) является бухгалтерия. Отсюда и популярность 1С.
Для того, чтобы написать грамотное Т.З. (ИМХО) надо быть владельцем бизнеса, а не разработчиком. А под это Т.З. софт написать - дело техники.

[skmdeveloper]

А чего все-таки не C++? Qt позволяет творить очень компактные проги- в плане исходного текста, средства разработки удобные.Ананасовцы ,считаю,не зра его выбрали,главная ошибка была- что зацепились в реализации к QSA. От которого сейчас trolltech вообще отказался, рекомендовано все портировать на QScript, а каждая установка "Ананаса" превращалась в основном в танцы с бубном именно вокруг него.

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

Ответ намного проще - дело в самом бизнесе, а точнее в его ведении. Невозможно сформулировать, что такое "малый бизнес" в принципе, неговоря уже о его автоматизации.
Часто решаются локальные задачи, первейшей из которых (за это дрючат) является бухгалтерия. Отсюда и популярность 1С.
Для того, чтобы написать грамотное Т.З. (ИМХО) надо быть владельцем бизнеса, а не разработчиком. А под это Т.З. софт написать - дело техники.

А что его формулировать? Я в малом бизнесе работаю с 2001 года. Сам веду свою бухгалтерию.

[Boboms]

Не ну так вы в какой-то определенной области или во всех сразу?

Речь идет о формулировании "типичного" бизнес-процесса (а это, имхо, глупость особенно для малого бизнеса )

[Voral]

А что его формулировать? Я в малом бизнесе работаю с 2001 года. Сам веду свою бухгалтерию.

А вы сами к программированию какое отношение имеете?

Я ИП (тоже с 2001 г). Разработчик ПО. Уверяю это только кажется, что все прозрачно и конкретно. Но когда появляются очень узкие условия, при не продуманном ТЗ.... МОжно нарваться на переписывание всего кода из-за казалось бы "какой-то мелочи". Ну, а самое главное это вам понятно - вы сами бухгалтерию ведете, мне понятно потому, что я тоже сам все веду (причем моя бухгалтерская кухня проще не придумаешь) и тоже понимаю.......

Но вот если есть время у программиста, который в этом ни чего не понимает....... Как без ТЗ?
"Просто" когда писать под одного очень конкретного пользователя. Когда массовое потребление вылезает кучу модификаций....


В голове ТЗ есть. Времени на написание хорошего ТЗ и на написание самой софтины нет.

[Doublespace]

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

Кому как, но мне лично в Qt creator быстрее перекомпилировать программу.

[skmdeveloper]

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

Кому как, но мне лично в Qt creator быстрее перекомпилировать программу.

Мне тоже. Но рядовым пользователям уже не так просто.

[trdm]

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

Кому как, но мне лично в Qt creator быстрее перекомпилировать программу.

А выгнать 70 пользователей из базы за сколько сможешь?
Скрипт подменить много меньше времени занимает, чем это действо..

[Voral]

А выгнать 70 пользователей из базы за сколько сможешь?

Рассылкой сообщений. (Поскольку подобный опыт у меня при обслуживании виндового приложения то net send .....)
Есть так же один объект к де к базе цепляются еще из двух соседних городков. Один звонок по телефону. Через пару минут путь свободен. (Правда там юзеров не больше 15).

[Denjs]

Интересно узнать, почему ни один из проектов не достиг стадии, что его можно просто использовать.

все очень просто ребяты) НЕЛЬЗЯ АВТОМАТИЗИРОВАТЬ БЕСПОРЯДОК.

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

это конечно утрируя, но тенденция "в среднем по бальничке" имхо именно такова. никто (надеюсь что пока) не платит за нормальное по.ъ
Платят за умение распилить бюджет. И не важно какое у вас ПО. Решение в 90% случаев принимают не те кто может отличить хорошую "учетку" от плохой.
Из них к экспертам/спецам обращаются только в 10-20% случаев. имхо.


Конечно, надо работать в данном направлении. С учетом ужесточения условий, процент обращений в работающим технологиям, а не к маркетинговым трюкам медленно, но растет. Сия задача сопоставима с "повсеместным внедрением Линукс", но нас же это не останавливает, да? ^_^

[skmdeveloper]

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

[Doublespace]

В качестве примера каши в голове- тут одни мои клиенты собрались автоматизировать магазин на 1С. Когда обьясняю им, что нужен бы сервер, и желательно терминальный, они мне- "А чего-это не подойдет,что ли?", и тычут на Dlinkовский роутер dir-100, через который их сетка в инет ходит.

[Denjs]

Но вот если есть время у программиста, который в этом ни чего не понимает....... Как без ТЗ?
"Просто" когда писать под одного очень конкретного пользователя. Когда массовое потребление вылезает кучу модификаций....

В голове ТЗ есть. Времени на написание хорошего ТЗ и на написание самой софтины нет.

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

имхо: во первых - изучайте UseCases, их суть (например важно понять что это не алгоритм работы программы, а процесс работы С программой), то как ставятся требования к ПО, то как usecases МЕНЯЮТСЯ и ДЕТАЛИЗАИРУЮТСЯ в ходе разработки проекта. Поймите RUP-вскую "пирамиду требований" потребности->фичи->требования->(элементы архитектуры + документы + тесты)
во вторых - изучайте итерационные технологии разработки. В этом контексте смотри пункт про изменения и детализацию useCases.

Уходите от ТЗ на программы. не будет у вас живых программ с ТЗ.

ТЗ - это по ГОСТУ. последние, актуальные сейчас ГОСТы (34 и 19) писались когда программная инженерия находилась практически в зачаточном состоянии - т.е. "все тупо копировалось" с классической строительной инженерии - строительства зданий, мостов, тоннелей, кораблей, самолетов, где ТЗ было единственным способом сделать надежный объект.

Программная инженерия - это кардинально другая область, как минмиум это область абстракций, не материальная, с другими законами и принципами.
И с ужесточением требований по срокам и объемам ПО игнорировтаь это уже никак нельзя.

Как минимум - хорошие программы не "строятся", хорошие программы "выращиваются".
А ТЗ - это попытка "построить франкенштейна": сначала сшить мертвую материю, а потом по волшебству оживить её. Понятно что надеется что результат будет жить - как минимум глупо. Сказок не бывает.


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

В итоге - мы опять приходим к тому с чего начинали (см мой пост выше), что процесс сдачи программы на практике часто не зависит ни от ТЗ, ни от самой программы, ни от её качества. А зависит от пиара, очковтирательства и других методов торгашества.
Какие заказчики - такие и методы. и что-б им пусто было,

[Boboms]

Я, скорее всего, неверно выразился. Под ТЗ я имел ввиду не ГОСТы, а именно техзадание, т.е. "алгоритм" по которому она (программа) должна работать.

А ТЗ это берется из бизнес-процессов компании за счет их разумной (!!!) формализации. Если нет бизнес-процессов (другими словами, понимания "что, когда, как и зачем делается"), то автоматизировать нечего.

Клиенты - все умницы (!), просто не все явно понимают за счет чего автоматизация и возможна.

[Voral]

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

Тем не менее я очень прилично поработал да кризиса. На проектах с ТЗ. И как бы то ни было они существуют и работают без остановок.
В прочем есть и проект без ТЗ, которому уже более 10 лет. И он по нескольку раз в месяц обновляется (то закон новый, то юристы что-то в законах откопают, то начальство отчет навороченный захочет).

Я это (без ТЗшные проекты) уже прошел. Клиент просит "сделайте на заковыколку" - делаешь - а нам бы надо скрещенную с кувыколкой..... Теперь порой даже на некоторые отчеты составляем подобие ТЗ. А в случаях коммерческой разработки это вообще очень опасно и можно себе геморой нажить.

Но вернемся к бухгалтерии.
Если говорить лично обо мне. Базовое ТЗ будет составлено в люом случае. И иначе как вы будете делать? Как структур БД продумаете? А если структура в результате без ТЗ шного создания превратится в черте, что? ТЗ не обязательно бумага с 7ю печатями. Возможно, в данном случае, просто клочек бумаги. Ну, а самое главное я кухню представляю. А если дать это написать комуто? Как ему объяснить, что ты хочешь.

программой[i]), то как ставятся требования к ПО, то как usecases МЕНЯЮТСЯ и ДЕТАЛИЗАИРУЮТСЯ в ходе разработки проекта. Поймите RUP-вскую "пирамиду требований" потребности->фичи->требования->(элементы архитектуры + документы + тесты)
во вторых - изучайте итерационные технологии разработки. В этом контексте смотри пункт про изменения и детализацию useCases.

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

Уходите от ТЗ на программы. не будет у вас живых программ с ТЗ.

10 летний опыт привел таки к обратному выводу.... может дальше....

А ТЗ - это попытка "построить франкенштейна": сначала сшить мертвую материю, а потом по волшебству оживить её. Понятно что надеется что результат будет жить - как минимум глупо. Сказок не бывает.

Слишком вы категорично. Я знаю случаи когда люди влетали в неприятности от отсутствия ТЗ даже на низкобюджетных проектах (причем с обоих сторон). Знаю так же случаи, когда приходилось жестоко переписывать код, из-за забытой заказчиком "мелочи".
И на ГОСТы мне фиолетово. Для меня ТЗ это не просто какаято отписка.

Другое дело. Мало кто умеет грамотно писать ТЗ. По этому написание хорошего грамотного ТЗ стоит столько же сколько работа по самому проекту.

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

Под ТЗ я имел ввиду не ГОСТы, а именно техзадание, т.е. "алгоритм" по которому она (программа) должна работать.

Естествено. Под ТЗ я подразумеваю абсолютно то же самое. Лишь в некоторых проектах выдвигалось требование оформить его скогласно ГОСТу. Но это только оформление суть у ТЗ в любом случае одна.

[skmdeveloper]

Я лично с ТЗ никогда не работал. В нашей глубинке никто не знает что это такое и с чем его едят. Я честно говоря тоже. Просто нужно вникать в то что делаешь. Хочешь писать программы для бухгалтерии - изучи ее как пользователь НА ПРАКТИКЕ.

Если уж по существу, то успех 1С в реалистичном подходе. Их программы делают немного, но достаточно хорошо. Другие много обещают, но мало делают.

Был у нас случай. Закупили нашим бюджетным организациям "Парус" - 20 комплектов. Их специалисты рассказывали местным лохам, насколько крутая их программа и насколько плоха 1С. Но факт - никто не смог работать, деньги (большие, чемм пришлось бы отдать за 1С) ушли впустую. А кто работал с 1С - работают многие годы без всякого сопровождения и обслуживания.

[trdm]

Я лично с ТЗ никогда не работал. В нашей глубинке никто не знает что это такое и с чем его едят.

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