Comments 37
Сколько букв
UFO just landed and posted this here
Текст хороший, если вы действительно готовы отдать проект лицензируйте его под 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) Удача.
Иногда удача улыбается всем и автор не исключение:
Мой бывший шеф по МРЦ возглавил в банке ПСБ департамент стратегических исследований. И он разрешил мне поставить проект на апробацию. И что я вам скажу? — Никогда не пробуйте эксплуатировать у заказчика сырой проект. Только навредите репутации. Так и случилось. После пары сбоев – прохлада со стороны банкиров.
Но тут он сам налажал и упустил свою синицу буквально из рук. А каждое успешное внедрение открывает дорогу к следующему.
Напоследок: корпоративные продажи это и участие в корпоративных междусобойчиков и если вы сделали правильную ставку на правильных людей — удача непременно улыбнется. Но не стоит забывать, что в крупной компании всегда будут пытаться «подсидеть» конкурирующие стороны, коих может быть немало. А тут уже нужны не технические навыки, а политические.
А шеф сам выходец из ПСБ и айтишники из ПСБ и все они знакомы. И шеф решил пользоваться тем, что принесут ребята из ПСБ и не рисковать новыми подходами. Итак, меня прокатили.
Повесть о поиске "серебренной пули". Банку нужны надежные команды, которые знакомы с каким то определенным продуктом, а желательно чтобы был источник кадров на рынке под этот продукт. Бизнес очень подозрительно относится к проектам от одного человека под которые еще пойди поищи команду. Грубо говоря бизнесам нужны другие надежные бизнесы (охапки специалистов ориентированных на длительные отношения).
UFO just landed and posted this here
Например — создать альтернативу 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, это же их профиль?
Sign up to leave a comment.
Облом, или как провалился любимый ИТ-проект