В ТЗ требуют интеграцию с API UETS: что это такое и как закладывать в смету?

Сервисы UETS работают на древнем стеке: вместо человеческого REST там в основном SOAP и WSDL. Придется ковыряться с подписью XML, проверкой сертификатов X.509 и шифрованием по требованиям PTT. Документация у них не первой свежести, так что готовьтесь потратить кучу времени на отладку и разбор пакетов в песочнице.

При формировании КП обязательно внесите в договор три особых условия: 1) Подписание протоколов с PTT и подача всех заявлений лежит целиком на клиенте. 2) Разработчик не несет ответственности за пропуск процессуальных сроков из-за сбоев или таймаутов на стороне UETS. 3) Тестирование интеграции проводится исключительно на тестовом аккаунте, предоставленном PTT.

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

В смете ни в коем случае не размазывайте эту работу по другим модулям. Выделите отдельной строкой: «Модуль официальной интеграции с UETS». И ценник ставьте минимум в два раза выше обычной API-интеграции потому что львиную долю общения клиента с PTT придется разруливать именно вам.

А у клиента аккаунт UETS оформлен на физлицо или на юрлицо? Для частных адвокатских кабинетов процесс выдачи прямого доступа к веб-сервисам может отличаться от процедур для компаний. Они уточняли этот момент в PTT заранее?

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

Мы пару лет назад в одном проекте отнеслись к этой интеграции как к обычному SMS-шлюзу и заложили копеечную стоимость разработки. В итоге из-за сертификатов безопасности, которые требовала PTT смены IP серверов и вечно меняющихся ответов сервиса вся прибыль ушла на техподдержку. Когда будете выставлять счет, обязательно закладывайте плату за ежегодное обслуживание и мониторинг сервиса.

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

Если смотреть на процесс в целом, картина меняется. Большая часть потерь времени копится на задачах, ожидающих согласования.

Эта тема в архиве. Если не зафиксировать это письменно с самого начала, потом возникнут споры.

Я сталкивался с тем же.

Я проходил через это, расскажу. График платежей должен быть привязан к этапам работ, а не к датам.

Надеюсь, это будет полезно.

Есть один момент, который меня интересует. Внедрение процесса управления изменениями не замедляет работу, а ускоряет её.

Это мое мнение не утверждаю, что оно единственно верное.

Попробую.

Взял на заметку, спасибо.

Расскажу, как это делается на практике. Большая часть потерь времени копится на задачах ожидающих согласования.

Удачи.

Я тоже так считаю. Все, кто торопится с интеграция с api uets, спотыкаются на одном и том же.

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

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

Надеюсь, это будет полезно.