В Украине есть множество мелких контор, студий, которые делают всякие небольшие проекты для заграничного заказчика. Довольно распространены расклады, когда к студии приходит заказ, а свободного ресурса у нее нет. Для этого есть всевозможные фейсбук-группы для работорговли и обмена гребцами, там пасутся проджект менеджеры и сейлзы и торгуют “есть реакт дев по 25$ час”, “нужен iOS разраб”, короче базар.

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

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

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

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

Наш девелопер собрал приложение из сорцов, но никак не мог дойти до шага, где находилась искомая проблема, потому что крашилось на предыдущем шаге. При этом, у клиента была рабочая сборка, которая не крашилась, но у нас вылазила совершенно криповая ошибка, которая ни о чем не говорила. Полторы недели разраб потратил на то, чтобы поковырять проблему со всех сторон, поменять версии либ и так далее, но к успеху не пришел. РМ-посредник начала беспокоиться, потому что ей нужно было объяснять клиенту почему мы тупим две недели. Когда я об этом узнал, то решил собрать аппку у себя на ноуте, чтобы посмотреть, что же там такое, скачал сорцы, собрал, залил на телефон, и — о чудо! криповая ошибка пропала! Этим же вечером я созвонился с разработчиком и мы то же самое попробовали сделать у него — его сборка все так же была невалидной, хотя у нас эквивалентные версии IDE, JVM, сборщиков и всего остального.

Однако, это не решило проблему — что же отвечать клиенту? РМ сказала, что ей “неудобно” говорить ему что мы две недели не могли сделать стабильную сборку несмотря на заявленную экспертизу и вот, наконец-то удосужились понять, в чем была загвоздка и теперь готовы пофиксить багу.

Если бы я работал напрямую с клиентом — я бы так и сказал “бро, тут такое дело, черт знает что происходит, мы такое первый раз видим чтобы ./gradlew assembleDebug выдавал разные результаты, сорян что тупили, щас возьмемся за твою проблему”. Но не в нашем случае, потому что политика и нельзя потерять лицо. Нужно придумывать какое-то монстроузное объяснение, прикрывать зад обтекаемыми(sic!) выражениями чтобы клиент ни на секунду не усомнился в том, что мы действительно че-то там делали, а не просто шарились.

Раздражает, что нельзя честно и прямо сказать, что вот так и так — пробовали, не работает, нашли причину, чиним. Не любят люди честность.