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>Да, Аристотель был идеалистом и предпочитал сферических коней в вакууме. Мы же имеем дело с реальными живыми людьми (которые, кстати, не увольняются по псевдокоду), со всеми их достоинствами и недостатками.
А как же логика? У неё есть законы, не нужно их игнорировать и превращать обсуждение сути в придирания к форме.
Хотя уже много раз убеждался, что многие на форум ходят не многогранно обсудить проблему, а навязать свою точку зрения.
* thriving in a production environment *
