Есть ли у локального программирования перспективы?
Во многом это объясняется тем, что оно возникло ещё во времена, когда существовал только досовский FoxPro, а всё программирование было не только локальным, но и экстремальным. Это означает, что большую часть времени программист проводил на рабочих местах пользователей, где и вносили все необходимые изменения в программные коды. Вплоть до того, что если было необходимо начислить зарплату сотруднику, который работал по сменам, при этом пользовался льготами, но платил алименты, был премирован, а потом оштрафован, то для него создавалась отдельная процедура. Часто её суть сводилась к возможности начислить зарплату или совершить какие-то другие действия именно в текущем периоде. При наступлении следующего всё просто перепрограммировалось заново. Например, все изменила разработка корпоративных мобильных приложений.
Когда программист был универсальным героем…
Таким образом, бизнес получал программы целиком и полностью завязанные на одного программиста. В крайнем случае — двух или трёх. Если они увольнялись, то новые даже не смотрели на их программы, а тут же внедряли свои. В целом на каждом предприятии можно было встретить базы данных и программы, которые вообще не отражались ни в какой документации. Характерно, что каждый новый программист делал огромные глаза и страшно ругал своих предшественников, разработчиков мобильных приложений.
Говорить о какой-то систематизации продуктов такого программирования – вести речь философскую, об упорядочивании хаоса. Когда старые программисты, начавшие свою карьеру в 90-ых, сетовали на то, что остался невостребованным их опыт экстремального программирования, то получали довольно справедливый ответ: «Он никому не нужен. Сейчас так никто не работает».
Итак, времена локального программирования ушли в прошлое. В компаниях массово простились с тем легендарным «компьютерщиком» в растянутом свитере, который и программы писал, и сервера поддерживал, и отчёты готовил, и даже набирал какие-то документы вместо начальства.
Место разработчиков в профильных компаниях
В наши дни компактные IT-отделы заводов и фабрик не содержат в своих штатах более 2-ух специалистов. Часто они не в состоянии написать и строчку программного кода, а занимаются только администрированием. А то и этим не занимаются, а просто следят за порядком в IT-хозяйстве. Вовсе не потому, что не хватает образования. Просто у современных сотрудников отделов IT другой профиль. Программы теперь покупают, потом нанимают специалистов по внедрению, которые и передают всё готовеньким. И даже разработка Android приложений становится уделом представителей третьих компаний.
С одной стороны мы получили систему, чёткость, ясность, прогнозируемость. Если уж приобретён комплекс «1С:Предприятие» с какой-то прикладной конфигурацией, то все задачи учтены. С другой – о временах, когда все программы создавались под нужны конкретного бизнеса, с учетом его индивидуальных особенностей, приходится забыть. Вместе с тем забыть и такие явления, как эскизные проекты. Практически невозможно провести совещание с участием IT-специалистов из штата той же компании и уже через несколько дней получить отдельные модули внедрённых бизнес-систем, направленные на решение каких-то вдруг возникших проблем. Потеряна скорость и дешевизна разработок. Если что-то не находит отражения в используемой конфигурации, то от момента возникновения идеи до её практической реализации могут пройти месяцы. И стоить изменения будут намного больше.
Нюансы локальной поддержки
Но дело не только в этом. Времена, когда разработка и поддержка бизнес-приложений было уделом штатных программистов компании связаны с одним неоспоримым преимуществом. В тот период IT-шникам не нужно было объяснять о том, что представителям бизнеса свойственно не знать, что они хотят. В конечном итоге понимание этого феномена и является одним из основных отличий опытного разработчика или системного аналитика. Это понимание в корне меняет взгляд на важность или неважность технического задания и любой документации. В этом незнании могут заключаться глубокие философские корни, но нам это мало что даст. На практике это незнание выражается в том, что представитель бизнеса никогда не сможет поставить задачу, выявить все проблемы, которые должен решать программный комплекс. Даже если речь идёт всего лишь об автоматизации его ежедневных процессов. Именно поэтому, говоря о соответствии используемой конфигурации и реальных потребностях бизнеса, необходимо помнить об эскизных проектах. До тех пор, пока что-то не запущено в эксплуатацию мы не сможем понять, какие видимые и скрытые проблемы при этом возникнут. Повсеместный переход на глобальные «коробочные» системы позволяет говорить о двух моделях выявления необходимой конфигурации. Это использование гибкости и масштабируемости при окончательной настройке, которую даёт «1С:Предприятие», и старый, уже забытый способ создания проектов сразу после совещания. Вполне возможно, что дальнейшее развитие создание Android приложений, систем автоматизации торговых и производственных предприятий будет связано с возникновением какого-то компромиссного варианта. Как бы не были хороши типовые конфигурации «1С» рано или поздно возникает потребность в локальном программировании. Не исключено, что его развитие станет новым трендом «1С» и вообще всех ERP-систем.
