?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Распределенная разработка и невероятная компания Codedgers

Posted on 2010.02.10 at 19:57
Tags: ,

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. Которой в привычной мне реальности просто не может существовать.

ЗЫ: И ведь как в воду глядел. :) Когда я коснулся юнит-тестов как способа контроля закрытия промежуточной задачи, рассматривая разные подходы к составлению плана работ, и показал, как в ряде случаев можно обойтись и без них, перегруппировав работы (ну, я в момент, когда это говорил, думал что говорю о большинстве случаев :) )– это спровоцировало ацкий флейм. :) У них юнит-тесты - это правило, оказывается. И появилось это правило не спроста. Специфика, знаете-ли, как всегда рулит.

С другой стороны – что это за тренинг без хорошего, доброго флейма? Это ж как свадьба без драки. :)

ЗЗЫ: Просто забавно. В Одессе Владимир, их директор, говорит мне, что срочно нужен тренер по паттернам, и спрашивает, не знаю ли я кого.
- Да нивапрос, - говорю, - позвоните Лене Арсеньевой из Карьерлаба. Номер я дам. Она попробует подобрать тренера. Скажете, что вы Владимир из Одессы, она знает, кто вы такой.
- Ах, я теперь уже из Одессы? - изумляется Владимир.
- А что, на самом деле - нет? - осторожно спрашиваю я.
- Ну, на самом деле, из Донецка, - уточняет он.
- Хм... - задумываюсь я, - Давайте вы лучше будете из Одессы! Тренера-то в Одессу надо, так? Зачем людей зазря путать?
- Хорошо, - улыбнулся Владимир, - Я буду из Одессы.


Comments:


zhiraffanjut
zhiraffanjut at 2010-02-10 17:05 (UTC) (Link)
Вау, неужели такое бывает?

Хочется увидеть таких ребят вживую.
schegloff
schegloff at 2010-02-10 17:19 (UTC) (Link)

Однако

До Вашей записи даже не подозревал, в каких сложных условиях мы работаем в своей скромной команде. Насчет юнит-тестов - отдельный респект.
Pavel Egorov
xoposhiy at 2010-02-10 18:41 (UTC) (Link)

Re: Однако

Полностью распределенная?! Блин! Опишите, как это работает! :-) Кросспост обещаю! :)))

PS. Я только сегодня переехал в одном офисе из одной комнаты в другую (соседнюю), чтобы быть ближе к людям с которыми предстоит работать. Вот на сколько я не верю в распределенную разработку. Короче очень интересно!

Edited at 2010-02-10 06:42 pm (UTC)
notacat
notacat at 2010-02-10 17:20 (UTC) (Link)
продолжение будет?
Gaperton
gaperton at 2010-02-11 23:14 (UTC) (Link)
Сделал продолжение. :) См. следующий пост.
Енотинька
raccoon at 2010-02-10 19:42 (UTC) (Link)
Aspose, Medialooks - из тех, с кем я сама сотрудничала.
Это компании с полностью удаленной и распределенной разработкой. Я тоже имею в виду, ПОЛНОСТЬЮ.
И что же в этом такого необычного?
i_love_python
i_love_python at 2010-02-11 07:24 (UTC) (Link)
хехе. для тех, кто не сталкивался раньше -- это необычно.
sleepy_drago at 2010-02-10 19:48 (UTC) (Link)
ну у нас промежуточный вариант - народ разбросан по 5 странам. Просто потому что в одном месте людей знающих что такое design rules checks для топологии микросхем просто не найти. а нанять студентов не решились. Но у нас нет понятия рейт и нет "лучших".
Скайп как форма жизни :) но все равно хреново.
Serguey Zefirov
thesz at 2010-02-10 22:19 (UTC) (Link)
Зачем у них unit-tests приняты?
i_love_python
i_love_python at 2010-02-11 07:22 (UTC) (Link)
Одно из назначений тестов -- описать как должен и не должен использовать тестируемый код. Так сказать примеры. Чтобы не дергать друг друга вопросами: а как в этом модуле...?
kin000 at 2010-02-11 01:10 (UTC) (Link)
в вакансиях на рсдн ру они предлагают 10 USD/час за C++ программинг
учитывая то, что я зарабатываю и зарабатывал 15-25 USD в час за "реально дубовый" PHP на удаленке это не выглядит, как "набор лучших" :)
Gaperton
gaperton at 2010-02-11 10:14 (UTC) (Link)
Налицо факт, что набор "лучших", вероятно, закончился - по крайней мере на РСДН :)

