Границы удаленной разработкиКоманда
Основатель и руководитель компании "Грамант", специализирующейся на разработке высоконагруженных Интернет-систем. В основном занимается запуском новых проектов, аналитикой и маркетингом. Является со-основателем и тех. диром agritech стартапа Fertyle, автором нескольких патентов в области роботизации сельского хозяйства. До этого был научным сотрудником, финансовым разработчиком, главным архитектором и руководителем IT-филиала известной японской Интернет-компании. Участвовал в ее продаже Yahoo! и выводе на IPO.
Я руковожу разработческой командой, работающей в нише больших высоконагруженных систем последние 10 лет. Команда компактно расположена в Москве. Наши заказчики часто просят расширить команду за счет удаленных специалистов или вывести часть проекта на удаленку. Мы это делаем, хоть и с переменным успехом.
Для начала мы определимся с терминологией, обсудим, что такое распределенная разработка, что такое "удаленка", как все это связано с фрилансом. По нашему опыту возможность распределенной разработки, кроме зрелости процессов в команде, зависит от стадии проекта и от сложности разрабатываемой системы. Чем выше сложность системы, тем сложнее ее распределить. Меньше всего шансов вывести на удаленку большие высоконагруженные системы и embedded. При этом даже на сложном проекте отдельные функции или даже подразделения можно и нужно выводить на удаленку.
В докладе будет показано, какие распределенные конфигурации команды работают, какие – нет.
На слуху несколько компаний, например Basecamp или Automattic (разработчик WordPress), которые широко пиарят распределенную разработку. Мы знаем об этом, тем не менее, уверены, что вывод сложного проекта особенно в начальной стадии на удаленку – гарантия его провала. Мы проводим границы, за пределами которых удаленная разработка становится либо слишком накладной, либо, вообще, бессмысленной.