Периодически просматриваю rsdn.ru, job.ru, joblist.ru в поисках постоянной удаленной работы. Предложений о постоянной удаленной работе очень
не много по сравнению с предложениями работы в оффисе. Отсюда вопрос работодателям — чем же работа девелоперов в оффисе выгоднее работы девелоперов такой же квалификации, но работающих удаленно?
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, уважаемые коллеги.
_>Периодически просматриваю rsdn.ru, job.ru, joblist.ru в поисках постоянной удаленной работы. Предложений о постоянной удаленной работе очень _>не много по сравнению с предложениями работы в оффисе. Отсюда вопрос работодателям — чем же работа девелоперов в оффисе выгоднее работы девелоперов такой же квалификации, но работающих удаленно?
Здравствуйте, Vis, Вы писали:
Vis>Здравствуйте, white_znake, Вы писали:
_>>Здравствуйте, уважаемые коллеги.
Vis>Контролировать намного легче.
А что вы понимаете под словом "контроль"?
Лично мое убеждение, нужно искать ответственных людей. Так как только контролем заставить человека работать эффективно нельзя. Я найду 100 причин если мне будет надо почему я это не сделал в срок и вы мне не докажите обратного, что это можно было сделать.
Так что контролировать меня, может только один человек, это Я. Вы же можите мне ставить только задачи.
_> чем же работа девелоперов в офисе выгоднее работы девелоперов такой же квалификации, но работающих удаленно?
Скорость обмена информацией.
Более конкретно: даже при наличии skype/IM/whatever спросить у начальника/коллеги становится сложнее, чем просто повернув голову.
И много вещей пишутся группой разработчиков. Meeting'и и прочее гораздо более действенны вживую.
Здравствуйте, Dair, Вы писали:
D>Более конкретно: даже при наличии skype/IM/whatever спросить у начальника/коллеги становится сложнее, чем просто повернув голову.
Про начальника не знаю, но коллегу своего вы точно выбьете из рабочего процесса. Любым вопросом на пол-часа.
По моему опыту использования удаленной разработки эффективность выполнения работы удаленным человеком была примерно в 3 раза ниже, чем под контролем в офисе (человеком такой же квалификации). Когда его оплата была в 3-4 раза ниже, чем в Москве, это было терпимо. Когда платить стало нужно половину московской зарплаты, стало невыгодно. Некоторые виды работ, не требующие особого качесва исполнения, продолжаю отдавать, таких не более 10%
SSP>Про начальника не знаю, но коллегу своего вы точно выбьете из рабочего процесса. Любым вопросом на полчаса.
Мои соболезнования. У меня переключение процессов нормально отлажено
К тому же, спросить совета у senior/lead developer'а очень часто более оправдано именно в процессе, нежели, например, в конце итерации, когда выяснится, что всё сделано совсем не так. ИМХО, конечно.
А если коллега сидит "в глубоком дебаге" четвертый час и отмахивается от вопросов, как от назойливой мухи, лучше сесть рядом и помочь (да, таким образом, овлекшись от собственной задачи на полчаса). Из собственной практики знаю, что свежий взгляд очень часто помогает (проверял в обе стороны )
Здравствуйте, Александр Игрушкин, Вы писали:
АИ>Здравствуйте, Vis, Вы писали:
Vis>>Контролировать намного легче. АИ>+ очная коммуникация между участниками проекта играет очень большую роль
у нас на работе очень многие общаются друг с другом по ICQ, хотя сидят в 4 — х шагах друг от друга, т.к. шум от очных коммуникаций мешает работать другим
Здравствуйте, swame, Вы писали:
S>По моему опыту использования удаленной разработки эффективность выполнения работы удаленным человеком была примерно в 3 раза ниже, чем под контролем в офисе (человеком такой же квалификации). Когда его оплата была в 3-4 раза ниже, чем в Москве, это было терпимо. Когда платить стало нужно половину московской зарплаты, стало невыгодно. Некоторые виды работ, не требующие особого качесва исполнения, продолжаю отдавать, таких не более 10%
Здравствуйте, Dair, Вы писали:
SSP>>Про начальника не знаю, но коллегу своего вы точно выбьете из рабочего процесса. Любым вопросом на полчаса.
D>Мои соболезнования.
Мне соболезнований не надо, Я-то как раз удалённо работаю.
D> У меня переключение процессов нормально отлажено
Здравствуйте, swame, Вы писали:
S>По моему опыту использования удаленной разработки эффективность выполнения работы удаленным человеком была примерно в 3 раза ниже, чем под контролем в офисе (человеком такой же квалификации). Когда его оплата была в 3-4 раза ниже, чем в Москве, это было терпимо. Когда платить стало нужно половину московской зарплаты, стало невыгодно. Некоторые виды работ, не требующие особого качесва исполнения, продолжаю отдавать, таких не более 10%
Это верное в слуыае если нету полноценного контроля. У меня товарищ работает на дому на одну довольно немаленькую и известную контору Так вот он садится за комп запускает IRC и начинает работать, причем работает он как по мне весьма эффективно. Но клучевым условием здесь является именно коммуникаиция внутри команды разработчиков т.е. в томже IRC сидит менеджер плюс еженедельные отчеты о проделанной работе (в неформальной форме). Да и сам я периодически работаю удаленно и заметил что качество моей работы прямо пропорционально возможнотсти взаимодействовать с остальными участниками разработки. Вобщем из своего и не только опыта я лично пришел к выводу что удаленная разработка вполне может быть эффективной но организовать ее намного сложнее чем не удаленную. Возможно, кстати, что тут свою роль играет отсутствие у менеджмента навыков руководства удаленными разработчикаи.
Здравствуйте, Tourist, Вы писали:
T>Лично мое убеждение, нужно искать ответственных людей. Так как только контролем заставить человека работать эффективно нельзя.
Отсутствие контроля — это полная бесконтрольность в буквальном смысле. И ни к чему хорошему это не приведет.
Здравствуйте, Dair, Вы писали:
D>Более конкретно: даже при наличии skype/IM/whatever спросить у начальника/коллеги становится сложнее, чем просто повернув голову.
А отвлечь человека и убить у него полчаса рабочего времени становится легче. Отвлекаешь — программеру уже сложнее втянуться. Поэтому в этом смысле работа в _общем_ офисе это минус, чем плюс. И в этом случае она уж точно не может быть лучше удаленной в плане продуктивности.
Здравствуйте, Roman Pushkin, Вы писали:
RP>Здравствуйте, Tourist, Вы писали:
T>>Лично мое убеждение, нужно искать ответственных людей. Так как только контролем заставить человека работать эффективно нельзя.
RP>Отсутствие контроля — это полная бесконтрольность в буквальном смысле. И ни к чему хорошему это не приведет.
А что такое контроль — это по вашему стоять за спиной разработчика с кнутом — типа рабоать нигер, работать. Или иметь project plan с детализацией работ по дням (если возможно) и требовать отчестность о ходе выполняемых работ?
Здравствуйте, swame, Вы писали:
S>По моему опыту использования удаленной разработки эффективность выполнения работы удаленным человеком была примерно в 3 раза ниже, чем под контролем в офисе (человеком такой же квалификации).
Это могло быть по следующим причинам:
— Дома человека могли отвлекать больше чем в офисе.
— Плохая организация.
— Плохая мотивация разработчика, разработчик не чувствует себя членом команды, нет уважения коллег.
— Не было веры в важность проекта.
Поэтому так сразу взять и сравнить нельзя. К каждой из ситуаций нужно подходить конкретно. И нельзя также сказать, что удаленная работа хуже. Можно сказать, что удаленную работу сложнее настроить. Но если ее хорошо настроить, эффективность может быть выше в разы.
Здравствуйте, Dair, Вы писали:
SSP>>Про начальника не знаю, но коллегу своего вы точно выбьете из рабочего процесса. Любым вопросом на полчаса. D>Мои соболезнования. У меня переключение процессов нормально отлажено
Работа среднестатистического разработчика требует, чтобы переключение внимания происходило не чаще, чем раз в несколько часов. Это прописная истина любого уважающего себя программиста. Вот, можешь почитать для затравки http://www.joelonsoftware.com/articles/fog0000000022.html
Здравствуйте, white_znake, Вы писали:
_>А что такое контроль — это по вашему стоять за спиной разработчика с кнутом — типа рабоать нигер, работать. Или иметь project plan с детализацией работ по дням (если возможно) и требовать отчестность о ходе выполняемых работ?
Контроль это:
— Создание детального плана проекта, согласно которому действия каждого разработчика будут соответствовать целям проекта.
— Пункт выше предотвращает конфликт с деятельностью других разработчиков.
— Установка стандартов проектирования и кодирования, которые смогут обеспечить совместимость результатов проектирования и исходного кода.
— Управление изменениями требований.
И многое другое. Перечислять можно долго. Но это нужно. И фокус в чем. Если процессу контроля уделять достаточно времени на начальном этапе, на конечном этапе это время не увеличится экспоненциально. Если не уделять процессу контроля время, то все равно его придется уделять в конце проекта. Следовательно, увеличится и "холостой ход" проекта ближе к его завершению. В итоге будете разгребать целую кучу непонятно чего, если не уделить достаточного внимания вначале.
Здравствуйте, Tourist, Вы писали:
T>> заставить человека работать эффективно нельзя.
Заставить человека работать вообще нельзя. Под дулом автомата только. В случае с разработчиком — его нужно заинтересовать. И обеспечить его самым необходимым: хорошими условиями работы, безопасностью (возможность реализовать проект в срок), поддержкой колег и верой в проект. Только тогда проект будет жить. И более того, только тогда в нем будет та искорка, которая отличает вымученные проекты от живых.
И даже заработная плата не играет решающей роли и не может покрыть все и сразу.
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, уважаемые коллеги.
_>Периодически просматриваю rsdn.ru, job.ru, joblist.ru в поисках постоянной удаленной работы. Предложений о постоянной удаленной работе очень _>не много по сравнению с предложениями работы в оффисе. Отсюда вопрос работодателям — чем же работа девелоперов в оффисе выгоднее работы девелоперов такой же квалификации, но работающих удаленно?
Есть большое количество факторов, которые не позволяют многим компаниям эффективно использовать удалённую разработку.
Основной, на мой взгляд, это отсутствие ресурсов на управление удалённой разработкой. Для того, чтобы удалёнка была эффективной, необходимо, чтобы процесс разработки был сильно формализован и эта формализация постоянно поддерживалась. Простыми словами — должны подготавливаться и отслеживаться все формальные документы процесса разработки, позволяющие разработчику работать автономно от других участников процесса (разработчиков, проектировщиков, тестировщиков, etc.).
Также играет роль отсутствие знаний, как организовать описанное выше
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, уважаемые коллеги.
_>Периодически просматриваю rsdn.ru, job.ru, joblist.ru в поисках постоянной удаленной работы. Предложений о постоянной удаленной работе очень _>не много по сравнению с предложениями работы в оффисе. Отсюда вопрос работодателям — чем же работа девелоперов в оффисе выгоднее работы девелоперов такой же квалификации, но работающих удаленно?
Мне еще одна мысль пришла в голову, очень часто нанимая удаленного разработчика почемуто думают что омжно действовать по принципу "выстрелил и забыл" т.е. дать задачу и спросить через n дней, как там дела, хотя должно быть какраз наоборот, т.е. постоянный контроль за ходом разработки. Кроме попытки сэкономить на офисе, зарплате, налогах и т.д. экономить пытаются еще и на менеджменте, именно на этом многие попытки наладить удаленную работу и погорели. ВСЕ успешние удаленные разработки которые я видел или в которых учавствовал основывались именно на постоянном контроле за ходом работы и корректировании направления разработки причем на началных этапах требовались немалые усилия чтобы наладить нормальные коммуникации.
Здравствуйте, Spidola, Вы писали:
S>Основной, на мой взгляд, это отсутствие ресурсов на управление удалённой разработкой. Для того, чтобы удалёнка была эффективной, необходимо, чтобы процесс разработки был сильно формализован и эта формализация постоянно поддерживалась. Простыми словами — должны подготавливаться и отслеживаться все формальные документы процесса разработки, позволяющие разработчику работать автономно от других участников процесса (разработчиков, проектировщиков, тестировщиков, etc.).
Извините, а разве при работе в оффисе для того что бы на выходе получился качественный продукт не нужны спецификации c требованиями к системе, документация по архитектуре системы, project plan, check lists для тестирования?
Здравствуйте, white_znake, Вы писали:
S>>Основной, на мой взгляд, это отсутствие ресурсов на управление удалённой разработкой. Для того, чтобы удалёнка была эффективной, необходимо, чтобы процесс разработки был сильно формализован и эта формализация постоянно поддерживалась. Простыми словами — должны подготавливаться и отслеживаться все формальные документы процесса разработки, позволяющие разработчику работать автономно от других участников процесса (разработчиков, проектировщиков, тестировщиков, etc.).
_>Извините, а разве при работе в оффисе для того что бы на выходе получился качественный продукт не нужны спецификации c требованиями к системе, документация по архитектуре системы, project plan, check lists для тестирования?
Нужны, конечно, но объём их может быть меньше, поскольку часть вопросов может быть решена на уровне общения участников процесса для ускорения разработки. Особенностью удалёнки также часто является несинхронность работы по времени. Например, когда проектировщик готовит документ утром, а разработчик начинает работать вечером. Если у разработчика возникают вопросы, то он их задаёт вечером, а проектировщик отвечает утром. При синхронизации рабочего времени в офисе этих задержек можно было бы избежать. При удалёнке одним из способов избежать задержек является более полная формализация задачи, чтобы уменьшить объём вопросов.
Или, например, при работе в офисе и возможности вербального общения участников команды можно создавать документы не последовательно, а накапливать сведения и потом вносить в документацию оптом. Уже быстрее.
В дополнение хочу пояснить, что под ресурсами понимаются также затраты на коммуникации между участниками проекта, поэтому, например, предложения поставить всем скайп, обеспечить удалённый доступ по высокоскоростной линии и т.п. также требуют затрат.
Я уж не говорю о том, что психологически и профессионально удалённый работник должен быть очень хорошо подготовлен, поскольку у многих людей уровень самоорганизации на весьма низком уровне и посмотр интересного футбольного матча или выполнение настойчивой просьбы любимой женщины о походе в магазин за хлебом некоторые разработчики ставят приоритетом выше чем работа по проекту.
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, уважаемые коллеги.
_>Периодически просматриваю rsdn.ru, job.ru, joblist.ru в поисках постоянной удаленной работы. Предложений о постоянной удаленной работе очень _>не много по сравнению с предложениями работы в оффисе. Отсюда вопрос работодателям — чем же работа девелоперов в оффисе выгоднее работы девелоперов такой же квалификации, но работающих удаленно?
Безусловно наличие сотрудников в офисе имеет преимущества и при равной стоимости нужно идти именно этим путем. Но если стоимость удаленной разработки дешевле, то конечно, она стоит рассмотрения.
Я считаю проблема №1 — это недоверие. ИТ-бизнес исторически развивался рядом с остальным крупным бизнесом, потому он сконцентрирован в мегаполисах. И естественно, что лучшие кадры и технологии находятся там же. Там же формируется и потребность в ИТ, и на месте она же и удовлетворяется. Квалификация удаленных разработчиков скорее всего будет ниже из-за отсутствия опыта и традиций. Исключения, конечно, есть и их много, появляются и удаленщики с многолетним опытом (мозги и целеустремленность к результату приведут). Но как правило, удаленку ищут люди невысокой квалификации и риск провала проектов с ними довольно высок.
Более того ИТ-компания или тем более консультант, вживую контактирующая с среднестатическим клиентом скорее всего лучше справится с задачей, нежели удаленный разработчик той же квалификации. Найм удаленщика для клиента целесообразен только если его собственная квалификация в ИТ высока и он четко представляет, что ему нужно. Либо если просто по деньгам нет других вариантов, что обычно и является движущей силой для клиентов обратиться к удаленщикам (наверное 95% удаленных проектов именно такие).
Но для ИТ-бизнеса удаленка тоже является вариантом решить проблемы нехватки специалистов и сократить издержки. И при современных технологиях это осуществимо и примеров тому много. Но опять же главная проблема по моему мнению — недоверие. Компании, которые строят правильный и успешный ИТ-бизнес, имеют технологии, обычно это не банальные навыки в Java или С#, а решения, которые так или иначе придется делить с удаленщиками. И далеко не все рискнут это делать, удаленщик завтра может прихватить все с собой. Как построить надежные отношения?
Кроме того нужна технология совместной работы. Версии, компоненты, базы, подключения и т.п. Все это гораздо проще организовать внутри офиса, нежели среди распределенной команды разработчиков. Иначе нестыковки, задержки, ошибки, разборки... Потому работа с удаленной командой, базирующейся в одном офисе, уже предпочтительнее для большинства проектов.
Также правильно было отмечено, что работа с удаленщиками требует бОльших усилий менеджера. Действительно, легче что-то устно сказать или объяснить разработчику, чем описывать требования и ждать реакции разработчика. Хорошо это или плохо — это большой вопрос. Для адекватного менеджера и понятливого разработчика это не будет проблемой. Тут уж как заведено в компании, вряд ли менеджер под удаленщиков будет перестраиваться. Но как говорил один клиент "большинство менеджеров предпочитают иметь возможность позвонить и сообщить исполнителю о том, что нужно срочно сделать" и таковы реалии. Хотя документирование требований — это общепризнанная практика, и чем крупнее проект тем более это необходимо. Так вот из-за дополнительных усилий со стороны менеджера найм одного удаленщика вряд ли оправдан, хотя и здесь бывают успешные исключения. Работа же с командой удаленщиков более целесообразна, так как стоимостные преимущества от команды разработчиков компенсируют дополнительные затраты времени менеджера.
Что касается отчетности, отслеживания загруженности разработчиков, то при адекватности и тех и других большой разницы нет. Если обе стороны хотят сделать больше и лучше, если у сотрудничества есть перспективы, есть доверие, то здесь проблем ожидать не стоит. По крайней мере они сопоставимы с аналогичными проблемами офисных работников.
А вообще хороший опытный разработчик в офисе это уже почти и есть удаленщик Обычно только поначалу нужно время на притирку, а дальше необходимость живого общения снижается. Обычные задачи решаются в рабочем режиме. Полезно бывает на старте проектов вживую обсудить архитектруру и т.п.. Но и это удаленно вполне можно делать.
Я работал в офисе, удаленно из дома в одиночку, удаленно в команде, довелось бывать и удаленным работодателем.
Со стороны работника: Дома удаленно работать все же тяжело, особенно если ты один на проекте, через какое-то время наступает спад, застой. Лучше работать в офисе и в команде. И особенно в команде, где тебе есть чему поучиться.
Со стороны работодателя: Есть предубеждение к удаленным работникам, есть в них что-то недолговечное и временное.
Я думаю, что использование удаленных работников, организованных в офисы, значительно расширится (это уже происходит). Также будет увеличиваться и число удаленных работников-одиночек, но вряд ли в сопоставимых темпах роста. И степень серьезности удаленных предложений останется невысокой, что сейчас и наблюдается повсеместно.
Здравствуйте, Roman Pushkin, Вы писали:
RP>- Плохая мотивация разработчика, разработчик не чувствует себя членом команды, нет уважения коллег.
Вот это основная проблема удаленки — сложно чуствовать себя членом группы которую ни разу не видел, и чувстовать ее уважение через ICQ.
Уважение и единство это внепроектная вещь, которая получается при работе вместе сама по себе при разговорах в курилке, а как ее удаленно получать вообще не понятно.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Spidola, Вы писали:
S>Нужны, конечно, но объём их может быть меньше, поскольку часть вопросов может быть решена на уровне общения участников процесса для ускорения разработки. Особенностью удалёнки также часто является несинхронность работы по времени. Например, когда проектировщик готовит документ утром, а разработчик начинает работать вечером. Если у разработчика возникают вопросы, то он их задаёт вечером, а проектировщик отвечает утром. При синхронизации рабочего времени в офисе этих задержек можно было бы избежать. При удалёнке одним из способов избежать задержек является более полная формализация задачи, чтобы уменьшить объём вопросов.
Из своего личного опыта скажу, что те проекты в которых не было хороших спецификаций, описания архитектуры, не было грамотного project plan, не было check lists — либо завершались с серьезным опазданием, либо не завершались совсем. Когда я приходил устраиваться на работу — то одним вопросом к работодателю было — "А как у вас построен процесс разработки и проектирования П.О.?". И когда я видел архитектуру системы нарисованную маркером на доске — без всякой доки, то я завершал собеседование.
S>Или, например, при работе в офисе и возможности вербального общения участников команды можно создавать документы не последовательно, а накапливать сведения и потом вносить в документацию оптом. Уже быстрее.
Да только в этом случае можно упустить какую — либо деталь, которая потом аукнится...
S>В дополнение хочу пояснить, что под ресурсами понимаются также затраты на коммуникации между участниками проекта, поэтому, например, предложения поставить всем скайп, обеспечить удалённый доступ по высокоскоростной линии и т.п. также требуют затрат.
А аренда оффиса, плата за "коммунальные" и технические услуги. А разве если сотрудники работают в оффисе, то им не нужен быстрый инет?
S>Я уж не говорю о том, что психологически и профессионально удалённый работник должен быть очень хорошо подготовлен, поскольку у многих людей уровень самоорганизации на весьма низком уровне и посмотр интересного футбольного матча или выполнение настойчивой просьбы любимой женщины о походе в магазин за хлебом некоторые разработчики ставят приоритетом выше чем работа по проекту.
Здравствуйте, white_znake, Вы писали:
_>...."А как у вас построен процесс разработки и проектирования П.О.?". И когда я видел архитектуру системы нарисованную маркером на доске — без всякой доки, то я завершал собеседование.
Agile?
white_znake wrote: > > "А как у вас построен процесс разработки > и проектирования П.О.?". И когда я видел архитектуру системы > нарисованную маркером на доске — без всякой доки,
Вы не поверите, или мне так везло, или это специфика контор, где я
работал, но в 80% проектов не было даже архитектуры, нарисованной на доске.
О какой удаленке можно говорить в таких конторах? К сведению, эти
конторы, отнюдь не развалились и живут себе вполне ничего.
И у меня сложилось впечатление, что порядка 80% контор не имеют
практически никакого процесса разработки. Точнее имеют — стохастический,
в первую очередь делается то, что горит для заказчика (классический
вариант "пожаротушения").
Здравствуйте, Vzhyk, Вы писали:
V>И у меня сложилось впечатление, что порядка 80% контор не имеют V>практически никакого процесса разработки. Точнее имеют — стохастический,
Не то чтобы это фатально. Но порядка это не добавляет точно. И ресурсов на такие проеты расходуется больше. И есть риск, что в будущем изменения в архитектуре ох как сильно могут ударить по ресурсам.
D>> У меня переключение процессов нормально отлажено SSP>Верю. А у вашего коллеги ?
Если коллега сильно занят, он способен об этом сказать, не отвлекаясь. У самого такое бывает.
RP>Работа среднестатистического разработчика требует, чтобы переключение внимания происходило не чаще, чем раз в несколько часов. Это прописная истина любого уважающего себя программиста. Вот, можешь почитать для затравки http://www.joelonsoftware.com/articles/fog0000000022.html
Спольски хорош, как обычно
Но он говорит о разных принципиально задачах.
А когда мы в одном проекте и, в принципе, делаем одно дело...
Опять же — если коллега "потеряет" один час засчет того, что переключится на мою задачу (очень часто это надо минут на 10, "свежая голова" видит ошибку обычно очень быстро), а я выиграю три, то, мне кажется, проект от этого выиграет.
Roman Pushkin wrote: > > V>И у меня сложилось впечатление, что порядка 80% контор не имеют > V>практически никакого процесса разработки. Точнее имеют — стохастический, > > Не то чтобы это фатально. Но порядка это не добавляет точно. И ресурсов > на такие проеты расходуется больше. И есть риск, что в будущем изменения > в архитектуре ох как сильно могут ударить по ресурсам.
Именно так. Но "пока гром не ударит, мужит не перекрестится".
Здравствуйте, white_znake, Вы писали:
_>у нас на работе очень многие общаются друг с другом по ICQ, хотя сидят в 4 — х шагах друг от друга, т.к. шум от очных коммуникаций мешает работать другим
А у нас никто не общается по ICQ кроме как для пересылки кусков кода.
Кто из нас кого переубедил охренительным примером?
Здравствуйте, Roman Pushkin, Вы писали:
RP>Одно дело — программируем одну и ту же функцию и один и тот же класс? Если так, то вы правы. Иначе — нет.
Ваши аргументы заставили меня изменить взгляд на жизнь.
Поясняю: не хотели бы Вы объяснить, показать на примерах, поделиться опытом, подтверждающим Вашу точку зрения?
Здравствуйте, Roman Pushkin, Вы писали:
RP>- Дома человека могли отвлекать больше чем в офисе.
Мне как руководителю от этого ни горячо, ни холодно. Проект провален.
RP>- Плохая организация.
Одна из причин неэффективности удаленщиков.
Покажите мне контору с хорошей организацией.
Я в такой одной работал. Было очень скучно.
RP>- Плохая мотивация разработчика, разработчик не чувствует себя членом команды, нет уважения коллег.
+
RP>- Не было веры в важность проекта.
++
RP>Поэтому так сразу взять и сравнить нельзя. К каждой из ситуаций нужно подходить конкретно. И нельзя также сказать, что удаленная работа хуже. Можно сказать, что удаленную работу сложнее настроить. Но если ее хорошо настроить, эффективность может быть выше в разы.
Здравствуйте, white_znake, Вы писали:
_>Из своего личного опыта скажу, что те проекты в которых не было хороших спецификаций, описания архитектуры, не было грамотного project plan, не было check lists — либо завершались с серьезным опазданием, либо не завершались совсем. Когда я приходил устраиваться на работу — то одним вопросом к работодателю было — "А как у вас построен процесс разработки и проектирования П.О.?". И когда я видел архитектуру системы нарисованную маркером на доске — без всякой доки, то я завершал собеседование.
А у меня с точностью до наоборот.
Наш отдел успешно сдал проект, по которому ВООБЩЕ не было документации проектной. В О О Б Щ Е.
И архитектура была нарисована именно маркером на доске.
S>>Или, например, при работе в офисе и возможности вербального общения участников команды можно создавать документы не последовательно, а накапливать сведения и потом вносить в документацию оптом. Уже быстрее. _>Да только в этом случае можно упустить какую — либо деталь, которая потом аукнится...
Мало кто готов инвестировать деньги в идеальный процесс разработки, когда сначала ВСЁ проектируем, а потом ВСЁ кодим и тестируем.
_>Работник и в оффисе может сидеть на rsdn.ru
Здравствуйте, Roman Pushkin, Вы писали:
RP>Не то чтобы это фатально. Но порядка это не добавляет точно. И ресурсов на такие проеты расходуется больше. И есть риск, что в будущем изменения в архитектуре ох как сильно могут ударить по ресурсам.
Я в такой конторе работаю.
Методика разработки называется superпуперveryохренетьagile.
Заключается в том, что клиенту продается продукт, которого ещё нет.
За два месяца группа выкатывает более-менее работающий проект. Ещё за два месяца доводит до ума.
Норма прибыли, не дай бог соврать, 300%.
Неэффективно?
Здравствуйте, Roman Pushkin, Вы писали:
RP>- Дома человека могли отвлекать больше чем в офисе.
Именно так. Типа "а что, в офисе ты посуду не моешь после того как чай попьёшь? быстренько помой то что со вчерашнего (и позавчерашнего) вечера накопилось, а потом ещё и полы пропылесосить надо". Наблюдал я такую сценку у одного товарища, работающего удалённо. Так и решил тогда — никогда удалёнщиков не брать. А товарищ тот, кстати, потом сбежал на работу в офисе. Уходит к 8, домой приходит к 23, и рад по уши. Посуду теперь можно не мыть, минутки перекуров никто с секундомером не считает.
Здравствуйте, white_znake, Вы писали:
_>Здравствуйте, уважаемые коллеги.
_>Периодически просматриваю rsdn.ru, job.ru, joblist.ru в поисках постоянной удаленной работы. Предложений о постоянной удаленной работе очень _>не много по сравнению с предложениями работы в оффисе. Отсюда вопрос работодателям — чем же работа девелоперов в оффисе выгоднее работы девелоперов такой же квалификации, но работающих удаленно?
Толком управлять удаленными разработчиками мало кто умеет. А между тем специфика удаленной работы существенно отличается от офисной. Как минимум требуются другие методы контроля, мотивации, взаимодействия и схемы оплаты. Просто взять и перетащить то что работает в офисе невозможно, а на то чтобы придумать что-то новое многих менеджеров не хватает. Удаленных работников привлекают в двух случаях: если хочется сэкономить деньги а сроки и качество не очень важны либо для выполнения рутины, которой своим разработчикам заниматься неинтересно. Как следствие, блестящих специалистов среди удаленщиков мало, что дает эффект положительной обратной связи. В третьих, "идейных" удаленщиков мало: мало у кого есть дома собственный кабинет, хорошая техника, толстый канал в интернет, выдрессированая жена и изрядная самодисциплина. Обычно удаленщики руководствуются другими причинами. Так что на нимая удаленщика есть высокий шанс нанять какого-нибудь урода.
Здравствуйте, Petrovich_, Вы писали:
>> Возможно, кстати, что тут свою роль играет отсутствие у менеджмента навыков руководства удаленными разработчикаи.
А зачастую и отсутствие этих навыков руководства и не удаленными разработчиками.
Мне кажется что сложность удаленного контроля заключается в том что начальство не в состоянии более или менее четко поставить задачу даже когда группа разработчиков сидит в оффисе. И так на много проще при любых вопросах давать не совсем внятные ответы и таким образам создавать видимость работы.
Здравствуйте, Roman Pushkin, Вы писали:
RP>Здравствуйте, Tourist, Вы писали:
T>>Лично мое убеждение, нужно искать ответственных людей. Так как только контролем заставить человека работать эффективно нельзя.
RP>Отсутствие контроля — это полная бесконтрольность в буквальном смысле. И ни к чему хорошему это не приведет.
100% Но вот одна проблема... контроллировать надо ход выполнения задачи, конечный результат а не то чтоб человек сидел в оффисе и лишний раз не зашел в инет.
Здравствуйте, Win2k, Вы писали:
W>Здравствуйте, Roman Pushkin, Вы писали:
RP>>- Дома человека могли отвлекать больше чем в офисе.
W> Именно так. Типа "а что, в офисе ты посуду не моешь после того как чай попьёшь? быстренько помой то что со вчерашнего (и позавчерашнего) вечера накопилось, а потом ещё и полы пропылесосить надо". Наблюдал я такую сценку у одного товарища, работающего удалённо. Так и решил тогда — никогда удалёнщиков не брать. А товарищ тот, кстати, потом сбежал на работу в офисе. Уходит к 8, домой приходит к 23, и рад по уши. Посуду теперь можно не мыть, минутки перекуров никто с секундомером не считает.
Так а работать удаленно кодгда ты дома не сам 100% нереально . Тут надо сначала дома процесс наладить, а потом браться за удаленку.
Здравствуйте, Miroff, Вы писали:
M>Толком управлять удаленными разработчиками мало кто умеет. А между тем специфика удаленной работы существенно отличается от офисной. Как минимум требуются другие методы контроля, мотивации, взаимодействия и схемы оплаты. Просто взять и перетащить то что работает в офисе невозможно, а на то чтобы придумать что-то новое многих менеджеров не хватает.
+1
M>Удаленных работников привлекают в двух случаях: если хочется сэкономить деньги а сроки и качество не очень важны либо для выполнения рутины, которой своим разработчикам заниматься неинтересно.
справедливости ради отмечу что бывает 3й случай: когда удаленно работающих по consulting agreement консультантов берут как раз потому что именно качество очень важно, а очень хороший специалист сидит далеко и переезжать не то что в офис а вообще в Ваш город не торопится
стоит не забывать, что есть типичный аутсорс, который Вы привели в качестве примера — где самое важное цена, и есть высокотехнологичный аутсорс — где цена конечно важна, но не определяет выбор и более того, находится примерно на мировом уровне, а не 10 уругвайских ескудо в час.
К сожалению в России действительно пока что доминируют первые 2 случая, фактически вся эксклюзивная "дорогая" работа делается не для российских фирм и вообще встречается редко\не афишируется — вот и сложился стереотип что "удаленно значит дешево" и появляются вот такие странные вакансии
<...excess quoted lines suppressed...>
Работа в офисе в Москве,З\п на испытательный срок от 2000$.
Возможна удаленная работа,З\п на испытательный срок от 1000$.
по мне так цифры если не должны были быть даны наоборот, то хотя бы совпадать ибо есть мнение, что работодатели нанимающие удаленно по идее должны и платить побольше — ибо не несут часто никаких расходов, которые имеют место быть в офисе, особенно если у удаленного работника есть вся инфраструктура и все что оплачивает работодатель это зарплата + расходы на связь. Лень писать внушительный список, но экономия может быть очень приличной, больше даже собственно самой зарплаты удаленщика иногда.
Вот это бы обсудить не мешало, что думает народ по этому поводу? причем хотелось бы услышать точку зрения работодателей по этому вопросу
... << RSDN@Home 1.2.0 alpha rev. 653>>
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.
)
