«Сверкающие кинжалы» или как мы арабский проект делали

в 1:15, , рубрики: контракты, разработка под iOS, управление проектами, метки:

**внимание, эта статья обрывается так же внезапно, как и проект в ней описываемый**

Начало

Начиналось всё более чем оптимистично: заказчики из ОАЭ (новый для нас рынок), презентабельный внешний вид представителей, обещания других контрактов, «деньги не проблема». Всё это в сумме сыграло с нами злую шутку и, на свою беду, мы подписались на эту разработку. Хотелось попробовать. В итоге это обернулось расторжением контракта в одностороннем порядке, но не со стороны клиента, а нами — компанией-аутсорсером.

Сам проект был несложным – это был аукцион по продаже автомобильных номеров (по $80,000-$90,000 за штуку), верблюдов и прочих атрибутов обыденной жизни Арабских Эмиратов. Необходимо было создать iOS апп, оглядываясь на уже существующую (но не работающую пока) веб-версию. На этапе первого послепродажного общения клиента вел его я, и уже тогда начала появляться первая тревога, потому что клиент предоставил очень мало информации о проекте. После этого управление передали нашему проект-менеджеру. Забегая вперёд, скажу, что по итогу он не только не уехал в жёлтый дом, но даже не полностью поседел за что ему большой респект.

Итак, особенность первая, упомянутая выше – очень мало информации, и, как оказалось, это не особенность отдельного клиента, а черта всех региональных компаний, которые размещают заказы напрямую, а не через западных партнёров. Дело в том, что культура менеджмента и управления в арабском мире сильно отличается от западной да и от нашей тоже. Она очень вариативна и одни и те же условия могут приводить к разным результатам. В качестве примера можно привести «устные соглашения»: в Лондоне (а проект, к слову, был продан через наш лондонский офис) устное соглашение – это юридически признанная форма заключения сделки и относятся к ней соответственно, однако оформлять договоры предпочитают всё-таки на бумаге. В арабском мире дела обстоят немного сложнее – контактами пренебрегают, а вот как раз устная форма договорных отношений доминирует. Из-за этого очень многое никогда не описывается на бумаге, если проект не выходит за рамки региона, т.к. считается, что обо всём можно договориться лично. В нашем случае было именно так, проект практически полностью для локального рынка и единственной международной его «фичей» была возможность выбрать английский язык интерфейса. Из-за отсутствия хоть сколько-нибудь ценной информации на первом этапе, стадия анализа проекта была очень важной. Кто бы мог подумать, что уже на этой стадии мы начнём чувствовать на себе всю силу удара от столкновения двух разных стилей управления проектами.

Сбор требований

Первое, что было замечено нами – это очень агрессивный стиль общения буквально с первого дня, когда проект поступил в офис разработки. До того мы думали, что экс-советские заказчики самые агрессивные, но нет. Эта агрессия проявлялась даже тогда, когда мы пытались уточнить абсолютно безобидные вещи, вроде того, когда же будет демка API. Это можно назвать второй особенностью – если вам платят деньги, то для арабского заказчика вы просто наёмный работник, но никак не партнёр. В нашем случае ситуация усугублялась тем, что учредителями компании-заказчика были люди довольно молодые. Предлагаю вам самим представить смесь восточного темперамента, молодого возраста и больших денег. В итоге, выход был найден в том, чтобы задавать им минимальное количество вопросов и самим предлагать максимум. Работало это не всегда, т.к. при более чем трёхчасовом молчании сразу начинали сыпаться письма-пинги, но жить стало немного легче.

Заказчиком был запрошен прототип. ОК, это наша работа. Прототип делался в Axure и получился очень детализированным, если учесть то количество информации, что было на руках. Сквозь постоянные письма возмущения — «чего так долго» — прототип удалось завершить. Проект-менеджер познал дзен и все нюансы приобретения автомобильных номеров в Абу-Даби. Клиент начал вносить правки в расположение элементов и прочие мелочи – это нормально, рабочий процесс. С горем пополам этот этап мы прошли, потеряв по пути «всего лишь» неделю на общении с клиентом. Параллельно шло написание технической спецификации, которое давалось очень тяжело в силу полного отсутствия содействия. Напор претензий к нам усиливался из-за того, что мы, затягиваем сроки уже на первых этапах, а о причинах задержки (читайте выше) слышать, разумеется, никто не хотел. Тут мы столкнулись с еще одной особенностью, третьей. По условиям контракта, мы подписались на определенные сроки выполнения работ, одновременно с этим, в контракте присутствовал и пункт, что заказчик обязуется предоставить нам данные, необходимые для разработки. И вот здесь они смогли уцепиться за то, что в контакте не было указано, что именно они должны нам предоставить. Оказалось, что по их мнению, API нам не нужен в принципе. Далее выяснилось, что API предоставлять никто не собирается, просто потому что его нет, и когда он будет, сказать никто не может, однако, это не мешало заказчикам постоянно напоминать про наши дедлайны и сроки в целом. Т.е. любые документы и договорённости извращаются в пользу заказчика и это было на каждом из 4-х моих арабских проектов.

