Чи повинні компанії вважати віддалених працівників або дотримуватися місцевих працівників? [зачинено]

Елітні розробники можуть бути в 10 разів продуктивнішими, ніж середні розробники.

Очевидно, що елітного забудовника у всьому світі простіше знайти, ніж у дворі компанії.

Якщо компанія не розташована в гарячій точці програмування, чи варто розглядати питання найму людей, які працюють вдома?

Я працював і керував персоналом в обох ситуаціях, і в комбінаціях обох. Я зробив такі зауваження:

• Молодший персонал не працює віддалено. Вони вимагають хороших та особистих робочих відносин з наставником. Я знаходжу, що мій молодший персонал швидше чекає, коли я стану доступним, ніж запитати досить старшого (і хорошого) віддаленого розробника.

• Переконайтесь, що будь-хто, кого ви вважаєте за віддалену роботу, є ефективним при самостійному керуванні та не виходить на дотичні.

• Віддалений персонал може дуже легко ізолюватись і не відчувати себе частиною команди, якщо не буде докладено особливих зусиль, щоб їх включити. Така ізоляція може призвести до нерозуміння конкретного бізнес-рушійного проекту або до неправильного трактування подій негативно.

• Ніколи не змушуйте підрядника працювати віддалено, якщо вони не мають належного стимулу до виконання.

• Працюючи з віддаленим членом команди, переконайтеся, що вони отримують рівноправний доступ до ресурсів, включаючи управління джерелами, довідкові матеріали тощо. Не змушуйте їх стрибати через обручі, щоб виконати роботу.

• Влаштовуйте зустрічі віч-на-віч настільки часто, наскільки це практично. Це заохочує набагато кращу співпрацю в команді, оскільки людям комфортніше тих, кого вони зустріли.

Можливо.

Ваші переваги:

• Доступ до більш широкого кола кандидатів (як ви зазначаєте)
• Доступ для людей, які хочуть працювати вдома

Ваші витрати:

• Більш складне спілкування - ви не можете просто завести когось у безкоштовний конференц-зал.
• Ніякої гарантії миттєвого спілкування - якщо ви заблоковані і чекаєте на Joe Remote, ви не можете просто зайти до його столу і запитати, що там. Якщо він без комунікатів, ти СОЛ.
• Не всі розробники працюють добре віддалено. Деякі потребують структурованого середовища, щоб бути продуктивним.
• Часто немає гарантії відповідності розкладів, наприклад, людина, яка працює на дому, може спати, або людина в іншому часовому поясі може прокинутися і працювати в інший час, ніж ви.

Етвуд мав про це гідну статтю .

Редагувати зі статті Етвуда:

Мінімальний розмір віддаленої команди - два. Завжди майте приятеля, навіть якщо ваш друг перебуває на іншому континенті на півдорозі світу.

На посади з віддаленої розробки потрібно подати заявку лише ветеранам із гризуном, які абсолютно люблять кодувати. Наставництво новачків або випадкових програмістів просто не працює віддалено.

Щоб бути ефективними, віддаленим командам необхідна повна автономія та керівник (PM, якщо ви хочете), який має сильне бачення та повноту для повноцінного виконання цього бачення.

Компанії, які не знають, що роблять, не повинні мати віддалених працівників. Самий некомпетентний менеджер відчує, що ти наполегливо працюєш, якщо вони насправді зможуть побачити, як ти сидиш за своїм комп’ютером, робиш багато друку. Також сидіння на марних зустрічах - один з найкращих показників міцного спілкування та управління часом.

Коли у вас є люди, які знають, що вони роблять, і якими керують ті, хто знає, що роблять, це насправді не має значення коли, де або як вони працюють. Вони отримують те, що потрібно, коли це потрібно зробити.

