Здравствуйте, 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%.
Неэффективно?
