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

[Voral]

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

тут не в Парусе дело. Программа далеко не новичок на рынке и успешно юзается во многих организациях


Но, что то мы от темы далековато ушли

[skmdeveloper]

Ни капельки. Может "Парусу" ТЗ писали академики, а вот 1С рассчитана на реальное положение дел.

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

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

[Voral]

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

Кхм.... Вообще говоря в создании нормального ТЗ всегда принимают участие обе стороны. Если ТЗ написано исключительно разработчиком, или наоборот заказчиком. То оно будет достаточно однобоким. Хотя, если ТЗ написано заказчиком, который может хорошо формулировать свои пожелания то хороший разработчик напишет таки программу. А изучить другую отрасль с целью написать программу!!!! Это утопия. Т.е. ктото сидит по 5 лет в институтах,а в тут так с кондачка взяли и изучили?
Загляните на бухгалтерские форумы, осознайте сколько там вопросов, и после этого подумайте может ли программист взять и резко въехать и узнать ответы на все вопросы? А останется ли у него время на разработку.
Это мелкую программулинку работающую линейно и без всяких особых заморочек можно написать вот так походя. Так, что и разработчик в одиночку не сможет написать ТЗ по такой сложной тематике.

Нет я вас понимаю. Я тоже раньше писал без ТЗ. И даже, что то складское..... И ну его нафиг теперь.....

Наивно думать, что 1Ска писалась без ТЗ. Или у вас есть неопровержимые доказательства?
И на Парус не стоит бочку катить. В вашем случае беда в кривости рук интеграторов. Ну или им толково не пояснили, чего от них ждут....

В идеале ТЗ должен быть написан в профессиональных терминах обоих сторон, и обеим же сторонам понятен.

[Boboms]

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

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

Да пускай даже и без тех языка и без спецификаций, лишь бы был план на бумаге! Я об этом. А так - всё остальное - фантазии (а у каждого они свои ) 

[Voral]

И вообще, на сколько я помню (хотя в этом могу и ошибаться) Парус не совсем аналог 1С.

Да пускай даже и без тех языка и без спецификаций, лишь бы был план на бумаге! Я об этом. А так - всё остальное - фантазии (а у каждого они свои

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

[Ali1]

Хорошо вам живется, однако.
ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ

1. Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.).

При конкурсной организации работ варианты проекта ТЗ на АС рассматриваются заказчиком, который - либо выбирает предпочтительный, вариант, либо на основании сопоставительного анализа подготавливает с участием будущего разработчика АС окончательный вариант ТЗ на AC.

2. Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС,

Работу по согласованию проекта ТЗ на AC осуществляют совместно разработчик ТЗ на АС и заказчик системы, каждый в организациях своего министерства (ведомства).

UPD А ПАРУС позволяет незаметно "изменить прошлое"?

[skmdeveloper]

Загляните на бухгалтерские форумы, осознайте сколько там вопросов, и после этого подумайте может ли программист взять и резко въехать и узнать ответы на все вопросы? А останется ли у него время на разработку.

Я по крайней мере умею заполнять эти формы и знаю откуда брать для них данные в бухгалтерском учете - приходилось делать неоднократно. Думаю таких людей много.

[skmdeveloper]

Да пускай даже и без тех языка и без спецификаций, лишь бы был план на бумаге! Я об этом. А так - всё остальное - фантазии (а у каждого они свои ) 

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

[Voral]

Я по крайней мере умею заполнять эти формы и знаю откуда брать для них данные в бухгалтерском учете - приходилось делать неоднократно. Думаю таких людей много.

это лишь верхушка "айсберга"

[Voral]

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

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

Еще раз повторю: не надо путать грамотное ТЗ и пустую отписку. Как бы вы не крутили, но и вы (пусть в голове) но составляете ТЗ.

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

Да можно сделать универсально и предусмотреть и историю и справочник. Но если это не нужно? Нафига плодить лишнее? Так тут задача простейшая.

Что касается "излишней свободы выбора".... Так надо работать с заказчиком. Могут быть две ситуации:
- он прав. Ему работать с этой программой, он работает с этими данными и говорит пожлание на собственном опыте. ВЫ должны понять его и реализовать. Видел я программы где разработчик сделал исключительно как он считает нужным - да работают, да уже привыкли, но делают это через тернии;
- он не прав. Надо объяснить почему не прав. И в итоге прийти к общему знаменателю.
Это все тоже является задачей ТЗ - прийти к общему знаменателю по все вопросам.

[Fregatte]

