Оценка рисков заказной разработки

Цель данной статьи – оценить риски заказной разработки в сравнении с готовыми программными продуктами. Риски можно распределить по группам, приведенным в настоящей статье.
Оценка рисков заказной разработки
Необходимо не только расширять функциональность решения новыми модулями и приложениями, это порой и не требуется, а важно использовать возможности программной платформы, на которой создана система. При этом думается, что будущее за решениями, построенными на технологиях с открытым кодом и использующими веб-ориентированную архитектуру с возможностью доступа к данным удаленно из любой точки без применения дополнительного ПО.
В процессе создания новой системы до 80% функциональности разрабатывается «с нуля», а остальное составляют существующие наработки и инструменты. С другой стороны, при использовании готовых продуктов доля заказного кода в общем объеме составляет 10-20%. Будем называть первый класс систем «заказными разработками», а второй «готовыми» или «конфигурируемыми» решениями.

СТОИМОСТЬ РЕАЛИЗАЦИИ


Одно из основных проблемных мест заказной разработки это слабо контролируемый бюджет. Часто возникает ситуация, когда необходимо расширение функциональности разрабатываемого решения в ходе реализации проекта. Это может быть связано с неверной оценкой объема требуемых возможностей, а также неполным представлением решаемых задач со стороны заказчика, у которого часто возникает желание изменить что-либо «на ходу». При этом бюджет возрастает пропорционально объему вносимых изменений. В случае с готовыми решениями этот риск существенно ниже, поскольку основную базу составляет ранее разработанный код и реализованные инструменты для расширения функциональности.


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


СРОКИ


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


СТОИМОСТЬ ВЛАДЕНИЯ И СОПРОВОЖДЕНИЯ


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


РАЗВИТИЕ


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


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


ИТОГО


В настоящее время на рынке представлены качественные готовые решения с возможность конфигурирования и подключения заказной разработки практически для всех отраслей деятельности. Когда вы окажетесь в ситуации, требующей автоматизации деятельности вашей компании и внедрения программного продукта для ее поддержки, задайте себе вопрос: «Нужно ли нам идти на такие риски, создавая заказную разработку?».

© Нетив, 2010
© Издание 12NEWS (ИП Маринин А.Л.), 2010


Комментарии на публикацию Оценка рисков заказной разработки

Цель данной статьи – оценить риски заказной разработки в сравнении с готовыми программными продуктами. Риски можно распределить по группам, приведенным в настоящей статье.
Гость
Тема/заголовок:
Комментарий: