Специфика деятельности в сфере офшорного программирования требует выработки набора особых методик и правил, дополняющих стандартные практики управления проектами. Вместе с тем, многие рекомендации носят достаточно универсальный характер и могут быть полезны для любого коллектива, занятого в области заказного программирования.
Прежде всего, остановимся на особенностях проектов из области офшорного программирования. Во-первых, в проектах такого рода заказчик удален от проектной команды и общается с ней, используя в основном электронные средства коммуникаций. Во-вторых, если заказчик расположен в другой временной зоне, то коммуникации могут терять свою оперативность, особенно, когда разница во времени велика. В-третьих, заказчик в большинстве случаев общается на английском языке, не родном для проектной команды, что означает дополнительный риск потери информации. В-четвертых, у заказчика иной менталитет и потому предположения проектной команды относительно мотивов поведения заказчика или о его возможных решениях могут быть не верны. В-пятых, уровень сотрудников заказчика может быть довольно разным, что нельзя не учитывать при организации общения: нельзя говорить об управлении рисками, если заказчик оперирует другими понятиями.
Может показаться, что я преувеличиваю сложности проектов офшорного программирования. Казалось бы, что проще: получили спецификацию и вперед, сдали проект и дальше, за следующим. Но в жизни все гораздо сложнее.
Прежде всего, лишь 10-15% заказчиков способны подготовить спецификации, которые можно действительно точно оценить и незамедлительно начать по ним работать; остальные требуют длительной и кропотливой работы по созданию и детализации спецификаций.
Далее, разработка проекта отнимает некоторое время, и зафиксированная в начале проекта спецификация может меняться; любое изменение спецификации требует выявления, детализации и оценки изменения.
Кроме того, надо четко понимать, что исполнение проекта согласно подписанным заказчиком спецификациям, бюджету, срокам и качеству является необходимым условием, но, увы, недостаточным. Во-первых, существует немалый риск, что проект, сделанный согласно спецификациям, — это вовсе не то, что действительно требуется заказчику. Звучит как крамола, однако бывает, что заказчик, формируя спецификации, неправильно представлял себе проект. Неотступно следуя такой спецификации, исполнитель формально будет прав, но расстроенный заказчик никогда в дальнейшем не станет с ним работать. Во-вторых, взаимодействие с исполнителем должно оставлять у заказчика чувство комфорта; заказчик должен быть уверен, что проект выполняется как надо. Запомнив ощущение дискомфорта, даже при выполнении всех требований проекта, заказчик впредь постарается избежать контактов с этим исполнителем.
В проектах офшорного программирования первый проект обычно убыточен: стоимость привлечения заказчика очень велика. Это означает, что выполнение первого проекта с неполучением последующих от того же заказчика следует рассматривать как неудачу.
Опыт выполнения многочисленных проектов офшорного программирования позволил нашей компании выработать ряд методик; их можно разбить на несколько групп в соответствии с рисками, управлять которыми они призваны.
1. Риск неправильного понимания проекта заказчиком и исполнителем. Самое опасное предположение, которое может привести любой проект к краху, — предположение, что заказчик все знает, и что проектной команде остается только выполнить его волю. Даже если следовать всем формальным методикам управления проектами, делать все, что требует заказчик, соблюдая сроки, бюджет и качество, но в результате получить не то, что заказчику действительно надо, проект придется признать провальным. Для того чтобы уменьшить этот риск, необходимо предпринять следующие шаги.
- Постараться понять бизнес-цели проекта, бизнес-требования, которые транслируются в требования к проекту. Это позволит правильно ориентироваться, понимать степень важности и приоритеты конкретных требований. Кроме того, такое знание позволит привносить свои идеи по улучшению проекта.
- Стараться понять не только заказчика, но и его конкурентов, что позволит более адекватно оценивать правильность решений заказчика и даст возможность исполнителю корректировать те или иные решения. Понимание бизнеса заказчика и его конкурентов позволит перейти с модели взаимоотношений "заказчик - исполнитель" к модели "партнер - партнер".
- Даже если заказчик правильно понимает свой бизнес, остается риск, что он может неправильно интерпретировать проектную документацию. При применении методологий, которые снижают риск неоднозначного толкования требований и проектных решений (например, UML), необходимо учитывать риск того, что специалисты заказчика недостаточно владеют этими технологиями. Поэтому комбинация методологий проектирования с обучением заказчика этим методологиям и применением прототипирования проекта с ранней доставкой функциональных версий проекта поможет заказчику на самых ранних этапах понимать, что он получит в результате разработки проекта. Прототипирование становится критически важным, когда технический представитель заказчика, который может разбираться в методологиях проектирования, не является основным заказчиком проекта. Имеется значительный риск, что технический представитель заказчика неправильно интерпретирует требования других заинтересованных в проекте лиц (с большой вероятностью эти лица не технически, а бизнес-ориентированы). В такой ситуации только прототипы могут помочь передать и подтвердить правильность понимания заказчиком и исполнителем проекта и внести коррективы на его ранних стадиях.
- Исполнитель должен отдавать себе отчет в том, что он может додумывать за заказчика и принимать решения самостоятельно, но тем самым он привносит дополнительные риски, если предположения оказываются неправильными. Одно из самых значительных заблуждений таково: "Отсутствие вопросов к заказчику показывает уровень знаний и глубину понимания бизнеса заказчика". То, что иногда преподносится как самостоятельность и знание, может стоить жизни проекту. Предположения могут оказаться неверными, и тогда исполнителю придется исправлять результаты предположений за свой счет. Если ошибочность предположений вскрывается на поздних стадиях проекта, то с большой вероятностью это ведет к задержкам, а потом и к провалу проекта. С другой стороны, если все решения принимает заказчик, это может привести к ощущению невысокой ценности исполнителя для проекта. Поэтому необходимо не только спрашивать заказчика, но и предлагать готовые варианты решения. Следует уйти от формулировок типа "расскажите мне, как…", заменив их на "правильно ли я понимаю, что…".
2. Риск дискомфорта. Этот риск связан с тем, что заказчик, находясь на расстоянии от проектной команды и в другом часовом поясе, всегда предполагает самое худшее. Не более 5-10% заказчиков являются оптимистами и способны спокойно ждать, когда исполнитель соизволит им предоставить результаты. Это не право заказчика требовать, а обязанность исполнителя обеспечивать заказчика постоянным информационным потоком о ходе проекта, причем способы для этого необходимо выбрать наиболее комфортные для конкретного заказчика и притом возможно различными для разных сотрудников заказчика. Скажем, можно посылать стандартные отчеты о ходе проекта совместно с проектной документацией, но, поняв, что заказчик не читает эти отчеты, лучше устраивать их совместное прочтение на телефонном совещании. Исполнитель должен анализировать состояние сотрудников заказчика, которые работают с ним по конкретному проекту, стараясь понять, какие у них есть опасения и что надо делать, чтобы эти опасения ликвидировать и создать чувство комфорта.
Говоря о средствах осуществления коммуникаций между проектной командой и заказчиком, необходимо отметить опасность выбора электронной почты в качестве основного их средства. К этому подталкивают ее распространенность, легкость в использовании, «терпимость» к уровню владения английским языком (пишем и читаем мы лучше, чем разговариваем), стремление избежать устных коммуникаций с заказчиком в силу возможного непонимания или демонстрации заказчику недостаточного владения языком. Электронная почта обладает рядом недостатков, которые непременно надо учитывать.
- Электронная почта не является оперативным средством коммуникаций. Нет никакой гарантии, что ответ на запрос будет немедленным. В коммуникациях возникает определенная задержка, которая накладывается на разницу во времени, что приводит к значительным общим задержкам по принятию тех или иных решений. Неточная формулировка в письме приводит к дополнительным циклам по ее прояснению.
- Электронная почта является письменным средством коммуникаций, что может привести к неточной интерпретации вопроса. Случается, что попытка детализировать вопрос расценивается как желание подчеркнуть некомпетентность представителя заказчика; требуется немало усилий, телефонных звонков и визитов, чтобы сгладить возникшую проблему.
- Наличие средств копирования сообщения многим адресатам позволяет создавать единое информационное поле, но в тоже время ограничивает возможности принятия решений тем или иным представителем заказчика - он должен принять решение публично. Даже если он уверен в решении на 99%, он будет вынужден официально его согласовывать.
Необходимо комбинировать использование электронной почты в проекте с другими средствами коммуникаций.
Естественно, самое оптимальное и эффективное средство коммуникаций — это постоянное присутствие представителя исполнителя в офисе заказчика. При правильном подборе такого сотрудника коммуникативные риски значительно снижаются. Если такое решение вследствие разного рода ограничений (от финансовых до визовых) невозможно, необходимо попытаться наладить регулярные визиты сотрудников исполнителя к заказчику. По крайней мере, такие визиты особенно важны на этапах разработки требований к проекту, обсуждения прототипов и доставки первых версий проекта. В дополнение к визитам к заказчику и обсуждению с ним хода проекта «лицом к лицу», необходимо наладить регулярные телефонные конференции с заказчиком, что создает эффект присутствия. Применение средств обмена срочными сообщениями вместо почты, не позволяет документировать коммуникации, более эффективно, чем электронная почта.
В качестве еще одного совета можно указать на необходимость организовать распределенные коммуникации со многими членами проектной команды, не замыкая все коммуникации на одного сотрудника (например, на менеджера проекта).
Правильно выстроенные коммуникации дают для проекта еще один плюс. Не секрет, что не бывает проектов без ошибок, особенно в разработке программного обеспечения, где существует множество неконтролируемых рисков. Очень важны возможность исправлять ошибки и терпимость заказчика к такого рода ситуациям. Правильно выстроенные коммуникации помогут сформировать правильное отношение заказчика к проекту и преодолеть возможные проблемы.
Анатолий Гавердовский (AnatolyG@moscow.vdiweb.com) — компания Vested Development (Москва).
