Комментарии 37
Сколько букв
Текст хороший, если вы действительно готовы отдать проект лицензируйте его под bsd, mpl или mit и выложите на гитхаб. Сложность вашего проекта потребует от специалистов сегодняшней квалификации полное погружение длинною в 6-12 месяцев, что много.
Ух, кипучая у вас голова. Выше написано о погружении в 6-12 месяцев. Вероятно, причина провала и в этом. Представьте ситуацию, когда команда, включая вас, снимается с поддержки: кто заболел, кто ещё чего. Новый функционал нужен вчера. И всё — махина вместе со всеми её надеждами, надеждами заказчика, рушится. Потому что полностью зависит от команды. А ведь чем сложнее система, тем проще её сломать. Описание в этом посте вызывает нечто на грани священного трепета. Рынку трепет не нужен. Ему нужно противоположное: хочу и беру, потому что это просто и удобно.
Ещё причина: как ни странно это прозвучит, переавтоматизация. Насколько я понимаю, в идеале и в перспективе некий человек, севший в кресло, может заменять несколько других людей. Несколько людей, достаточно умных для того, чтобы сохранить своё рабочее место за собой.
Ещё причина: как ни странно это прозвучит, переавтоматизация. Насколько я понимаю, в идеале и в перспективе некий человек, севший в кресло, может заменять несколько других людей. Несколько людей, достаточно умных для того, чтобы сохранить своё рабочее место за собой.
Что сразу бросается в глаза, это уникальный понятийный аппарат, практически не пересекающийся как с предметной областью, так и с офисными средствами автоматизации а-ля Excel. Из этого фактора вытекает проблема отсутствия интереса к продукту со стороны потенциальных пользователей, а пользователи — это не ИТ-специалисты банков, а непосредственно сами банкиры.
Следующим фактором неуспеха проекта является отсутствие «политической крыши» в организации, которая могла бы стать потенциальным пользователем системы. Ведь комплексные системы аналитики — это не просто накачанные калькуляторы, а инструмент ведения внутрикорпоративных войн («кто владеет информацией, тот владеет миром»). А потому оппоненты группе, владеющей таким инструментом, всегда будут заинтересованы, чтобы у конкурента не появился эффективный рычаг давления на них самих. При этом сама группа-владелец инструмента всегда будет опасаться попасть в зависимость от технического специалиста, которого потенциально может «перекупить» конкурент. Поэтому в таких проектах нужно абсолютное доверие между «политической крышей» и разработчиком.
Еще один фактор неуспеха связан с отсутствием команды (речь не идет о подчиненных) хотя бы в лице одного специалиста из предметной области, владеющим ИТ на уровне, чтобы в разговоре с ним не нужно было разжевывать элементарные вещи. Потому что в одиночку постоянно приходится переключаться с вопросов предметной области на вопросы ИТ и обратно. Это, во-первых, вызывает потери времени на переключении между темами до половины всего рабочего времени, а во-вторых, у одиночек крайне «узкий канал» генерации идей по сравнению с работой в коллективе, что связано с отсутствием эффективной обратной связи в процессе создания абсолютно нового решения, не имеющего аналогов.
Не уверен, но подозреваю, что в программном коде очень много сгенерированного IDE кода, так как проект довольно долго развивался на Delphi, в котором кодогенерация в свое время преподносилась как супер-фишка. С этим возможно связана переусложненная архитектора, которая с точки зрения разработки крайне тяжело масштабируема.
Подводя итоги, можно сделать вывод о том, что желающих подхватить Ваш проект не будет, можете не рассчитывать. Единственный вариант для запуска проекта — это поиск надежного и комфортного партнера по бизнесу для зарабатывания денег на Вашем продукте. Партнера именно по бизнесу, а не по разработке. Следующим шагом является поиск «политической крыши» из числа первых лиц хотя бы средне-крупной организации (для небольших организаций функционал аналитических систем избыточен). Ну а дальше — как карта ляжет.
Следующим фактором неуспеха проекта является отсутствие «политической крыши» в организации, которая могла бы стать потенциальным пользователем системы. Ведь комплексные системы аналитики — это не просто накачанные калькуляторы, а инструмент ведения внутрикорпоративных войн («кто владеет информацией, тот владеет миром»). А потому оппоненты группе, владеющей таким инструментом, всегда будут заинтересованы, чтобы у конкурента не появился эффективный рычаг давления на них самих. При этом сама группа-владелец инструмента всегда будет опасаться попасть в зависимость от технического специалиста, которого потенциально может «перекупить» конкурент. Поэтому в таких проектах нужно абсолютное доверие между «политической крышей» и разработчиком.
Еще один фактор неуспеха связан с отсутствием команды (речь не идет о подчиненных) хотя бы в лице одного специалиста из предметной области, владеющим ИТ на уровне, чтобы в разговоре с ним не нужно было разжевывать элементарные вещи. Потому что в одиночку постоянно приходится переключаться с вопросов предметной области на вопросы ИТ и обратно. Это, во-первых, вызывает потери времени на переключении между темами до половины всего рабочего времени, а во-вторых, у одиночек крайне «узкий канал» генерации идей по сравнению с работой в коллективе, что связано с отсутствием эффективной обратной связи в процессе создания абсолютно нового решения, не имеющего аналогов.
Не уверен, но подозреваю, что в программном коде очень много сгенерированного IDE кода, так как проект довольно долго развивался на Delphi, в котором кодогенерация в свое время преподносилась как супер-фишка. С этим возможно связана переусложненная архитектора, которая с точки зрения разработки крайне тяжело масштабируема.
Подводя итоги, можно сделать вывод о том, что желающих подхватить Ваш проект не будет, можете не рассчитывать. Единственный вариант для запуска проекта — это поиск надежного и комфортного партнера по бизнесу для зарабатывания денег на Вашем продукте. Партнера именно по бизнесу, а не по разработке. Следующим шагом является поиск «политической крыши» из числа первых лиц хотя бы средне-крупной организации (для небольших организаций функционал аналитических систем избыточен). Ну а дальше — как карта ляжет.
С точки зрения банковского ITшника.
«Сердцем» работы любого банка является некая АБС (Автоматизированная Банковская Система). Именно в ней происходит вся работа банка и хранятся все данные.
Как бы ни была хороша Ваша система, ее надо как-то интегрировать в конкретную АБС на которой работает конкретный банк. Как у вас этот процесс реализуется?
Вот у нас используется АБС MySYS Equation на платформе IBM i (бывш. AS/400). Как туда можно интегрировать Вашу систему? Каким образом Вы планируете получать данные из АБС? Кто будет этим заниматься?
Непосредственно на AS-ку Вы ее не встроите — никаких дельфей там нет. Есть RPG, есть С/С++.
Есть еще Pega. Но это тоже не ваше.
Что еще есть… Есть механизм вебсервисов, через которые можно посылать запросы и получать ответы (как в виде единичных блоков данных, так и в виде resultset'ов). Есть WBI через которую мы можем обмениваться данными со внешними системами (скажем, посылать туда некоторые данные при изменении каких-либо таблиц БД АБС).
Но в любом случае прямого доступа к БД Вам никто не даст. Нужен механизм выгрузки нужных вам данных.
«Сердцем» работы любого банка является некая АБС (Автоматизированная Банковская Система). Именно в ней происходит вся работа банка и хранятся все данные.
Как бы ни была хороша Ваша система, ее надо как-то интегрировать в конкретную АБС на которой работает конкретный банк. Как у вас этот процесс реализуется?
Вот у нас используется АБС MySYS Equation на платформе IBM i (бывш. AS/400). Как туда можно интегрировать Вашу систему? Каким образом Вы планируете получать данные из АБС? Кто будет этим заниматься?
Непосредственно на AS-ку Вы ее не встроите — никаких дельфей там нет. Есть RPG, есть С/С++.
Есть еще Pega. Но это тоже не ваше.
Что еще есть… Есть механизм вебсервисов, через которые можно посылать запросы и получать ответы (как в виде единичных блоков данных, так и в виде resultset'ов). Есть WBI через которую мы можем обмениваться данными со внешними системами (скажем, посылать туда некоторые данные при изменении каких-либо таблиц БД АБС).
Но в любом случае прямого доступа к БД Вам никто не даст. Нужен механизм выгрузки нужных вам данных.
Github — pet проект?! :-)
Сначала подумал, что статья про стартап, а оказалось — о том, как хотелось разработать продукт и внедрить.
В проекте такой сложности вы сами в первую очередь являетесь точкой отказа. Вам уже про это написали. Связываясь с вашей разработкой, резко повышаются риски бизнеса, ведь вы же не «старая уважаемая фирма», а какой-то идейный васян-одиночка.
В бизнесе, тем более корпоративном, нельзя недооценивать эффекты, связанные с карго-культом. Поэтому хорошей стратегией было бы, к примеру, запилить свою аналитику на готовой широко известной платформе. Из-за лицензионных проблем, на SAP этого бы сделать просто и быстро не удалось, но взять хотя бы (к примеру!) 1С — тут только в путь. Например, даже если в вашей реализации не нужна 1С, вы даже могли взять web-клиент 1С, поднять сервер приложений 1С в веб-частью (это Апач), и к нему прикрутить модуль веб-сервера, реализованный так, как вам нужно. Вы могли бы взять тонкий клиент 1С, поднять чистый сервер приложений 1С без веб-части, и на 1С сделать только прослойку до вашего кода. В любом случае вы прикрывались бы всем известной платформой, и не особо афишируя как там устроено внутри, могли бы продвигаться «под прикрытием» бренда.
Я не знаю, какие еще популярные платформы есть в банковском бизнесе, ну хотя бы TomCat и иже с ним, им тоже можно было бы прикрываться.
Вообще, судя по материалам статьи, вы реализовали недо-клиент 1С (модуль форм, бизнес-объекты, объекты баз данных и т.д.), только на более низком технологическом уровне (просто потому что вы один, а не команда разработчиков, начавшая проект 30 лет назад). И еще Delphi в 2020 году...
В любом случае, у карго-пользователей нет к вам доверия как к поставщику системообразующего сервиса. Как к специалисту доверие есть, а вот к вышеописанному процессу — нет.
* * *
Я вам расскажу другую историю.
Я работал в фирме, которая выпускала некие аппараты с кнопочками и экраном. Так вот, политика этой фирмы была в том, чтобы всячески поддерживать миф о том, что это импортное оборудование, хотя вся линия сборки и ПО было российским. По сути, китайским там были материнка и экран, остальная электроника собиралась самостоятельно на своих платах, корпус и силовой каркас был тоже были нашими. И ПО тоже от начала и до конца полностью свое, от прошивок микроконтроллеров до пользовательского интерфейса с отрисовкой через OpenGL, вплоть до официально разрешенных комментариев в коде на русском языке. Но для покупателей мы выглядели именно как представительство иностранной фирмы родом из 80-х.
Если бы фирма позиционировала свое оборудование как отечественный продукт, она бы просто не выжила в 90-х. А она выжила.
Вот и вам надо было тянуть рядом с проектом не просто перечень технологий, а долбить всем, что проект построен на базе того, к чему уже есть доверие у потенциальных заказчиков; по каким причинам есть доверие — неважно. Но важно искуственно понизить свою значимость до «мы всего лишь сделали модуль под <Всем Известную Платформу К Которой Есть Доверие Сформированное Годами>». Вот тогда было бы больше шансов на продвижение. Это неприятно и неправильно, но таковую стратегию диктует среда в которой вы работаете.
В бизнесе, тем более корпоративном, нельзя недооценивать эффекты, связанные с карго-культом. Поэтому хорошей стратегией было бы, к примеру, запилить свою аналитику на готовой широко известной платформе. Из-за лицензионных проблем, на SAP этого бы сделать просто и быстро не удалось, но взять хотя бы (к примеру!) 1С — тут только в путь. Например, даже если в вашей реализации не нужна 1С, вы даже могли взять web-клиент 1С, поднять сервер приложений 1С в веб-частью (это Апач), и к нему прикрутить модуль веб-сервера, реализованный так, как вам нужно. Вы могли бы взять тонкий клиент 1С, поднять чистый сервер приложений 1С без веб-части, и на 1С сделать только прослойку до вашего кода. В любом случае вы прикрывались бы всем известной платформой, и не особо афишируя как там устроено внутри, могли бы продвигаться «под прикрытием» бренда.
Я не знаю, какие еще популярные платформы есть в банковском бизнесе, ну хотя бы TomCat и иже с ним, им тоже можно было бы прикрываться.
Вообще, судя по материалам статьи, вы реализовали недо-клиент 1С (модуль форм, бизнес-объекты, объекты баз данных и т.д.), только на более низком технологическом уровне (просто потому что вы один, а не команда разработчиков, начавшая проект 30 лет назад). И еще Delphi в 2020 году...
В любом случае, у карго-пользователей нет к вам доверия как к поставщику системообразующего сервиса. Как к специалисту доверие есть, а вот к вышеописанному процессу — нет.
* * *
Я вам расскажу другую историю.
Я работал в фирме, которая выпускала некие аппараты с кнопочками и экраном. Так вот, политика этой фирмы была в том, чтобы всячески поддерживать миф о том, что это импортное оборудование, хотя вся линия сборки и ПО было российским. По сути, китайским там были материнка и экран, остальная электроника собиралась самостоятельно на своих платах, корпус и силовой каркас был тоже были нашими. И ПО тоже от начала и до конца полностью свое, от прошивок микроконтроллеров до пользовательского интерфейса с отрисовкой через OpenGL, вплоть до официально разрешенных комментариев в коде на русском языке. Но для покупателей мы выглядели именно как представительство иностранной фирмы родом из 80-х.
Если бы фирма позиционировала свое оборудование как отечественный продукт, она бы просто не выжила в 90-х. А она выжила.
Вот и вам надо было тянуть рядом с проектом не просто перечень технологий, а долбить всем, что проект построен на базе того, к чему уже есть доверие у потенциальных заказчиков; по каким причинам есть доверие — неважно. Но важно искуственно понизить свою значимость до «мы всего лишь сделали модуль под <Всем Известную Платформу К Которой Есть Доверие Сформированное Годами>». Вот тогда было бы больше шансов на продвижение. Это неприятно и неправильно, но таковую стратегию диктует среда в которой вы работаете.
И почему все кончилось обломом, я до сих пор толком не понимаю.
tl;dr; — чтобы что-то продавать, нужно уметь это делать, сори.
Продажа продукта это всегда история о том, как покупатель с помощью продукта побеждает врагов, прославляется, получает уважение, признание, славу, богатство. Для этого в голове у покупателя должно быть кое-что
— Должен быть образ проблемы (Змей-Горыныч, Кащей-Бессмертный)
— Должно быть понимание того, как проблему решить (найти меч кладенец, отрубить все головы; найти и разбить яйцо, сломать иголку)
Важно (думаю вам как раз этого не хватило) чтобы продавец и покупатель одинаково смотрели на проблему. Часто бывает так, что приходит сотрудник (часто из ИТ) и говорит что-то вроде — «на нас идет Горыныч! Щас все сожжет! Мы все умрем! АААА! Надо срочно строить крепость!» А ему в ответ — «Это не Горыныч, это всего лишь ящерица. Щас мы ее кааак заигнорим и все будет ок».
Например — ЦБ изменил требования к отчетности, нужно собирать новые показатели. ИТ отдел в ужасе — это же невозможно вычислить, там все нелинейное, там надо 100 раз по базе в 100 ТБ пройтись чтобы это посчитать, у нас же отчет такой будет строиться 6 месяцев. А ген. дир. спокоен, он знает, что в ЦБ насрать на эти показатели, их можно посчитать примерно, в Excel. Да погрешность будет 30%, но это невозможно проверить, поэтому на это, как и на многие другие требования можно забить. Кому-то «Горыныч и все умрем», а кому-то «ящерица, в игнор».
Если говорить о вашем продукте, то думаю у вас проблемы на двух фронтах. У покупателя нет образа проблемы или он не совпадает с тем, что у вас в голове. Вторая предполагаемая проблема — ваш продукт говорит на непонятном языке. Может быть это и есть меч кладенец, но у него инструкция на китайском. Может он Горыныча рубит, а может только морковку, непонятно. В такой ситуации никто рисковать не будет. Выше говорили, что у вас немного нестандартная терминология, это аналог китайской инструкции. Полагаю, терминология нестандартная потому, что вы нестандартно решаете проблему. Но это все же усложняет понимание вашего продукта.
То, что продуктом интересовались и даже выделяли на него деньги говорит в пользу его нужности. А то, что делали это по вторичному принципу говорит о том, что не понимали всей его важности. Проблема либо в том, что он действительно не важен (вам кажется Горыныч, покупателю ящерица) либо в коммуникации. Кажется у вас мало опыта в продажах, это чувствуется по тексту и это еще одна большая проблема. Отсутствие опыта продаж почти всегда заканчивается созданием «странных» (с точки зрения клиентов) продуктов. Разработчик не умеет увидеть, когда у клиента загораются глаза, в итоге вместе с важными фичами в продукте оказывается гора того, что важно программисту, но не важно клиенту.
Очень большая статья, я так и не смог до конца дочитать( Хочу высказать мнение, что может дело в Асемблере и отсутствии реляционной бд? Ведь для сложный огромных проектов существует Java и реляционные бд не просто так крепко закрепились на рынке, они очень упрощают управление сложностью огромных систем, я на своем уровне даже не представлю как такое разрабатывать и поддерживать наверно нужны очень хорошие специалисты в узком профиле, и как найти их на рынке.
Много букв, прочитал не все. Но из того что я прочитал могу точно сказать в чем проблема и почему проект не «полетел». Автор рассуждает как инженер и наемный работник. Скорее всего думал о том, что проблема любого продукта — сугубо техническая и главное его напрограммировать, а клиенты попрут сами. Так бывает почти всегда, когда программисты первые разы пытаются в бизнес. Увы, бизнес заключается вовсе не в строках кода, которые вы смогли или не смогли написать. Дьявол кроется в живом общении, умении рассказать, привлечь, убедить, продать, найти нужных людей, выстроить с ними отношения.
У меня лежит куча проектов, которые я думал что «выстрелят» стоит им только оказаться на рынке. Сказать сколько раз произошло так, как я думал? Ни одного.
У меня лежит куча проектов, которые я думал что «выстрелят» стоит им только оказаться на рынке. Сказать сколько раз произошло так, как я думал? Ни одного.
Тут еще проблема часто в том, что нужно пообщаться с потенциальным заказчиком и выяснить его потребности. Потом выяснить в какой среде он работатет. И только потом думать как реализовать потребности заказчика и интегрировать реализацию в его рабочую среду.
А здесь получился сферический конь в вакууме. Вроде как все красиво, но от реальной жизни бесконечно далеко.
А здесь получился сферический конь в вакууме. Вроде как все красиво, но от реальной жизни бесконечно далеко.
Несколько странно, что человек, имевший столько попыток на внедрение в разных компаниях так и не понял, как это работает.
Есть несколько способов продать продукт в Enterprise:
1) Личные связи.
Этот способ самый надежный, но и самый сложный, если нет таких связей. Нужно найти выходы на топ-менеджеров компании и заинтересовать их. Способов заинтересовать не так много, но это тема для отдельной статьи.
2) Уникальные фичи продукта.
То, чего нет ни у кого. Либо есть, но стоит дорого. Либо есть, но работает не так как нужно(медленно, с багами, потребляет много ресурсов и так далее). Лишь с большой натяжкой сюда можно отнести продукт автора.
3) Удача.
Иногда удача улыбается всем и автор не исключение:
Но тут он сам налажал и упустил свою синицу буквально из рук. А каждое успешное внедрение открывает дорогу к следующему.
Напоследок: корпоративные продажи это и участие в корпоративных междусобойчиков и если вы сделали правильную ставку на правильных людей — удача непременно улыбнется. Но не стоит забывать, что в крупной компании всегда будут пытаться «подсидеть» конкурирующие стороны, коих может быть немало. А тут уже нужны не технические навыки, а политические.
Есть несколько способов продать продукт в Enterprise:
1) Личные связи.
Этот способ самый надежный, но и самый сложный, если нет таких связей. Нужно найти выходы на топ-менеджеров компании и заинтересовать их. Способов заинтересовать не так много, но это тема для отдельной статьи.
2) Уникальные фичи продукта.
То, чего нет ни у кого. Либо есть, но стоит дорого. Либо есть, но работает не так как нужно(медленно, с багами, потребляет много ресурсов и так далее). Лишь с большой натяжкой сюда можно отнести продукт автора.
3) Удача.
Иногда удача улыбается всем и автор не исключение:
Мой бывший шеф по МРЦ возглавил в банке ПСБ департамент стратегических исследований. И он разрешил мне поставить проект на апробацию. И что я вам скажу? — Никогда не пробуйте эксплуатировать у заказчика сырой проект. Только навредите репутации. Так и случилось. После пары сбоев – прохлада со стороны банкиров.
Но тут он сам налажал и упустил свою синицу буквально из рук. А каждое успешное внедрение открывает дорогу к следующему.
Напоследок: корпоративные продажи это и участие в корпоративных междусобойчиков и если вы сделали правильную ставку на правильных людей — удача непременно улыбнется. Но не стоит забывать, что в крупной компании всегда будут пытаться «подсидеть» конкурирующие стороны, коих может быть немало. А тут уже нужны не технические навыки, а политические.
А шеф сам выходец из ПСБ и айтишники из ПСБ и все они знакомы. И шеф решил пользоваться тем, что принесут ребята из ПСБ и не рисковать новыми подходами. Итак, меня прокатили.
Повесть о поиске "серебренной пули". Банку нужны надежные команды, которые знакомы с каким то определенным продуктом, а желательно чтобы был источник кадров на рынке под этот продукт. Бизнес очень подозрительно относится к проектам от одного человека под которые еще пойди поищи команду. Грубо говоря бизнесам нужны другие надежные бизнесы (охапки специалистов ориентированных на длительные отношения).
Например — создать альтернативу 1С
не надо, мы опять будем читать статью, сделал — бомбу — не пошло
убийц 1С было ооочень много, проблема там не в «что им не нравится в 1С.», а в том «что вам не понравится в вашей альтернативе, но вы еще об этом не знаете» (с)
>> Вообще, судя по материалам статьи, вы реализовали недо-клиент 1С (модуль форм, бизнес-объекты, объекты баз данных и т.д.), только на более низком технологическом уровне (просто потому что вы один, а не команда разработчиков, начавшая проект 30 лет назад). И еще Delphi в 2020 году…
> Но мне кажется, что на самом деле автор сделал полноценный движок — аналог движка 1С. А не «недо-клиент».
Я по запарке написал «недо-клиент». Конечно, я имел в виду «недо-среду исполнения», с сервером, клиентом, сопутствующим обвесом и различными уровнями абстракции. Проблема в том, что этот проект по своей сути представляет собой в лучшем случае «ранний прототип 1С». До уровня 1С ему еще расти и расти. Он даже будет работать и выдавать результат, но надо потратить кучу ресурсов, чтобы получилось что-нибудь вменяемое, на что большой бизнес может положиться. Куча ресурсов, которую надо потратить, настолько большая, что у автора их точно нет и никогда не будет. А большой бизнес не готов оплачивать такие эксперименты.
> И я не согласен, что на более низком техническом уровне. Мне кажется, что технологического уровня ниже 1С трудно добиться.
Видимо, вы не знаете и не представляете, как устроена разработка 1С изнутри. Все там в порядке с технологичностью. И уж конечно, никто в здравом уме не стал бы завязывать разработку на Delphi, хотя бы из-за проблем с кроссплатформенностью.
Автору я рекомендую посмотреть на Дебет Плюс: это «народная» система организации учета на Украине, имеет частично открытый исходный код, базовая конфигурация распространяется бесплатно. У нее тысячи официальных внедрений и неизвестное количество никак неучтенных использований. Она полностью построена на открытых продуктах, таких как:
Как и у нас с 1С, на Украине есть местная прослойка специалистов по внедрению Дебет Плюс. То есть, есть все элементы инфраструктуры, сформированные годами, и они реально работают. Но при всех этих достоинствах эта система как была уделом малого бизнеса, так им и осталась. И что-то не видно, чтобы крупный бизнес внедрял данную систему в свои бизнес-процессы. А у автора нет даже того, что предоставляет Дебет Плюс с точки зрения потребителя. У него есть просто реализация концепта. Но до реального продукта ему как пешком до луны.
> Работы конечно много, но есть и краудфандинг и опенсорс варианты развития.
Как автор нескольких опенсорс-проектов, скажу: вряд ли это возможно, тем более в России. Все, на что может рассчитывать автор — это пилить проект параллельно со своей основной работой, а донатов хватит только «на пиво». Учитывая тот объем мелочей, в которых можно увязнуть в проекте таких размеров, у одного человека просто не будет времени в сутках, чтобы в разумные сроки выдавать результат, который может выдать хорошо оплачиваемая команда профессионалов-разработчиков в разумное время.
Я понимаю автора, и он делает прекрасный жест, выдавая свой проект в опенсорс. Но я бы особо не расчитывал на то, что проект будет дальше развываться сообществом.
> Но мне кажется, что на самом деле автор сделал полноценный движок — аналог движка 1С. А не «недо-клиент».
Я по запарке написал «недо-клиент». Конечно, я имел в виду «недо-среду исполнения», с сервером, клиентом, сопутствующим обвесом и различными уровнями абстракции. Проблема в том, что этот проект по своей сути представляет собой в лучшем случае «ранний прототип 1С». До уровня 1С ему еще расти и расти. Он даже будет работать и выдавать результат, но надо потратить кучу ресурсов, чтобы получилось что-нибудь вменяемое, на что большой бизнес может положиться. Куча ресурсов, которую надо потратить, настолько большая, что у автора их точно нет и никогда не будет. А большой бизнес не готов оплачивать такие эксперименты.
> И я не согласен, что на более низком техническом уровне. Мне кажется, что технологического уровня ниже 1С трудно добиться.
Видимо, вы не знаете и не представляете, как устроена разработка 1С изнутри. Все там в порядке с технологичностью. И уж конечно, никто в здравом уме не стал бы завязывать разработку на Delphi, хотя бы из-за проблем с кроссплатформенностью.
Автору я рекомендую посмотреть на Дебет Плюс: это «народная» система организации учета на Украине, имеет частично открытый исходный код, базовая конфигурация распространяется бесплатно. У нее тысячи официальных внедрений и неизвестное количество никак неучтенных использований. Она полностью построена на открытых продуктах, таких как:
- Java,
- Eclipse RCP (интерфейс),
- JasperReports (генератор отчетов),
- JavaScript (как внутренний язык),
- Rhino (как среда исполнения JS),
- XML (как язык описания форм),
- PostgreSQL/MySQL на выбор (база данных).
Как и у нас с 1С, на Украине есть местная прослойка специалистов по внедрению Дебет Плюс. То есть, есть все элементы инфраструктуры, сформированные годами, и они реально работают. Но при всех этих достоинствах эта система как была уделом малого бизнеса, так им и осталась. И что-то не видно, чтобы крупный бизнес внедрял данную систему в свои бизнес-процессы. А у автора нет даже того, что предоставляет Дебет Плюс с точки зрения потребителя. У него есть просто реализация концепта. Но до реального продукта ему как пешком до луны.
> Работы конечно много, но есть и краудфандинг и опенсорс варианты развития.
Как автор нескольких опенсорс-проектов, скажу: вряд ли это возможно, тем более в России. Все, на что может рассчитывать автор — это пилить проект параллельно со своей основной работой, а донатов хватит только «на пиво». Учитывая тот объем мелочей, в которых можно увязнуть в проекте таких размеров, у одного человека просто не будет времени в сутках, чтобы в разумные сроки выдавать результат, который может выдать хорошо оплачиваемая команда профессионалов-разработчиков в разумное время.
Я понимаю автора, и он делает прекрасный жест, выдавая свой проект в опенсорс. Но я бы особо не расчитывал на то, что проект будет дальше развываться сообществом.
А мой проект был венчурным и работали в нем неплохие ребята.
Проект должен продаваться с самого начала (исключительно мое мнение), так как деньги — прямое доказательство, что проект решает реальную задачу и встроен в потребности организации или рынка.
А не пробовали из вашего проекта сделать несколько узкоспециализированных специфичных продуктов или проектов, основанных на части функционала с 2-3 ключевыми преимуществами для решения конкретных проблем бизнеса?
Возможно, что специализация позволит:
- быстрее вникать в продукт и его преимущества потенциальным заказчикам и инвесторам
- занять ниши в тех местах, где для решения "конкретного головняка" нет необходимости покупать большие системы (SAP etc..).
Исключительно мое мнение:
"В невостребованность не верю. Востребованность почти очевидна. Не будем же мы дискутировать о невостребованности давления, пульса, РОЕ… в медицине. Например, в последнее время на слуху ССП- сбалансированная система показателей. А это подмножество аналитики."
— не вы решаете востребован проект или нет, есть рынок и он решает: или покупается — значит востребован, или не покупается.
- "Маркетинг?"
- "За спиной не стояла крупная фирма, имеющая историческую репутацию?"
Есть прикольная книжка "Lean Startup" и еще одна "Спроси маму". Это вводные книги в тему стартап-бизнеса. Но я ваш путь не ходил, поэтому эти книги могут быть для вас какой то банальностью. Все же пересекаются с настроением статьи.
Даже описание проекта крайне сложное, конечно, может быть это впечатление возникает от избалованности к простым решениям на рынке, в которых стараются все уместить в несколько предложений. Но что бы я предложил автору, так это сделать декомпозицию проекта и попробовать продвигать мелкие узконаправленные сервисы, которые легко объяснить и как следствие — легко продавать.
Я бы предложил автору
Я бы предложил автору
Автор, у вас открывающие скобки слиплись с предыдущими словами. Или это профдеформация?
… И у меня забрезжила мысль, что каждой специфичной проблеме нужен свой язык. Язык проектирования и генерации отчетов, язык проектирования ввода данных, язык проектирования вывода данных, язык коммуникаций, язык обработки отношений, язык обработки списков, язык описания данных, язык бизнес-аналитики, язык размещения сервисов и управления ими, язык бухучета,… Короче, нужны не универсальные, а предметно-ориентированные языки.
И в это большая ошибка. Заново учить и разбираться в предметно-ориентированном языке, помнить все нюансы, это сильно отторгает и повышает порог вхождения. Достаточно было использовать шаблоны проектирования в универсальном языке, тот же Spring позволяет их применять и даже можно в декларативном стиле работать. Всегда, когда используете какую-либо технологию — читайте про её недостатки, например про DSL.
Автор — яркий представитель гениальных интровертов. Отличная идея, рабочая реализация. Провал в коммуникациях и внутри команды и команды с заказчиком, команда продукта толком и не образовалась. Провал внедрения сырого продукта вовсе не в том, что он сырой. Видели бы вы, каким запускают SAP или 1С. Ваши пользователи не поверили в то, что ваше решение решает их проблемы. Если бы решало хотя бы часть — мирились бы и с багами и сбоями и просили бы улучшений.
Ваши боссы не поверили, что ваше решение сможет решить их проблемы (проблемы их клиентов): отзывы снизу отрицательные, отзывы сбоку отсутствуют.
Видели бы вы, каким запускают SAP или 1С
А я видел, и запуск «технологичных и современных» софтин бывает проходит гораздо эпичнее монстров типа 1С или Сап
когда всплывают косяки в стиле «оо, а можете здесь сделать сортировку по колонке и отбор? == да конечно! задача на 2 месяца с вас 100500 денег!»...«так, а тут нам надо экспорт в csv… эээ а у нас это не предусмотрено архитектурой, мы считаем это никому не надо»
А директор говорит: “А почему бы не перейти на самоокупаемость — продавать проект по частям, которые уже реализованы?” Я опешил. Начинаю возражать, что мол МАЗ не продает колеса, а продает самосвалыКмк, разработка и продажа ПО может быть довольно успешной и при торговле небольшими законченными «блоками». Зря вы тогда не решились на это…
Сейчас, конечно, уже полно достойных конкурентов, поэтому возможно стоит посмотреть на какое-то узкое место, где ваши идеи достаточно конкурентны. В любом случае, удачи!
А что по этому поводу говорит Минский SoftClub, это же их профиль?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Облом, или как провалился любимый ИТ-проект