Взять готовое или написать свое? Вечный спор в любом бизнесе, который остро встает при выборе буквально чего угодно. И биллинга в частности.

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

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

Привет, Хабр! Меня зовут Василий, я директор SaaS-направления Аспро — руковожу разработкой Аспро.Cloud.

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

Расскажу, как у нас устроена очередь задач: по какому правилу задача попадает в спринт, как мы понимаем, что она принесла, и во что обходится срочное, которое никто не планировал.

В офертах сервисов, которые продаются бизнесу – CRM, рассылки, HR-платформы, трекеры задач, сервисы расшифровки созвонов, – раздел про персональные данные есть почти всегда. Поручения на обработку в нем почти никогда нет, хотя авторы оферт обычно уверены в обратном.

Разбираю, что требует часть 3 статьи 6 152-ФЗ дословно, почему четыре самые частые формулировки поручением не являются и какая часть требований выполняется не текстом договора, а продуктом: доказательство акцепта редакции, порядок смены редакции, уведомление об инциденте в срок меньше суток и блокирование данных по конкретному субъекту.