Мало писать хороший софт. Это умеют многие, и собственно за это вам и платят деньги. Но хотите вы этого или нет, работа в IT требует не только соответствующих технических навыков, но еще и умения работать с людьми, и в первую очередь с заказчиком. Для оффшорной команды, когда команду от заказчика отделяют тысячи километров, это правило становится еще важнее.
Цель этой статьи обратить внимание на специфические моменты, которые сопутствуют написанию программ оффшорными командами, а также на особенности планирования задач и общения с клиентами.
Так сложилось, что по ходу своей работы я уже много лет работаю с оффшором, как с одной стороны, со стороны менеджера оффшорной команды, так и с другой стороны, со стороны заказчика. За это время было сделано много наблюдений и выводов, которые позволяют избежать, или хотя бы минимизировать «терки» с заказчиками, неизбежно возникающие при удалённом общении.
Все рекомендации приведены, исходя из личного опыта работы с заказчиками из Западной Европы и США. Вероятно, работа с заказчиками из других регионов будет иметь свою специфику, но возможно некоторые выводы будут верны и для этого случая.
Итак, рассмотрим вариант работы оффшорной команды: команда технически подкована, пишет хороший код, но общение с клиентами организовано не на должном уровне. Результат: рано или поздно такое сотрудничество прекращается.
Здесь приведены советы/замечания, которые помогут оффшорной команде выглядеть хорошо в глазах заказчика.
1. Будьте активными
Это может показаться не важно в начале, но на самом деле оказывает большое влияние на впечатление от команды разработчиков. Активность проявляется в том, чтобы постоянно смотреть на проект с точки зрения менеджера проекта или человека, который платит вам деньги.
То есть вы не только разрабатываете проект, но и пытаетесь улучшить скорость разработки, выяснить, как более эффективно интегрировать разные компоненты вместе, продумать более оптимальную архитектуру, или, в простейшем случае, как ускорить сборку проекта.
Этим самым вы берете на себя часть задач управления / осмысления проекта, и кроме всего прочего, показываете заказчику свою заинтересованность в проекте.
2. Поток выполненных задач
Один из важнейших моментов общения с заказчиком — это информация о выполненных задачах.
На активном проекте задачи поступают постоянно, и если вы даете «сбалансированный» отчет о том, что сделано, то ожидания будут сформированы правильно. Например: если у вас есть задачи по UI и серверной части, то в еженедельном отчете / релизе должны присутствовать задачи из обоих частей.
Еще один момент — это скорость выполнения задач. Вы не должны их делать очень быстро, потому что клиент, как правило, не понимает, что на одну задачу требуется час, а на другую неделя. Клиенту все задачи представляются одинаковой сложности. Поэтому большие задачи выполняются в бэкграунде, в то время как маленькие задачи «показываются» клиенту.
Если перефразировать сказанное, то вам нужен «поток позитива» в сторону заказчика.
3. Не меняйте людей на проекте
Как правило, оффшорные компании поступают следующим образом. В начале проекта на место разработчиков ставят очень опытных людей. Менеджер привыкает к высокому качеству и скорости выполнения задач, и ожидает, что такой уровень будет поддерживаться и дальше. Но со временем опытные разработчики переводятся на другие проекты, а более слабые (читай, дешевые) ставятся на их место. В результате, скорость и качество разработки падают. Индия особенно славится таким подходом.
Когда менеджер проекта осознает эту ситуация, он ничего сделать уже не может, потому что до сдачи проекта осталось мало времени, и передача дел другой фирме сорвет проект. К тому же, перенаправить денежный поток в другую фирму не так просто (подписать бумаги, заручиться поддержки руководства и т.д.). К тому же будут возникать неудобные вопросы вроде «а куда ты смотрел когда подписывал с ними договор» и т.п.
Все это ведет к напряжению в отношениях, и рано или поздно приведет к их разрыву.
4. Метрики / среда разработки
По умолчанию, должны быть поставлены билд сервер, unit test coverage, Jira и т.д. Используя эту информацию, менеджеру проекта будет проще показать ход работ вышестоящему руководству. То есть мы заботимся о том, как менеджер «выглядит» перед руководством.
К тому же, эти метрики являются объективными оценками хода выполнения проекта.
5. Выбирайте технологию правильно
Задавайте больше вопросов по поводу будущего проекта. Из ответов станет понятно, какую технологию выбрать. Например, если первоначальное демо было сделано на .Net и все были довольны, а в конце проекта выясняется, что все это надо ставить на unux, возникнет неловкая ситуация.
Понимание будущего поможет вам лучше выполнить задачу и спланировать production environment.
6. Постоянно напоминайте о своем существовании
Каждую неделю отсылайте статус текущих задач, например, в пятницу. Отчет должен включать информацию о том, что было сделано на прошлой неделе, что планируется на следующей и какие проблемы возникли при выполнении задач.
Менеджер проекта в этом случае сможет поменять приоритет задач и известить клиентов, если будет необходимо.
Хорошим дополнением к отчету будет демо текущего состояния системы.
7. Прямые контакты
На стороне оффшорной команды должны быть люди, которые разговаривают с клиентом (как правило, свободно говорящие на языке клиента) и способные решать задачи по телефону.
Это люди, которые работают в компании достаточно долго, и которые не уйдут при первой возможности из компании. Это «лицо» компании.
Работающая схема выглядит так: на большой проект выделяется два человека. Один менеджер и один технический специалист, которые в состоянии решать все вопросы по проекту.
Должен быть еще один человек (escalation person), которому клиент сможет «пожаловаться», если не удалось договориться.
Доступ девелоперов к общению с клиентом рано или поздно приведет к тому, что девелопер попытается «увести» клиента. Я попадал в такую ситуацию много раз: девелопер просто демпингует (и он может себе это позволить, в то время как компания не может) и компания теряет заказчика.
Дополнительным преимуществом того, что всё общение с заказчиком будет происходить через одного человека, является контроль над ситуацией: этот выделенный человек в любой момент времени будет знать текущее состояние проекта, возникающие проблемы, вопросы и т.п.
8. Email
Email — это документ, на основе которого принимаются решения. Email-ы по пректу не удаляются, для того чтобы в любой момент времени можно было поднять полную цепочку обсуждения. Все телефонные дискуссии желательно подтверждать письмом, в котором вы описываете все, что было обсуждено и планируемые шаги.
На самом деле, объяснение того, что надо сделать человеку, который сидит от вас в десяти часах лета, вещь не простая. Я делаю это следующим образом. Пишу маленький документ с основными требованиями, потом проговариваем все детали по телефону. После обсуждения девелопер пишет документ, в котором описывает, как он все это понял. Если у меня после прочтения создается «картинка» схожая с тем, что я первоначально хотел донести до разработчиков, то задача идет на выполнение. В противном случае продолжаем обсуждать.
Может показаться, что это дополнительная волокита, но в итоге получается быстрее, чем сделать, не поняв суть задачи и потом всё переделывать. После месяца такой практики все происходит достаточно быстро.
9. Run Down Script
Run Down Script вещь полезная, но я не понимал её назначение до тех пор, пока не пошел работать в банк.
Банк это большая организация, и установка новой версии продукта происходит в определенное время, так называемое «окно» (release window). В это время очень многие будут выставлять свои версии, и координация действий очень важна.
Run Down Script как раз и решает эту проблему. В этом документе описывается, кто, когда и что будет ставить, на каких серверах, и если что-то «свалится», как это можно будет откатить до предыдущей стадии. Должно быть описано всё, вплоть до команд, которые надо выполнить.
10. Техническая поддержка
Не бойтесь брать проект на поддержку/сопровождение. Основные деньги софтверная компания получает с тех. поддержки, а не с разработки.
На поддержку можно нанять менее опытных разработчиков, чтобы они учились, в то время, как более опытные делают новый проект.
11. «Продавливание» решения
Клиенты любят «продавливать» дополнительные требования к системе, особенно когда 90% работы уже сделано и появилось условно свободное время.
Здесь два пути решения:
* показывать выполнение задач таким образом, чтобы создавалось впечатление, что 10% функциональности сделать не успеем, и только при помощи «невероятных» усилий и командной работы, мы все таки это сделали
* отбиваться, используя начальные требования к проекту — у вас все есть письма и документы, которые были обсуждены, и согласие на выполнение работ в данном объеме было получено.
12. Запретные слова
Не используйте запретных слов в общении. Например, фраза «мы за неделю ПЕРЕПИШЕМ (rewrite) систему» в корне не верна. Если вы говорите «rewrite», то следующий вопрос будет «а что вы все это время делали?». Такие моменты могут возникнуть из-за незнания языка заказчика на должном уровне. Лучше написать «improve the system» или «tune the system».
13. Не уверен — переспроси
Многие боятся спрашивать, чтобы не показывать, что на самом деле ничего не понятно. Но когда дело доходит до выполнения задачи, начинаются проблемы.
Все понимают, что всего знать нельзя и вопросы/обсуждения показывают, что человек хочет разобраться, и это всегда приветствуется и поддерживается.
14. Релиз
Дата релиза очень важна, и предоставлять продукт на определенную дату важно потому, что релиз это не только написанный софт, но и железо, и админы и т.д и т.п.
На эту дату должно быть синхронизировано очень много параметров.
Например, если железо куплено и работает в холостую, то клиент за это платит. Если бы там был софт, то сервис приносил бы доход, а так железо просто стоит.
Пожалуйста, планируйте задачи правильно и предоставляйте софт вовремя.
Комментарии приветствуются.
Автор: sergmesh
