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

Я приехал в Гургаон разрабатывать интернет-магазин. E-commerce - новая для Индии тема, первые магазины масштаба страны здесь начали появляться около полутора лет назад. Компания, пригласившая меня сюда приехать, торгует косметикой, парфюмерией и разными модными аксессуарами. Начинали они по-простому - установили готовый движок Magento, кое-как его под себя настроили и стали продавать.

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

Однако, в какой-то момент ребятам стало тесно (в том числе и в маркетинговом смысле) в рамках Magento, сайт стал заметно тормозить, и они решили написать магазин с нуля на Node.JS. Квалифицированных разработчиков со знанием одновременно Node.JS, JavaScript и хорошим опытом серверного программирования в Индии днем с огнем ищут, поэтому решили поднапрячься и поставлять сотрудников из Европы. Я здесь второй европеец - первым был (и есть до сих пор - уедет только в августе) специалист из Болгарии.

В целом в компании работает около 160 человек (число меняется каждый день - магазин активно растет), 20 из которых - разработчики (или Tech Team, как нас здесь называют все остальные). Руководит разработчиками VP of Technology, а вся команда из 20 человек условно поделена на рабочие группы по четверо-пятеро программистов, в каждой из которых выделяют Tech Lead'а.

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

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

Целиком вся команда из 20 человек тоже собирается на "митинг", в пятницу вечером. Это совещание проводит, как правило, VP of Technology. Здесь, кроме уточнения текущего положения дел (что сделано за неделю, что в процессе, к чему предстоит приступить на следующей неделе), поднимаются вопросы бизнес-уровня. Такие "митинги" позволяют абсолютно всем разработчикам знать о том, что происходит в компании, какие новые задачи решают их коллеги и как они это делают. Каждый может активно высказывать свое мнение по любому вопросу. VP тоже пользуется случаем и транслирует все, что наболело за неделю и любые отзывы о работе, которые он за минувшую неделю получил от коллег из других департаментов. Однако, технические детали здесь обычно не рассматривают, иначе бы такие совещания длились часами.

Главная особенность разработки в этом интернет-магазине - принципиальное отсутствие дедлайнов. Ни одна задача не может иметь строго определенного дедлайна. Это позволяет разработчику полностью показывать свой потенциал, сосредоточиться на результате, а не на компромиссе между сроком и качеством.

Профессиональные эффективные менеджеры тут же придумают тьму минусов такого подхода.

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

Может случиться, что человек просто не хочет или не может работать, не понимает, чего от него хотят, ну и в целом неадекватен. А что убережет от этого в дедлайновом подходе?

Задачи, как и во многих "продуктовых" компаниях, ставит PM, Program Manager. Он собирает требования с внутренних заказчиков (специалистов по маркетингу, рекламе, каким-то конкретным товарным категориям), формулирует их в терминах продукта и доносит до Technology Team. PM - человек, одновременно пребывающий и в контексте разработки, и в контексте бизнеса. Для разработчиков он эксперт по бизнесу, ему можно задавать любые вопросы, связанные с предметной областью. И, в то же время, ему можно объяснить свое технологическое решение на привычном для программистов языке.

Отдельного отдела QA не существуют, тестируют все фичи и багфиксы сами разработчики. Перед релизом очередной версии сайта объявляется Testing Call - пару часов своего времени программисты должны уделить тестированию. Кроме того, все ошибки, которые случаются на боевом сервере, тут же попадают в систему мониторинга. За ней каждый день наблюдает следующий в очереди человек. Если случается какая-то проблема - транслирует ее коллегам. Получается, что работаем почти по модной методологии DevOps.

Отчасти поэтому, а отчасти из-за общего духа, настроя и идеи, всем в Technology Team говорят: "Ребята, мы работаем в стартапе". Здесь, разумеется, это слово не вызывает тех эмоций, которые привыкли испытывать в России. Но компания и действительно, по всем западным канонам, стартап. Она живет большей частью на инвесторские деньги, готовится ко второму раунду инвестиций, активно растет, развивается и набирает сотрудников.

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

http://mkazantsev.livejournal.com/135595.html