Особенность четвертая – никакие претензии к заказчику не принимаются, точка. Попытки объяснить, что сроки затягиваются, т.к. клиент не отвечает на вопросы или не предоставляет достаточно информации в своих ответах, а так же из-за отсутствия документации по API или живой демки — всё это игнорировалось, а если и удостаивалось ответа, то было это в духе "занимайтесь проектом, не стоит нас учить, у вас есть контракт – вы обязаны нам к такому-то числу предоставить уже бета-билд, выполняйте" — это цитата из одного из телефонных разговоров. И это, замечу, еще до того как был согласован интерфейс. Как так можно общаться и вести совместный проект, пусть мы всего лишь исполнитель, у меня в голове не укладывалось. Проект уже превращался в муку, и у нас начали появляться первые мысли, что хорошо это не закончится.

Дизайн

Когда началась стадия дизайна, клиент попросил, чтобы приложение было похоже на веб-сайт аукционов дабы соблюсти преемственность. Вступать в спор по поводу дизайна их сайта не хотелось, потому решено было выжать из того, что есть максимум. Мы подготовили «два с половиной» варианта дизайна, заказчик выбрал один, еще 2 недели шли переделки и уточнения, при том до такой степени, что нам говорили, какой элемент куда подвинуть и какую фоновую фотографию использовать. Ладно, вроде бы закончили, дизайн принят. В этот момент статистика проекта показывала, что он точно не будет прибыльным для компании, т.к. затраченное время уже составляло 50% предполагаемого. Приняли как данное, что маржа по проекту будет минимальной, если вообще будет.

image

Тем не менее, дизайн принят, повод радоваться, но не тут-то было. Начался шквал звонков и писем по поводу того, что буквально завтра уже должен быть бета-билд по оригинальному контракту, а вы только сегодня прислали нам финальный дизайн. Слушать о том, что сроки майлстоунов отодвигаются соразмерно времени простоев по вине заказчика, никто не хотел, разумеется. И тут случилось неожиданное – в наш лондонский офис «Пришли». Я написал словно «Пришли» с большой буквы, потому что по рассказам сотрудников это было настоящее зрелище. На бизнес-встречу явились представители наших заказчиков в очень агрессивном настроении и при кинжалах, которыми они не преминули блеснуть и угрожали воспользоваться. В дело пришлось вмешаться директору офиса, который указал этим людям сперва на контракт, а затем на дверь. Особенность пятая – часто арабские заказчики стараются перенести конфликт как можно ближе к вам (физически). На наш английский офис эта история, безусловно, произвела двоякое впечатление: с одной стороны, бесплатное представление, а с другой как-то невесело совсем.

Финиш

Давление усиливалось, и мы приняли решение не начинать разработку, пока не будет готов API. Какую реакцию это вызвало у заказчика, вы можете представить. Начались угрозы судом, давление на английский офис и менеджера проекта возросло максимально. Посовещавшись, мы приняли решение разорвать контракт в одностороннем порядке, т.к. условия, создаваемые клиентом, оказались для нас за гранью. Все материалы: прототип, дизайн, спецификация на 30+ страниц были высланы клиенту вместе с формальным уведомлением о разрыве контракта. Разумеется были дальнейшие угрозы, звонки, письма, но это были уже совсем неважно.

Так для нас закончился один из арабских проектов – даже не дойдя до стадии, собственно, разработки. Какая компания в итоге закончила проект я не знаю, но судя по тому, что доступно в App Store, дизайн был взят наш, логика соответствует нашему же прототипу.

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

За всю карьеру у меня было 4 арабских проекта: 2 мобильных, один телеком и один веб. Один из них удалось довести до конца. Разумеется, судить вообще обо всём регионе нельзя ни по этой статье ни по 4-м проектам, тем не менее, опыт пока негативный. Возможно, работая локально, в Абу-Даби или Дубае ситуация видится вовсе иначе. Отсюда просьба. Расскажите в комментариях о своём опыте работы с заказчиками из арабских стран.

Автор: MennyCalavera

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js