Junior'ы — особая тема. Обычно в случае джуниора пытаешься нащупать дно, так сказать — оттуда и вопросы. Ну и плюс заложенную в нём потенциальную энергию. А вот со средними и гуру — уже проверяешь соответствие специализации своим требованиям и высоту полёта на примере уже полученного опыта.
Разве? Давайте обсудим. То есть хорошие плотники (скажем, 7+ лет стажа) в Москве получают 150-200 тр/мес, при этом не являясь предпринимателями или менеджерами или «родственниками» или кем-то иным кроме плотников? Потому что такого плотника, если он столько получает, будут собеседовать вот ровно как программистов.
Если бы плотники получали столько же, сколько и программисты, то и нанимали их бы как программистов. Но плотники не получают столько же, сколько и программисты, поэтому нанимают их таки попроще.
Ну, если что, то и цикл не for-in, а foreach-as.
Да и не foreach-as, а что-то там про while(mysql_fetch() !== null).
Ну как вспомнил, так вспомнил. Это всё дурное влияние питона :)
А если кто-то прочитает мой код и не поймёт шутки, и будет делать так же — ну, ссзб :)
И вообще, это был намёк, что выборка юзеров не является задачей. Это способ решения какой-то задачи, о которой изначально и было спрошено. Но намёк был слишком тонким, никто не понял. Со мной такое бывает.
Не понял про жалобы на отсутствующий рынок и приложения. Мне казалось что они сначала планировали рассылать экземпляры для разработчиков, чтобы они начали писать приложения. Надпись «dev board» как бы намекает. А на в массы оно пойдёт позже, когда разработчики напишут приложений. Нет?
Диферсификация работодателей — это как раз и есть фриланс. Свои риски, свои способы их преодоления. Работая в офисе люди обычно не задумываются о диверсификации, т.к. это другая поляна, другие правила и модели поведения. Спорить о freelance vs in-office не будем, это очень глубокая нора :)
А вот удалённая работа на full-time — это, как я и писал где-то тут рядом, нечно совсем новое. Это не фриланс. Это всё-таки ближе к офисной работе. Ну разве что способ доставки себя до рабочего места отличается (метрополитен vs telecommuting). Соответственно, ценности и модели работы тут скорее как у офисной работы, без «диверсификации работодателей».
Впрочем, свою полянку каждый волен выбирать сам. Главное чтоб по обоюдному согласию. Меня, например, не устраивает «левак» именно по причине выгорания и снижения эффективности по основному месту работы. Наверняка есть работодатели, которых «левак» вполне устроит.
1. И да, и нет. Обучать придётся в любом случае. Под обучением я не имел в виду основы языка, паттерны или что-то такое. Обучение процессам компании как минимум; плюс обучение нашей системе, наследственным системам, общему вектору развития как компании, так и системы.
Ну и плюс нанимать средних разработчиков и растить их внутри компании в долгосрочной перспективе выгоднее, чем нанимать готовых гуру. Хотя для ряда задач мы готовы нанимать и гуру, было бы кого.
На эту тему сломано немало копий, и можно очень долго обсуждать. Но явно не тут в теме про удалённую работу.
2. Возможно я не понял ваш вопрос. А если понял то ответ таков: потому что задач много, и управляются именно задачи. А управление людьми (вливание в процессы компании (которые ещё довольно активно меняются), стандарты качества, и тп) — это скорее уже про вот то самое обучение из п.1. Это во-первых.
А во-вторых, почему сложность администрирование задачи не должна зависеть от количества исполнителей? Нелинейно, конечно, но зависит. Либо делегируется, и эта же зависимость работает уже не лично у меня, а где-то там у кого-то, кому оно делегировано. От этого зависимость не исчезает.
У нас речь идёт о фултайм. На не-фуллтайм будет тратиться неоправданно большое количество сил на обучение и управление (равное фуллтайму) в отношении к приносимой пользе. Поэтому с парт-тайм или почасовой схемой мы не работаем.
Да, критерии почти такие же как при найме в офис (плюс умение из дома вообще работать, а не халявить — у меня, например, это тяжко получается). Поэтому и говорю где-то тут рядом в комментах, что надомная работа — это и не фриланс, и не офисная работа, это что-то новое, третье.
У нас целая методика, которую разрабатывают и опробывают проджект-менеджеры. Общий концепт: найти для каждого разработчика свой коэффициент, как его реальность расходится с его оценками, и далее применять для вычисления более реальных сроков.
Детальную оценку делают разработчики вместе с ведущим, да.
Касательно «своих» команд — я ещё дополнительно прикидываю и оцениваю сам для себя (без технических деталей, именно на высоком продуктовом уровне). Чай, не зря 10+ лет разрабатывал.
Сотрудники гугл имеют возможность 20% времени работать на не-основных проектах или личных инициативах, но всё равно созданные в эти 20% времени проекты принадлежат гуглу и делатся в интересах гугла.
Я не представляю себе того менеджера в здравом уме, который будет оплачивать 20% времени сотрудника, чтобы он левачил на сторону.
en.wikipedia.org/wiki/Flow_(psychology) — … fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does.
Мы платим зарплату. Фиксированную в месяц. Всю «белую» (следовательно, нормальный 2НДФЛ). Оформление в штат по ТК РФ, с заключением трудового договора. «Белее» прямо не придумаешь :) Думаем о мотивационных схемах.
Про контроль и оценку я чуть выше написал большой коммент.
Про информированность: пока нет, это проблема, мы её решаем как умеем. Начиная с публикации новостей проектов и компании в redmine, фиксации протоколов встреч в вики (если есть допуск к соответствующей информации, конечно). В ближайшее время начнём проводить еженедельные общие встречи, как вот у автора поста написано (хотя этот соц.заказ всплыл сильно раньше и от многих сотрудников).
С социализацией как раз плохо. Ищу способы её повысить. Вот «перманентный hangout», наверное, от автора поста позаимствую экспериментально. Но он может быть и отвлекающим — надо пробовать.
По сути, потери ≈30-50% общей эффективности из-за распределённости, полученные по оценкам ведущих, на мой взгляд и вызваны в первую очередь двумя вещами: (1) отсутствии социализации надомников, подразумевающейся в офисе, но отсутствующей в надомной работе; (2) сложностями коммуникации офисных и надомных сотрудников.
Кстати, отвечая на вторую часть вопроса, про работу на сторону. Как это видеть и оценивать пока не знаю. Я ориентируюсь на общие показатели сотрудника как такового, фактически на его соответствие моим ожиданиям.
Но подработки на сторону плохо влияют на успешность сотрудников в нашей компании, которая является основным рабочим местом. Надомные сотрудники не торопятся расставаться с кормящими их проектами на стороне. При этом тратят личное время, в итоге в рабочее время они уже уставшие, либо, что ещё хуже, выгоревшие.
И тут начинаются проблемы: с одной стороны, я не готов занижать свои ожидания для высококвалифицированных и высокооплачиваемых сотрудников, с другой стороны они не соответствуют ожиданиям.
В конце концов всё заканчивается или увольнением (или хождением под знаком вопроса) с нашей стороны, или полным сгоранием и уходом по собственному. В любом случае, из-за сторонних подработок мы теряем ценные кадры.
За последние пару месяцев по этой причине потерял 2х, и чуть не потерял 1ого разработчика. Теперь сразу при найме акцентирую внимание что у нас fulltime в штат, а не разовый проект, и не почасовка (кроме тех случаев, когда действительно разовый проект и почасовка). И что работа на сторону очень плохо скажется на наших рабочих отношениях (коль уж запретить на практике нельзя).
По сути, работа на сторону — это фрилансная привычка, которая не особо уместна в надомной работе. Но и старой доброй офисной работой надомничество тоже не является. В РФ только начинает формироваться культура (именно культура!) надомной работы full-time, отличная от этих двух крайностей. Тут «ГдеЭтотДом» в авангарде :-)
Встречный вопрос: а как вы понимаете что офисный сотрудник эффективно работает? Ведь присутствие на рабочем месте не является показателем эффективной работы, или вообще работы.
Отвечаю про себя:
Эффективность сотрудников я оцениваю по выполнению поставленных задач и достижению целей, в привязке к их уровню квалификации и зарплаты. Вообще, к слову, ожидания у меня, как показала длительная практика, очень завышенные, приходится намеренно занижать. Также, по выполнению стандартов и процессов компании (базовых, типа отчётности по затраченному времени).
Но эта схема работает только в командах порядка 7-10 человек, не больше. Как только начинается рост, появляются типичные проблемы роста. Например, невозможность контролировать всё и всех. Тут на помощь приходят и типичные решения: функциональные иерархии. И тогда оценка сотрудников делается через доверенных лиц на основании уже их мнения; обычно это ведущие команд.
В моём личном случае ситуация смешанная. Я напрямую контролирую три команды (пять до недавнего времени), и лично оцениваю успешность сотрудников; это, конечно, слишком много, и двигаюсь в направлении самостоятельности команд и их ведущих, но на то требуется время и силы. Сотрудников остальных команд я оцениваю через ведущих, на основании их мнения.
Другой способ, более сложный, но зато более системный — вводить KPI или аналоги. И не говорите мне что программистов нельзя померить. Очень даже можно! В KPI можно вкладывать такие вещи, как выполнение ежемесячных планов, попадание в сроки проектов, количество или длительность инцидентов при эксплуатации проектов/систем, и пр. В конце концов, в KPI можно включать даже экспертную оценку другими сотрудниками, как ведущими, так и мной лично через призму ведущих. Да и измерять можно не только сотрудников, но и сами команды.
Disclaimer: Вообще 2012ый год я провёл в попытке достичь результата любой ценой, предполагая что процессы как-нибудь сами организуются. Был неправ. Последние 1-2 месяца начинаю делать схему наоборот: процессы нужно выстраивать, результат сам как-нибудь образуется. Формирование упомянутых выше оценок и KPI как раз является частью формирования процессов, так что я пока не могу сказать как было бы идеально правильно. Но мы в компании как раз продумываем и детализируем эти KPI для разработчиков, с некоторыми базовыми прототипами уже наготове.
Вот как-то так. Заметьте, ни слова про надомность/офисность ;-)
Немного самопиара: мы в ГдеЭтомДоме тоже используем удалённую работу. Примерно 2/3 разработчиков и вообще технических специалистов — надомные (термин из ТК), 1/3 — офисные. Так что если вы знаете php/python/js — welcome (jobs@gdeetotdom.ru) ;-)
С начала 2012, то есть уже второй год, набиваем шишки, набираем опыт. Могу кое-чем поделиться — задавайте вопросы; применимо как к работодателям, так и к сотрудникам, которые хотят работать удалённо. С радостью выслушаю опыт других, потому что кое-чего нам и мне лично сильно не хватает.
Про цели и методы.
К сожалению, автор не упоминает много раз и на несколько параграфов как важно́ общение в таком режиме работы, иногда управляемое и чуть ли не насильное. Если всё пустить на самотёк, то удалённые разработчики превращаются в тяжкий груз, потому что, в отличие от офиса, у них нет давящего фактора окружающего коллектива («все работают, наверное и мне стоит хотя бы редактор открыть»).
Также, исходная статья написана в расчёте на американскую разработку с её спецификой (у них нет МКАДа). В России многие компании питают иллюзии(!) на тему того, что надомные сотрудники в регионах будут дешевле Москвы и сэкономят бюджеты. Бюджеты они действительно сэкономят, этак 30-50% в зависимости от. Но при этом просядет эффективность на те же самые 30-50%, и главным образом за счёт сложностей общения и интеграции. Ещё неизвестно что хуже.
Поэтому единственная ценность удалённой работы, как и указано в посте, — только в расширении потенциальной аудитории сотрудников (устранение критерия локации). На ту же цель можно направить и используемую у нас многоязыковую платформу (php+js для FE, python для BE, но возможны любые комбинации и вариации) — но это уже вопрос архитектуры, а не схемы работы.
Про методы.
Касательно способов — там всё довольно сложно. Может быть даже чисто-распределённая команда была бы проще управляема и легче реализуема, чем гибридная. А может и нет. В гибридной команде естественным образом формируется ядро из офисных сотрудников, потому что это «классический» способ, к которому все привыкли и знают как делать. Приходится применять управленческие усилия (начиная с ведущих и выше), чтобы преодолеть эти психологические барьеры.
Хотя вот некоторые приёмы я у автора позаимствую. Про google hangout могу пока сказать неприятную вещь: они публичны; и записи из них в youtube по умолчанию публичны. Но, видимо, это специфика личных hangouts. Надо попробовать которые «for business».
Пока что используем Skype. Он и чат, он и голос, он и видео и screen-share при необходимости.
Да и не foreach-as, а что-то там про while(mysql_fetch() !== null).
Ну как вспомнил, так вспомнил. Это всё дурное влияние питона :)
А если кто-то прочитает мой код и не поймёт шутки, и будет делать так же — ну, ссзб :)
И вообще, это был намёк, что выборка юзеров не является задачей. Это способ решения какой-то задачи, о которой изначально и было спрошено. Но намёк был слишком тонким, никто не понял. Со мной такое бывает.
так?
PS: И сам иногда для отвлечения мозга занимаюсь всякими кодерскими штучками. Такая вот форма релаксации.
А вот удалённая работа на full-time — это, как я и писал где-то тут рядом, нечно совсем новое. Это не фриланс. Это всё-таки ближе к офисной работе. Ну разве что способ доставки себя до рабочего места отличается (метрополитен vs telecommuting). Соответственно, ценности и модели работы тут скорее как у офисной работы, без «диверсификации работодателей».
Впрочем, свою полянку каждый волен выбирать сам. Главное чтоб по обоюдному согласию. Меня, например, не устраивает «левак» именно по причине выгорания и снижения эффективности по основному месту работы. Наверняка есть работодатели, которых «левак» вполне устроит.
Ну и плюс нанимать средних разработчиков и растить их внутри компании в долгосрочной перспективе выгоднее, чем нанимать готовых гуру. Хотя для ряда задач мы готовы нанимать и гуру, было бы кого.
На эту тему сломано немало копий, и можно очень долго обсуждать. Но явно не тут в теме про удалённую работу.
2. Возможно я не понял ваш вопрос. А если понял то ответ таков: потому что задач много, и управляются именно задачи. А управление людьми (вливание в процессы компании (которые ещё довольно активно меняются), стандарты качества, и тп) — это скорее уже про вот то самое обучение из п.1. Это во-первых.
А во-вторых, почему сложность администрирование задачи не должна зависеть от количества исполнителей? Нелинейно, конечно, но зависит. Либо делегируется, и эта же зависимость работает уже не лично у меня, а где-то там у кого-то, кому оно делегировано. От этого зависимость не исчезает.
Детальную оценку делают разработчики вместе с ведущим, да.
Касательно «своих» команд — я ещё дополнительно прикидываю и оцениваю сам для себя (без технических деталей, именно на высоком продуктовом уровне). Чай, не зря 10+ лет разрабатывал.
Сотрудники гугл имеют возможность 20% времени работать на не-основных проектах или личных инициативах, но всё равно созданные в эти 20% времени проекты принадлежат гуглу и делатся в интересах гугла.
Я не представляю себе того менеджера в здравом уме, который будет оплачивать 20% времени сотрудника, чтобы он левачил на сторону.
en.wikipedia.org/wiki/Flow_(psychology) — … fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does.
Про контроль и оценку я чуть выше написал большой коммент.
Про информированность: пока нет, это проблема, мы её решаем как умеем. Начиная с публикации новостей проектов и компании в redmine, фиксации протоколов встреч в вики (если есть допуск к соответствующей информации, конечно). В ближайшее время начнём проводить еженедельные общие встречи, как вот у автора поста написано (хотя этот соц.заказ всплыл сильно раньше и от многих сотрудников).
С социализацией как раз плохо. Ищу способы её повысить. Вот «перманентный hangout», наверное, от автора поста позаимствую экспериментально. Но он может быть и отвлекающим — надо пробовать.
По сути, потери ≈30-50% общей эффективности из-за распределённости, полученные по оценкам ведущих, на мой взгляд и вызваны в первую очередь двумя вещами: (1) отсутствии социализации надомников, подразумевающейся в офисе, но отсутствующей в надомной работе; (2) сложностями коммуникации офисных и надомных сотрудников.
Но подработки на сторону плохо влияют на успешность сотрудников в нашей компании, которая является основным рабочим местом. Надомные сотрудники не торопятся расставаться с кормящими их проектами на стороне. При этом тратят личное время, в итоге в рабочее время они уже уставшие, либо, что ещё хуже, выгоревшие.
И тут начинаются проблемы: с одной стороны, я не готов занижать свои ожидания для высококвалифицированных и высокооплачиваемых сотрудников, с другой стороны они не соответствуют ожиданиям.
В конце концов всё заканчивается или увольнением (или хождением под знаком вопроса) с нашей стороны, или полным сгоранием и уходом по собственному. В любом случае, из-за сторонних подработок мы теряем ценные кадры.
За последние пару месяцев по этой причине потерял 2х, и чуть не потерял 1ого разработчика. Теперь сразу при найме акцентирую внимание что у нас fulltime в штат, а не разовый проект, и не почасовка (кроме тех случаев, когда действительно разовый проект и почасовка). И что работа на сторону очень плохо скажется на наших рабочих отношениях (коль уж запретить на практике нельзя).
По сути, работа на сторону — это фрилансная привычка, которая не особо уместна в надомной работе. Но и старой доброй офисной работой надомничество тоже не является. В РФ только начинает формироваться культура (именно культура!) надомной работы full-time, отличная от этих двух крайностей. Тут «ГдеЭтотДом» в авангарде :-)
Встречный вопрос: а как вы понимаете что офисный сотрудник эффективно работает? Ведь присутствие на рабочем месте не является показателем эффективной работы, или вообще работы.
Отвечаю про себя:
Эффективность сотрудников я оцениваю по выполнению поставленных задач и достижению целей, в привязке к их уровню квалификации и зарплаты. Вообще, к слову, ожидания у меня, как показала длительная практика, очень завышенные, приходится намеренно занижать. Также, по выполнению стандартов и процессов компании (базовых, типа отчётности по затраченному времени).
Но эта схема работает только в командах порядка 7-10 человек, не больше. Как только начинается рост, появляются типичные проблемы роста. Например, невозможность контролировать всё и всех. Тут на помощь приходят и типичные решения: функциональные иерархии. И тогда оценка сотрудников делается через доверенных лиц на основании уже их мнения; обычно это ведущие команд.
В моём личном случае ситуация смешанная. Я напрямую контролирую три команды (пять до недавнего времени), и лично оцениваю успешность сотрудников; это, конечно, слишком много, и двигаюсь в направлении самостоятельности команд и их ведущих, но на то требуется время и силы. Сотрудников остальных команд я оцениваю через ведущих, на основании их мнения.
Другой способ, более сложный, но зато более системный — вводить KPI или аналоги. И не говорите мне что программистов нельзя померить. Очень даже можно! В KPI можно вкладывать такие вещи, как выполнение ежемесячных планов, попадание в сроки проектов, количество или длительность инцидентов при эксплуатации проектов/систем, и пр. В конце концов, в KPI можно включать даже экспертную оценку другими сотрудниками, как ведущими, так и мной лично через призму ведущих. Да и измерять можно не только сотрудников, но и сами команды.
Disclaimer: Вообще 2012ый год я провёл в попытке достичь результата любой ценой, предполагая что процессы как-нибудь сами организуются. Был неправ. Последние 1-2 месяца начинаю делать схему наоборот: процессы нужно выстраивать, результат сам как-нибудь образуется. Формирование упомянутых выше оценок и KPI как раз является частью формирования процессов, так что я пока не могу сказать как было бы идеально правильно. Но мы в компании как раз продумываем и детализируем эти KPI для разработчиков, с некоторыми базовыми прототипами уже наготове.
Вот как-то так. Заметьте, ни слова про надомность/офисность ;-)
Немного самопиара: мы в ГдеЭтомДоме тоже используем удалённую работу. Примерно 2/3 разработчиков и вообще технических специалистов — надомные (термин из ТК), 1/3 — офисные. Так что если вы знаете php/python/js — welcome (jobs@gdeetotdom.ru) ;-)
С начала 2012, то есть уже второй год, набиваем шишки, набираем опыт. Могу кое-чем поделиться — задавайте вопросы; применимо как к работодателям, так и к сотрудникам, которые хотят работать удалённо. С радостью выслушаю опыт других, потому что кое-чего нам и мне лично сильно не хватает.
Про цели и методы.
К сожалению, автор не упоминает много раз и на несколько параграфов как важно́ общение в таком режиме работы, иногда управляемое и чуть ли не насильное. Если всё пустить на самотёк, то удалённые разработчики превращаются в тяжкий груз, потому что, в отличие от офиса, у них нет давящего фактора окружающего коллектива («все работают, наверное и мне стоит хотя бы редактор открыть»).
Также, исходная статья написана в расчёте на американскую разработку с её спецификой (у них нет МКАДа). В России многие компании питают иллюзии(!) на тему того, что надомные сотрудники в регионах будут дешевле Москвы и сэкономят бюджеты. Бюджеты они действительно сэкономят, этак 30-50% в зависимости от. Но при этом просядет эффективность на те же самые 30-50%, и главным образом за счёт сложностей общения и интеграции. Ещё неизвестно что хуже.
Поэтому единственная ценность удалённой работы, как и указано в посте, — только в расширении потенциальной аудитории сотрудников (устранение критерия локации). На ту же цель можно направить и используемую у нас многоязыковую платформу (php+js для FE, python для BE, но возможны любые комбинации и вариации) — но это уже вопрос архитектуры, а не схемы работы.
Про методы.
Касательно способов — там всё довольно сложно. Может быть даже чисто-распределённая команда была бы проще управляема и легче реализуема, чем гибридная. А может и нет. В гибридной команде естественным образом формируется ядро из офисных сотрудников, потому что это «классический» способ, к которому все привыкли и знают как делать. Приходится применять управленческие усилия (начиная с ведущих и выше), чтобы преодолеть эти психологические барьеры.
Хотя вот некоторые приёмы я у автора позаимствую. Про google hangout могу пока сказать неприятную вещь: они публичны; и записи из них в youtube по умолчанию публичны. Но, видимо, это специфика личных hangouts. Надо попробовать которые «for business».
Пока что используем Skype. Он и чат, он и голос, он и видео и screen-share при необходимости.
А какие у вас способы удалённой работы?