Comments 75
Чего я так и не смог понять в этой истории, так это чего не хватало людям: мотивации или способностей. Ведь если кто-то работает на низкооплачиваемой работе, которая не приносит ему удовольствия, то что ему мешает потратить даже несколько часов, чтобы разобраться в задаче и решить ее. Мы уже со старта предлагали высокую зарплату, которую платят далеко не всем junior разработчикам на других языках
Людям не хватало перспектив.
Если человек способен и готов учиться, то он скорее выберет какой-то уже популярный язык. Конечно, из десятков тысяч можно найти сорок рисковых парней, способных прыгнуть в неизвестность. Но остальные скорее пойдут изучать то, что у всех на слуху.
А людям не нужен ваш мостик-то, не выглядит он для них достаточно прочным, чтобы по нему идти. Вот они и голосуют своими поступками.
А достаточно хорошо осветили, что именно "мостик" "вайтивайти" предлагаете, а не "вечный" вендор лок с вечной же сильноджуновской зарплатой?
У нас была указана вилка зарплат. Она, кстати, соответствовала уровню зарплаты в классическом программировании.
Такие менеджеры бывают обращаются ко мне за консультациями по поводу "с чего начать" и "стоит ли обратить внимание на эту вакансию". И вряд ли я посоветую при одинаковом уровне зарплаты что-то очень узкоспециализированное.
Мы предлагали очень короткий путь, где человек сразу же получал больше, чем на предыдущем месте работы.
Просто в чем проблема языков низкого уровня. Вам чтобы получать хоть какую-то зарплату, недостаточно просто выучить их синтаксис, нужно выучить еще много архитектурных шаблонов, их подводных камней, а главное фреймворков и что, где, когда и как применять. Ну или в тех же бизнес-приложениях, кроме языков общего назначения, вам нужно еще SQL выучить, с основами их оптимизации и т.п. Если вы в состоянии это сделать с нуля без всяких «мостиков» — отлично. Но таких людей не так много. А есть люди, которым необходимо изучать такие вещи step-by-step. А мы предлагали (ем) при этом еще денег заработать (причем по рынку классического программирования), уйти в Java разработку при желании, и так далее. То есть люди, которые решили «войтивайти» все равно ничего не теряли, они могли продолжать искать параллельно место джуна и практиковаться в той же Java. Но что-то их останавливало.
Так мой вопрос в том, что достаточно ли явно это было освещено в вакансии как для самих целевых кандидатов, так и для программистов, к которым эти кандидаты могли обратиться за консультацией?
И адекватный джуниор понимает что проработав в такой фирме и на таком языке несколько лет он для всех остальных фирм всё равно остаётся потенциальным джуниором. А кому такое надо?
Неудивительно, что такие компании как Google, Microsoft и Facebook редко смотрят на то, какие технологии ты знаешь. Гораздо важнее, чтобы человек понимал фундаментальные принципы различных технологий, архитектур, систем, алгоритмов и так далее. А выучить какую-то технологию или язык можно относительно быстро в таком случае.
Конечно язык это вторично. Но "вторично" не означает неважно.
И грубо говоря если ко мне приходит человек работавший скажем с С++ и желающий работать скажем с С#, то я примерно знаю чему его надо доучить, где переучить и от чего отучить. И исходя из этого "уменьшаю" его "виртуальный стаж". И даже в таком случае есть вероятность что бывший миддл получит офер на джуниора, а сениор на миддла.
А если ко мне приходит человек, который работал на каком-то малоизвестном в принципе и совсем неизвестном мне языке, то мне надо уже самому первым делом лезть и разбираться что это за зверь такой.
И если ради сениора я может и поднапрягусь, то в случае с миддлом я просто буду исходить из того что человека надо будет обучать с нуля.
И я уверен что я далеко не один с таким подходом.
И я уверен что я далеко не один с таким подходом. Хотя возможно это все касается только продуктовой разработки.
Ну и в статье в принципе речь шла о другом. А именно о learning gap. То есть, если человек не в состоянии сразу проскочить несколько уровней абстракций, ему будет проще пройти их шаг за шагом, зарабатывая при этом неплохие деньги.
И одну вещь которую я уяснил давно: человек, который умеет быстро учиться, анализировать и структурировать информацию, на любом языке даже в среднесрочной перспективе принесет проекту гораздо больше
Извините, но это уже совсем о другом. Если я вижу что у человека приличный опыт и он работал на куче разных языков, то это конечно явный плюс.
Но вот если он всю свою профессиональную жизнь проработал на одном языке, а теперь хочет у меня работать на другом, то это на мой взгляд совсем иная ситуация.
Особенно если его "старый" язык сильно отличается от "нового". И особенно если он до этого работал на каком-то малоизвестном и экзотическом языке.
Ну и в статье в принципе речь шла о другом. А именно о learning gap. То есть, если человек не в состоянии сразу проскочить несколько уровней абстракций, ему будет проще пройти их шаг за шагом, зарабатывая при этом неплохие деньги.
Всё это конечно очень субъективно, но лично я бы пошёл на такую работу только если бы я вообще нигде не мог ничего найти. Да и то ровно до тех пор пока я бы не нашёл чего-то получше. И я бы это "получше" активно искал.
Ну либо если бы зарплата была раза в полтора-два-три выше чем в среднем по профессии/позиции/региону. И то тоже не факт что не стал бы параллельно с этой работой искать другую.
Другое дело, когда начинает программировать менеджер среднего звена, который о программировании раньше ничего не слышал. Я себе слабо представляю такого человека, который вот так сядет и начнет сразу кодить, например, на C++. Вполне возможно, что таким людям проще будет идти сверху вниз (с 5го уровня как описано в статье), погружаясь при возможности/необходимости все ниже и ниже. Дело в том, что вполне возможно, что некоторые из них остановятся на каком-то из уровней и не захотят пойти глубже (в силу желания или способностей).
У нас в Беларуси, часто можно видеть картину, когда на какие-нибудь курсы по Java набирается группа из бывших врачей, учителей, экономистов и так далее, а просто до конца этих курсов доходит меньше половины. Так как для них это очень большой скачок в сознании, и они не понимают «кто все эти люди и зачем все это надо». Возможно им проще было бы начинать со связывания бизнес-объектов (как в lsFusion), чем с переменных/циклов/управления памятью и т.д.
Возможно им проще было бы начинать со связывания бизнес-объектов (как в lsFusion), чем с переменных/циклов/управления памятью и т.д.
Я соглашусь что начинать с языков вроде С/С++ или Ассемблера таким людям возможно не стоит. Но на мой взгляд какие-нибудь С#/Java/JavaScript/TypeScript на уровне стажёра/джуниора потянет любой кто теоретически имеет хоть какие-то способности к программированию.
И кроме того с моей точки зрения как раз для подобных людей вещи вроде InFusion это "болото" из которого они потом если и смогут выбраться, то с большим трудом.
А это значит мало или даже практически никаких особых перспектив куда-то уйти и/или получать нормальные зарплаты в будущем.
Интересная точка зрения. Скажите, а по-вашему, бизнес-анализ — это тоже «болото»? Там нет нормальных зарплат?
Бизнес-анализ бизнес-анализу рознь. Но я бы сказал что бывший врач или учитель в бизнес-анализе тоже вряд ли будет много зарабатывать.
Какая разница, когда человек составляет море различных бумажек (вроде ТЗ) или пишет тоже самое, например, на lsFusion?
В том то и дело что и на мой взгляд тоже здесь особой разницы нет. То есть не в InFusion дело. И человек, который понимает и умеет в "бизнес-анализ", скорее всего и так уже нормально зарабатывает и вряд ли пойдёт работать по этому объявлению.
Ну если вы вот прямо с этой стороны хотите зайти...
Да, наверное не все смогут научиться программировать на Java и уж тем более C++. И возможно даже для кого-то 1С и InFusion это в каком-то роде предел. Но даже если это и так и кто-то ориентируется именно на таких людей, то тогда наверное не стоит им рассказывать про какие-то "мостики" и будить в них несбыточные надежды? Или вы это по другому видите?
Другое дело, что если изначально для человека самой сильной была именно финансовая мотивация, то после того, как он разобравшись даже в непопулярной технологии будет зарабатывать столько же, сколько и на популярной, у него не будет стимула двигаться дальше. Но разве это нечестно со стороны работодателя, когда он говорит про «мостики»? Все в руках конкретного человека.
Поэтому не очень понимаю, причем здесь несбыточные надежды.
Потому что если человек способен на большее чем на "просто" InFusion, то ему логичнее идти не к вам, а куда-то ещё.
А вот если человек не настолько хорош или как минимум сомневается в своих способностях, то придя к вам он с большой вероятностью у вас и останется.
И в этом в общем-то нет ничего плохого, просто надо во первых понимать что скорее всего именно такие люди к вами и пойдут. То есть те самые "люди без особой мотивации и/или способностей" о которых написано в статье. И это на мой взгляд вполне себе понятно и логично.
А во вторых по мне так стоит сразу раскрыть перед таким людьми все карты и не рассказывать им про какие-то "мостики".
Ну это опять же как я лично вижу ситуацию.
Потому что если человек способен на большее чем на «просто» InFusion, то ему логичнее идти не к вам, а куда-то ещё.
Все верно. Только вот основная проблема: а как определить на что человек способен? Этого изначально не знает ни будущий работодатель, ни сам человек.
Естественно вам может тоже "повезти" и к вам внезапно попадёт какой-нибудь самородок. Или другой фирме может "не повезти" и к ним под видом самородка попадёт кто-то, для кого "1С это предел".
Но в среднем на мой взгляд всё будет происходить более-менее "логично" и к вам будут идти по большей части именно "люди без особой мотивации и/или способностей".
Когда выбирал вуз думал что программисты и математики никому не нужны и пошел за компанию с парой одноклассников на экономиста в сх вузе.
Даже если бы пошел на ИТ специальность — не потянул бы. 10 лет назад у меня еще не было компьютера, у меня даже скорость печати была меньше 20-30 символов в минуту.
Уже в процессе учебы, курсе на втором вроде, у меня появился свой компьютер, я понемногу научился набирать текст с достаточной скоростью, освоил win на минимальном уровне, начал интересоваться ИТ (благо оно меня и до того интересовало, но поскольку единственным вычислительным устройством до того была nokia 5300 развернуться не мог). Курсу к 4-5 кое как научился пользоваться linux, через попытки писать на разных языках осилил 1с (и простенький диплом был на ней). В общем к концу 5 курса 1с я еще как то мог, но больше не мог ничего. Наверно будь у меня еще год-полтора — осилил бы что нибудь другое (опустим что вакансии были либо в мелких веб студиях либо на 1с и почти ничего другого не было в регионе). А вот уже освоившись с 1с и поняв что меня в ней не устраивает — гораздо проще было сменить технологический стек. Так что это, имхо, вполне рабочий вариант.
Ну вот все же немного вас своим примером опровергну. Я начинал 5 лет назад с 1с, и на тот момент больше ни во что бы не мог.
Извините, но вы на мой взгляд меня не опровергаете, а скорее подтверждаете. Потому что вы по хорошему всегда были как минимум теоретически способны на большее.
И если бы вы сразу пошли "по правильному пути", то и "настоящим программистом" стали бы гораздо быстрее и скорее всего в професиональном плане на данный момент добились бы большего. Это если совсем упрощать :)
Если человек без IT-бэкграунда сходу въехал в Java, а точнее скажем в Java Spring (так как голая Java как вы понимаете никому не нужна), то супер, я бы его сразу Senior'ом взял, так как у него просто уникальные способности к обучению. Но речь то об «обычных» людях. И тут смотрите какой у человека выбор:
а) Поучаствовать в реальных высоконагруженных (для систем уровня сложности ERP естественно) проектах. При этом проекты на стыке прикладного языка и Java, так некоторые вещи делаются на Java, вы всегда можете спуститься на уровень Java и т.п. Более того можно работать с «полными» исходниками (и многие так и делают), то есть одновременно и с исходниками платформы на Java, при желании туда коммитить, решая задачи по платформе (что очень даже приветствуется), тем самым заполняя свой профиль на Github участием в open-source проекте с миллионами строк кода, на которых работают десятки тысяч пользователей и компании с миллиардными оборотами. Но даже если не делать этого, все равно можно разобраться как работают сложные ИТ-системы, как они разрабатываются поддерживаются, научиться работать с CI/CD, IDEA, Git, Maven и т.п. При этом получать нормальные деньги даже по меркам классического программирования.
б) рассылать резюме, а вдруг возьмут джуном работать за еду.
Даже не знаю, чтобы я выбрал. В любом случае хотелось бы услышать от вас более эффективный вариант как разорвать порочный круг «нет опыта, не берут на работу», «нет работы, не будет опыта»?
Если человек без IT-бэкграунда сходу въехал в Java, а точнее скажем в Java Spring
У нас школьники-практиканты приходят на двухнедельную обязательную школьную практику и по большей части "сходу вьезжают" в то, что мы им показываем на С#, TypeScript, Angular, WPF и прочем. И это при том как минимум половина из них в ИТ даже особо то и идти не собирается.
И на мой взгляд если человек даже такое осилить не способен, то наверное в ИТ ему делать нечего.
В любом случае хотелось бы услышать от вас более эффективный вариант как разорвать порочный круг «нет опыта, не берут на работу», «нет работы, не будет опыта»?
Так вы же на мой взгляд как раз таки тоже никакой "порочный круг" не разрываете. Потому что как по мне, так что нет у человека вообще опыта в программировании, что у него есть опыт работы у вас, никакой особой разницы это не делает.
И я либо буду смотреть что человек в принципе из себя представляет, либо просто откажу ему сразу и всё.
П.С. Наверняка кто-то к этому подходит и по другому. Но не думаю что прямо так чтобы очень много людей :)
П.П.С. А если действительно у кого-то нет опыта/стажа и ему очень хочется куда-то на работу айтишником устроиться, то можно какой-то более-менее адекватный пет-проект завести и про него в резюме писать.
Либо например пытаться искать работу в айтишную компанию не айтишником(например QA, техдокументацию писать/оформлять, Scrum master'ом каким-нибудь) с опцией "переквалификации" по ходу дела.
Потому что как по мне, так что нет у человека вообще опыта в программировании, что у него есть опыт работы у вас, никакой особой разницы это не делает.
Ну, как минимум, человек, у которого есть опыт работы у нас умеет:
1. Работать с системами контроля версий (Subversion/Git)
2. Работать с IntelliJ IDEA
3. Пользоваться дебаггером
4. Работать с Issue tracking system.
5. Строить доменную логику (по сути, основы баз данных и SQL)
6. Строить пользовательские интерфейсы (то есть умеет делать простую верстку)
Уже лучше, чем ничего. Разве нет?
Уже лучше, чем ничего. Разве нет?
Это вы сейчас это утверждаете. Но почему кто-то должен вам верить? И уж тем более почему кто-то должен верить потенциальному кандидату, который это рассказывает?
И это сейчас не какой-то наезд на вас с моей стороны, а обычная ситуация при приёме на работу когда напротив тебя сидит незнакомый тебе человек.
П.С. Кроме того лично я знаю кучу айтишников, которые по каким-то своим причинам считают что 1С/Sap это не "настоящее программирование" и человека с опытом рпботы в этой области возьмут к себе в последнюю очередь. И такой подход пожалуй не особо адекватен, но он встречается повсеместно.
У нас школьники-практиканты приходят на двухнедельную обязательную школьную практику и по большей части «сходу вьезжают» в то, что мы им показываем на С#, TypeScript, Angular, WPF и прочем. И это при том как минимум половина из них в ИТ даже особо то и идти не собирается.
Эээ… Что это за школа в которой обязательная практика школьная в ИТ компании? Это точно обычная российская школа?
У нас школьники-практиканты приходят на двухнедельную обязательную школьную практику и по большей части «сходу вьезжают» в то, что мы им показываем на С#, TypeScript, Angular, WPF и прочем
Сходу въезжают — это кивают головой, типа да все понятно? Или по аналогии могут еще одну компоненту сделать? Для того чтобы писать на любой технологии нужно иметь хоть какую-то общую картину, а ее на pet проекте ну очень тяжело составить. Проверено на личном опыте. Я так много вещей изучал, но в реальной среде приходится все переосмыслять практически заново (в том случае конечно если нет опыта в очень похожей технологии).
Так вы же на мой взгляд как раз таки тоже никакой «порочный круг» не разрываете. Потому что как по мне, так что нет у человека вообще опыта в программировании, что у него есть опыт работы у вас, никакой особой разницы это не делает.
Вы конечно нам льстите. В том плане что считаете, что у нас человек вообще ничего не должен понимать, а оно все само работает на террабайтных базах, тысячах одновременных пользователей и очень сложной логике. Но ок, еще раз. Если человек хочет, он может сразу начать и на Java писать, это только приветствуется. Внутри используется тот же Java Spring, фронт сейчас будет делаться на React, есть много инфраструктурных вещей на разных языках. Все open-source, все видно в профиле на GitHub. Можно при желании выбрать любую технологию, и продолжить работать на ней внутри компании. И все можно делать step-by-step. А не сразу вот тебе тонны низкоуровневого кода разбирайся — не можешь так чего ты сюда пришел работать.
П.С,: Из QA или техдокументации переквалифицироваться еще сложнее так, как это вообще не программирование. То есть «болото» как вы говорите еще хуже.
Сходу въезжают — это кивают головой, типа да все понятно? Или по аналогии могут еще одну компоненту сделать?
Когда как. Иногда компоненту. Иногда маленькую программку. Зависит от того сколько практикантов и сколько у народа есть на них свободного времени.
В принципе присматриваемся мы к ним обычно хорошо, потому что нам потом кого-то из них скорее всего придётся на профтехобучение или на студенческую "рабочую практику" брать.
Я не знаю как вы там обучаете новичков и что у вас лично за опыт со всем этим делом. Но по мему опыту даже нормальный джуниор после ВУЗa/Техникума обычно после первыx 2-3 лет в лучшем случае более-менее понимает как работает та конкретная вещь, которую он делает.
А уж человек, пришедший в ИТ со стороны лет в 30-35-40, начинает хоть как-то понимать "картину в целом" вообще лет через 5-10. Если вообще когда-то начинает это делать. Обычно они концентрируются на своих конкретных задачах, а все "постороние" вещи либо заучиваются наизусть, либо вообще просто последовательность действий для каждого случая записывается на бумажке. Более того и новые вещи вроде языков и фреймворков такие люди учат гораздо медленнее и хуже.
И поэтому когда такой человек отработает где-то 3-5 лет и придёт на собеседование в новую фирму, то во первых глупо ожидать что он действительно понимает "как оно всё работает в целом". А во вторых если ему будет нужно учить новый язык/фреймворк, который сильно отличается от старого, то с большой вероятностью это будет не особо легко и обычно гораздо проще взять кого-то со знанием уже нужных тебе вещей. И если у вас и так полно кандидатов на рынке, то и найти такого будет не особо сложно.
Ислючения конечно тоже бывают, но они редки.
По разные стороны двери туалета время течет по разному. Здесь мгновения, там века.
Veidt 1 октября 2019 в 15:43
Давид и Голиаф — скорее. Но поживем увидим. Мы всего два месяца назад вышли и несколько десятков тысяч лицензионных пользователей у нас уже есть.
dlsf сегодня в 11:34
Давным давно мы разработали высокоуровневую платформу для разработки бизнес-приложений lsFusion
всегоили
давным давно
Один написал «Почему не SQL», второй — «начните с SQL».
А то неувязочка получается
Программи́рование — процесс создания компьютерных программ.
А Компью́терная програ́мма — комбинация компьютерных инструкций и данных, позволяющая аппаратному обеспечению вычислительной системы выполнять вычисления или функции управления.
Не более того.
Есть более менее универсальные ЯП, есть наоборот.
Соответственно на каких то определенные вещи проще выполнять, на каких то сложнее.
Но это всегда не задаром — либо высокие затраты на разработку, либо высокие требования к матчасти.
SQL — декларативный язык в принципе, 1С — предметно-ориентированный их сравнивать некорректно
Несколько месяцев назад мы завели блог, и решили поделиться ей с сообществом.
вышли
Это время когда вышла первая публичная версия, появился сайт, начали писать статьи, на форумах и т.п. До этого платформа использовалась только для проектов нескольких конкретных компаний. Разницу надеюсь не надо объяснять?
Соответственно если вы хотите построить pr-кампанию на качество, эффективнее всего это делать в противопоставлении «продукту по умолчанию».
Но это все касается естественно только русскоязычного рынка, англоязычный не настолько консолидирован, и там таких проблем / возможностей нет.
«Евангелисты» технологии, которой вы себя противопоставляете, все равно не откажутся от своей веры, а вот внимание «сомневающихся» и «не в теме» сравнением вполне можно привлечь. Это как бы азы маркетинга.
Ну и еще раз: возможности ничего не стоят без проблем, которые они решают.
Ну а проблемы как обычно:
Скорость, стоимость, качество разработки / доработки. А к ухудшению всех этих показателей приводят проблемы из недавней статьи.
Мы на местном рынке успешно противостоим 1С, не вижу причин по которым мы тоже самое не можем делать в России. Но время покажет. Больше, не меньше.
Отличаются, конечно
Даже стало интересно, а много вы знаете про то как работает IT-бизнес в Беларуси? Потому как мы в России выполнили несколько нестандартных, в том числе крупных проектов. Ну и за все время успели пообщаться с десятками представителей разных бизнесов: от конечных заказчиков и местных IT-компаний до системных интеграторов. Поэтому можем делать какие-то выводы. А вы так уверено утверждаете, что отличаются, даже интересно стало, а какой у вас все-таки опыт в ИТ-бизнесе Беларуси?
Сейчас у нас фокус на розницу и проекты с глубокой степенью кастомизации и/или высокими требованиями к эргономике / производительности. И именно по этим NFR требованиям (как впрочем и остальным) у lsFusion на наш скромный взгляд значительное преимущество перед остальными технологиями (понятно что это субьективно, но время покажет кто был прав).
Хорошо, если брать именно розницу — может, отличия и небольшие, тут спорить не буду, у меня знаний нет, только рассказы ваших товарищей.
По клиентам в рознице (вы ведь только про крупную розницу, насколько помню) — почему вы думаете, что в России значительное количество розничных сетей, недовольных своей автоматизацией?
«проекты с глубокой степенью кастомизации» — что вы под этим подразумеваете, приведите пример какой-нибудь.
О проектах в России что-то никаких сведений на вашем сайте не нашёл, хотелось бы подробностей.
Скоро будут, не волнуйтесь.
По клиентам в рознице (вы ведь только про крупную розницу, насколько помню) — почему вы думаете, что в России значительное количество розничных сетей, недовольных своей автоматизацией?
Потому как управление розничной сетью это творческий процесс, а значит вариантов этого процесса очень много и это огромное поле для реализации различных хотелок пользователя, то есть той самой глубокой кастомизации (собственно это очень часто основная причина смены софта, мы хотим так-то, а текущий подрядчик не хочет / не может это сделать или это слишком дорого). Плюс большие объемы, а значит требования к эргономике / производительности.
«проекты с глубокой степенью кастомизации» — что вы под этим подразумеваете, приведите пример какой-нибудь.
Например у нас один из клиентов был логист скоропорта, практически без складов, торгует по времени с колес будущим числом, с очень специфическими требованиями к перевозки, плюс по сути «дефицитным» товаром, так как а) логистическое плечо очень короткое, б) в скоропорте (условном мясе, молочке) очень частые замены и нехватка товара (опять таки по причине короткого логистического плеча). Соответственно все процессы очень нестандартны и требуют высокой эргономики (их нажмите 5 кнопок зайдите в 2 формы и 3 отчета не устраивают). Да это не масс-маркет, зато такие клиенты имеют достаточно уникальное положение на рынке, а значит более платежеспособны. И для них самое главное скорость, стоимость и качество разработки / доработки.
Ну или еще один пример — крупная известная компания (кстати в России), автоматизация всех процессов (не торговля / производство), купили дорогую платформу (и какие-то наработки на ней), сменили два известных подрядчика на слуху. Не взлетело, (причем именно из-за качества платформы, там точно не проблема в квалификации подрядчиков была). Пошли суды. Мы сделали все гораздо быстрее и дешевле, хотя и очень многое там было против нас.
Например, есть ряд людей, которые ездят исключительно на механической коробке передач, крайне негативно относясь к автоматической. Они считают, что автомат переключает передачи не эффективно, и вручную они могут лучше
Стоит правда отметить, что у водителя с автоматической коробкой передач есть возможность переключиться на ручной режим.
А чего же крайний негатив, если якобы есть возможность переключиться и не страдать?
И да, я бы предложил конкурс на лучшее название нового языка. Участники, разумеется, должны включать в основном сторонних разработчиков (в т.ч. потенциальных). Плюс обсуждение и прочая социальная активность. А то сегодняшнее название — это скорее название прототипа, а не чего-то массового. Попробуйте произнести быстро Java и LsFusion.
Может, просто Fusion? Поспрашивать англоязычных нэйтивов, нет ли какой неожиданной коннотации.
Application software
Autodesk Fusion 360, a 3D CAD, CAM and CAE program
Blackmagic Fusion, a visual effects package
BT Fusion, a defunct UK voice-over-IP service
ColdFusion, a rapid application-development platform
Lucidworks Fusion, a search engine platform
NetObjects Fusion, a web design program
Middleware and operating system components
Compiz Fusion, a community-maintained set of plugins for the Compiz Window Manager
IBRIX Fusion, a parallel file system
Oracle Fusion Middleware, a portfolio of standards-based software products that spans multiple services
VMware Fusion, a virtual machine software product
Я когда придумывал названия для своих нетленок, брал либо вообще новое слово, либо редкое словосочетание. И потом проверял Гуглом.
С названием, да, косяк. Мягко говоря не самое лучшее. Но уже было поздно менять, слишком много было на него завязано. Правда преимущество в том, что все домены, твиттеры, слэки и т.п. были свободными.
По названию. Это опять маркетинг, который вы опять мимо ушей и мозга пропускаете. Заменить все ссылки не так сложно, повесить ссылки на новый ресурс на странице старого — тоже элементарно. Всё легко и ненапряжно исправимо, но для этого нужно желание.
В целом у вас подход программиста, что понятно, но слона программисты продавать не умеют, а потому — либо отдайте маркетинг грамотным людям, либо забейте на программирование и начинайте изучать маркетинг сами. Второй вариант обычно заканчивается просто — не хочу. Поэтому нужен маркетолог. Ну а я здесь на паре примеров вам (надеюсь) показал, что без него у вас получается уг вместо конфетки.
В принципе, уг тоже можно впарить, оплачивая его использование и тому подобными методами, но как бы снова повторю — слона вы так не продадите.
Заменить все ссылки не так сложно
Не все так просто. Расширения файлов — lsf, package'и начинаются на lsfusion, и еще есть несколько мест, где используется имя lsfusion, в которых его достаточно тяжело изменить. То есть можно конечно оставить его как «рабочее название» внутри, а снаружи все переделать и это скорее всего правильно. Но мы сначала хотим получить фидбек. Понятно что людей, которые не будут обращать внимание на «обертку» и полезут внутрь очень малый процент, но в этом как раз и смысл. Можно оценить все потенциальные проблемы, акценты которые надо делать, а уже потом подключить тяжелую артиллерию. Это очень инертный рынок, как такового узкого окна возможностей, куда можно не успеть, тут нет — COBOL'у и SQL уже под 50 лет.
Забавно, но в шахматах используются похожие навыки, что и в программировании. Позиционная игра — это проектирование архитектуры. Тактическая игра — отладка программы.
Некорректно сравнивать шахматы с программированием, так как цель в шахматах — выиграть любой ценой, а в случае тактической игры — еще и выграть максимально быстро, жертвуя при этом ресурсами. В программировании выиграть нельзя, да и жертвовать ресурсами(программистами?) — дело явно проигрышное.
При этом, конечно же, умение просчитывать на много ходов вперед используется и в программировании, но оно много где в жизни используется, это базовый подход к анализу.
Важны законченные бизнес решения.
Простой пример. Вы приходите к потенциальному заказчику.
Он показывает вам связку из Розницы, Бухгалтерии и Зарплаты, которые уже установлены и худо-бедно решают текущие задачи бизнеса.
Заказчик достаточно дружелюбно к вам настроен и говорит, что согласен отказаться от части конфигураций или даже от всех конфигураций 1С.
Сколько времени вам потребуется, что бы заменить используемый у нас функционал этих конфигураций? Сколько будут стоить обновления при изменении законодательства? Как быстро вы реагируете на изменения законодательства?
Ну и главный вопрос, сколько дополнительных денег, я начну зарабатывать, что бы окупить переход на вашу систему, покажите пути экономии при установке вашей системы.
Если вы напишете статью с ответами на эти вопросы это гораздо больше приблизит вас к потенциальным заказчикам, чем объяснения, что в 1С нет ООП, SQL запросы на русском языке и почему это плохо.
Одинэсу жизненно важен конкурент в той нише, которую он занял, но вот только одинэс не конкурирует ни с кем в нише языков программирования. А для бизнес решений одного языка программирования, даже лучшего по всем статьям, явно недостаточно.
- В бухгалтерию и зуп в ближайшее время смысла лезть нет. Это даже сам 1с это понимает, вырезав эти модули из erp для международного рынка и рекомендовав использовать для этого местный софт. Более того даже в России сейчас erp чаще всего внедряется без бух и зуп.
- Соответственно если речь идёт об остальных модулях, там поддержка законодательства куда менее критична. Да были всякие ЕГАИС, но это единичные случаи и поддерживать такие изменения весьма не сложно.
- Для современного бизнеса сама по себе технология естественно не важна, но для него важно чтобы система могла меняться вместе с ним, то есть должна быть модульной и иметь возможность быстро, просто и качественно дорабатываться. И вот тут возможности платформы в плане модульности, декларативности, возможностей рефакторинга и т.п. выходят на первый план. И реализовав свои ноу хау именно в той постановке, в которой хочет бизнес, без лишних действий и с высокой производительностью, этот бизнес отбивает деньги потраченные на ит ну очень быстро.
Где же начинается программирование