Это вторая статья из серии статей про подводные камни заказной разработки ПО. Первая — здесь.

В какой-то момент осмысливая работу с клиентами и задачу удешевления разработки клиентского решения я пришёл к тому, что в нашей индустрии существует шкала видов клиентских решений, которая практически плавно простирается от коробочного решения до полной и бескомпромиссной заказной разработки.

По пути мы проходим несколько общеизвестных остановок

1. Коробка в буквальном смысле.
Клиент не имеет вообще никакого права выбора. Бери и пользуйся как есть, или не бери. Антивирус и Яндекс.Диск — очевидные примеры. Если решение тебе не совсем подходит — измени себя или выбери другое решение. Минус — поставщику плевать на то, что хочешь лично ты. Если вас таких много, если вендор вас заметит и если это как-то может повлиять на продажи, возможно, со временем, фича и появится. Плюс — это экстремально дёшево, вплоть до полной бесплатности.

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

3. Интегрируемые решения.
То же, но есть документиованный API.

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

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

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

7. Заказное решение на базе крупной библиотеки, которая закрывает ключевую задачу. Например, мы делаем систему видеонаблюдения, но работа с видеопотоками берётся из известной библиотеки кода.

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

Посмотрите на это как на шкалу.

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

Кроме основного сценария, в рамках которого мы реализуем так или иначе проект и запускаем его в работу есть ещё пост-сценарии. В том числе, хорошо бы ответить на вопросы:

– Кастомизируемость проекта уже после запуска. Силами заказчика? Силами подрядчика?

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

– Способность к росту нагрузочной способности. Насколько нагрузка возрастёт за 5 лет? 8 лет? Теоретически если время амортизации системы — 8 лет, то на столько и надо рассчитывать. Но в реальности — мало амортизировать старую систему, нужно ещё и сделать новую. И случаи, когда новую делают пять лет я тоже знаю. Так что план по нагрузке на 10 лет не будет лишним.

Кроме того, у проекта, естественно, кроме стартовой цены есть и ещё парочка свойств, которые тоже транслируются в деньги, а, порой, даже дороже денег.

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

Второе — это надёжность поставщика и шансы на срыв проекта. Или — хуже того, проект на базе коробочного решения будет внедрён, но через какое-то время выяснится, что он настолько кардинально не масштабируется, что надо всё выкинуть и начинать с нуля.

Лирическое отступление. Одна огромная компания в своих невероятно больших задачах по внутренней разработке программных систем использовала для управления широко известный во всём мире баг трекер. И всё с ним было хорошо, даже отлично. Коробочный продукт, разработан именно для того, для чего и использовался, с отличными возможностями по кастомизации и интеграции — просто праздник какой-то (С) Карабас Барабас. И вот — количество разработчиков в компании утроилось. Продукт под нагрузкой скрипнул, но выстоял. Упятерилось. Продукт застонал, но суровые сисадмины подложили лист в рессоры, брызнули из баллончика в карбюратор, ускорили БД, добавили памяти, поправили индексы и сказали «работай, собака, солнце ещё высоко». Но призадумались. А сыр во рту держали. Нагрузка тем временем удесятерилась, и стало ясно, что сколько палкой ни подпирай — упадёт.

Куда крестьянину податься — пошли к вендору на поклон. Сколько, говорят, вам заплатить, чтобы вы продукт для нас ускорили? Мочи нет, как тормозит. Давайте таблеточек для кластеризации продукту скормим, или какие-то примочки из кафки с толчёными микросервисами, а? Вы только цену назовите. Миллион убитых енотов достаточно? Или добавить?

Посмотрел на них вендор грустно, и протянул руку, прямо как дедушка Ленин. Идите, говорит, вы, товарищи, в баню. Таких как вы в мире десять-двадцать. Ну — сто. А у нас клиентов — хоть и мелких, да миллионы. Вы нам как покупатель не интересны, и ничего мы для вас делать не будем. Это муторно, сложно и миллионам не надо.

В общем, нажил вендор себе врага и конкурента, но это уже совсем другая история.

И жили они долго и счастливо. Конец отступления.

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

Мы как разработчик заказного ПО почти не предлагаем клиентам коробку, но если видим в ТЗ заказчика слова про микросервисы, шину и нагрузочную способность, которой хватит на любую европейскую страну целиком обычно предлагаем клиенту рассмотреть вариант поскромнее — сначала реализовать систему на базе lowcode платформы, что куда дешевле и позволяет легко модифицировать уже запущенную в работу систему, а уж потом, если просматривается ограничение по нагрузке, развивать её через кастомную доработку высоконагруженных компонент, причём тоже в чисто эволюционном режиме. Благо в любой системе, как правило, максимум 20% сущностей и алгоритмов задействованы в реально тяжёлых и часто используемых сценариях.

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

Есть и ещё критерии, которые могут повлиять на выбор. Сертификация и лицензии, облачное или локальное размещение, технологические ограничения заказчика. Мало того, они могут рассматриваться как ограничения на весь продукт или на его часть (скажем, выделить часть системы, которая работает с персональными данными — несложно).

Например — может существовать внутренний запрет на размещение в облаке, или же, напротив, облако соответствует требованиям 152-ФЗ, и это снижает затраты на сертификацию, поэтому является предпочтительным вариантом.

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

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

И, наконец, существует ещё один критерий, совсем не технического свойства. А именно — попадут ли расходы на новую систему в CAPEX или OPEX. Косвенно, но часто возникает и вопрос о правах на результирующую систему. Иногда покупателя пугает платформенное решение, потому что возникает опасение, что не все права на результат будут принадлежать покупателю. На деле это вполне обходимая проблема — если, конечно, поставщик договороспособен. Существует и ещё несколько инструментов формирования именно такой договорной и правовой модели, которая требуется покупателю, не буду пытаться перечислить тут все возможные сочетания. Скажу только, что неразрешимых проблем мы ещё не встречали.

Подводя итог: когда вы выбираете способ решения задачи по той шкале, которая описана в начале статьи, не забывайте продумать будущее проекта. Иногда это заставит вас принять более дорогое, но надёжное решение, иногда, напротив, позволит начать с более дешёвого. Дорогу осиливает идущий.