Здравствуйте, Дмитрий В, Вы писали:

ДВ>Ну а кто в результате выиграл — тот, кто контору свою в результате основал, либо тот, кто сразу уменьшил гемморой, став наемным работником? Не получилось ли так, что уменьшив гемморой, люди сильно уменьшили свои возможности? И теперь из заработок определяет не спрос на программное обеспечение, а спрос на них как на специалистов?

Трудно сказать. Посмотрим через 10 лет, не исключено что люди, пришедшие сейчас как наемные работники, отпочкуются и обрастут своими конторами. У них еще все впереди. Отнюдь не факт что стадия "вольных художников" обязательна.

Здравствуйте, goldblueranger, Вы писали:

G>А как же логика? У неё есть законы, не нужно их игнорировать и превращать обсуждение сути в придирания к форме.

Хорошо. Влияние "человеческого фактора" Вам не кажется убедительным аргументом? А именно его я считаю главным в данном случае. Просто суть была заключена в форму рассказа о собственном опыте

G>Хотя уже много раз убеждался, что многие на форум ходят не многогранно обсудить проблему, а навязать свою точку зрения.

Давайте будем до конца откровенны. Я Вас не знаю, поэтому равнодушен к Вашему личному мнению, собственное ли оно будет или навязанное мной. Так какой смысл мне что-то Вам навязывать?

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, bkat, Вы писали:

B>>Это да. "Курилка" — это одно из самых эффективных мест обсуждения проблемы.
B>>"блог проекта, общий чат, лист рассылки" — это все можно воссоздать,
B>>но вот курилку нет

C0s>всё-таки, процесс надо строить так, что проблемы результата (понятная спецификация, качественный код, радостный заказчик) волновали людей существенно больше, чем удовлетворение эфемерных радостей курильщиков

Я в общем сторонник четких формальных процессов.
Хорошие спецификации, прошедшие через review — для меня это все.
Но со временем убедился, что неформальное общение тоже очень и очень важно.
Нет проблем после неформальных дискуссий в курилке накатать хороший документ.
Одно другому не мешает, а помогает...

Кстати, курилка — это образно. Я, кстати, не курю
Сидя за обеденным столом тоже время от времени кое какие вещи обсуждаем...

Здравствуйте, bkat, Вы писали:

B>Кстати, курилка — это образно. Я, кстати, не курю
B>Сидя за обеденным столом тоже время от времени кое какие вещи обсуждаем...

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

Здравствуйте, Michael Chelnokov, Вы писали:

MC>Здравствуйте, goldblueranger, Вы писали:

G>>А как же логика? У неё есть законы, не нужно их игнорировать и превращать обсуждение сути в придирания к форме.

MC>Хорошо. Влияние "человеческого фактора" Вам не кажется убедительным аргументом? А именно его я считаю главным в данном случае. Просто суть была заключена в форму рассказа о собственном опыте

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

Задача — чтобы первая чаша не перевешивала вторую. Как по мне — вполне решаемая.

> Держать плохого — убыток косвенный, но намного больше. А риск при наборе есть всегда — куда от него деться?
> А увольнять нужно за неделю-две, иначе — камень в огород организации процесса. (за него-то и приходиться расплачиваться 2 зарплатами)

Проблема в том, чтобы отличить человека, которого имеет смысл учить, от человека, которого надо увольнять. Две недели на это мало.

> S>Например, разработчик Вася злоупотребляет дефайнами. Его начальник Вова каждый раз, увидев #define там, где мог бы быть enum, восклицает "какой нехороший человек опять написал #define вместо enum'а". Разработчик Петя (студент), который сидит с ними в одной комнате, без каких либо затрат на коммуникации с ним запоминает, что не следует использовать #define вместо enum. Очевидно, что такую мелочь на митинги выносить не стоит — и в то же время подобных мелких вопросов набирается масса.
> А в чем проблема? Открываешь мессенджер или скайп и вперед, для этого совсем не обязательно общие митинги устраивать.

Я уже писал, в чем тут проблема.

>
> S>Чиркануть схемку на бумажке, показать коллеге, обсудить ее, признать негодной и выкинуть в разы быстрее, чем проделать то же, пользуясь Visio и электронной почтой.
> И здесь проблемы не вижу: бумажка-->сканер-->почта.

