Мы предпочитаем брать всю разработку на себя, но в этот раз дизайном и бэкендом клиент занимался самостоятельно, а нам делегировал только разработку мобильного приложения. Из-за того, что приложение разрабатывали параллельно с сервером, конфигурация API иногда менялась без согласования с нашим разработчиком. Это влияло на сроки запуска. Например, если клиент менял спецификацию, а мы узнавали об этом ближе к концу спринта, то срок сдачи проделанного скоупа сдвигался. Чтобы ускорить процесс разработки, мы договорились с клиентом предварительно сообщать друг другу об изменениях. Так мы избежали возможных ошибок в приложении.
Спасибо за статью, не так давно слежу за КММ, но всё же назрел вопрос. Забабахали вы сторону андроида и мультиплатформенную логику, ios пока остался в стороне, затем придет клиент и скажет - пилим ios!
Собственно сам вопрос в том, а не будет ли потом этот самый ios разраб страдать из-за того, что в прошлом нативный разраб, а ныне мультиплатформенный котлинист, прикрутил мультиплатформу так, что её использование будет удобно только андроиду? Есть же согласованность между разработчиками как в описанном вами случае, что например, так делаем, а так не делаем, по тому что.... на стороне ios?
Такие ситуации мы, на самом деле, действительно довольно часто ловили на первых проектах, когда ещё обкатывали технологию. Это работало в обе стороны - андроидщики ломали iOS, айосники ломали андроид.
Об этом говорили вот тут вот на докладе: https://www.youtube.com/watch?v=h9ioWnSlUJc (примерно с 6:40).
Поэтому мы вывели определённый набор правил и стандартов, которых придерживаемся у нас при разработке. Они помогают унифицировать подходы по взаимодействию нативных приложений с common-кодом без ущерба какой-либо из платформ. Так что сейчас вероятность таких поломок сведена к минимуму