Причина #2. Безопасность. Желание иметь только свой софт и ни от кого не зависеть. На самом деле независимость — это миф. К нам приходят компании, которые самостоятельно разработали систему и попали к ней в заложники. Почему так происходит? Когда ты разрабатываешь продукт в отрыве от рынка, то список задач, который нужно реализовать, формируется не под действием реальных необходимых факторов, а под действием внутренних сил. И побеждает тот, кто из корпоративных заказчиков, грубо говоря, применил бОльшую силу. Иногда делают все очень быстро и причем такие вещи, которые в итоге не используются. Много ресурсов расходуется впустую, на реальном рынке так не происходит. Часто бывает так, что люди, вместо того, чтобы задуматься над эффективностью, закрывают какие-то дыры кодом. В итоге появляется куча разного функционала и костылей. И такое решение только мешает. Система в безопасности, но, в то же время, она не позволяет развиваться.
Спасибо за статью и открытость к экспериментам. Он был очень интересен и показателен. Он мне помог добавить критериев к нашей целевой аудитории.
С выводами я бы не был так однозначен.
Заказная разработка имеет право быть и в решении задач, которые не являются основной частью продукта компании, который они выводят на рынок.
При всем уважении к платформам и готовым коробочным решениям есть пласт задач, не достигших критической массы в кол-ве клиентов/рынках/деньгах, чтобы для них были созданы коробочные решения. Они не стали рынком для продукта. И поэтому их можно решить только с помощью заказной разработки или собственной разработки.
И вот тут один из выводов для меня - если вы не готовы вкладывать силы своей разработки в поддержку и развитие системы, которая будет создана внешними аутсорсерами, то подумайте еще раз. Нужно оно вам?
Согласен, что есть еще какие-то нишевые вещи, которые не покрыты коробками и конечно, бывают уникальные варианты, например, когда компания создает такую нагрузку, которую не тянут коробки. Во втором случае, когда нужен hi-load, я бы 30 раз подумал, нужно ли заводить у себя такую уникальную компетенцию, или, лучше обратиться к специалистам, например к вам, как вариант ))
Глобализация как она есть. Вы сделали чисто менеджерские выводы по поверхностному осмотру, тк у всех коробочных решений есть недостаток - отсутствие того что надо именно тебе, причем выясняется оно уже на последнем этапе(закон Мерфи:/). Если коротко, то да, коробка для базовых ф-й норм, но как только ты выходишь за рамки, и ты не Apple, дружно пишешь костыли с помощью своих 2х админов на полставки, п если коробка проприетарка, то расширения заказываешь у производителя, что как бы дороже, чем нормально решение. Классический примеры - 1С, SAP. Хотите в другой формат отчётик - пишите расширение, ой а вы абап не знаете? Ну все, с вас 100500 тыщ. Лучшее решение для тех, кто не хочет тянуть свою команду - заказ системы на основе фреймворков, которые и дают быструю разработку(или уже содержат готовое) базовых фй, и не ограничивают владельца в расширении платформы под индивидуальные нужды. И все это великолепие можно взять как аутсорс, так и по необходимости нанять человеков на постоянку для разработки/поддержки. Конечно, для такого придется чуть чуть включить мозг, возможно, прочитать собственные потребности от системы, а так же потратить пару бутылок дедовской настойки на разговор со знакомым, который разбирается в теме
Согласен, что истина где-то в балансе и платформы с готовым функционалом, понятным фреймворком для hard-code, а так же инструментами no-code и law-code дают преимущества. Но! Я так призываю внимательно разобраться с собственной уникальностью. И здесь у меня есть богатая проектная практика, часто уникальность - это исторически не оптимально сложившиеся процессы. Референсные модели заложенные в тот же SAP или 1С и методология внедрения и использования, все это появилось не просто так, а как выжимка лучших практик. И в итоге эффективнее перестроить свои процессы, чем прогибать этот мир под нас ))