Электронная коммерция. Страница 29.

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

Мелкие компании или просто физические лица, работающие по заказу, получают доход, с которого очень часто никаких налогов не платят. Работы же обычно ведутся в режиме “удаленного офиса”, а проще говоря, исполнители сидят по домам, что в свою очередь, сводит к нулю накладные расходы группы – на аренду помещений, электроэнергию и т.п. А это позволяет группа дэмпинговать: даже при условии высокой квалификации разработчиков группы час работы программиста в среднем обходится заказчику в 10 долларов в регионах и в 50 долларов Москве.

Впрочем, при всех выгодах и для заказчика, и для разработчика в схеме офшорного программирования есть несколько отрицательных сторон.

Прежде всего ни заказчик, ни исполнитель, особенно если совместная работа ведется впервые и стороны незнакомы, не могут быть до конца уверены друг в друге. Всегда есть вероятность, что заказчик окажется неплатежеспособным или не захочет платить наперед оговоренную сумму. С другой сторон, исполнитель может не справиться с поставленной задачей, или справиться не на должном уровне, или банально сорвать сроки.

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

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

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

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

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