Если клиент не хочет платить за программу (ту же 1С Предприятие, SQL Server не важно какой IBM DB2, Oracl, или MS SQL), то и разработчику он много не заплатит, если вообще что-то заплатит. Если думать, что за счет свеого самописанного софта типа сэкономить на покупке программ, то скупой платит на дважды, а трижды и больше. Для разработки бизнес-софта нужно очень хорошо знать методологию. Такие специалисты врядли будут писать бесплатную самоделку. Пушут их обычно для изучения программирования и ждать от этого чего-то полезного врядли стоит.

[Boboms]

Вы слишком категоричны. А если клиент хочет платить за нормальный софт, а не за 1с-помойку?

[Fregatte]

Вы слишком категоричны. А если клиент хочет платить за нормальный софт, а не за 1с-помойку?

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

[Boboms]

Я с вами в корне не согласен насчет сапа и прочей типа навижна. Кто сказал, что сап - нормальный софт? В каких условиях. У нас что, в каждом закаулке по мега-крупно-оптовой фирме понатыкано, торгующей мириадами товаров? Даже в ашане сап уже избыточна, а ее пытаются запихнуть в "технологический" бизнес и небольшие компании.

ЗЫ: искренне надеюсь, что у того же Voral хватит упорства (с коим он спорил со мной на форуме ) дабы разродиться софтом для ИЧП - ООО аля "мелкий бизнес".

ЗЗЫ: вопрос не в том, что люди "жадные", а в здравом смысле. Не более того.

[Boboms]

Еще раз повторю: не надо путать грамотное ТЗ и пустую отписку. Как бы вы не крутили, но и вы (пусть в голове) но составляете ТЗ.

Проблема в том, что мало кто вообще понимает, что такое это "ТЗ". Большинство воспринимает это как "бюрократию", грязные домогательства и потерю времени, к сожалению.

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

[Denjs]

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

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

