редакции
Микросервис биллинга: история проекта, закрытого в срок
Когда можно назвать проект успешным? Для меня это:
- уложиться в сроки;
- уложиться в бюджет;
- закрыть все требования по ТЗ.
И одним из первых таких проектов для меня стала разработка микросервиса биллинга, хоть мы и столкнулись при этом с некоторыми препятствиями — как техническими, так и коммуникационными.
На связи команда ZAKUPKI.GROUP и ее COO Алексей Николаев. Мы проектируем корпоративное ПО на Java EE.
Все началось с внутреннего продукта — CRM-системы для участников госзакупок. Нужен был шлюз с приемом платежей от физ- и юрлиц. У нас получилось быстро встроить его в монолит, тем более что поддерживал он только один банк и одну платежную систему.
Но самое интересное началось, когда к нам пришел клиент — экосистема для проведения турниров по играм Apex Legends. Изначально они сами не понимали, чего хотят, как это часто бывает с заказчиками. Около полугода мы согласовывали, что будем делать, и в итоге решили: нужен продукт, осуществляющий прием/выплату и внутреннее движение средств. И мы приступили к разработке микросервиса биллинга с модульной архитектурой, который плавно бы вписался в сервера и приложения клиента. В то время у нас в команде не было аналитиков. Сбором функциональных и нефункциональных требований, построением диаграмм занимались разработчики. Естественно, это происходило под чутким контролем CTO, и результат получился достойным. Но насколько было бы легче с аналитическим отделом! К слову, сейчас он у нас уже сформирован, и теперь разработчики занимаются своими прямыми обязанностями, и даже не выгорают и не увольняются! (Да, было и такое, но это тянет на отдельный лонгрид) Вместе с клиентом мы долго и методично разрабатывали ТЗ, и вот основные моменты, к которым мы пришли: ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ SL В разработке считается, что превышение заложенного времени в 3 раза — это еще не срыв дедлайна, а норма. Но мы думаем, что срыв сроков происходит из-за недостаточной первичной аналитики. Закладывая время на работу, мы понимали, что нужно быть реалистами и не давать невыполнимых обещаний клиенту. Особое внимание уделили этапу тестирования. Он не является последним и наличие тестов не гарантирует полного отсутствия багов, поэтому за ним обычно идет этап исправлений со стороны разработки. В итоге мы не поскупились — на тестирование и на исправление багов выделили по 40 часов. Итак, хорошая аналитика позволила нам спокойно и без особых помех работать над проектом, укладываясь в сроки. Однако не все зависело от нас, т. к. для интеграции платежных систем нужно пройти их внутреннюю модерацию — а значит подгонять под них клиентские сайты и заключать договоры. Такие полномочия были только у заказчика, и его приходилось периодически «пинать», напоминая о дедлайнах. Мы решили не упускать момент, и пока клиент тянул время, написали реактивный код. Масштабируемое и высоконагруженное приложение как результат проволочек от заказчика — звучит неплохо! В итоге на работу ушло 3 месяца, клиент остался доволен, сейчас мы сотрудничаем с ним уже по другому проекту. А судьба микросервиса биллинга сложилась как нельзя лучше — мы подключаем его к новым платежным системам и готовимся интегрировать во внутренние проекты, а также продавать как готовый продукт. Кстати, продажа микросервиса заказчикам возможна в том числе благодаря Докеру (Docker) — платформе, которая позволяет упаковать в контейнер приложение со всем окружением и зависимостями, а затем доставить и запустить его в целевой системе. Другими словами, он позволяет быстро и без проблем развернуть готовый продукт на клиентских серверах. В следующих статьях я могу подробнее рассказать о том, как мы переходили на Докер и какие у него преимущества перед голыми серверами. Буду рад любым комментариям! Алексей Николаев, COO ZAKUPKI.GROUP / CEO NIKSOFT
Этап аналитики
Сдача проекта
