Менеджер-программист — тренд или уловка маркетологов?

Каждая организация в современном цифровом мире должна сделать выбор: купить ли готовое коммерческое программное обеспечение (COTS) или разработать программное обеспечение, которое полностью будет соответствовать ее потребностям. Более 20 лет все говорило в пользу покупки. Исторически сложилось так, что готовое ПО имеет ряд преимуществ: более быстрый срок внедрения, более низкие затраты на разработку, низкие риски и немедленное развертывание.

Создание программного обеспечения под определенные цели или на заказ давало организациям гибкость, но также считалось рискованным подходом, так как было связано с большими затратами (такими как расходы на эксплуатацию и обслуживание, найм разработчиков и другие накладные расходы), проблемами при реализации и длительным сроком внедрения.

Исследование, проведенное Standish Group, показало, что 31% проектов разработки был отменен до завершения. Исследование также показало, что 53% проектов превысили первоначальную смету на 189%. 24% респондентов заявили, что основной причиной неудачных проектов оказались неполные или изменяющиеся требования и спецификации, а 12% респондентов указали на недостаток участия пользователей. Подумайте об этом. В 1994 году более 36% респондентов отметили недостаток сотрудничества и обратной связи в режиме реального времени как причину неудач.

Последующее исследование IAG Consulting в 2009 году показало, что 68% ИТ-проектов были с самого начала обречены на неудачу из-за неадекватных требований. 50% неудачных проектов вышли из-под контроля как минимум по двум из следующих причин:

• фактическое время выполнения проекта почти вдвое превысило спрогнозированное;
• затраты превысили нормы по бюджету более чем в 1,6 раза;
• было обеспечено менее 70% ожидаемого функционала.

Организации не только терпели неудачи в разработке, но и теряли конкурентные преимущества из-за выбранной базовой системы. Это была эпоха покупки. В последнее десятилетие на рынке программ­ного обеспечения наблюдается трансформация. Привычные компании исчезли. Теперь все используют одинаковую систему управления отношениями с клиен­тами (CRM), средство планирования ресурсов предприятия (ERP) и другие основные системы, такие как SAP, Teamcenter® и Salesforce.

Организации больше не могут получить долгосрочное конкурентное преиму­щество благодаря выбранной базовой системе. Это в корне отличается от ситуации пятилетней давности и заставляет компании менять свой подход при выборе между разра­боткой и покупкой.

Возможно, компании надеются, что готовое ПО с парой подключаемых модулей после недол­гого программирования отлично дополнит их базовые системы. Но реальность такова, что готовое программное обеспечение тре­бует масштабной индивидуальной настройки, обходных решений и особого подхода для достижения функциональной интеграции с ИТ-инфраструктурой организации. Внедрение готового решения всегда заканчивается тем, что для полной функциональности нужно пытаться совместить несовместимое.

Допустим, вы покупаете систему управления жизненным циклом изделия (PLM) для улучше­ния управления ИТ-услугами, но понимаете, что она содержит ряд базовых рабочих про­цессов, которые не соответствуют вашим потребностям. Вы думаете, что сейчас без проблем интегрируете комплексное решение, но когда дело доходит до практики, обнару­живаете, что вам не хватает программного обеспечения для взаимодействия между вашими базовыми системами. Новую PLM-систему можно интегрировать с SAP, чтобы продолжить управлять существующим процес­сом, а это требует дополнительной настройки. Однако проблема заключается в том, что приобретенное решение не предназначено для сложных задач разработки.

Как правило, приобретенные решения позволяют вам осуществить задуманное на 60%, но оставшиеся 40% можно достичь только с помощью дополни­тельной разработки. Так как большинство организаций недооценивает необходимый объем разработки, работа обычно выполня­ется в спешке и не отличается высоким качеством. Так было и в 1994 году, и в 2009-м, и происходит до сих пор. Организации покупают решение и сталкиваются с необходимостью незапланиро­ванной разработки, тем самым сводя на нет экономию затрат, времени и ресурсов, кото­рую должно было обеспечить готовое решение.

Компании, инвестирующие в облачные технологии, гибкие методы разработки и DevOps, переходят на low-code разработку, так как объединение всех этих технологий и методологий сделало разработку выгодным вариантом.

Аналогичным образом с развитием облачных вычислений, концепций «платформа как услуга» (PaaS) и «программное обеспечение как услуга» (SaaS) предприятия могут получить конкурентное преимущество, объединяя эти технологии для оптимизации процессов и одновременно избегая всех проблем, которые когда-то были связаны с созданием собственного программного обеспечения.

1. Базовые системы открыты и имеют развитые интерфейсы, так что вы можете создавать программное обеспечение, которое работает с ними, и разрабатывать решения под определенные цели.
2. Средства экономичной и быстрой разработки стали намного эффективнее за последние несколько лет. Технические возможности действительно изменились, поэтому старые предрассудки в отношении разработки больше не актуальны.

К примеру, методология LowCode платформы Mendix включает в себя ключевую идею — объединение команды профессиональных разработчиков с разработчиками-любителями (теми, у кого нет опыта разработки/программирования). С точки зрения подхода и эффективности разработки тут есть очевидные плюсы: непрофессиональные разработчики (гражданские разработчики) обладают специфичной информацией, которая важна для заказчика, или если это разработка для внутренних нужд, то они знают, как лучше сделать, чтобы было удобнее и эффективнее, а профессионал знает, как это можно сделать сточки зрения технологий на Backend. Построение такой коллаборации возможно на единой платформе с инструментарием разработки в соответствии с компетенцией специалистов, ее использующих.

С точки зрения компаний, которые исповедуют такой подход, это снижение количества профессиональных программистов на проект, которые в свою очередь очень дорого стоят на рынке, и добавление других специалистов, которые могут обойтись дешевле. При всем этом скорость разработки увеличивается до 10 раз и, что также немаловажно, повышается качество результата.

Развитие этих инструментов и технологий также облегчило работу разработчиков. Согласно исследованию IAG Consulting от 2009 года, 70% компаний заявили, что у разработ­чиков не было достаточного уровня компетентности, необходимого для завершения проектов. Нехватка навыков напрямую увеличивала время выполнения проекта, затраты и риски неудачи.

В наши дни компании сталкиваются с теми же проблемами. Рыночный спрос на услуги по разработке мобильных приложений растет минимум в пять раз быстрее, чем способность ИТ-организаций предоставлять их. Тенденция усугубляется отсутствием достаточного количе­ства профессиональных разработчиков. Предприятия не могут своевременно найти их, даже если готовы вкладывать больше средств в ИТ. По данным IT World, компании часто тратят от восьми до двенадцати недель (или больше) на поиск людей в команду разработчиков на проект.

Заоблачная зарплата не решит проблему нехватки профессио­нальных разработчиков. Решение проблемы заключается в том, чтобы дать возможность разработчикам-любителям вашей организации внести свой вклад в разработку, используя новые, более доступные, инструменты. Разработка больше не является прерогативой профессионалов.