Во первых вы путаете план работ (иерархическое разбиение работ проеекта, и техническое задание.
Набор спецификаций в соответсвии с которыми долждно быть разработано техническое изделие.

2ALL кто слишком эмоционально отреагировал на призыв отказываться от ТЗ.

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

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

Читайте RUP - там НЕТ никакого "ТЗ".
Более того - вы можете сгенерировать _очередную_ версию "ТЗ" (в полном соответсвии с требованиями ГОСТ) но (тут очень важный момент) - только после получения "исполняемой архитектуры" - когда уже прошло несколько итераций разработки.
И что также важно отметить - если вы будете генерировать ТЗ как отчет в конце разных итераций разработки - он у вас будет постепенно все более и более детальным.

[Boboms]

2 Denjs
Не могу понять, что вы так за "ГОСТ" взялись? Опять таки, никто не навязывает делать ТЗ строго в соответствии с ГОСТом, хотя если ГОСТ - нормальный, то это было бы грамотно.

Под ТЗ я имел ввиду
http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%...%BD%D0%B8%D0%B5

[Denjs]

Под ТЗ я имел ввиду
http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%...%BD%D0%B8%D0%B5

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

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

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

повторюсь - имхо наиболее адекватный процесс и подход к постановке требований - опять же - смотрите UseCase и как оно развивается в RUP.

[Voral]

ЗЫ: искренне надеюсь, что у того же Voral хватит упорства (с коим он спорил со мной на форуме ) дабы разродиться софтом для ИЧП - ООО аля "мелкий бизнес".

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

[Voral]

2ALL кто слишком эмоционально отреагировал на призыв отказываться от ТЗ.

Я, наверное.

Давайте понимать одну важную и ключевую вешь: отказ от ТЗ не подразумевает отказа от описания требований к программе.

Наверное мы под ТЗ понимаем разные вещи. Или (как вариант) говорим об одном и том же, но по разному обзываем.
Я ни когда не воспринимал ТЗ как четкий и окончательный "закон". В ТЗ всегда указываю фразу типа "ТЗ может быить исправлено, дополнено по согласованию сторон".......

Если вы в таком разрезе говорите об "уходе от ТЗ". Что ж.... Пусть это так называться будет.

[trdm]

ЗЫ: искренне надеюсь, что у того же Voral хватит упорства (с коим он спорил со мной на форуме ) дабы разродиться софтом для ИЧП - ООО аля "мелкий бизнес".

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

Захостись на гуглекоде или ассембле и кинь ссылку плз.
Все в одну харьку пишут... КПД ниже абсолютного нуля

[Boboms]

Для разработки ПО нужен процесс/набор_документов который позволяет уточнять требования по мере развития ситуации. (но при этом конечно не менять объема работ и не противоречить старым требованиям)

А уточнять требования будем до бесконечности.

[Denjs]

Для разработки ПО нужен процесс/набор_документов который позволяет уточнять требования по мере развития ситуации. (но при этом конечно не менять объема работ и не противоречить старым требованиям)

А уточнять требования будем до бесконечности.

ну если вы в состоянии-нестояния и не управляете проектом, а смотрите как он сам расплывается в никуда - то да.

[Denjs]

Я ни когда не воспринимал ТЗ как четкий и окончательный "закон". В ТЗ всегда указываю фразу типа "ТЗ может быть исправлено, дополнено по согласованию сторон".......

Если вы в таком разрезе говорите об "уходе от ТЗ". Что ж.... Пусть это так называться будет.

вы не учитываете одну важную вещь: когда вы формулируете "ТЗ может быть исправлено, дополнено по согласованию сторон"
вы фактически говорите что - исправление ТЗ - это катастрофа.
признание того что "наступила жопа", простите за выражение. это "негатив" и "крайне плохо для проекта".
Т.е. начав "работать по ТЗ" - вы будете всеми силами стараться не менять его.
В итоге вы будете противиться естественным и необходимым вещам процесса разработки ПО - изменениям.
По факту мы имеем то, что "изменение" - это неотъемлемый процесс любого более-менее серьезного IT проекта.

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

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

чуете разницу? "может быть" и "будет"?

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

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

(все естественно на правах "имхо" и собственного опыта)

[Boboms]

...
Какие заказчики - такие и методы. и что-б им пусто было,

[lsfkd]

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

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

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

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

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

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

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

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

Чтобы ответить на ваш вопрос (если его можно так назвать) можете ответить на такое уточнение: "Уже два месяца вплотную сижу (после долгого перерыва) и пишу программу автоматизации учета." - почему вы начали писать программу, то есть по какой причине?

[skmdeveloper]

Чтобы ответить на ваш вопрос (если его можно так назвать) можете ответить на такое уточнение: "Уже два месяца вплотную сижу (после долгого перерыва) и пишу программу автоматизации учета." - почему вы начали писать программу, то есть по какой причине?

Просто мне нравится заниматься программированием. В практических целях (а я живу очень уж в глубинке) мне кроме как с 1С не приходилось сталкиваться.

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

Кроме того интересно - кажется не так уж неподъемное дело, но никто кажется не осилил за столько лет.

[lsfkd]

>Просто мне нравится заниматься программированием. В практических целях (а я живу очень уж в глубинке) мне кроме как с 1С не >приходилось сталкиваться.
>
>Вот и занимаюсь - может выйдет из этого какой нибудь толк, в том числе и в материальном смысле.
>
>Кроме того интересно - кажется не так уж неподъемное дело, но никто кажется не осилил за столько лет.

В общем понятно, приблизительно такой ответ я и предполагал услышать.

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

В идеале для успешного программного продукта (которых характеризуется широким спектром решаемых задач, а не банальным сложить 2+2 и вывести результат 4), пользоваться которым будут сотни, тысячи или даже миллионы пользователей нужно две вещи:
1 - Решить технические задачи, прочитайте книгу "Разработка программного обеспечения" Л.Константайн, Л.Локвуд,
Питер:2004 г
2 - Решить маркетинговые задачи, ну это наверное к дядюшке Биллу Г. или скажем к лучше к основателям Гугла
И наверное ответить на главный вопрос, готово ли сознание общества (поспольку человек социальное животное)
для тех или иных нововведений и открытий. А то вас ждет участь (в той или иной степени) человека который сказал:"И все же она вертится"
http://ru.wikipedia.org/wiki/%D0%98_%D0%B2...%82%D1%81%D1%8F!

[Boboms]

Дорогой друг!

Я крайне несогласен с п.п. 2 и 3.

2.
Если про Гейтса, зачем у него спрашивать, вот вам цепь: родственники, знакомые, друзья, ответственные за/ могущие повлиять на ... госзаказ -> ...

3.
Со всей ответственностью заявляю, что я - не "животное"! (хотя подобную формулировку слышал в Анапе в отношении туристов).

[lsfkd]

Дорогой друг!

Я крайне несогласен с п.п. 2 и 3.

2.
Если про Гейтса, зачем у него спрашивать, вот вам цепь: родственники, знакомые, друзья, ответственные за/ могущие повлиять на ... госзаказ -> ...

3.
Со всей ответственностью заявляю, что я - не "животное"! (хотя подобную формулировку слышал в Анапе в отношении туристов).

Насчет 2 - вы думаете что Билл не башлял ответственным за/ ? Или вы думаете что Гугол не накручивал счетчики платной рекламы? и т.д. и тп.

Насчет 3 - если вы находитесь на вершине пищевой пирамиды, это еще не значит что вы не животное!