"- Пошлите лучших из лучших котов!
- Лучшие из лучших зализывают раны...
- Пошлите лучших из худших!"
Злобное чувырло
grau at 2010-02-11 06:06 (UTC) (Link)
> Они пользуются возможностью нанимать на работу лучших специалистов

Я может сейчас глупость скажу, но ИМХО, высокая квалификация сотрудников есть не только приятное следствие, но и необходимое условие этой самой распределенности.
Gaperton
gaperton at 2010-02-11 10:04 (UTC) (Link)
Это же хорошо, не правда-ли? Должно быть приятно работать с умными людьми :).

Кстати, изолированные задачи, не критичные для успеха софтины (появляются после успешного завершения проектирования, когда система с внутренними компонентами и интерфейсами более-менее устаканилась), вполне можно поручать и удаленным сотрудникам низкой квалификации.
i_love_python
i_love_python at 2010-02-11 07:21 (UTC) (Link)
Улыбнуло.

Есть такая фирма Canonical Ltd. Строгает всякую фигню и свой дистрибутив Линукса. У них команды еще больше по размеру и все распределенные и все тщательно подобранные. Так что в опен-сорсе есть гораздо больше таких успешных примеров.

Тесты + постоянное код ревью + постоянное общение в IRC и по телефону/скайпу + периодические спринты = главные компоненты их успха, если посмотреть со строны.
Gaperton
gaperton at 2010-02-11 10:07 (UTC) (Link)
Опыт опенсорса (в том числе "коммерческого опенсорса) полезный, но не релевантен, если разрабатывается что-то принципиально новое, а не строгается всякая фигня вокруг существующих сорцов.

Как мне пока кажется. Я, собственно, про это написал в тексте.
Записки PM'a
pmant at 2010-02-11 13:04 (UTC) (Link)
Интресно, как у них финансовые потоки устроены, если у них нет офиса, они вообще как юр. лицо существуют? ;)
i_love_python
i_love_python at 2010-02-11 13:37 (UTC) (Link)
вы спрашиваете про Codedgers или Canonical? (Выравнивание комментариев такое неудобное, что не понять где кому ответ).
mr Denis R.
homo_vitalis at 2010-02-11 22:51 (UTC) (Link)
История действительно башнесдвигающая! А вот интересно, возможно ли принципиально такое в вопросах, скажем, разработки бизнес-логики ERP-систем? Не движков таких систем, предельно универсальных и практически не зависящих от требований конкретного заказчика, а именно бизнес-логики с учетом всех особенностей бизнес-процессов?

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

Даже когда все - территориально рядом и доступны, трудно бывает усадить этих всех за один стол, чтобы они сначала договорились между собой, а потом и с другими, кто их договорённости в итоге реализует, а если представить, что каждый из них находится невесть где, то всё в итоге потонет в белом шуме :)

Всё-таки, наверное, или подобный подход хорош для тех случаев, когда хотя бы какое-то относительно длительное время можно работать в детерминированных условиях, или я ничего не понимаю про эту жизнь, что тоже весьма вероятно...
AndrewScater
andrewscater at 2010-02-13 09:39 (UTC) (Link)
извените, но я за свою жизнь работал и работаю в двух таких командах :)
Малень Лев - Властелин котів
akhavr at 2010-02-13 10:00 (UTC) (Link)
А что тут такого странного? Например, наша компания - 42 Coffee Cups - такой есть от рождения. Сейчас сидим в двух странах и четырёх-пяти городах.

Более того, практически каждый раз на "живой" встрече всплывает вопрос об офисе - и тут же умирает от встречного "кто там хочет сидеть?" :)

Так что распределённая коммерческая разработка становится скорее правилом чем исключением.
Gaperton
gaperton at 2010-02-15 11:54 (UTC) (Link)
Ну, расскажите тогда, как она у вас организована :). Если есть желание, конечно. Можно в своем ЖЖ длинным постом. Дам кросс-пост с комментариями.
vb_dev at 2010-08-26 09:45 (UTC) (Link)

Knowledge sharing и распределенная команда

Очень интересно как у вас происходит knowledge sharing? Какие активности выполняются с этой целью? Какие ограничения накладываются за счет распределенности команды?
Есть ли у вас понятие owner-а (владельца) какой-то части проекта? Как разрешаете связанными с этим риски (например, временное отсутствие owner-а, или уход из команды)?
Большое спасибо за релевантную информацию.
Previous Entry  Next Entry