Я в компанії, яка платить комусь, щоб здійснити прямий депозит на нарахування заробітної плати І роздрукує чековий штучний папір (фактична попередньо роздрукована чекова папір), кладе її в конверт і вклеює в наші поштові скриньки. Я думаю, що внутрішня електронна пошта недостатньо захищена, і що б ми зробили з усіма цими чеками ?. Я вважаю, що цей указ поступив з Департаменту надмірності. Якщо хтось працював би віддалено, то додаткові витрати на поштові перевезення, що є вагомою причиною не дозволяти людям працювати віддалено - занадто дорого.

Добре мати віддалених людей, якщо дві речі справжні:

1. Люди достатньо старші та мають досвід роботи, що означає, що ви довіряєте їм, що вони можуть робити все без особливого нагляду та проявляти активність щодо прохання про допомогу чи повідомлення про те, якщо вони застрягли.
2. "Пульс" вашого проекту досить короткий (бажано щоденний), щоб будь-які проблеми з домовленістю були швидко виявлені. Я маю на увазі не те, що хтось сказав, що щось зробив у звіті про стан чи перевіряв предмет зі списку завдань, а фактичний, наочний прогрес у функції. Звичайно, існує маса способів зробити це, але головна хитрість полягає в тому, щоб розділити завдання на досить маленькі шматки, які можна виконати за день або менше, і підтвердити, що ці завдання виконуються.

Сьогодні є дивовижні технології, які дозволяють легко діяти як команда, не сидіти близько один до одного.

IRC, Jabber або подібне програмне забезпечення для чату дозволяє дуже легко інформувати всіх про команду один про одного, що вони роблять, і не вагаючись негайно обговорювати проблеми. Я часто використовую IRC з групами freenode, і це як би мати під рукою одну велику групу розробників, яка діє як гігантський колективний мозок. Apple отримала приємний клієнт чату в Mac OS, який також підтримує відеоконференції, особливо ефективні на своїх ноутбуках.

Уявіть, як було б, якби компанія мала власний внутрішній сервер чату з групами для відділів, проектів та зацікавленими групами, що стосуються роботи. Розробник міг задати питання, де це буде бачити по всій компанії, тож інший розробник де-небудь ще міг бачити це і відповідати. Стіни офісу зникають, комунікації та кращі практики та спільний використання коду можуть відбуватися самостійно, не маючи великої палиці.

Один з наших інженерів з навантажувальних випробувань працює віддалено близько 1/3 року, іноді від його будинку, який знаходиться в 30 милях від нашого офісу, в інший час - поза штатом. Він настільки ж ефективний в офісі, як і поза ним, тому що він підтримує роботу свого програмного забезпечення для чатів та закликає до наших конференц-дзвінків.

Мої колеги в моїй команді сідають в зал, щоб я їх не бачив і не чув. Я не знаю, коли вони в їх кубиках, тому я надсилаю їм повідомлення в чаті, і вони відповідають якомога швидше. Я програмую команду з одним із наших інженерів на іншому сайті. Те саме відбувається; Ми регулярно обмінюємось питаннями та / або дурними думками, і якщо нам потрібно набрати темп, ми поділимося екраном і зв’яжемось по телефону. Я не можу сказати, чи він в офісі, чи вдома, і це не має значення. Ми працюємо так само і в будь-якому випадку.

Наш відділ QA розділений між двома різними містами в різних штатах, наші інженери розповсюджуються по нашому місту приблизно в чотирьох різних місцях, але це важко сказати, оскільки ми використовуємо наші телефони та спілкуємось регулярно. Ми реально працюємо віддалено один від одного, тож у чому різниця? Різниця полягає в корпоративному мисленні.

Є велика кількість переваг роботи віддалено, і, як правило, для зміни роботодавця потрібні роботодавці, щоб спробувати дізнатися, що працівники на це позитивно реагують.

Я думаю, це також залежить від того, що ти хочеш, щоб вони робили.

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

Якщо вони отримують детальні характеристики та методи вибивання, то не так багато.

Редагувати: Щоб уточнити, я намагаюся сказати, що якщо роботу можна ізолювати, то це прекрасно віддавати віддаленому працівникові. Якщо ж вона потребує детальних обговорень та зустрічей архітектурного дизайну, то це зробити дуже важко в різних країнах.