А ты попробуй. Потом расскажешь, во сколько раз больше это займет времени, по сравнению с личным общением.

> G>>Кроме того, не забывайте что в мире действительно много проектов ведется удалённо — взять Linux или Eclipse или MySQL.
>
> S>Потому что для этих проектов нет альтернативы — без удаленной разработки их вообще бы не было. Когда рабочее время бесплатно, его потери будут дешевле, чем затраты на аренду офиса и перемещение разработчиков в один город.
>
> Почему "бесплатно"? Очень даже платно.

Платным оно стало далеко не сразу. К тому времени менять сложившийся процесс смысла не было.

> G>>Кстати запрос 'Telecommuting' на dice.com выдаёт 665 ссылок — согласитесь тоже о чем-то говорит
>
> S>Это говорит только о том, что в некоторых случаях удаленная разработка считается более дешевой. Я же говорю о другом — о проблемах, имеющих место при удаленной разработке. Если бы этих проблем не было, ни одна компания не тратилась бы на аренду офисов — чего на практике не наблюдается (попробуйте, предложите гуглу или MS поработать на них удаленно).
>
> Наличие проблем не значит, что они непобедимы. Никто и не говорил, что удаленка — панацея от всех проблем.

Никто не говорит, также, что удаленка невозможна Просто alexandrST просил рассказать о проблемах.

Здравствуйте, Sergey, Вы писали:

S>Я уже писал, в чем тут проблема.
Читал по диагонали и не заметил.
По поводу отсутствовать, — должно быть требование о временных рамках в которых человек должен быть онлайн. А то, что человек может обидеться, — если он нормален и адекватен, и ты нормально себя ведешь, то я вообще не вижу здесь проблемы. Во всяком случае, мой опыт говорит о том, что такой проблемы нет, я с таким не сталкивался.


S>А ты попробуй. Потом расскажешь, во сколько раз больше это займет времени, по сравнению с личным общением.
Пробовал, нормально. Там еще хуже было — команда была многонациональная. Твои аргументы базируются ИМХО исключительно на привычках. Да, с одной стороны приходится гораздо больше писать, но с другой стороны, то, что ты написал — все остается, и через месяц или два ты спокойно можешь перечитать все записи (и не только ты, но и любой член команды), в скайпе можно вести записи технических разговоров, и если что-то забыл — легко можно прослушать еще раз. В плане коммуникации ИМХО проблем нет.
Но есть другие проблемы — доступ к высокотехнологичному оборудованию, конфиденциальность, более жесткие требования к личностным качествам удаленного сотрудника. Вот эти проблемы ИМХО и есть главными, которые не позволяют массово использовать удаленную разработку, а коммуникация между сотрудниками — не проблема на сегодня.

Здравствуйте, Игoрь, Вы писали:

И>конфиденциальность

а что упрощается в вопросах конфиденциальности в случае работы в офисе?
какая разница в том, как сотрудник получил доступ к конфиденциальной информации — удалённо или локально?

Здравствуйте, Игoрь, Вы писали:

И>Здравствуйте, Sergey, Вы писали:

S>>Я уже писал, в чем тут проблема.
И>Читал по диагонали и не заметил.
И>По поводу отсутствовать, — должно быть требование о временных рамках в которых человек должен быть онлайн.

Ага, он на месте, только провайдер профилактику проводит.

S>>А ты попробуй. Потом расскажешь, во сколько раз больше это займет времени, по сравнению с личным общением.
И>Пробовал, нормально. Там еще хуже было — команда была многонациональная. Твои аргументы базируются ИМХО исключительно на привычках. Да, с одной стороны приходится гораздо больше писать, но с другой стороны, то, что ты написал — все остается, и через месяц или два ты спокойно можешь перечитать все записи (и не только ты, но и любой член команды), в скайпе можно вести записи технических разговоров, и если что-то забыл — легко можно прослушать еще раз.

А оно мне нужно, смотреть отвергнутые спецификации, через месяц или два?

В плане коммуникации ИМХО проблем нет.
И>Но есть другие проблемы — доступ к высокотехнологичному оборудованию, конфиденциальность, более жесткие требования к личностным качествам удаленного сотрудника. Вот эти проблемы ИМХО и есть главными, которые не позволяют массово использовать удаленную разработку, а коммуникация между сотрудниками — не проблема на сегодня.

