Ниже приводится мнение Петра Вайханского, руководителя американского представительства компании First Line Software. Он призывает ИТ-руководителей рассмотреть альтернативы аутсорсингу разработки исходного кода программного обеспечения.

Не отдавайте разработку своего ПО на аутсорсинг.

Да-да, вы правильно поняли. Я работаю на компанию, занимающуюся аутсорсингом разработки ПО, и я советую вам не отдавать ПО на аутсорсинг.

Руководитель одной из аутсорсинговых компаний указывает на риски и скрытые издержки, связанные с аутсорсингом. Однако есть один особенный, недооцененный пока метод…

Но почему? Все это делают. А все же не могут ошибаться, так? Все считают, что аутсорсинг экономит деньги за счет использования так называемого арбитража рабочей силы. Могут быть и другие факторы, но в большинстве своем компании отдают разработку ПО на аутсорсинг (особенно в офшор), стремясь получить на выходе больше ПО, возможно, быстрее, чем обычно, и за меньшие деньги.

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

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

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

Теперь представим, что вы уже прошли начальный этап передачи знаний. Ну что, может быть, вы уже экономите деньги? Вряд ли. В процессе разработки ПО налаженность коммуникаций — критически важный фактор. Иногда бывает достаточно трудно объяснить даже опытному специалисту, сидящему в той же комнате, что именно вам от него нужно. А теперь представьте, каково это, если человек, которому вы объясняете задачу, находится в тысячах километров от вас и общается с вами только по электронной почте или через чат, в крайнем случае по телефону или Skype.

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

А что можно сказать о возможности поставить на проект большее количество людей ? Например, вы опаздываете с выпуском продукта и хотите воспользоваться относительной дешевизной трудовых ресурсов в другой стране или регионе, чтобы успеть в срок. К сожалению, в этом случае вступает в действие так называемый закон Брукса. Согласно этому общеизвестному принципу, привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта , или, используя более красочное выражение Фреда Брукса, “девять женщин не смогут родить ребенка за месяц”. Даже если ваш проект еще укладывается в сроки, увеличение количества разработчиков на проекте не означает, что работа будет закончена быстрее. Учитывая сложности коммуникации, более крупная команда зачастую менее производительна. То есть, получить за те же деньги больше разработчиков можно, а вот окупятся это или нет в конечном продукте — большой вопрос.

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

И наконец, учитывайте потенциальный риск срыва проекта. Статистические сведения в этом отношении разнятся, но, в зависимости от источника, от 30 до 50% аутсорсинговых проектов кончились провалом: они либо были полностью списаны на убытки (а разработка в конечном итоге возвращена “вовнутрь”, за еще большие дополнительные расходы ), либо продемонстрировали функциональность или бизнес-результаты радикально ниже ожидаемого. Конечно, не все проекты, выполняемые силами штатных сотрудников, проходят гладко, но при аутсорсинге риск срыва намного выше.

Поэтому, пожалуйста, не отдавайте разработку ПО на аутсорсинг.

За исключением тех случаев, когда вам этого не избежать, или если вы используете Agile-методологии, а особенно — Scrum.

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

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

Появившийся под влиянием успеха системы производства, используемой компанией Toyota (Toyota Production System, или TPS) процесс Scrum был впервые описан в статье Джеффа Сазерленда и Кена Швабера, написанной для конференции в 1995 г. Scrum создан на основе нескольких фундаментальных принципов, включая разработку в виде малых субпроектов, присвоение приоритета различным блокам функциональности на основе их ценности для бизнеса, а также плотное и непосредственное взаимодействие с заказчиком на этапах планирования, разработки и приемки системы.

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

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

Джефф Сазерленд, который в данный момент консультирует руководство венчурного фонда OpenView Venture Partners в Бостоне и предоставляет тренинги представителям портфельных компаний фонда в области использования Agile методологий, рассказал мне, что он дает этим компаниям тот же самый совет: либо отдавать разработку на аусорсинг в компании, работающие по процессу Scrum, либо вообще не отдавать.

Стив Деннинг из Forbes называет Scrum важнейшим открытием в области менеджмента и настаивает на том, что его создатели должны были бы получить Нобелевскую премию по менеджменту, если бы таковая существовала. Может ли этот процесс действительно помочь вам преодолеть закон Брукса — увеличить количество ресурсов на проекте и ускорить, а не замедлить процесс разработки? Может ли он помочь вам писать качественное ПО, работая с аутсорсинговыми подрядчиками? Мой личный ответ на это вопрос — безапелляционное “Да”, но вам следует составить свое собственное мнение. Особенно, если вы уже отдаете разработку на аутсорсинг — мне кажется, вы не можете себе позволить не исследовать этот вопрос подробнее. Потому что я подозреваю, что ваши конкуренты это уже делают.