Стоит ли это строить? Вопрос, который мы задаём, прежде чем писать код

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

Стоит ли нам это вообще строить?

В Libertas Software Research (LSR) мы считаем, что знать, стоит ли разрабатывать программное обеспечение, так же важно, как знать, как. Иногда индивидуальное приложение, именно то, что нужно. Иногда проверенная SaaS-платформа полностью закрывает потребность, а иногда соединение уже имеющихся систем даёт результат без затрат и сбоев, связанных с их заменой. Цель, улучшить работу организации, а не добавить ещё одно приложение в и без того сложную среду.

Начинайте с проблемы, а не с решения

Организации склонны описывать решение, которое, по их мнению, им нужно, а не проблему, которая у них есть. «Панель отчётов» или «приложение вместо наших таблиц» звучит чётко, но мало говорит о том, что вызвало запрос.

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

Когда покупка разумнее

Коммерческий рынок зрелый. Для CRM, бухгалтерии, планирования, управления документами и бизнес-аналитики есть продукты с годами доработки. Если один из них отвечает вашим потребностям без неразумных ограничений, индивидуальная замена добавляет мало ценности.

Но сравнивайте совокупную стоимость владения, а не цену подписки. Продукт за 500 £ в месяц, это 30 000 £ за пять лет, ещё до настройки, интеграций, дополнительных лицензий и изменений в ваших собственных процессах. Проверьте, как растёт цена, можно ли экспортировать данные и что будет, если поставщик изменит модель. И остерегайтесь принуждать бизнес отказываться от того, что его действительно отличает, только потому, что продукт предполагает иное.

Иногда ответ: связать то, что уже есть

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

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

Когда индивидуальная разработка: правильная инвестиция

Некоторые требования действительно не вписываются в массовые продукты: специализированные операции, необычные требования к безопасности или данным, либо программное обеспечение, которое само по себе является конкурентным преимуществом. Здесь индивидуальное ПО позволяет архитектуре следовать тому, как бизнес работает на самом деле.

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

Не каждая проблема требует больше программ

Иногда проблема в самом процессе. Согласования, отчёты и административные шаги накапливаются годами, давно после того, как исчезли обстоятельства, их породившие. Автоматизировать их такими, какие они есть, значит лишь сохранить сложность.

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

Смотрите дальше первоначальной стоимости

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

Учтите и стоимость бездействия. Неэффективный процесс, съедающий 20 рабочих часов в неделю,, это около 1 040 часов в год. При иллюстративной ставке 35 £ в час это примерно 36 400 £ в год при условии, что это время действительно можно вернуть и направить на другое. Добавьте низкое качество данных и медленные решения, которые труднее оценить, но которые не менее реальны. Лучший вариант, не самый дешёвый, а тот, где сильнее всего сочетаются ценность, приемлемый риск и долгосрочная устойчивость.

Зачем компании-разработчику рекомендовать не разрабатывать ПО?

Это справедливый вопрос. Если мы рекомендуем продукт или небольшую интеграцию, на бумаге это меньше работы по разработке.

Но одно дело, предоставлять мощности для разработки, и совсем другое, быть партнёром по исследованиям и архитектуре ПО. Наша работа начинается до того, как появляется спецификация: понять проблему, оценить варианты и помочь вам решить, куда инвестировать. Это имеет ценность независимо от результата, и обычно остаётся работа по анализу, архитектуре, планированию и интеграции, даже когда индивидуальная разработка не является ответом.

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

Возможность строить: не причина строить

ИИ и современные инструменты делают код быстрее и дешевле в производстве. Это полезно, но делает предварительные размышления более важными, а не менее, потому что усилие, которое раньше заставляло спрашивать «а действительно ли нам это нужно?», исчезает. Вполне возможно построить нечто технически превосходное, эффективно сдать и обнаружить, что это был неверный ответ.

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

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

Прежде чем спрашивать, как нам что-то строить, стоит выяснить, нужно ли нам это строить вообще.

Libertas Software Research помогает организациям исследовать, оценивать, проектировать и разрабатывать программные решения, делая упор на долгосрочную поддерживаемость, операционную ценность и обоснованные технологические инвестиции.