"более жесткие требования к личностным качествам удаленного сотрудника" — это ключевой момент. Придется либо увольнять больше народа, что приведет к убыткам, либо работать с теми, что есть, что приведет к проблемам, которые я уже описывал.

ST>Соответственно интересует мнение и советы специалистов по следующим направлениям (тех кто имеет опыт подобного рода

А вы продаете или покупаете? Это для начала.

ST>0. процесс разработки — какие инструменты сейчас имеются для удаленной разработки (желательно свободно распространяемые), а именно:

ST>- для управления процессом (планирование, назначение задач, контроль их выполнения, багтрекинг и т.п.)?

Для багтрекинга при удаленной разработке используются багтрекеры/issue тракеры. Сюрприз? Если еcть немножко денег, то Jira или Sourceforge, если нет — то traс, bugzilla, mantis

ST>- управления кодом (отслеживание изменений, поддержка версий, сборка и т.п.) ?

Для управления кодом при удаленной разработке используются системы контроля версий, для сборки — системы сборки.
Например, Subversion и make. Или bzr + setuptools

ST>имеются всмысле "используются нами"

Да, нами. Используются.

ST>1. есть ли какие-нибудь методологии, заточенные на удаленную разработку ? (даже если не методологии то такой своего рода набор рекомендаций что ли.)

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

сбор требований + планирование + проектирование + разработка + peer review + тестирование = итерация
конкретные этапы могут иметь различные конкретные реализации, но еще не одна нормальная методология от этого не ушла, как бы стремно (экстримально) она бы не выглядела.

ST>интересуют в первую очередь даже не отдельные инструменты а отзывы об опыте их использования в куче (аналогично с методологиями.)

еще раз — вы покупаете или продаете? если покупаете — это одно, если продаете — другое.
покупателям я бы не рекомендовал строить процессы внутри удаленной команды, а брать такую команду, которая эти процессы уже построила для себя и не мешать им работать.

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

ST>например, "мы используем jira + svn + trac + cruise control + ...потому что..."

ну например, с одной стороны мы используем bzr + moinmoin wiki + setuptools. Потому что просто, легковесно, дешево и сердито.

с другой стороны, мы используем jira + svn + ant + make, потому что jira у нас есть и она лучшая, svn потому что (а что еще? — ну я бы лично bzr бы использовал) он есть, ant + make потому что жизнь такая.

никакой разницы в этом с не удаленной разработкой тут нет.

ST>если найдется тот кто потратит время и распишет вкратце регламент разработки буду очень признателен.
ST>(т.е. какие "роли" есть в проекте, кто чем занимается, какие знания необходимы и т.д.)

ST>2. любые моменты которые неочевидны и важны.(и очевидные тоже )


ST>Наверняка есть какие-то подводные камни (такие тривиальные как кто-то кого-то кидает рассматривать не будем) — если о них расскажете то буду благодарен.

слишком общие вопросы. не на что отвечать.

попробуйте как-то сузить, например — мы покупаем, мы хотим X, у нас есть Y и Z, как лучше сделать, что бы X получился?

или мы продаем, хотим X', у нас есть Z. Как лучше добиться X' ?

тогда могу ответить более предметно.

ST>РСДНцы, неужели никто не занимается удаленной разработкой ?
Я занимаюсь. И покупаю, и продаю. Ставьте более конкретные вопросы, и будет вам счастье в виде внятных ответов.

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, Игoрь, Вы писали:

И>>конфиденциальность

C0s>а что упрощается в вопросах конфиденциальности в случае работы в офисе?
C0s>какая разница в том, как сотрудник получил доступ к конфиденциальной информации — удалённо или локально?
Во втором случае угроз больше. Во-первых, нужно предоставить доступ к внутренним ресурсам извне, во-вторых,
копия данных будет храниться на домашних компьютерах каждого удаленного сотрудника. Иногда в этом нет ничего страшного,
а иногда бывает и не приемлемо.

Здравствуйте, Sergey, Вы писали:

S>Ага, он на месте, только провайдер профилактику проводит.
Современные провайдеры вполне нормально работают. Когда я так работал, у меня было два провайдера — основной,
которому я платил 30$/мес и запасной на случай проблем с первым. Там я взял самый минимальный тариф за 5$/мес.
Причем, пользоваться запасным вариантом приходилось крайне редко, в среднем где-то один раз в месяц. Так что
можно было обойтись и без запаски.

S>А оно мне нужно, смотреть отвергнутые спецификации, через месяц или два?
Да ладно, возможность просмотреть разговор/обсуждение месячной или более давности зачастую очень удобная фича, особенно
если занимаешься несколькими проектами или несвязными частями проекта, и иногда банально забываешь на чем
там остановились.


S>"более жесткие требования к личностным качествам удаленного сотрудника" — это ключевой момент. Придется либо увольнять больше народа, что приведет к убыткам, либо работать с теми, что есть, что приведет к проблемам, которые я уже описывал.
Не, ну я и не спорю, что у удаленки риски выше. И тем не менее...
Лично для меня бы идеальным вариантом было что-то среднее между офисной и удаленной работой, например, один-два дня в неделю в офисе, а остальное — дома. По-моему, удобно.

Здравствуйте, Игoрь, Вы писали:

C0s>>а что упрощается в вопросах конфиденциальности в случае работы в офисе?
C0s>>какая разница в том, как сотрудник получил доступ к конфиденциальной информации — удалённо или локально?
И>Во втором случае угроз больше. Во-первых, нужно предоставить доступ к внутренним ресурсам извне, во-вторых,
И>копия данных будет храниться на домашних компьютерах каждого удаленного сотрудника. Иногда в этом нет ничего страшного,
И>а иногда бывает и не приемлемо.

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

Здравствуйте, Игoрь, Вы писали:

так, в этом месте разрешите поучаствовать в дискуссии, дальше ветку пока не читал

S>>Чиркануть схемку на бумажке, показать коллеге, обсудить ее, признать негодной и выкинуть в разы быстрее, чем проделать то же, пользуясь Visio и электронной почтой.
И>И здесь проблемы не вижу: бумажка-->сканер-->почта.
какой сканер, какая почта? вебкамеры нынче стоят рублей по 300, дальше объяснять куда бумажку со схемкой показывать? если нет вебкамеры, цифровик-то есть рядом? или телефон?

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

вообще толковые люди как правило способны донести свою мысль любым способом, хотя признаю что оформление по полной схеме — в доках с UML диаграммами — может иной раз оказаться по времени трудоемким делом. Но так на то профи и имеют уже опыт — способны оценивать на что стоит тратить время, а что требует обсуждения до того как начать высекать в камне. тем более если есть аудио канал и почта как следует из текста выше. так что тут смешивать действительно не надо — ОФис\Визио\Роза это одно, а обмен мнениями о том что туда нужно вносить это другое.

кстати, иногда переписка дисциплинирует как раз в плане написания фундаментальных вещей — набросков архитектуры и важных решений по реализации.

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

Да и потом сразу было бы ясно кто виноват и что более важно, как получилось что было худшее решение принято. Это не всегда очевидно по прошествии некоторого времени с момента митинга, где ЦУ были выданы в устной форме — с диктофонами не все еще ходят. У нас только управляющий разработкой продукта такими штучками балуется

мое мнение: никогда наличие\отсутствие технических девайсов для коммуникации не являлось определяющим фактором в успехе\провале (в т.ч. удаленного) проекта.

Но как отмазка в случае неуспеха используется вероятно всегда — надо же на что-то пенять? Вон, футболисты вечно мяч круглый и поле неровное приводят как причину пролета, хотя вторая команда вроде бы на том же поле и тем же мячом играла

Здравствуйте, bkat, Вы писали:

B>Это да. "Курилка" — это одно из самых эффективных мест обсуждения проблемы.
у нас курящих в девелопменте нет. и проблемы даже около кофе-машины, в чем-то выполняющей роль "курилки", как правило не обсуждаются — в силу менталитета и особенностей команды. Тем не менее не мешает достигать результата — в течении многих лет.

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

написал лишь для того чтобы отметить что "случаи всякие бывают", а так роль "курилки" а плане внутрикорпоративной культуры мне понятна и с ее значением совсем не спорю!