В чем разница между кастомной и продуктовой разработкой и какая нужна вам?

В новой статье Григорий Столяренко рассказывает о разнице между кастомной и продуктовой разработки для ресторана, выделяя плюсы и минусы каждого подхода, делится опытом компании ARBUS (казалось бы, при чем тут “Катапульта”?) и резюмирует: кастомная разработка подходит далеко не для всех. Проверьте себя. Для все любителей великого и могучего, но английского, сразу после русской версии есть и версия на языке Шекспира и Трампа

В самом начале давайте разберемся с понятиями: что такое кастомная и продуктовая разработка, и чем они отличаются друг от друга. Кастомная или индивидуальная разработка – это уникальное решение, которое создается под задачи определенного заказчика. Продуктовая разработка или коробочное решение – это некий стандартный продукт, который предназначен для большого круга пользователей.

У каждого из этих решений есть свои плюсы и минусы. Мы хотим рассказать о своем опыте использования каждого из этих подходов.

Так получилось, что начинали мы именно с коробочной разработки. Именно первому нашему решению, iikoWaiter, суждено было стать флагманским продуктом, и самым продаваемым партнерским продуктом в семействе iiko. Толчком к написанию собственного продукта послужила конкуренция – на тот момент у нашего основного конкурента, r_keeper, уже имелся недорогой “мобильный официант”, который работал под управлением iOS, а у iiko были только варианты дорогостоящих девайсов с достаточно примитивным ПО на борту. И когда мы проиграли одну, затем вторую сделку, а вендор не торопился с реализацией, уверяя нас, что рынку это не нужно, мы приняли решение написать “мобильного официанта” самостоятельно.

Первая реализация была выполнена на аутсорсинге (мы были постановщиками задачи, а программированием занималась сторонняя организация), и делали мы ее как внутренний продукт компании ARBUS. Когда продукт был создан, появились первые клиенты и отзывы, мы решили, что нужно делать нативное приложение и не только под iOS, как было изначально, но и под Android. Так мы создали собственную команду разработки, которую возглавил человек-легенда и любитель С#  по утрам, Сергей Мясников. А еще приняли историческое решение, что теперь делаем продукты для всего рынка, а не только как наше внутреннее решение. Через какое-то время, мы сформулировали наши принципы разработки:

• Открытость (наши продукты могут продавать любые компании-интеграторы)
• Качество (мы хотим гордиться нашими решениями)
• Полезность (мы хотим приносить пользу нашим клиентам, повышая эффективность ресторанного рынка)
• Неконкурентность (мы не конкурируем с нашими партнерами по создаваемым нами продуктам)

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

Мы даже выделили нашу продуктовую разработку в отдельную компанию, “Катапульта”, чтобы не путать наши бизнесы: интеграционный, которым занимается ARBUS, и вендорский (разработка), которым стала заниматься компания “Катапульта”.

Что касается кастомной разработки, то она превратилась в одно из ключевых УТП и конкурентных преимуществ компании ARBUS. Благодаря тому, что мы можем дописывать стандартный функционал: интеграции с другими системами, виджеты, мобильные приложения, специфические отчеты, доработанные под индивидуальные требования наших клиентов, мы можем выполнить очень сложные задачи и удовлетворить самых требовательных заказчиков, которым необходимо большее, чем то, что есть в коробке. Но и здесь мы придерживаемся наших принципов разработки. Например, открытости – мы с удовольствием продаем созданные решения другим интеграторам и клиентам, если, конечно, не передали вместе с ПО и исключительные права на его использование. Но в кастомной разработке, помимо индивидуальности, есть и свои нюансы.  Их можно охарактеризовать девизом Артемия Лебедева: “Долго.Дорого.Ох..но”!

Что же получает в результате клиент, обратившись к нам за кастомной разработкой? Кому это вообще может быть интересно? Начнем с последнего.  

Это может быть интересно вам, если у вас есть потребности, которые выходят за рамки стандартного функционала. Есть четкое понимание того, что вы хотите и есть возможность/желание разбираться в ТЗ, принимать конечный продукт, тестировать, давать обратную связь разработчику. А еще деньги и время, так как индивидуальные решения – это всегда недешевое удовольствие, и требуется время, чтобы создать/получить качественный, реально работающий инструмент.

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

English

For a start let’s define Custom and Product Development, and how they differ from each other. Custom or individual development is a unique solution that is created for the tasks of a particular customer. Product development or a boxed solution is a kind of standard product that is intended for a wide range of users. Each of these solutions has its advantages and disadvantages. We want to talk about our experience of both approaches. It so happened that we started with box development, and our first solution, iikoWaiter, was destined to become the flagship product, and the best-selling partner solution in the iiko product family. The impetus for creating  our own product was the competition – at that time our main competitor, r_keeper, already had an inexpensive mobile waiter that was run by iOS, and iiko had only options for expensive devices with fairly primitive software on board. And when we lost one, the second deal, and the vendor was not in a hurry with the implementation, assuring us that the market did not need it, we decided to write a mobile waiter ourself. The first implementation was performed on outsourcing (we were problem directors, and another organization was involved in programming), and we did it as an internal product of ARBUS. And so, the product was created, the first clients and reviews appeared, we came to the conclusion that we have to make a native application and not only under iOS, as it was originally, but also under Android, and created our own development team, headed by a human legend and amateur c # in the morning, Sergey Myasnikov. And also, we made a historic decision that we make products for the market, and not only as our internal solution. Later we formulated our design principles:

• Openness (any companies-integrators can sell our products)
• Quality (we want to be proud of our decisions)
• Utility (we want to benefit our customers by increasing the efficiency of the restaurant market)
• Noncompetitiveness (we don’t compete with our partners in the products we create)

Of course, all this could not have happened if it were not for iiko’s competent API openness policy, which allowed other developers, and even customers, to integrate with the product as comfortably as possible, as well as integrate iiko into their internal IT-infrastructure. We even singled out our product development into a separate company, Catapulta, in order not to confuse our businesses: integration, which ARBUS is engaged in, and vendor business (development), which Catapulta became involved in. As for custom development, it has become one of the key competitive advantages of the company ARBUS. Due to the fact that we can add standard functionality: integration with other systems, widgets, mobile applications, specific reports, customized for our clients’ individual requirements, we can perform very complex tasks and satisfy the most demanding customers who need more than what is in the box. However here we adhere to our principles of development. For example, openness – we are happy to sell the solutions we have created to other integrators and customers, unless, of course, we have transferred exclusive rights along with the software. However in custom development, in addition to individuality, there are some nuances. They can be characterized by the slogan of Artemy Lebedev: “Long.Expensive…..”!

What is the result of the client, contacting us for custom development? Who is interested in this at all? Let’s start with the last.

It may be interesting for you if you have needs that go beyond the standard functionality. There is a clear understanding of what you want and have the opportunity/desire to understand the specification, to accept the final product, to test, to give feedback to the developer. And also money and time, since individual solutions are always an expensive pleasure, and it takes time to create/get a high-quality, really working tool.

And also, in a good way, you or your team should have a strategic vision of how you plan to develop your business, and how well individual products will fit into your strategy and IT- infrastructure not only now, but also in the future. As a result, you get an IT-solution, according to an agreed specification, taking into account your individual needs and desires, allowing you to fine-tune the system to suit your work nuances and specifics, as well as additional competitive advantages. In particular, custom solutions are ideal for companies that sell a franchise and want to provide their partners with proven tools for work, and give yourself the transparency of business, security and scalability.