В настоящее время имеет место быть тенденция к удаленной разработке.
На мой (и не только) взгляд это направление имеет смысл интенсивно осваивать ввиду его несомненных выгод как для разработчиков так и для менеджеров. Т.е. необходимо осваивать инструменты и методологии для такой разработки.
Соответственно интересует мнение и советы специалистов по следующим направлениям (тех кто имеет опыт подобного рода):
0. процесс разработки — какие инструменты сейчас имеются для удаленной разработки (желательно свободно распространяемые), а именно:
— для управления процессом (планирование, назначение задач, контроль их выполнения, багтрекинг и т.п.)?
— управления кодом (отслеживание изменений, поддержка версий, сборка и т.п.) ?
и т.д. — т.е. любые полезные инструменты
имеются всмысле "используются нами"
1. есть ли какие-нибудь методологии, заточенные на удаленную разработку ? (даже если не методологии то такой своего рода набор рекомендаций что ли.)
интересуют в первую очередь даже не отдельные инструменты а отзывы об опыте их использования в куче (аналогично с методологиями.)
например, "мы используем jira + svn + trac + cruise control + ...потому что..."
если найдется тот кто потратит время и распишет вкратце регламент разработки буду очень признателен.
(т.е. какие "роли" есть в проекте, кто чем занимается, какие знания необходимы и т.д.)
2. любые моменты которые неочевидны и важны.(и очевидные тоже )
P.S. просто я подозреваю что хотя такая разработка достаточно сильно отличается от обычной офисной в лучшую сторону,
т.е. поскольку оплата фактически сдельная (если я правильно понимаю) то требования к коду
(оформление, инфраструктура (комментарии и тесты)) выше, что хорошо, но с другой стороны требования к разработчику и менеджеру (особенно) выше.
Наверняка есть какие-то подводные камни (такие тривиальные как кто-то кого-то кидает рассматривать не будем) — если о них расскажете то буду благодарен.
Здравствуйте, alexandrST, Вы писали:
ST>В настоящее время имеет место быть тенденция к удаленной разработке.
Что-то слабо такая тенденция наблюдается.
ST>На мой (и не только) взгляд это направление имеет смысл интенсивно осваивать ввиду его несомненных выгод как для разработчиков так и для менеджеров.
Абсолютное большинство менеджеров в России даже не подозревают о своей выгоде и по поводу удаленной работе свих сотрудникоы никакого энтузиазма не испытывают.
Здравствуйте, alexandrST, Вы писали:
ST>Доброго времени суток.
ST>В настоящее время имеет место быть тенденция к удаленной разработке. ST>На мой (и не только) взгляд это направление имеет смысл интенсивно осваивать ввиду его несомненных выгод как для разработчиков так и для менеджеров. Т.е. необходимо осваивать инструменты и методологии для такой разработки.
Кроме несомненных выгод у удаленной разработки есть и несомненные недостатки и боюсь, недостатки перевешивают.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Здравствуйте, alexandrST, Вы писали:
ST>>Доброго времени суток.
S>Кроме несомненных выгод у удаленной разработки есть и несомненные недостатки и боюсь, недостатки перевешивают.
Недостатки при удаленной разработке возникают из-за плохого project management'a.
Реалии у нас таковы, что хороших менеджеров у нас довольно мало, а управлять удаленной коммандой разработчиков на много сложнее — поэтому не хватает силенок у наших 'горе — манагеров'
убедительная просьба следить за объемом цитирования — модератор
_>Реалии у нас таковы, что хороших менеджеров у нас довольно мало, а управлять удаленной коммандой разработчиков на много сложнее — поэтому не хватает силенок у наших 'горе — манагеров'
А проблемы всегда в людях
То менеджеры не те, то программеры ленивы и неподконтрольны...
Проблема коммуникации на проектах очень непроста.
Именно по этой причине народ все же стараются собрать под одну крышу.
На западе, кстати, тоже...
А если еще и какое дополнительное обородувание нужно,
то об удаленке вообще можно не вспоминать.
Здравствуйте, white_znake, Вы писали:
S>>Кроме несомненных выгод у удаленной разработки есть и несомненные недостатки и боюсь, недостатки перевешивают.
_>Недостатки при удаленной разработке возникают из-за плохого project management'a.
_>Реалии у нас таковы, что хороших менеджеров у нас довольно мало, а управлять удаленной коммандой разработчиков на много сложнее — поэтому не хватает силенок у наших 'горе — манагеров'
Дело не в плохом менелжменте, а в человечьей психологии и модели общения. Когда 4 человека сидят в одной комнате и работают над одной подсистемой — каждый из них автоматически будет в курсе всех проблем коллег. Рассадите их в разные города — и вам понадобиться еще один человек, единственной работой которого будет координация усилий этих четверых. Причем мало того что у начальника после перехода на удаленную работу не останется времени на программирование, у вас еще и исчезнут горизонтальные связи внутри рабочей группы.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
РСДНцы, неужели никто не занимается удаленной разработкой ?
2 Michael Chelnokov — аргументируйте пожалуйста вашу позицию если считаете это возможным (время == деньги)
2 justinian — пока слабо. но думаю (это мое мнение) что за этим будущее.
2 Sergey — расскажите пожалуйста о недостатках.
По моему скромному мнению у удаленной разработки одни плюсы — при условии добросовестной работы всех участников команды.
Например, для разработчика что хорошо:
0.не нужно тратить время на дорогу.
Что дает около 2-х часов времени в среднем (считая что требуется 1 час чтобы доехать из дома до работы...у меня это 1.5. часа в лучшем случае) + можно обедать дома, а это еще минут 40 экономится. Если считать что в среднем программист стоит 12-15$ час то работа в офисе приносит в среднем около 40$ чистого убытка ежедневно. В случае если специалист квалифицирован эта цифра может быть гораздо больше.
т.е. я на работу трачу 11 часов в день (из которых рабочих 8). по-моему достаточно заманчивым выглядит увеличение этого рабочего времени (и соответственно) до 10 часов в день при тех же временных затратах
1.лучше условия работы что сказывается на производительности. например мне гораздо больше нравится сидеть дома, с открытым окном, в шортах и почесывать пузо нежели находится в "казарме" под продувающим кондером.
время работы — можно выбирать самому. например мне работается лучше всего утром и вечером ближе к ночи.
performance выше.
это все лирика конечно, но на производительности сказывается.
2. процесс разработки более строг, управляем и регламентируем.
что дает лучший контроль над состоянием и развитием системы.
да, это требует всестороннего анализа проблемы, хорошей методологии (надеюсь, правильно слово употребляю ), выработки грамотного ТЗ, грамотного опять же планирования, разбиения проблемы на "задания" с оценкой каждого задания по времени, чуткого высококвалифицированного управления процессом и т.д.
ну а в конце-то концов за что менеджеры деньги получают ? за переадресацию мэйлов в обе стороны ?
учиться нужно и расти
и от всех участников разработки будет требоваться дисциплина и добросовестность
(тут еще такой плюс как сдельная оплата. хочешь работать больше — работай больше, меньше — работай меньше.)
P.S. по поводу тенденции почему такая уверенность — посмотрите на объявления. там одни и те же вакансии на 2.5 — 3 K по нескольку месяцев висят. почитайте отчеты hh о востребованности специалистов с опытом работы.
сейчас насколько я понимаю специалистов на всех не хватает. ЗП везде примерно одни и те же. Компании различаются только задачами -> а удаленная работа на мой взгляд это дополнительное и очень весомое преимущество в борьбе за толковых людей.
P.P.S. а еще мне путешествовать нравится . в случае привязки к Office Space это возможно, но не в той мере как того хотелось бы. а в случае удаленки работа и отдых вещи не взаимоисключающие.
Здравствуйте, alexandrST, Вы писали:
ST>РСДНцы, неужели никто не занимается удаленной разработкой ?
лично я тебя всецело поддерживаю, с тем лишь уточнением, что под удалённой работой я склонен понимать некоторую близость к месту обсуждений/работы (офису и/или территории заказчика), чтобы при необходимости (обсуждение ТЗ, спецификаций, анализ требований, тестирование на спец.оборудовании и проч) можно было легко договориться с другими членами команды об одновременном присутствии в нужном месте
при этом такие этапы, как, собственно, кодирование, предварительные обсуждения, юнит-тестирование можно было бы делать и удалённо (т.е. сидя по домам)
как бы вопреки тому, что от меня хотели, на двух-трёх работах мне удавалось некоторые периоды работать из дома.
но это, к сожалению, в норму так и не вошло, хотя мой опыт свидетельствует о том, что при определённых условиях такая схема не только вполне рабочая, но и позволяет в течение более длительного, чем обычно, времени работать с интенсивностью выше средней без снижения качества
потом, для группы создателей ПО (программистов, тестировщиков) офис нужен всё равно, пусть даже и не для каждодневной работы. всё равно, на обсуждения собираться надо, потом, кому-то, наоборот, дома не работается (я и таких встречал), к тому же в офисе может быть установлено пресловутое спец. оборудование и/или спец.софт для интеграционного тестирования. поэтому затраты на офис, всё равно, остаются
насчёт всех остальных причин нераспространения светлой идеи "работы из дома" — здесь уже высказались.
Здравствуйте, alexandrST, Вы писали:
ST>Доброго времени суток. ST>[удалено]
Взять нового человека с улицы человека, удаленную работу, на испытательный срок, проблематично.
Не известно какой у него настрой на работу.
Когда человка видишь каждый день, лучше его узнаешь.
Здравствуйте, _Oleg_, Вы писали:
_O_>Здравствуйте, alexandrST, Вы писали:
ST>>Доброго времени суток. ST>>[удалено]
_O_>Взять нового человека с улицы человека, удаленную работу, на испытательный срок, проблематично. _O_>Не известно какой у него настрой на работу. _O_>Когда человка видишь каждый день, лучше его узнаешь.
Олег, на мой взгляд это как раз не проблема.
По моему скромному мнению, если человек качественно выполняет работу и при этом адекватен (не мешает другим людям из комманды выполнять свою работу) то я думаю не имеет значения какой у него "настрой" ( кстати что вы под этим понимаете ? ).
Критерий один — сделанная полезная работа.
Да, согласен. Коммуникация страдает. Но не всегда она настолько критична — всмысле не на всех этапах разработки.
Как справедливо (на мой взгляд) отметил С0s, есть задачи в которых очень желательно присутствие всех членов комманды (мозговой штурм), т.е. это решение ключевых вещей по проекту ("обсуждение ТЗ, спецификаций, анализ требований", обсуждение архитектуры, детализация направлений и задач и т.п. Так сказать "фаза исследования")
Под обсуждением я здесь понимаю именно обсуждение а не разработку.
Т.е. все эти замечательные вещи решает небольшая кучка высококвалифицированных людей и потом результаты их труда всем рассылаются для ознакомления, после чего все собираются и утверждают эти результаты (дополненные и измененные в соответствиями пожеланиями комманды).
Но после того как все обсуждено начинается кодирование и тестирование которое не требует постоянного нахождения всех в одной казарме.
(А оперативные вопросы вполне можно порешать по ICQ и телефону.)
И если все грамотно обсуждено то многочисленных критичных изменений, способных убить проект быть не должно
Офис конечно нужен. Чтоб было куда приглашать заказчиков, чтоб было где устанавливать сервера и "спец.оборудование", собираться и т.д. Не то чтобы необходим, но с офисом гораздо лучше чем без него.
Но необходимости присутсвия в офисе по 8 часов в день так точно нет.
0.5 — 1 раз в неделю по моему скромному мнению вполне достаточно.
2 Sergey
Про руководителя согласен отчасти. (у вас в оригинале "начальник", но я предпочитаю "руководитель" )
Любое руководство подразумевает в определенной степени отказ "от кодирования". Потому что когда человек кодит он погружен в какую-то подзадачу, "находится в контексте". А первичная задача руководителя на мой взгяд именно видеть картину в целом и "водить руками", указывая куда двигаться дальше.
"Тот, кто видит со стороны, смотрит восемью глазами"(Юдзан Дайдодзи, Будосесинсю)
ST>РСДНцы, неужели никто не занимается удаленной разработкой ?
ЗанимаЛСЯ. И я, и практически все мои знакомые программисты.
ST>2 Michael Chelnokov — аргументируйте пожалуйста вашу позицию если считаете это возможным
Пожалуйста.
Если вы посмотрите в мой профайл, то увидите что я из провинции. Скорее всего именно там вы и собираетесь себе искать "удаленных" сотрудников (в "центрах цивилизации" с этим будет еще хуже, т.к. у людей там существует намного больше возможностей найти себе куда более стабильное место, нежели случайные подработки). Так вот, возможности для "удаленной" работы у нас появились лет 10 назад, с приходом и более-менее доступностью инета (в более крупных городах это произошло еще на несколько лет раньше). Чем мы, собственно, и занялись. Во-первых, сразу же выяснилось что совмещать две работы практически нереально. Надо быть или полным задротом и ничего кроме монитора не видеть, или жертвовать одной из работ. Ладно, пожертвовали "основной". Далее выяснилось что работать, сидя по норам (дома) крайне неэффективно. Заметьте — мы жили в одном небольшом городе, проблемы с коммуникацией не возникало в принципе — телефоны и периодические собрания. Однако все же гораздо лучше стало, когда обосновались в офисе — работа пошла заметно эффективнее. Ну а раз уж офис, то уже и фирма. Через подобное прошли все знакомые мне местные программисты (а они мне знакомы практически все). Как вы думаете, что происходит с группой таких вот собравшихся вместе "вольных художников"? Очень быстро такая группа либо становится филиалом более крупной компании (де-юре, когда происходит "слияние", или де-факто, когда у группы 1-3 постоянных заказчика), либо сама вырастает до уровня самостоятельной компании с собственными проектами. И куда делась "удаленная разработка"? А нет её больше, давно пройденный этап.
Кстати, за последние несколько лет таких групп у нас больше не возникало. Молодежь предпочитает иметь стабильность со старта (т.е. работать в уже существующих фирмах), нежели рисковать и идти на вольные хлеба. Ну а у нас 10 лет назад такой возможности не было, поэтому приходилось рисковать.
Вот почему я и написал что вы опоздали на 10 лет. Время не то, у людей возможности другие.
Здравствуйте, alexandrST, Вы писали:
ST>Но после того как все обсуждено начинается кодирование и тестирование которое не требует постоянного нахождения всех в одной казарме.
Т.е. в итоге надо поддерживать 2 инфраструктуры.
Одну для коллективной работы в офисе (с кондишками, хорошими столами, помещениями и пр...)
и другую для кофмфортной работы дома.
Так где же тогда экономия? А нету ее на самом деле.
Получаются только одни дополнительные расходы
и только ради незначительной части работников, которые смогут выполнять рутинную работу дома.
Ну а потом, если посмотреть на статистику сколько вообще отнимает время именно кодирование,
то будет видно что все это того не стоит.
Т.е. в качестве исключений такое вполне возможно, но реально это только дополнительные проблемы...
Вот у нас один раз в неделю работает дома.
Решение проблем по аське наааамного медленнее, чем если он стоит рядом за моим компом.
Здравствуйте, alexandrST, Вы писали:
ST>По моему скромному мнению у удаленной разработки одни плюсы — при условии добросовестной работы всех участников команды.
Хорошее условие. Найдите команду таких идеальных людей.
ST>Например, для разработчика что хорошо:
ST>0.не нужно тратить время на дорогу.
Это да.
ST>1. ... это все лирика конечно, но на производительности сказывается.
Да, еще как сказывается. Только совсем не в ту сторону.
ST>2. процесс разработки более строг, управляем и регламентируем.
Ой ли? Расскажите это тем кто пытался управлять группой удаленных разработчиков.
Здравствуйте, _Oleg_, Вы писали:
_O_>Здравствуйте, alexandrST, Вы писали:
ST>>Доброго времени суток. ST>>[удалено]
_O_>Взять нового человека с улицы человека, удаленную работу, на испытательный срок, проблематично. _O_>Не известно какой у него настрой на работу. _O_>Когда человка видишь каждый день, лучше его узнаешь.
Вот что мне лично непонятно — почему многим видится большая проблема в том чтобы уволить человека результатами которого недоволен?
Вот схема, эфективная вне зависимости от того удаленка или нет:
void new_employee()
{
int warning_count = 0;
while (true)
{
Output output = get_next_task_done();
switch( measure( output ) )
{
case BAD_OUTPUT:
++warning_count;
if (warning_count>0)
{
say_bb();
retrun;
}
talk_to_employee();
break;
case PERFECT_OUTPUT:
increase_salary();
default:
--warning_count; // forget single warning with every task done
}
}
}
В этом случае у удаленки остаётся всего один недостаток — общение внутри команды. Видеоконференции и обязательные короткие ежедневные митинги помогут решить эту проблему. Согласен, что этого может хватать не всегда — на этот слуай можно снять конференс в гостинице за городом на неделю. Если такая необходимость слишком часто, то что-то нужно менять в организации работы, но это никак не связано с тем удаленная работа или нет. (Уверен, что есть частные случаи где такой вариант неприменим, но они всего лишь частные).
Да, еще. Я не сказал ни слова про заказчиков. Так вот, мало какой заказчик доверит свой проект (свои деньги) группе каких-то виртуальных товарищей. Ну разве что посредник, который разводит лоха-инвестора, а результат "работы" заведомо пойдет в корзину, о чем знают как посредник, так и работники.
У вас есть лишние деньги, которые вы хотите выбросить в корзину? Тогда мы идем к вам.
Здравствуйте, bkat, Вы писали:
B>Вот у нас один раз в неделю работает дома. B>Решение проблем по аське наааамного медленнее, чем если он стоит рядом за моим компом.
Т.е. я, как программист, не хочу со своим коллегой работать удаленно.
Ну разве только за существенную добавку к зарплате
Здравствуйте, bkat, Вы писали:
B>>Вот у нас один раз в неделю работает дома. B>>Решение проблем по аське наааамного медленнее, чем если он стоит рядом за моим компом.
B>Т.е. я, как программист, не хочу со своим коллегой работать удаленно. B>Ну разве только за существенную добавку к зарплате
ключевое слово — проблемы
мой опыт работы "из дома, близкого к офису" (я продолжаю называть это именно так вместо термина "удаленная работа", чтобы избежать путаницы и привлечения в качестве минусов аргументов типа "виртуальных людей из далёкого региона") кстати показал, что в ситуации, когда люди не создают проблем, то в целом работа идёт лучше
лучше здесь — сугубо субъективная оценка, которая, например, в последнем случае моего опыта выражается в том, что была написана масса грамотного работающего кода практически без привлечения тестеров — при том, что я как лид, не видел своих ребят неделями
если бы я постоянно тогда ездил бы в офис, я бы просто не успевал физически всё контролировать, сам бы писал меньше, плюс пришлось бы привлекать тестеров или отвлекаться на тестирование самим
ST>P.S. просто я подозреваю что хотя такая разработка достаточно сильно отличается от обычной офисной в лучшую сторону, ST>т.е. поскольку оплата фактически сдельная (если я правильно понимаю) то требования к коду ST>(оформление, инфраструктура (комментарии и тесты)) выше, что хорошо, но с другой стороны требования к разработчику и менеджеру (особенно) выше. ST>Наверняка есть какие-то подводные камни (такие тривиальные как кто-то кого-то кидает рассматривать не будем) — если о них расскажете то буду благодарен.
А вот мы уже с 1999 года удаленно работаем. С 2001 года пишем систему управления задачами, которую и используем для удаленной разработки: http://www.trackstudio.ru
Основные особенности такие:
1) Удаленка у нас добровальная, т.е. никто силой в офис не гонит, но и дома сидеть не заставляет. Просто кому-то удобнее работать в офисе (привычка, дома дети мешают), кому-то — дома (например, рабочий график смещен на выходные/ночь). Удаленные работники в нашем случае — это местные (смоленские) разработчики, которые просто предпочитают сидеть дома.
2) Внутренняя дисциплина работников очень важна — не всякий человек, который может работать в офисе будет хорошо работать дома. Хорошие девелоперы при прочих равных дома работают лучше, плохие — хуже.
3) Отсутствие жесткого графика и пинания частенько приводит к совместительствам со стороны работников, подработкой на офшор и т.п. Т.е. за счет свободного графика местные конторы нам в плане работников конкуренции не представляют, но вероятность сваливания на "в разы" большие деньги сильно растет. Думаю, больше половины офшорных контор в Смоленске организовали наши бывшие программисты
4) Все коммуникации должны вестись через систему управления задачами (мы TrackStudio используем). Если что-то идет мимо или человек привык, чтоб его пинали голосом/e-mail-ом — будет большой бардак. Один пример — я буквально месяц назад узнал ICQ всех удаленных работников, а телефонов многих не знаю до сих пор т.к. не нужно было: если человека нужно "пинать" альтернативными способами, то толку от него все равно не будет.
5) Разработчик сидит либо дома, либо в офисе. Вариант "хочу — приду на работу, хочу — буду дома сидеть" отсутствует.
6) Конторе с удаленной работы выгода такая:
— лучшие девелоперы за меньшие деньги
— на удаленщиков не нужны затраты на офис. Скажем, офис на 5 и 25 человек — это 2 большие разницы.
— удаленка очень формализует процессы даже в маленькой команде. Дисциплина порядком закрывания/тестирования багов, указанием номеров release и версий — железная.
убедительная просьба следить за объемом цитирования, следующий подобный экзерсис может повлечь за собой санкции согласно правил форума — модератор
S>Дело не в плохом менелжменте, а в человечьей психологии и модели общения. Когда 4 человека сидят в одной комнате и работают над одной подсистемой — каждый из них автоматически будет в курсе всех проблем коллег. Рассадите их в разные города — и вам понадобиться еще один человек, единственной работой которого будет координация усилий этих четверых. Причем мало того что у начальника после перехода на удаленную работу не останется времени на программирование, у вас еще и исчезнут горизонтальные связи внутри рабочей группы.
Мне кажется, что вы тут смешиваете три момента.
1. Быть в курсе проблем друг друга — ежедневные митинги.
2. Про вертикальные связи — они хоть их и намного проще поддерживать сидением в одной комнате, однако это не является ни необходимым, ни достаточным.
3. Про координацию усилий членов команды — она должна опять же быть всегда, вне зависимости от типа разработки. Конечно, когда все под рукой координировать несколько легче; но уверен, что (в 99%) если у команды нет проблем с координацией работы в офисе, у них не будет проблем и удаленно.
Кроме того, не забывайте что в мире действительно много проектов ведется удалённо — взять Linux или Eclipse или MySQL.
Кстати запрос 'Telecommuting' на dice.com выдаёт 665 ссылок — согласитесь тоже о чем-то говорит
Здравствуйте, goldblueranger, Вы писали:
G>Вот что мне лично непонятно — почему многим видится большая проблема в том чтобы уволить человека результатами которого недоволен?
Потому что увольнять сотрудника — прямой убыток. Месяц-другой он въезжал в тему, еще через месяц выяснилось, что толку от него значительно меньше, чем хотелось бы. Итого 1-2 зарплаты на ветер, работа сделана или наполовину, или, хуже того, ее надо переделывать.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, alexandrST, Вы писали:
ST>Под обсуждением я здесь понимаю именно обсуждение а не разработку.
Непосредственно при разработке постоянно приходится принимать кучу технических решений разной степени сложности и важности.
ST>Т.е. все эти замечательные вещи решает небольшая кучка высококвалифицированных людей и потом результаты их труда всем рассылаются для ознакомления, после чего все собираются и утверждают эти результаты (дополненные и измененные в соответствиями пожеланиями комманды). ST>Но после того как все обсуждено начинается кодирование и тестирование которое не требует постоянного нахождения всех в одной казарме. ST>(А оперативные вопросы вполне можно порешать по ICQ и телефону.)
В том то и дело, что при кодировании коммуникации тоже важны. Если я вижу в проекте негодный код, мне не лень поругаться на сидящего рядом коллегу — при этом он не обидится и для дела польза будет. Те же слова по аське или скайпу мне во-первых лень печатать/звонить (да и человек может в этот момент отсутствовать), во-вторых через коммуникации те же слова воспринимаются иногда совершенно по другому — не как дружеская конструктивная критика, а как наезд (просто на подсознательном уровне — раз человек не поленился из-за такой мелочи отрываться от своих дел и многабукав набирать — значит сильно разозлился).
ST>2 Sergey ST>Про руководителя согласен отчасти. (у вас в оригинале "начальник", но я предпочитаю "руководитель" ) ST>Любое руководство подразумевает в определенной степени отказ "от кодирования". Потому что когда человек кодит он погружен в какую-то подзадачу, "находится в контексте". А первичная задача руководителя на мой взгяд именно видеть картину в целом и "водить руками", указывая куда двигаться дальше.
В примере было всего 4 человека. Выделенный руководитель на такую мелкую команду во-первых чересчур дорог, во-вторых, если он сам код не пишет, то не сможет руководить, т.е. подсказывать пути решения конкретных технических проблем.
Еще кстати есть проблема распространения изменений. Забрал я допустим новую версию того же boost, пропатчил там кой-чего, пересобрал. После этого в случае локальной разработки просто сложил результат на сервер, а в случае распределенной мне придется рассылать много мегабайт каждому коллеге — либо рассылать мало мегабайт, но все равно рассылать, плюс всем им придется тратить кучу времени на сборку буста.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Здравствуйте, goldblueranger, Вы писали:
G>>Вот что мне лично непонятно — почему многим видится большая проблема в том чтобы уволить человека результатами которого недоволен?
S>Потому что увольнять сотрудника — прямой убыток. Месяц-другой он въезжал в тему, еще через месяц выяснилось, что толку от него значительно меньше, чем хотелось бы. Итого 1-2 зарплаты на ветер, работа сделана или наполовину, или, хуже того, ее надо переделывать.
Держать плохого — убыток косвенный, но намного больше. А риск при наборе есть всегда — куда от него деться?
А увольнять нужно за неделю-две, иначе — камень в огород организации процесса. (за него-то и приходиться расплачиваться 2 зарплатами)
Здравствуйте, Michael Chelnokov, Вы писали:
MC>Здравствуйте, alexandrST, Вы писали:
ST>>РСДНцы, неужели никто не занимается удаленной разработкой ?
MC>ЗанимаЛСЯ. И я, и практически все мои знакомые программисты.
ST>>2 Michael Chelnokov — аргументируйте пожалуйста вашу позицию если считаете это возможным
MC>Пожалуйста. MC>Если вы посмотрите в мой профайл [skipped]
Ага, "все мужики сволочи — я знала одного такого"
Как сказал по-моему Аристотель "ни один пример не может доказать истинность высказывания, но достаточно одного контрпримера, чтобы опровергнуть".
У вас же просили "аргументацию"...
Здравствуйте, Michael Chelnokov, Вы писали: MC>Кстати, за последние несколько лет таких групп у нас больше не возникало. Молодежь предпочитает иметь стабильность со старта (т.е. работать в уже существующих фирмах), нежели рисковать и идти на вольные хлеба. Ну а у нас 10 лет назад такой возможности не было, поэтому приходилось рисковать. MC>Вот почему я и написал что вы опоздали на 10 лет. Время не то, у людей возможности другие.
Ну а кто в результате выиграл — тот, кто контору свою в результате основал, либо тот, кто сразу уменьшил гемморой, став наемным работником? Не получилось ли так, что уменьшив гемморой, люди сильно уменьшили свои возможности? И теперь из заработок определяет не спрос на программное обеспечение, а спрос на них как на специалистов?
Здравствуйте, goldblueranger, Вы писали:
G>Мне кажется, что вы тут смешиваете три момента. G>1. Быть в курсе проблем друг друга — ежедневные митинги.
Например, разработчик Вася злоупотребляет дефайнами. Его начальник Вова каждый раз, увидев #define там, где мог бы быть enum, восклицает "какой нехороший человек опять написал #define вместо enum'а". Разработчик Петя (студент), который сидит с ними в одной комнате, без каких либо затрат на коммуникации с ним запоминает, что не следует использовать #define вместо enum. Очевидно, что такую мелочь на митинги выносить не стоит — и в то же время подобных мелких вопросов набирается масса.
G>2. Про вертикальные связи — они хоть их и намного проще поддерживать сидением в одной комнате, однако это не является ни необходимым, ни достаточным. G>3. Про координацию усилий членов команды — она должна опять же быть всегда, вне зависимости от типа разработки. Конечно, когда все под рукой координировать несколько легче; но уверен, что (в 99%) если у команды нет проблем с координацией работы в офисе, у них не будет проблем и удаленно.
Чиркануть схемку на бумажке, показать коллеге, обсудить ее, признать негодной и выкинуть в разы быстрее, чем проделать то же, пользуясь Visio и электронной почтой.
G>Кроме того, не забывайте что в мире действительно много проектов ведется удалённо — взять Linux или Eclipse или MySQL.
Потому что для этих проектов нет альтернативы — без удаленной разработки их вообще бы не было. Когда рабочее время бесплатно, его потери будут дешевле, чем затраты на аренду офиса и перемещение разработчиков в один город.
G>Кстати запрос 'Telecommuting' на dice.com выдаёт 665 ссылок — согласитесь тоже о чем-то говорит
Это говорит только о том, что в некоторых случаях удаленная разработка считается более дешевой. Я же говорю о другом — о проблемах, имеющих место при удаленной разработке. Если бы этих проблем не было, ни одна компания не тратилась бы на аренду офисов — чего на практике не наблюдается (попробуйте, предложите гуглу или MS поработать на них удаленно).
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Здравствуйте, goldblueranger, Вы писали:
G>>Кроме того, не забывайте что в мире действительно много проектов ведется удалённо — взять Linux или Eclipse или MySQL.
S>Потому что для этих проектов нет альтернативы — без удаленной разработки их вообще бы не было. Когда рабочее время бесплатно, его потери будут дешевле, чем затраты на аренду офиса и перемещение разработчиков в один город.
Почему "бесплатно"? Очень даже платно.
G>>Кстати запрос 'Telecommuting' на dice.com выдаёт 665 ссылок — согласитесь тоже о чем-то говорит
S>Это говорит только о том, что в некоторых случаях удаленная разработка считается более дешевой. Я же говорю о другом — о проблемах, имеющих место при удаленной разработке. Если бы этих проблем не было, ни одна компания не тратилась бы на аренду офисов — чего на практике не наблюдается (попробуйте, предложите гуглу или MS поработать на них удаленно).
Наличие проблем не значит, что они непобедимы. Никто и не говорил, что удаленка — панацея от всех проблем.
Здравствуйте, goldblueranger, Вы писали:
G>Вот что мне лично непонятно — почему многим видится большая проблема в том чтобы уволить человека результатами которого недоволен?
потому что после определенного количетсва увольнений уволят тебя самого.
Здравствуйте, alexandrST, Вы писали:
ST>2. любые моменты которые неочевидны и важны.(и очевидные тоже )
Момент неочевидный, первый:
Процесс должен быть достаточно формальный, иначе бардак наступит гораздо раньше чем при офисной разработке.
Каким быть процессу, зависит от того чем вы занимаетесь и общих рекомендаций здесь нет. Основной критерий качества процесса: в любой момент ты можешь сказать, кто чем занимается и сколько ему осталось. Если не чувствуешь в себе сил создать процесс под себя сам, обратись к консультанту.
Момент неочевидный, второй:
Удаленный процесс отличается от офисного, в том числе и психологически. Поэтому привычные офисные стереотипы следует выкинуть на помойку. Попробуй представить, что твоему ведущему разработчику 13 лет и с 0800 до 1300 он занимается в школе. Если не получается, значит удаленная разработка не для тебя. Есть менеджеры, которые любят контролировать каждую мелочь: как сотрудник выглядит, где живет, с кем спит, в чем ходит, сколько работает. При удаленной работе все это не важно, поскольку единственное что можно контроллировать это результат.
Момент неочевидный, третий:
В офисе по умолчанию присутствует некоторая "информационная среда", которую в слчае удаленной работы нужно создавать.
Это могут быть блог проекта, общий чат, лист рассылки и т.п. Именно в эту среду коллеги будут выплескивать возмущение по поводу
кучи define вместо enum. Почему-то, об этой среде многие напрочь забывают, когда пытаются создать распределенную команду.
Момент неочевидный, четвертый:
Начинать проект сразу силами распределенной команды нельзя, погрязнете в спорах и согласованиях. Нужен талантливый архитектор, способный в одиночку изготовить прототип и задать направление всей команде. Желательно, если с архитектором вы будете общаться лично.
Момент неочевидный, пятый:
Поскольку коммуникации дороги, их нужно минимизировать. Для этого тоже поребуется архитектор, способный распределить задачи так, чтобы они минимально пересекались между собой и запланировать глобальные рефакоринги так, чтобы затронуть как можно меншее число людей. Кроме того, для этого потребуется документация, значит тебе прийдется заставить людей писать хоты бы codedoc, а архитекора design notes.
Исходя из этого я бы предположил следующее распределение ролей в команде:
"Менеджер" -- взаимодействие с заказчиком, аналитика, постановка задач.
"Архитектор" -- разрабатывает дизайн системы, согласует интерфейсы, разрабатывает общие библиотеки, консультирует разработчиков, проводит code review, контроллирует технические риски.
"Лидер" -- администрирует рабочую среду, решает организационные вопросы, контроллирует организационные риски.
"Разработчики" -- собственно разработка, GUI дизайн, техрайтинг, QA, и т.п. в пределах специализации.
Здравствуйте, Sergey, Вы писали:
S>Например, разработчик Вася злоупотребляет дефайнами. Его начальник Вова каждый раз, увидев #define там, где мог бы быть enum, восклицает "какой нехороший человек опять написал #define вместо enum'а". Разработчик Петя (студент), который сидит с ними в одной комнате, без каких либо затрат на коммуникации с ним запоминает, что не следует использовать #define вместо enum. Очевидно, что такую мелочь на митинги выносить не стоит — и в то же время подобных мелких вопросов набирается масса.
А в чем проблема? Открываешь мессенджер или скайп и вперед, для этого совсем не обязательно общие митинги устраивать.
S>Чиркануть схемку на бумажке, показать коллеге, обсудить ее, признать негодной и выкинуть в разы быстрее, чем проделать то же, пользуясь Visio и электронной почтой.
И здесь проблемы не вижу: бумажка-->сканер-->почта.
Здравствуйте, Miroff, Вы писали:
M>Момент неочевидный, третий: M>В офисе по умолчанию присутствует некоторая "информационная среда", которую в слчае удаленной работы нужно создавать. M>Это могут быть блог проекта, общий чат, лист рассылки и т.п. Именно в эту среду коллеги будут выплескивать возмущение по поводу M>кучи define вместо enum. Почему-то, об этой среде многие напрочь забывают, когда пытаются создать распределенную команду.
Это да. "Курилка" — это одно из самых эффективных мест обсуждения проблемы.
"блог проекта, общий чат, лист рассылки" — это все можно воссоздать,
но вот курилку нет
Здравствуйте, goldblueranger, Вы писали:
G>Как сказал по-моему Аристотель "ни один пример не может доказать истинность высказывания, но достаточно одного контрпримера, чтобы опровергнуть".
Да, Аристотель был идеалистом и предпочитал сферических коней в вакууме. Мы же имеем дело с реальными живыми людьми (которые, кстати, не увольняются по псевдокоду), со всеми их достоинствами и недостатками.
Здравствуйте, bkat, Вы писали:
B>Это да. "Курилка" — это одно из самых эффективных мест обсуждения проблемы. B>"блог проекта, общий чат, лист рассылки" — это все можно воссоздать, B>но вот курилку нет
всё-таки, процесс надо строить так, что проблемы результата (понятная спецификация, качественный код, радостный заказчик) волновали людей существенно больше, чем удовлетворение эфемерных радостей курильщиков
Здравствуйте, Michael Chelnokov, Вы писали:
MC>Здравствуйте, goldblueranger, Вы писали:
G>>Как сказал по-моему Аристотель "ни один пример не может доказать истинность высказывания, но достаточно одного контрпримера, чтобы опровергнуть".
MC>Да, Аристотель был идеалистом и предпочитал сферических коней в вакууме. Мы же имеем дело с реальными живыми людьми (которые, кстати, не увольняются по псевдокоду), со всеми их достоинствами и недостатками.
А как же логика? У неё есть законы, не нужно их игнорировать и превращать обсуждение сути в придирания к форме.
Хотя уже много раз убеждался, что многие на форум ходят не многогранно обсудить проблему, а навязать свою точку зрения.
Здравствуйте, Дмитрий В, Вы писали:
ДВ>Ну а кто в результате выиграл — тот, кто контору свою в результате основал, либо тот, кто сразу уменьшил гемморой, став наемным работником? Не получилось ли так, что уменьшив гемморой, люди сильно уменьшили свои возможности? И теперь из заработок определяет не спрос на программное обеспечение, а спрос на них как на специалистов?
Трудно сказать. Посмотрим через 10 лет, не исключено что люди, пришедшие сейчас как наемные работники, отпочкуются и обрастут своими конторами. У них еще все впереди. Отнюдь не факт что стадия "вольных художников" обязательна.
Здравствуйте, goldblueranger, Вы писали:
G>А как же логика? У неё есть законы, не нужно их игнорировать и превращать обсуждение сути в придирания к форме.
Хорошо. Влияние "человеческого фактора" Вам не кажется убедительным аргументом? А именно его я считаю главным в данном случае. Просто суть была заключена в форму рассказа о собственном опыте
G>Хотя уже много раз убеждался, что многие на форум ходят не многогранно обсудить проблему, а навязать свою точку зрения.
Давайте будем до конца откровенны. Я Вас не знаю, поэтому равнодушен к Вашему личному мнению, собственное ли оно будет или навязанное мной. Так какой смысл мне что-то Вам навязывать?
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, bkat, Вы писали:
B>>Это да. "Курилка" — это одно из самых эффективных мест обсуждения проблемы. B>>"блог проекта, общий чат, лист рассылки" — это все можно воссоздать, B>>но вот курилку нет
C0s>всё-таки, процесс надо строить так, что проблемы результата (понятная спецификация, качественный код, радостный заказчик) волновали людей существенно больше, чем удовлетворение эфемерных радостей курильщиков
Я в общем сторонник четких формальных процессов.
Хорошие спецификации, прошедшие через review — для меня это все.
Но со временем убедился, что неформальное общение тоже очень и очень важно.
Нет проблем после неформальных дискуссий в курилке накатать хороший документ.
Одно другому не мешает, а помогает...
Кстати, курилка — это образно. Я, кстати, не курю
Сидя за обеденным столом тоже время от времени кое какие вещи обсуждаем...
Здравствуйте, bkat, Вы писали:
B>Кстати, курилка — это образно. Я, кстати, не курю B>Сидя за обеденным столом тоже время от времени кое какие вещи обсуждаем...
уж сколько раз я убеждался, что за обедом лучше кушать, после чего еще на час оставить поевших людей в покое
Здравствуйте, Michael Chelnokov, Вы писали:
MC>Здравствуйте, goldblueranger, Вы писали:
G>>А как же логика? У неё есть законы, не нужно их игнорировать и превращать обсуждение сути в придирания к форме.
MC>Хорошо. Влияние "человеческого фактора" Вам не кажется убедительным аргументом? А именно его я считаю главным в данном случае. Просто суть была заключена в форму рассказа о собственном опыте
ОК
Согласен, что ЧФ присутствует. Он присутствует всегда и вполне может стать решающим в удаленной разработке.
То есть на одной чаше весов — доп. усилия по поддержке горизонтальных связей при удаленном общении (и вертикальных, но это проще),
а на другой — различные бенефиты (экономия на офисе, на дороге, на организации времени, большая свобода в пространстве — три последних может помочь привлечь высококлассных профи).
Задача — чтобы первая чаша не перевешивала вторую. Как по мне — вполне решаемая.
> Держать плохого — убыток косвенный, но намного больше. А риск при наборе есть всегда — куда от него деться? > А увольнять нужно за неделю-две, иначе — камень в огород организации процесса. (за него-то и приходиться расплачиваться 2 зарплатами)
Проблема в том, чтобы отличить человека, которого имеет смысл учить, от человека, которого надо увольнять. Две недели на это мало.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
> S>Например, разработчик Вася злоупотребляет дефайнами. Его начальник Вова каждый раз, увидев #define там, где мог бы быть enum, восклицает "какой нехороший человек опять написал #define вместо enum'а". Разработчик Петя (студент), который сидит с ними в одной комнате, без каких либо затрат на коммуникации с ним запоминает, что не следует использовать #define вместо enum. Очевидно, что такую мелочь на митинги выносить не стоит — и в то же время подобных мелких вопросов набирается масса. > А в чем проблема? Открываешь мессенджер или скайп и вперед, для этого совсем не обязательно общие митинги устраивать.
Я уже писал, в чем тут проблема.
> > S>Чиркануть схемку на бумажке, показать коллеге, обсудить ее, признать негодной и выкинуть в разы быстрее, чем проделать то же, пользуясь Visio и электронной почтой. > И здесь проблемы не вижу: бумажка-->сканер-->почта.
А ты попробуй. Потом расскажешь, во сколько раз больше это займет времени, по сравнению с личным общением.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
> G>>Кроме того, не забывайте что в мире действительно много проектов ведется удалённо — взять Linux или Eclipse или MySQL. > > S>Потому что для этих проектов нет альтернативы — без удаленной разработки их вообще бы не было. Когда рабочее время бесплатно, его потери будут дешевле, чем затраты на аренду офиса и перемещение разработчиков в один город. > > Почему "бесплатно"? Очень даже платно.
Платным оно стало далеко не сразу. К тому времени менять сложившийся процесс смысла не было.
> G>>Кстати запрос 'Telecommuting' на dice.com выдаёт 665 ссылок — согласитесь тоже о чем-то говорит > > S>Это говорит только о том, что в некоторых случаях удаленная разработка считается более дешевой. Я же говорю о другом — о проблемах, имеющих место при удаленной разработке. Если бы этих проблем не было, ни одна компания не тратилась бы на аренду офисов — чего на практике не наблюдается (попробуйте, предложите гуглу или MS поработать на них удаленно). > > Наличие проблем не значит, что они непобедимы. Никто и не говорил, что удаленка — панацея от всех проблем.
Никто не говорит, также, что удаленка невозможна Просто alexandrST просил рассказать о проблемах.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Я уже писал, в чем тут проблема.
Читал по диагонали и не заметил.
По поводу отсутствовать, — должно быть требование о временных рамках в которых человек должен быть онлайн. А то, что человек может обидеться, — если он нормален и адекватен, и ты нормально себя ведешь, то я вообще не вижу здесь проблемы. Во всяком случае, мой опыт говорит о том, что такой проблемы нет, я с таким не сталкивался.
S>А ты попробуй. Потом расскажешь, во сколько раз больше это займет времени, по сравнению с личным общением.
Пробовал, нормально. Там еще хуже было — команда была многонациональная. Твои аргументы базируются ИМХО исключительно на привычках. Да, с одной стороны приходится гораздо больше писать, но с другой стороны, то, что ты написал — все остается, и через месяц или два ты спокойно можешь перечитать все записи (и не только ты, но и любой член команды), в скайпе можно вести записи технических разговоров, и если что-то забыл — легко можно прослушать еще раз. В плане коммуникации ИМХО проблем нет.
Но есть другие проблемы — доступ к высокотехнологичному оборудованию, конфиденциальность, более жесткие требования к личностным качествам удаленного сотрудника. Вот эти проблемы ИМХО и есть главными, которые не позволяют массово использовать удаленную разработку, а коммуникация между сотрудниками — не проблема на сегодня.
Здравствуйте, Игoрь, Вы писали:
И>конфиденциальность
а что упрощается в вопросах конфиденциальности в случае работы в офисе?
какая разница в том, как сотрудник получил доступ к конфиденциальной информации — удалённо или локально?
Здравствуйте, Игoрь, Вы писали:
И>Здравствуйте, Sergey, Вы писали:
S>>Я уже писал, в чем тут проблема. И>Читал по диагонали и не заметил. И>По поводу отсутствовать, — должно быть требование о временных рамках в которых человек должен быть онлайн.
Ага, он на месте, только провайдер профилактику проводит.
S>>А ты попробуй. Потом расскажешь, во сколько раз больше это займет времени, по сравнению с личным общением. И>Пробовал, нормально. Там еще хуже было — команда была многонациональная. Твои аргументы базируются ИМХО исключительно на привычках. Да, с одной стороны приходится гораздо больше писать, но с другой стороны, то, что ты написал — все остается, и через месяц или два ты спокойно можешь перечитать все записи (и не только ты, но и любой член команды), в скайпе можно вести записи технических разговоров, и если что-то забыл — легко можно прослушать еще раз.
А оно мне нужно, смотреть отвергнутые спецификации, через месяц или два?
В плане коммуникации ИМХО проблем нет. И>Но есть другие проблемы — доступ к высокотехнологичному оборудованию, конфиденциальность, более жесткие требования к личностным качествам удаленного сотрудника. Вот эти проблемы ИМХО и есть главными, которые не позволяют массово использовать удаленную разработку, а коммуникация между сотрудниками — не проблема на сегодня.
"более жесткие требования к личностным качествам удаленного сотрудника" — это ключевой момент. Придется либо увольнять больше народа, что приведет к убыткам, либо работать с теми, что есть, что приведет к проблемам, которые я уже описывал.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
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>>какая разница в том, как сотрудник получил доступ к конфиденциальной информации — удалённо или локально? И>Во втором случае угроз больше. Во-первых, нужно предоставить доступ к внутренним ресурсам извне, во-вторых, И>копия данных будет храниться на домашних компьютерах каждого удаленного сотрудника. Иногда в этом нет ничего страшного, И>а иногда бывает и не приемлемо.
да, но нечистоплотный сотрудник придумает даже как обойти службу безопасности охраняемого офиса, и ничего тут не сделать
а нормальный (причём, из тех, что подходят по критериям для удалёнки), сможет сделать так, что к его компьютеру доступ будет существенно ограничен, по крайней мере решения типа всяких электронных чипов для шифрования данных сейчас вполне доступны
так, в этом месте разрешите поучаствовать в дискуссии, дальше ветку пока не читал
S>>Чиркануть схемку на бумажке, показать коллеге, обсудить ее, признать негодной и выкинуть в разы быстрее, чем проделать то же, пользуясь Visio и электронной почтой. И>И здесь проблемы не вижу: бумажка-->сканер-->почта.
какой сканер, какая почта? вебкамеры нынче стоят рублей по 300, дальше объяснять куда бумажку со схемкой показывать? если нет вебкамеры, цифровик-то есть рядом? или телефон?
многие недооценивают возможности этих нехитрых девайсов и действительно до сих пор бегают в поисках сканеров — хотя качества даже самых отсталых девайсов вполне хватает запечатлеть для коллег полет мысли. картинки могут конечно и почты потребовать — но передать файло можно и по тому же скайпу в процессе конференции весьма шустро — рисуй себе, щелкай и отправляй или просто в вебкамеру демонстрируй, если адепт бумажного творчества.
вообще толковые люди как правило способны донести свою мысль любым способом, хотя признаю что оформление по полной схеме — в доках с UML диаграммами — может иной раз оказаться по времени трудоемким делом. Но так на то профи и имеют уже опыт — способны оценивать на что стоит тратить время, а что требует обсуждения до того как начать высекать в камне. тем более если есть аудио канал и почта как следует из текста выше. так что тут смешивать действительно не надо — ОФис\Визио\Роза это одно, а обмен мнениями о том что туда нужно вносить это другое.
кстати, иногда переписка дисциплинирует как раз в плане написания фундаментальных вещей — набросков архитектуры и важных решений по реализации.
Пока напишешь — подумаешь лишний раз. А то как бывает: дал ЦУ (ляпнул мимоходом) кто-то постарше своей бригаде — и народ колбасит пока не упрется, иногда спустя значительное время. А глядишь выдавал бы ЦУ в письменной форме — сразу бы заметил, просмотры у всех случаются. Плюс в артефакты проектные личное общение не положишь (на стол не поставишь? )
Да и потом сразу было бы ясно кто виноват и что более важно, как получилось что было худшее решение принято. Это не всегда очевидно по прошествии некоторого времени с момента митинга, где ЦУ были выданы в устной форме — с диктофонами не все еще ходят. У нас только управляющий разработкой продукта такими штучками балуется
мое мнение: никогда наличие\отсутствие технических девайсов для коммуникации не являлось определяющим фактором в успехе\провале (в т.ч. удаленного) проекта.
Но как отмазка в случае неуспеха используется вероятно всегда — надо же на что-то пенять? Вон, футболисты вечно мяч круглый и поле неровное приводят как причину пролета, хотя вторая команда вроде бы на том же поле и тем же мячом играла
... << RSDN@Home 1.2.0 alpha rev. 677>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, bkat, Вы писали:
B>Это да. "Курилка" — это одно из самых эффективных мест обсуждения проблемы.
у нас курящих в девелопменте нет. и проблемы даже около кофе-машины, в чем-то выполняющей роль "курилки", как правило не обсуждаются — в силу менталитета и особенностей команды. Тем не менее не мешает достигать результата — в течении многих лет.
Напротив, разработчицкие бла-бла наверняка съели бы больше времени без существенного выхлопа. Есть проблема — есть как правило и вовлеченные в нее люди, они сами способны ее решить без курилки и без лишних сантиментов. Но отмечу что у нас случай в чем-то особый, может потому и курилка не нужна.
написал лишь для того чтобы отметить что "случаи всякие бывают", а так роль "курилки" а плане внутрикорпоративной культуры мне понятна и с ее значением совсем не спорю!
... << RSDN@Home 1.2.0 alpha rev. 677>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
)
. в случае привязки к Office Space это возможно, но не в той мере как того хотелось бы. а в случае удаленки работа и отдых вещи не взаимоисключающие.
* thriving in a production environment *
