Дмитрий Мельников

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

После короткой вводной сессии самостоятельно погрузился в незнакомую кодовую базу. Определил основные модули и сущности, проследил маршруты запросов, структуру входных и выходных данных, зависимости между компонентами и обработку ошибок. Языковые модели использовал как инструмент ускоренного анализа кода, поиска связей и проверки гипотез; выводы подтверждал по реализации и поведению системы.

Сформировал единое описание API: назначение методов, параметры, форматы запросов и ответов, ограничения, ошибки и ключевые сценарии использования. Подготовил машиночитаемую спецификацию OpenAPI / Swagger, которую можно использовать как документацию, основу для тестирования и источник для генерации клиентского кода.

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

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

Предложил изменить порядок работы: сначала спроектировать пользовательский опыт и собрать интерактивный прототип, а техническое задание подготовить после его проверки. Разложил процесс конфигурации на шаги, описал роли и сценарии, определил зависимости между параметрами и спроектировал интерфейс. Затем собрал функциональный прототип в Lovable.

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

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

Компания использовала облачный Битрикс24 как основную операционную систему. По мере развития процессов возникла необходимость учитывать сложные начисления, расходы, перерасчёты и взаиморасчёты, а также получать оперативную аналитику по объектам. Ограничения облачной версии не позволяли надёжно реализовать необходимую финансовую логику и дальнейшую автоматизацию.

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

Организовал миграцию данных и процессов на коробочный Битрикс24. Спроектировал финансовую модель, связывающую объекты, договоры, начисления, расходы, корректировки и итоговые показатели. Реализовал двусторонние начисления и перерасчёты, автоматические действия при изменении данных, интеграции и аналитические панели для контроля операционной деятельности.

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

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

Спроектировал платформу, в которой запуск процесса начинается с ИНН компании. Система обращается к нескольким открытым и платным API, получает регистрационные сведения, данные о руководителях, учредителях и бенефициарах, приводит ответы разных сервисов к единой структуре и проверяет полноту информации.

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

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