{"id":13845,"url":"\/distributions\/13845\/click?bit=1&hash=54601a6ed47cd6f2ea994f54c639affb7b60c3a1bcc160f3f669d0dd5dd46701","title":"\u041f\u043e\u0434\u043a\u0430\u0441\u0442 \u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u2014 \u0431\u0435\u0437 \u0444\u043e\u043a\u0443\u0441\u0430 \u043d\u0430 \u0431\u0440\u0435\u043d\u0434\u0435, \u043d\u043e \u0441 \u044d\u043a\u0441\u043f\u0435\u0440\u0438\u043c\u0435\u043d\u0442\u0430\u043c\u0438","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"5e2e3429-1282-582a-a245-b0558a631fd2","isPaidAndBannersEnabled":false}

SaaS-решения VS своя разработка

Основной причиной, по которой некоторые компании принимают решение о самостоятельной разработке программного обеспечения, является мнимая дешевизна данного подхода. Почему мнимая? Потому что на деле всё не совсем так, как кажется. Мы в Kodix Auto разрабатываем SaaS-решения для автобизнеса более 10 лет и за эти годы сталкивались с недоверием к такому типу продуктов и с возражениями.

Давайте рассмотрим основные из них и взвесим все "за" и “против".

Возражение 1: Мы сами будем разрабатывать цифровой продукт для компании

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

Сценарий А: Мы сами будем разрабатывать цифровой продукт для компании, но у нас еще нет команды

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

Первый из них — собрать команду, особенно когда ранее подбором технических специалистов ваш HR не занимался. Маленькая подсказка: начинайте с поиска человека, который возглавит проект — тимлида. В процессе поиска придёт осознание, что рынок IT достаточно высококонкурентный. Следовательно, зарплата востребованного специалиста выше средней. А потому даже небольшой отдел разработки в штате будет обходится гораздо дороже использования SaaS-продукта. При этом, чтобы создать собственную платформу, необходимо как минимум по 2 разработчика из каждого основного направления (Frontend, Backend, Дизайн), а также аналитики и проектные менеджеры. В случае недостатка единиц в команде вы можете столкнуться с так называемым «фактором автобуса» — когда кто-то из сотрудников берет отпуск, больничный или увольняется, в результате чего проект останавливается. Немаловажно, что команда должна быть в правильной среде. Редкому тимлиду будет интересно у вас работать, если а) нет открытой культуры IT-компании, б) ему не у кого учиться внутри. Такие команды часто разваливаются, ротируются, а каждый новый состав будет неизменно переделывать большую часть старого кода, что еще больше увеличит расходы на конечный продукт.

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

Сценарий Б: Мы сами будем разрабатывать цифровой продукт для компании и у нас уже есть собственная команда разработки

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

***

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

Возражение 2: Если содержать свою команду разработчиков дорого, то лучшим вариантом будет обратиться к услугам компании, которая сделает продукт под наши требования

Данный вариант подойдет тем, кто очень хорошо знает IT-составляющую своего бизнеса и понимает, что конкретно ему необходимо для развития и продвижения решения. На выходе вы с большей вероятностью получите то, что опишите в ТЗ. Но для начала вам придется заплатить большую сумму за первичную разработку необходимой системы, потратить время на составление того же технического задания, его согласование и постоянный контроль за происходящим. В случае, если вы собираетесь использовать готовое SaaS-решение, вам всего лишь требуется подобрать то самое, которое по большей части вас устроит. При этом запуск обычно не превышает нескольких дней, а абонентская плата сравнительно невысока.

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

И все же я не уверен, что хочу использовать SaaS-решение.

В таком случае, вот еще несколько "за" и “против", которые могут повлиять на ваш выбор:

- SaaS-решение уже готово к использованию. Вам нужно лишь выбрать подходящее.

- Время установки SaaS-решения от 1 до 14 дней в зависимости от сложности, тогда как собственная разработка может длиться от 3 месяцев до бесконечности. Так, например, в каждый из наших продуктов инвестировано не менее 2-х лет кропотливой работы.

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

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

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

Подытожим:

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

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

0
Комментарии
Читать все 0 комментариев
null