Определите, чего вы ждете от подрядчиков

ТЕХНИЧЕСКИЙ АНАЛИЗ

Как любое другое новое явление, наем внештатных разработчиков (outsourcing) и родственное ему офшорное программирование пережили свой миг славы. В тишине, наступившей после громогласных заявлений, сулящих неправдоподобное сокращение расходов, и апокалиптических предсказаний об отмирании профессии программиста в США, команды разработчиков должны более точно определить свои перспективы.

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

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

Например, исследование, проведенное Hewitt Associates, обнаружило, что в ряде отраслей Индии уровень зарплаты изменялся в соответствии с прежними прогнозами компании. В этом году он возрастет на 14% и продолжит рост теми же темпами в следующем году. Данные, приводимые компанией AMR Research, свидетельствуют о еще более быстром росте зарплаты в Индии: на 20% в год для работников, окончивших колледж в 2004-м.

Не следует думать, будто доходы программистов США замерли на одном уровне. Хотя некоторые могут сказать, что они не меняются или даже (в реальном выражении) снижаются. Но и при среднем росте лишь в 10%, например, потребуется менее двух десятков лет, чтобы ликвидировать разницу между зарплатой руководителя софтверного проекта в Индии и его коллеги в США. Этот разрыв обычно оценивается как шестикратный.

Между тем многие, похоже, забывают, что уже на протяжении десятилетий известно о неравномерном распределении навыков как в работающих над проектами командах, так и в региональном плане. Норман Огастин, бывший глава корпорации Lockheed Martin, писал в своих часто цитируемых "Законах Огастина", что среди представителей многих специальностей - от ученых до профессиональных футболистов - лучшая часть любой группы, составляющая 1/5, выполняет около половины работы, а худшая - половина сотрудников - примерно 1/5 работы.

Если немного расширить сферу применения этих пропорций, то можно подсчитать, что снижения производительности труда пятой части лучших работников коллектива на 20% достаточно, чтобы свести на нет 50-процентный рост производительности труда (или сокращение почасовой платы на 33%) худшей половины сотрудников. Поэтому, если эффективность труда руководителей проектов хоть немного упадет из-за языковых трудностей, различия часовых поясов и других факторов, выигрыш для проекта в целом может быть на удивление невелик, как бы ни гордился бухгалтер проекта тем, что ему удалось нанять рядовых сотрудников с более низкой зарплатой благодаря системе офшорного программирования.

Диспропорции, о которых пишет Огастин, вероятнее всего, дополнительно усиливаются, когда речь идет о разработке ПО. Бари Боум в своем изданном в 1981 г. авторитетном исследовании "Экономика инжиниринга программного обеспечения" приходит к выводу, что команда программистов, составленная путем отбора 10% наиболее опытных специалистов, будет работать примерно в четыре раза продуктивнее, чем команда, в которую входит 15% самых слабых сотрудников. Так что если нанять лучших и предоставить им оптимальные условия для работы, включая должным образом организованное общение с руководителями бизнеса, то это хоть и обойдется в каждом случае втрое дороже, но в конечном итоге даст намного более высокий результат.

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

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

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

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

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

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

Наконец, если проект поручается внешнему подрядчику, позаботиться о полном жизненном цикле разработки столь же необходимо, как и тогда, когда работу выполняют собственные программисты. В действительности это по меньшей мере вдвое важнее, поскольку необходимо учитывать два взаимосвязанных цикла. Впоследствии может потребоваться техническая поддержка или доработка приложений. Логично, если этим будут заниматься те же люди, которые выполнили первоначальную работу. Разумеется, при условии, что качество соответствует требованиям покупателя и что подрядчик найдет время для проведения дополнительных работ. В то же время, однако, может возникнуть необходимость в такой дополнительной работе, которая носит или слишком конфиденциальный характер или должна быть выполнена в слишком сжатые сроки, чтобы ее можно было доверить внешнему подрядчику. В таких случаях важно, чтобы у собственной команды программистов имелась под рукой вся необходимая интеллектуальная собственность.

Руководителям разработчиков некого винить, кроме самих себя, если привлечение внешних или офшорных программистов оборачивается предложением получить "меньше за меньшие деньги". Более того, в долгосрочном плане нереально надеяться на продолжающийся поток предложений большего за меньшие деньги. Хорошая цена - в долгосрочном плане - это оплата того, что вы получаете. А хорошие отношения с внешними подрядчиками - это такие, при которых ни одна сторона не будет неприятно удивлена ни тем, сколько было уплачено, ни тем, что было куплено.

С редактором по вопросам технологии Питером Коффи можно связаться по адресу: peter_coffee@ziffdavis.com.

Если вам есть что сказать по вопросам заказных разработок, присылайте свое мнение в PCWeek/RE по адресу: editorial@pcweek.ru.