Но до того как TopCoder обратится к клиентам со своей необычной моделью разработки программного обеспечения, Хьюзу и его сотрудникам нужно было продумать метод разбиения задач на мельчайшие дискретные компоненты. «Мы с момента основания компании знали, что нам нужно будет разбивать крупные задачи на более мелкие, четко структурированные фрагменты», – говорит Хьюз. TopCoder отбирала программы, которые при обычном раскладе можно было разбить на сотню компонентов, и продумывала варианты, как их разбить на тысячу мелких задач. «Идея заключалась в том, что чем меньше “рабочий блок”, тем больше вариантов его последующего использования», – говорит Майкл Моррис, начальник отдела программного обеспечения TopCoder. Это казалось выгодным по многим соображениям. Во-первых, работа оказывается приспособленной к «свободному циклу» человека. А во-вторых, подход TopCoder увеличил скорость и эффективность работы. «Если бы у нас над проектом работало пять разработчиков, у них никогда не оставалось бы времени для использования модульной организации заданий, – говорит Моррис. – Им нужно было бы сначала закончить одно задание и только затем приниматься за другое. Теперь же у нас имеется неопределенное количество людей, одновременно работающих над одним заданием. Чем больше фрагментов мы получим в процессе разбиения, тем быстрее будет выполнена вся работа».
Хьюз и его компания полностью следовали сценарию краудсорсинга, за исключением того, что, конечно, ничего подобного в то время не существовало. В 2003 г. TopCoder была, по существу, единственной в своем роде компанией, использующей модель, которую Хьюз назвал «конкурентным сотрудничеством». На исправление ошибок потребовалось несколько лет. «Тогда не было краудсорсинга. Никакой мудрости “толпы”. Мы не применяли теорию, мы сами были научным экспериментом», – говорит Хьюз.
К началу 2006 г. TopCoder установила деловые отношения с несколькими клиентами и систематизировала процессы разработки. «Это был переломный момент. У нас было около 70 000 программистов, и мы посчитали, что этого достаточно для написания компьютерного кода в производственном масштабе, – говорит Хьюз. – Пожалуй, у нас были лучшие молодые программисты мира, конкурирующие друг с другом». Примерно тогда же Шри Котай, старший вицепрезидент компании AOL, отвечавший за разработку программного обеспечения, позвонил в TopCoder, чтобы договориться о встрече. «Парадокс заключался в том, что он даже не знал, что мы разрабатываем программное обеспечение, – вспоминает Моррис. – Котай просто хотел поговорить с нами об участии в некоторых соревнованиях». Вместо этого Моррис предложил Котаю, чтобы AOL использовал TopCoder для разработки нового программного обеспечения для компании. И показал ему, как проходят соревнования в режиме реального времени на сайте TopCoder. «Это не просто состязания, – сказал он Котаю. – Это будущие разработки программного обеспечения». Вскоре несколько сотрудников Котая уже сидели в офисе и слушали Морриса, рассказывавшего о модели, используемой TopCoder. В общем, все решил случай. «Когда-то давно Котай сам работал программистом, он понимал всю важность качественного кода». Вскоре после этой встречи AOL поручил TopCoder написать три программы: усовершенствовать систему электронной почты AOL, систему синдикации контента и программу для амбициозной серверной системы, которая позволила бы приложению интернет-пейджера корректно работать с другими IM-клиентами, такими как Google Talk и Yahoo Messenger.
Последнее задание стало самым серьезным тестом для TopCoder. Для начала Моррис назначил ответственного разработчика программного обеспечения и руководителя проекта. Это были единственные сотрудники TopCoder, занятые в проекте. Все остальное сделало сообщество. «Они разбили программу мгновенного обмена сообщениями на пятьдесят два компонента. Оказалось, что сообщество уже разработало часть компонентов. Если представить себе, что речь идет о кубиках Lego, из которых уже собирались другие фигурки, то оказалось, что двадцать два кубика к этому времени у нас уже были. Оставалось лишь собрать их в единое целое»47.