"Мы не используем программных решений для контроля за удаленными сотрудниками" - по моему опыту это работает плохо. Невозможно контролировать результат и процесс. Не ясны сроки. Обычно, если нет контроля (банальные скриншоты), то программисты обычно "тянут" до цонца, в итоге ничего вовремя не сделано, а если программистов больше одного, то нет возможности корректировать процесс в процессе.
У нас работает отлично. Разрешите дать некоторые советы по тем проблемам, о которых вы написали:
Невозможно контролировать результат и процессРезультат конкретной фичи — пул реквест, другой разработчик или CTO смотрит код и его качество, менеджер открывает ветку с кодом на тестовой машине и смотрит, доволен ли он новой функцией.
Не ясны срокиВсе задачи разрезаются на кусочки, к каждой делаем хорошее описание, после чего команда на еженедельном митинге оценивает их, и мы формируем спринт. По большой функциональности меньшее понимание деталей, поэтому там дисперсия в сроках выше — но чем долгосрочнее планирование, тем больше нужно закладывать времени на то, что мы не донца понимаем предстоящий пулл работ.
программисты обычно "тянут" до цонца, в итоге ничего вовремя не сделаноНу это говорит о плохом менеджементе, как мне кажется. Мы режем крупные задачи на подзадачи, оцениваем их, менеджер в реальном времени на дашборде в JIRA видит, какие задачи сделаны, а какие нет, разработчик логируя время актуализирует Remaining time (сколько осталось времени до конца) — таким образом менеджер всегда в курсе, на сколько сделана задача, увеличились ли сроки и если да, то почему.
Это вопрос периодичности и неизбежности контроля. Достаточно в понедельник обозначать цели на неделю, а потом контролировать их выполнение. + общая цель на месяц и 2 раза в месяц обязательный созвон для подведения итогов. + задачи в Jira - и у вас всё как на ладони. Если выстроена нормальная мотивация, то и тянуть никто не будет.
Коллеги, есть очень простое решение для контроля: ежедневное код ревью (обязательные коммиты по итогам дня) и, главное - ежедневные письменные отчеты о проделанной работе в свободной форме (делал это, не получилось потому что вот такая проблема возникла, вот это пошло не так и т.д.). Нет отчета по итогам дня - рабочий день не учитывается при расчете зп. Уже через неделю можно понять, кто эффективно работает, а кто время транжирит.
Мне очень жаль, если вы работаете в компании, куда вы приходите на работу ради денег. Мы делаем очень крутые продукты, меняем рынок образования и радуемся нашим общим успехам. Ребята из команды разработки всегда супер рады интересным публикациям о нас, когда СМИ публично хвалят продукт, или именитые клиенты оставляют классные отзывы )
Спасибо большое за добрые слова :-) Мы планируем запустить к концу года групповые занятия в мини-группах (до 3-4 человек) — хочется сделать их намного эффективнее обычных оффлайн-групп, поэтому разработка нового продукта занимает очень много времени. Но мы надеемся, что уже скоро сможем предложить продукт, доступный большей аудитории!
Наконец примеры положительные, это хорошо. А можно подробнее по разработчикам - у всех зарплаты разные? Мотивация в деньгах есть отдельная, kpi? Время присутствия фиксировано? По Москве?
Зарплаты разные, так как у людей реально разный уровень. Так же ведущие разработчики (как и сотрудники) через год работы могут получить опцион, у нас здесь хорошая политика, сразу договорились с акционерами и зарезервировали под это определённую долю в компании.
Однако мы уже давно поняли, что дорогой опытный разработчик может делать в разы больше пользы (особенно в работе над сложными проектами, где всё плохо параллелиться), чем 2 или 3 разработчика ниже уровнем — сейчас в команде оставили только профессионалов.
Мотивации и KPI есть только перед руководителем разработки, для самих разработчиков пока ничего такого не делали, однако для ребят мы транслируем важные сроки — и это часто мотивирует, команда сплочаетс в энтузиазме заделиверить продкт в определенные рамки по времени или бюджету.
Что касается времени пресутствия, у нас есть 4 часа в день (с 12 до 17 с обеденным перерывом), когда мы ожидаем что все на месте — в остальное время каждый решает сам, когда ему удобнее работать. Это особенно актуально, так как есть ребята из совсем разных часовых поясов.
Согласен с Вами, у кого-то удалённая работа понижает продуктивность (ведь не видишь коллег, легко отвлечься), возможно даже таких людей большинство. Однако у многих производительность выше (можно сосредоточиться, быть в тишине, не бегает менеджер за спиной и не отвлекает в оффлайне по своим вопросам). Это инструмент — и нужно научиться им пользоваться, правильно выбирать людей на собеседовании. Основная моя мысль в этой статье — что удалённая продуктовая разработка, это совершенно реально и мне кажется, люди неоправданно этого опасаются.
Спасибо большое! Тут коллеги писали и просили подробнее рассказать как мы используем Slack, с какими-то деталями и хитростями внутренней кухни — думаю, это из этого может получиться что-то интересное и полезное :-)
Про это могу написать отдельную статью. За что я больше всего люблю — это бесконечные интеграции (по сути, всё изо всех систем стекается в Slack, от фидбека пользователей до Alert систем мониторинга серверов). Ну и второе — крутейшие нотификации, я могу настроить для мобильного приложения, например, чтобы ко мне приходили 2 канала все сообщения, а вот с этих трёх — только те сообщения, где меня упомянули.
Современные методологии (аджайл, скрам, XP) постулируют get team together. Никакими *generic skype* не заменить чувство локтя. Даже видеоконференция не дает обратной связи-не понятно смотрит ли человек на тебя или почитывает vc. Кроме того, очень часто видеоконференция-бОльший стресс, чем личное общение, даже для интровертов. Я не верю в распределенные команды.
Понимаю вас, я сам в начале то же самое говорил нашему директору ) Что разработка может быть только в одной комнате.
Однако мы попробовали — и не пожалели. Конечно, правильно её построить и организовать сложнее, и людей нужно подбирать к этому предрасположенных и процессы грамотно ставить и мотивационные инструменты в оффлайн плохо переносятся. Однако же мне кажется, наш опыт говорит о том, что у нас не плохо это получилось.
А как вводятся новые разработчики? Руководитель следит за кодом нового человека? Раз время работы не контролируется - ставятся сроки на задачи? Что если не выполнил или причины сомнительные? Как оценивается срок на реализацию? Что если постановщик ошибся с оценкой и разработчик не по своей вине превысил срок?
А как вводятся новые разработчики? Новый разработчик получает доступы, знакомится с командой и начинает читать документы с конвенциями и архитектурой проекта. После этого ему дают простые небольшие задачи, потом сложность и ответственность увеличивается.
Раз время работы не контролируется - ставятся сроки на задачи?Мы не контроллируем, утром или вечером ты работаешь. Но мы контроллируем, что в неделю человек отработал +- 40 часов, а так же какие задачи он закрыл — и соотносим сложность задачи и итоговый код (который прикрепляется к тикету в JIRA автоматически) с сложностью задачи.
Как оценивается срок на реализацию?Стоимость оценивает разработчик, эпрувит тимлид. Если не согласны, они обсуждают и договариваются о разумной оценке.
Что если постановщик ошибся с оценкой и разработчик не по своей вине превысил срок?Ничего страшного — ошибся ведь из-за чего-то, что что-то не учёл. Теперь он стал мудрнее и знает о новой веще и в будущем сможет лучше сделать оценку )
Самый большой отклик на moikrug, иногда приходят интересные ребята с hh. Был положительный опыт использования сервиса AmazingHiring :-). А так же пиарим — распространяем в Facebook и часто наши вакансии берут на VC.
А если программист и верстальщик фрилансеры? У которых по 3-4 клиента. Был ли у кого опыт создания хорошего проекта с фрилансерами? Или лучше смотреть в сторону штатного удаленного сотрудника?
"Мы не используем программных решений для контроля за удаленными сотрудниками" - по моему опыту это работает плохо. Невозможно контролировать результат и процесс. Не ясны сроки. Обычно, если нет контроля (банальные скриншоты), то программисты обычно "тянут" до цонца, в итоге ничего вовремя не сделано, а если программистов больше одного, то нет возможности корректировать процесс в процессе.
У нас работает отлично. Разрешите дать некоторые советы по тем проблемам, о которых вы написали:
Невозможно контролировать результат и процессРезультат конкретной фичи — пул реквест, другой разработчик или CTO смотрит код и его качество, менеджер открывает ветку с кодом на тестовой машине и смотрит, доволен ли он новой функцией.
Не ясны срокиВсе задачи разрезаются на кусочки, к каждой делаем хорошее описание, после чего команда на еженедельном митинге оценивает их, и мы формируем спринт. По большой функциональности меньшее понимание деталей, поэтому там дисперсия в сроках выше — но чем долгосрочнее планирование, тем больше нужно закладывать времени на то, что мы не донца понимаем предстоящий пулл работ.
программисты обычно "тянут" до цонца, в итоге ничего вовремя не сделаноНу это говорит о плохом менеджементе, как мне кажется. Мы режем крупные задачи на подзадачи, оцениваем их, менеджер в реальном времени на дашборде в JIRA видит, какие задачи сделаны, а какие нет, разработчик логируя время актуализирует Remaining time (сколько осталось времени до конца) — таким образом менеджер всегда в курсе, на сколько сделана задача, увеличились ли сроки и если да, то почему.
Это вопрос периодичности и неизбежности контроля. Достаточно в понедельник обозначать цели на неделю, а потом контролировать их выполнение.
+ общая цель на месяц и 2 раза в месяц обязательный созвон для подведения итогов.
+ задачи в Jira - и у вас всё как на ладони.
Если выстроена нормальная мотивация, то и тянуть никто не будет.
Коллеги, есть очень простое решение для контроля:
ежедневное код ревью (обязательные коммиты по итогам дня) и, главное - ежедневные письменные отчеты о проделанной работе в свободной форме (делал это, не получилось потому что вот такая проблема возникла, вот это пошло не так и т.д.).
Нет отчета по итогам дня - рабочий день не учитывается при расчете зп. Уже через неделю можно понять, кто эффективно работает, а кто время транжирит.
чтобы не тянули до конца, нужно принимать работу ежедневно
по-другому никак, и это не зависит от удаленки / не удаленки
Молодцы ребята, че уж там.
Большое спасибо, мы стараемся :-)
у нас есть канал Inspiration, в котором мы рассказываем сотрудникам о наших успеха
корпоративный bullshit перевели теперь на прямую трансляцию. что дальше-сразу в уши начнут лить через скайп?
Комментарий недоступен
Мне очень жаль, если вы работаете в компании, куда вы приходите на работу ради денег. Мы делаем очень крутые продукты, меняем рынок образования и радуемся нашим общим успехам. Ребята из команды разработки всегда супер рады интересным публикациям о нас, когда СМИ публично хвалят продукт, или именитые клиенты оставляют классные отзывы )
Skyeng очень круты, до повышения цен учился там и бед не знал)
Сейчас занимаюсь самостоятельно, благо есть куча решений и методик..
Спасибо большое за добрые слова :-) Мы планируем запустить к концу года групповые занятия в мини-группах (до 3-4 человек) — хочется сделать их намного эффективнее обычных оффлайн-групп, поэтому разработка нового продукта занимает очень много времени. Но мы надеемся, что уже скоро сможем предложить продукт, доступный большей аудитории!
Хорошая статья, возьму как за методичку. Как раз нужно вырасти в несколько раз :)
Спасибо, Вань! :-)
Наконец примеры положительные, это хорошо.
А можно подробнее по разработчикам - у всех зарплаты разные? Мотивация в деньгах есть отдельная, kpi?
Время присутствия фиксировано? По Москве?
Зарплаты разные, так как у людей реально разный уровень. Так же ведущие разработчики (как и сотрудники) через год работы могут получить опцион, у нас здесь хорошая политика, сразу договорились с акционерами и зарезервировали под это определённую долю в компании.
Однако мы уже давно поняли, что дорогой опытный разработчик может делать в разы больше пользы (особенно в работе над сложными проектами, где всё плохо параллелиться), чем 2 или 3 разработчика ниже уровнем — сейчас в команде оставили только профессионалов.
Мотивации и KPI есть только перед руководителем разработки, для самих разработчиков пока ничего такого не делали, однако для ребят мы транслируем важные сроки — и это часто мотивирует, команда сплочаетс в энтузиазме заделиверить продкт в определенные рамки по времени или бюджету.
Что касается времени пресутствия, у нас есть 4 часа в день (с 12 до 17 с обеденным перерывом), когда мы ожидаем что все на месте — в остальное время каждый решает сам, когда ему удобнее работать. Это особенно актуально, так как есть ребята из совсем разных часовых поясов.
Будто про людей из другой вселенной читаю. Кодил как-то на удаленке. КПД в среднем на 30% ниже.
Согласен с Вами, у кого-то удалённая работа понижает продуктивность (ведь не видишь коллег, легко отвлечься), возможно даже таких людей большинство. Однако у многих производительность выше (можно сосредоточиться, быть в тишине, не бегает менеджер за спиной и не отвлекает в оффлайне по своим вопросам). Это инструмент — и нужно научиться им пользоваться, правильно выбирать людей на собеседовании. Основная моя мысль в этой статье — что удалённая продуктовая разработка, это совершенно реально и мне кажется, люди неоправданно этого опасаются.
Удаленные сотрудники у вас числятся официально в штате сразу? Или оформляете через какое-то проверенное время? Или не офрмляете или ИП им?
У нас есть испытательный срок. Поскольку не все сотрудники живут в России, то они находятся в штате не российской компании.
Да, как правильно ответил Саша — после испытательного срока мы подписываем договор и NDA с головной компанией по британскому праву.
Спасибо!
Отличная статья! Хочется продолжения!
Спасибо большое! Тут коллеги писали и просили подробнее рассказать как мы используем Slack, с какими-то деталями и хитростями внутренней кухни — думаю, это из этого может получиться что-то интересное и полезное :-)
А чем именно Slack лучше, чем Скайп? Не пользовался, но у меня ровно такие же потребности. Что он позволяет делать?
На эту тему полно статей, в том числе на vc.ru.
Вот, например: https://vc.ru/p/meduza-slack
Про это могу написать отдельную статью. За что я больше всего люблю — это бесконечные интеграции (по сути, всё изо всех систем стекается в Slack, от фидбека пользователей до Alert систем мониторинга серверов). Ну и второе — крутейшие нотификации, я могу настроить для мобильного приложения, например, чтобы ко мне приходили 2 канала все сообщения, а вот с этих трёх — только те сообщения, где меня упомянули.
Современные методологии (аджайл, скрам, XP) постулируют get team together. Никакими *generic skype* не заменить чувство локтя.
Даже видеоконференция не дает обратной связи-не понятно смотрит ли человек на тебя или почитывает vc. Кроме того, очень часто видеоконференция-бОльший стресс, чем личное общение, даже для интровертов.
Я не верю в распределенные команды.
Понимаю вас, я сам в начале то же самое говорил нашему директору ) Что разработка может быть только в одной комнате.
Однако мы попробовали — и не пожалели. Конечно, правильно её построить и организовать сложнее, и людей нужно подбирать к этому предрасположенных и процессы грамотно ставить и мотивационные инструменты в оффлайн плохо переносятся. Однако же мне кажется, наш опыт говорит о том, что у нас не плохо это получилось.
А как вводятся новые разработчики? Руководитель следит за кодом нового человека?
Раз время работы не контролируется - ставятся сроки на задачи? Что если не выполнил или причины сомнительные? Как оценивается срок на реализацию? Что если постановщик ошибся с оценкой и разработчик не по своей вине превысил срок?
А как вводятся новые разработчики? Новый разработчик получает доступы, знакомится с командой и начинает читать документы с конвенциями и архитектурой проекта. После этого ему дают простые небольшие задачи, потом сложность и ответственность увеличивается.
Раз время работы не контролируется - ставятся сроки на задачи?Мы не контроллируем, утром или вечером ты работаешь. Но мы контроллируем, что в неделю человек отработал +- 40 часов, а так же какие задачи он закрыл — и соотносим сложность задачи и итоговый код (который прикрепляется к тикету в JIRA автоматически) с сложностью задачи.
Как оценивается срок на реализацию?Стоимость оценивает разработчик, эпрувит тимлид. Если не согласны, они обсуждают и договариваются о разумной оценке.
Что если постановщик ошибся с оценкой и разработчик не по своей вине превысил срок?Ничего страшного — ошибся ведь из-за чего-то, что что-то не учёл. Теперь он стал мудрнее и знает о новой веще и в будущем сможет лучше сделать оценку )
Где вы публикуете актуальные вакансии? На сайте не нашел раздела.
Самый большой отклик на moikrug, иногда приходят интересные ребята с hh. Был положительный опыт использования сервиса AmazingHiring :-). А так же пиарим — распространяем в Facebook и часто наши вакансии берут на VC.
А если программист и верстальщик фрилансеры? У которых по 3-4 клиента. Был ли у кого опыт создания хорошего проекта с фрилансерами? Или лучше смотреть в сторону штатного удаленного сотрудника?