Распределенная разработка и невероятная компания Codedgers
24 января провел полнодневный тренинг для сотрудников компании Codedgers в Одессе. Для тренинга я попытался увязать воедино все свои материалы и представления о разработке ПО, и сделать главной целью тренинга определенный сдвиг мировоззрения слушателей “в правильную сторону”, чтобы они поняли главное, а детали смогли додумать самостоятельно. В результате получилось так, что “сдвинулось” мое мировоззрение, чего я не ожидал. :)
На тренинге было более 20 человек. Общее количество сотрудников в компании - 35 человек. Компания занимается низкоуровневым программированием - как заказной разработкой, так и продуктовой. В данный момент в процессе разработки находится несколько сложных, инновационных продуктов (мало общего с вебсайтами на заказ, собранными на коленке).
И что тут особенного, спросите вы? Дело в том, что Codedgers - необычная компания. Если вы вдруг подумаете, это обычная компания, как думал в начале я, знайте - вы глубоко заблуждаетесь. Потому, что они представляют собой то, чего, по мнению многих, попросту не может быть.
Codedgers - это хорошо организованная, сплоченная, и довольно большая группа профессионалов, прошедших тщательный отбор. Они выполняют сложные работы, требующие квалификации и координации, и все эти специалисты живут в разных городах и странах.
У них полностью удаленная и распределенная разработка. Я имею в виду, ПОЛНОСТЬЮ, понимаете? У них нет не только головного офиса, у них вообще никакого офиса нет.
Вы представляете, какие преимущества это дает? Умея работать полностью распределенно, они легко делают то, что, скорее всего, не может себе позволить ваша компания. Они пользуются возможностью нанимать на работу лучших специалистов, вне зависимости от того, где они живут, и хотят-ли они куда-то переезжать. И это для них штатный способ найма, а не подвиг.
На фоне этого, экономия на затратах на офис - это, в сущности, ерунда, не стоящая внимания. Хотя эта “ерунда” - важная часть того, что помогает иметь одновременно и высококвалифицированных сотрудников, и конкурентоспособный рейт для клиентов.
Ну преимущества-то понятны, непонятно одно - как работать-то в таких условиях можно вообще? :) Черт, как они это делают?! :) Поразительно.
Когда я узнал детали, а узнал я их уже по дороге в Одессу (где, как внезапно выяснилось, вовсе нет никакого офиса), я всерьез задумался о том, что именно я им буду рассказывать. Я подозревал, что многие мои методы по снижению “трения” в коммуникациях неявно предполагают превалирование личного контакта над написанием документов. По крайней мере о таком важном условии, как полная распределенность, я никогда не думал.
Ну, в принципе, не все так плохо, думал я, у меня все-таки есть богатый опыт работы в “распределенном офисе” в CQG. С другой стороны, полная распределенность меня все равно бросает в дрожь. Выбивает точку опоры нафиг.
Распределенная разработка по своей природе имеет более высокое “трение” в коммуникациях, чем работа в офисе. Более того, это “трение” принципиально неустранимо простыми способами, и требуются специальные методы чтобы работать в таких условиях.
Скажем, как с “трением” боролась ранняя CQG, с двумя офисами Москва-Денвер. Все сотрудники московского офиса отправлялись в длительную (несколько месяцев) командировку в штаты вскоре после найма, где работали в команде с американскими коллегами. Просто, чтобы познакомится, и притереться. Это раз. При старте серьезного проекта, вся команда также собирается в одном офисе - от нескольких дней до недель, где они вместе думают и проектируют. Это два. И наконец, есть плановые межофисные командировки на срок порядка недели - это три.
То есть, “трение” снижается посредством личного общения (ну, VCS+Issue Tracker+email - само собой, но это необходимость, а не лекарство). Это стоит дорого. Но могу заметить, что процедуры раннего CQG, автором которых был Ernest Popke, были потрясающе эффективны.
Но дело-то в том, что в случае полностью распределенной разработки эти меры мертвому припарка. В раннем CQG команды были разделены на две половинки, а тут… на 35. :) Здесь надо что-то еще. Определенная дисциплина работы с документами, технические средства, и бОльшие требования к процессам. Все это само по себе также вносит “трение”, что требует аккуратного подхода. Черт знает что.
Но постойте, все ж просто! Опен-сорс сообщество накопило огромный опыт именно в таком типе разработки. И вроде как все возможно, известно, легко, и фокуса особого тут нет!
Одна проблема. Как только речь заходит о коммерческой разработке, появляются интересные дополнительные требования…
…вроде того, что делать надо не что хочется, а то, что требуется.
…а что требуется, это не то же самое, что хочется, и это надо еще выяснить.
…а требуется то, что в одиночку не сделать, и на результаты работы одних будут полагаться другие программисты, что требует координации и договоренности.
…и все перечисленное - в разумные и предсказуемые сроки.
Короче, когда Линуса Торвальдса взяли в Трансмету, его сделали руководителем проекта, в расчете, что раз он координирует разработку ядра Линукс, то с более простым проектом он обязательно справится. Линус эпически не справился, о чем он пишет в своей книге “just for fun”.
“just for fun” естественным образом снижает “трение”. А коммерческая разработка - это “just for money”, и, если повезет, то “for fun and money”. И в этом суть разницы.
Так что опыт open source, хоть и ценен, но тоже не дает полного ответа…
Вот ехал я в поезде, и подозревал, что к тренингу не готов. Я был почти уверен, что многие посылки (причем - я затруднялся определить, какие именно) в моем тренинге будут противоречить реалиям такой невероятной компании, как Codedgers. Которой в привычной мне реальности просто не может существовать.
ЗЫ: И ведь как в воду глядел. :) Когда я коснулся юнит-тестов как способа контроля закрытия промежуточной задачи, рассматривая разные подходы к составлению плана работ, и показал, как в ряде случаев можно обойтись и без них, перегруппировав работы (ну, я в момент, когда это говорил, думал что говорю о большинстве случаев :) )- это спровоцировало ацкий флейм. :) У них юнит-тесты - это правило, оказывается. И появилось это правило не спроста. Специфика, знаете-ли, как всегда рулит.
С другой стороны - что это за тренинг без хорошего, доброго флейма? Это ж как свадьба без драки. :)
ЗЗЫ: Просто забавно. В Одессе Владимир, их директор, говорит мне, что срочно нужен тренер по паттернам, и спрашивает, не знаю ли я кого.
- Да нивапрос, - говорю, - позвоните Лене Арсеньевой из Карьерлаба. Номер я дам. Она попробует подобрать тренера. Скажете, что вы Владимир из Одессы, она знает, кто вы такой.
- Ах, я теперь уже из Одессы? - изумляется Владимир.
- А что, на самом деле - нет? - осторожно спрашиваю я.
- Ну, на самом деле, из Донецка, - уточняет он.
- Хм... - задумываюсь я, - Давайте вы лучше будете из Одессы! Тренера-то в Одессу надо, так? Зачем людей зазря путать?
- Хорошо, - улыбнулся Владимир, - Я буду из Одессы.