|
Современные тенденции в области технологий разработки ПО […] все больше избавляют программистов от программирования, а пользователей – от необходимости заботиться об установке и конфигурировании программных систем. Это очень хорошо, что прикладные разработчики могут сосредоточиться на «сборке» требуемого функционала из готовых компонентов вместо того, чтобы «с нуля» писать код программы, а программисты компонентов каждого уровня иерархии, в свою очередь, могут сосредоточиться на их гибкости, производительности и т.п., а не на рутинном потоке требований «глупых пользователей». Однако число людей, вынужденных тесно взаимодействовать друг с другом в процессе разработки даже одного верхнего (прикладного) уровня ПО, становится очень большим, и на коммуникацию между ними тратится чрезмерно много времени и денег. Впрочем, проблема затрат на коммуникацию (документацию) отчасти решается современными (в т.ч. «гибкими») методологиями разработки ПО. Но вот затраты на «вспомогательных» IT-специалистов (по деплойменту, конфигурационному управлению, автоматизации процессов и т.п.) уменьшить невозможно – это плата за те стандартные преимущества, которые поставщики современных программных систем предлагают заказчикам (безопасность, отказоустойчивость, масштабируемость, автоматическое обновление версий и др.). Что касается разработки вспомогательных компонентов и технологий (а не программ для пользователей), то наличие нескольких уровней таких компонентов зачастую не увеличивает стоимость конечной системы напрямую (в частности, благодаря проработанной методологии разработки ПО с открытым кодом). Однако огромное разнообразие компонентов, помноженное на возможность выбора разнообразных архитектур, требует затрат на постоянное обучение прикладных специалистов (сложнее подобрать специалиста нужного профиля, они становятся дороже, и большую часть времени занимаются изучением технологий/компонентов). Работа программистов превращается из творчества в поиск нужных функций компонентов и в преодоление их несовместимостей. Причем это касается не только краткосрочных проектов (которые обычно выполняются аутсорсерами), но и долгоживущих проектов (развиваемых в продуктовых компаниях), поскольку «продуктовые» проекты тоже вынуждены трансформироваться под новые технологии (ибо технологии, а тем более реализующие их конкретные компоненты, меняются очень быстро; и со временем специалистов по старым технологиям находить все сложнее, а функционирование продукта на старой платформе становится не только неудобным, но и невыгодным для заказчика). Программные системы разрастаются и «вглубь», и «вширь» (с одной стороны – становятся многоуровневыми/многослойными, с другой стороны – интегрируются друг с другом и становится многомодульными). В связи с этим возникает особая потребность в стандартизации компонентов, из которых собираются системы, и в стандартизации протоколов взаимодействия между ними. Однако стандартизация всегда имеет обратную сторону – понижение гибкости (кроме того, негативное влияние она может также оказать и на другие характеристики систем и процессов – уменьшение производительности, расходы на написание и изучение большого количества документации). Многие компании-разработчики, особенно крупные, также пытаются скрыть сложность программных систем за счет предложения «готовых решений». Конечно, это сильно сокращает сроки выполнения заказов (решение нужно не разработать, а «лишь» адаптировать под потребности конечного заказчика). Однако и стоимость готовых решений может быть еще выше, поскольку необходим больший штат людей, специализирующихся на внедрении «решений», а также на обучении (обучение готовым системам тоже требуется в большем объеме, так как они создавались по требованиям не конкретных, а «усредненных» пользователей).
|
