Дисклеймер. У нас нет «удаленных» сотрудников — в команде все равноудалены друг от друга. Просто кто-то работает (сейчас правильнее сказать «работал») в офисе, а кто-то дома или в коворкинге. Поэтому внутри мы предпочитаем термин «распределенная команда».
Переход на распределенную команду начался довольно давно. Сначала было страшно, но в итоге повысилась эффективность всех сотрудников, даже в офисе. Решили поделиться опытом и собрать развернутый материал по внутренним процессам.
У нас много команд занимающихся разработкой продуктов — есть и по 10 человек, и по 40-50 — но нет ни одной, где все ребята сидели бы рядом в офисе. Зато есть команды, которые полностью работают из дома. Из-за последних событий на «домашний режим» перешли вообще все, но пандемия практически не повлияла на процессы, потому что всё было выстроено заранее.
Дальше — несколько больших разделов о внутренней кухне: онбординг, коммуникации и работа с командой, обмен опытом. А для разнообразия разбавим текст фотографиями наших «домашних офисов».
Онбординг
На базовом уровне процессы одинаковые для всех. Не важно, где работает сотрудник, главное — обеспечить его всем необходимым (в первую очередь — технически), и правильно «погрузить» в работу: какую информацию рассказать в начале, с кем познакомить, что дать почитать, к каким встречам подключить, какую задачу поставить первой и так далее.
За качество онбординга и адаптацию отвечают:
- Менеджер.
- Наставник на период адаптации.
- HR-специалист.
Задачи менеджера. Менеджер координирует работу специалиста с наставником и командой, отвечает за обеспечение всем необходимым, чтобы спустя месяц можно было проанализировать первые результаты.
Основные задачи менеджера на этой стадии:
- Сформировать план адаптации.
- Вместе с наставником подобрать задачи для старта.
- Сформулировать ожидания и обозначить цели на испытательный период.
- Обеспечить погружение в команду и процессы.
- Мониторить результаты и вместе с наставником давать развивающий фидбек.
Задачи наставника. Наставником становится человек, у которого есть прямой опыт в задачах нового специалиста. Цель менторства на старте — пройденный испытательный период с хорошими результатами. Наставник отвечает на вопросы, сопровождает в задачах, помогает с трудностями. Тут важно, чтобы он не делал работу за специалиста.
Менторство завершается после прохождения ИС или раньше (если новичок успешно освоился и начал самостоятельно без ошибок справляться с задачами) — тут все индивидуально. У одного наставника может быть 1-2 новых специалистов одновременно, чтобы хватало времени и на них, и на свои таски.
Задачи HR-специалиста. Он отвечает за процесс онбординга в целом: от взаимодействий с отделом кадров и бухгалтерией при оформлении до координации первых встреч с менеджером и наставником.
Ниже под спойлером — более подробное описание процесса онбординга. Детальные планы разрабатываются каждым отделом и проектом в отдельности, с учетом специфики и особенностей позиций/ролей.
Как происходит процесс онбординга
Общий процесс:
Теперь подробнее про первые встречи. HR на старте проводит два созвона.
Первая встреча с HR (еще до выхода): рассказываем об особенностях оформления и документооборота в зависимости от местонахождения, запрашиваем документы, подписываем электронную версию NDA (чтобы заранее выслать информацию о доступах в корпоративные инструменты), рассказываем о первом рабочем дне и договариваемся о времени созвона для встречи с менеджером и наставником.
Вторая встреча с HR (первый рабочий день): даем доступы, еще раз рассказываем о базовых правилах (условиях гибкого графика, отпуске, бенефитах, больничных в зависимости от локации и так далее), подробнее рассказываем об Asana (а также даем ссылку на задачу в проекте «Онбординг»), называем ключевых сотрудников и напоминаем о назначенных встречах. Обязательно уточняем, не появились ли вопросы.
Следующий этап — встречи с менеджером.
Они помогают во всем разобраться и легче влиться в команду. Старайтесь планировать встречи так, чтобы новичок успевал переварить всю информацию. В первую неделю мы обычно проводим 3 таких синка.
Первая встреча с менеджером (в день выхода). К этому времени у сотрудника уже есть некоторая информация, которую он получил через задачу «Онбординг и адаптация». Лучше знакомиться со специалистом в первой половине дня: помочь расставить приоритеты, подсказать, что стоит почитать и сделать в первую очередь. На ней также говорим про следующие вещи:
Вторая встреча с менеджером. Ко второй встрече сотрудник скорее всего приступил к первой задаче, отталкивайтесь от этого.
Третья встреча с менеджером проводится спустя неделю работы.
Дальше встречаемся с новичком 1-2 раза в неделю, пока он не войдет в рабочий поток. Повестки будут зависеть от результатов, фидбека и так далее.
Встречи с наставником. Задача наставника — поддерживать при выполнении первых задач и обеспечивать передачу знаний, которые затем помогут специалисту выполнять свою работу самостоятельно:
- На этапе рекрутинга определяются менеджер и наставник будущего сотрудника.
- За две недели до выхода нового сотрудника HR ставит в Asana ряд задач по шаблонам: на выход, на онбординг и адаптацию, и на развитие специалиста.
- HR создает в Google Календаре три встречи с помощью Google Meet в первый рабочий день: welcome-встреча с HR, встреча с менеджером, встреча с наставником.
- Менеджер и наставник составляют план адаптации и цели для сотрудника.
- В день выхода HR, менеджер и наставник проводят встречи с сотрудником и знакомят с командой на онлайн-дейлике.
- На 2-3 день работы сотруднику ставятся первые задачи (всё всегда через Asana): несложные, с развернутыми описаниями. В фолловеры ставится наставник, чтобы первым следить за результатами и давать фидбек.
- Через неделю менеджер и наставник проставляют в календаре регулярные встречи (обычно — раз в 1-2 недели).
- Через две недели HR проводит синк с сотрудником: нужно убедиться, что онбординг идёт по плану, новичок влился в работу, ему уделяется должное внимание и т.д.
- Через месяц менеджер проводит ревью по результатам (фиксирует фидбек в задаче по развитию специалиста). Сотрудник заполняет опрос по качеству онбординга, менеджер подводит итоги, а HR анализирует результаты опроса и, при необходимости, обсуждает их с менеджером и наставником
Теперь подробнее про первые встречи. HR на старте проводит два созвона.
Первая встреча с HR (еще до выхода): рассказываем об особенностях оформления и документооборота в зависимости от местонахождения, запрашиваем документы, подписываем электронную версию NDA (чтобы заранее выслать информацию о доступах в корпоративные инструменты), рассказываем о первом рабочем дне и договариваемся о времени созвона для встречи с менеджером и наставником.
Вторая встреча с HR (первый рабочий день): даем доступы, еще раз рассказываем о базовых правилах (условиях гибкого графика, отпуске, бенефитах, больничных в зависимости от локации и так далее), подробнее рассказываем об Asana (а также даем ссылку на задачу в проекте «Онбординг»), называем ключевых сотрудников и напоминаем о назначенных встречах. Обязательно уточняем, не появились ли вопросы.
Следующий этап — встречи с менеджером.
Они помогают во всем разобраться и легче влиться в команду. Старайтесь планировать встречи так, чтобы новичок успевал переварить всю информацию. В первую неделю мы обычно проводим 3 таких синка.
Первая встреча с менеджером (в день выхода). К этому времени у сотрудника уже есть некоторая информация, которую он получил через задачу «Онбординг и адаптация». Лучше знакомиться со специалистом в первой половине дня: помочь расставить приоритеты, подсказать, что стоит почитать и сделать в первую очередь. На ней также говорим про следующие вещи:
- Проект/отдел (где будет работать сотрудник) и планы.
- Документация проекта/отдела.
- Ключевые специалисты в команде (мотивируем писать первому с вопросами, знакомим с наставником и командой).
- Основные процессы, в которых будет участвовать специалист.
- Роль наставника и менеджера (сотрудник должен четко понимать, с какими вопросами к кому идти).
- Цели на ИС и задачи (рассказать об оценке результатов).
- Проекты компании (попросить спокойно в них поиграть — это часть рабочего процесса).
- Следующий синк через 1-2 дня (сотрудник может подготовить свои вопросы).
Вторая встреча с менеджером. Ко второй встрече сотрудник скорее всего приступил к первой задаче, отталкивайтесь от этого.
- Узнайте, как идут дела, все ли понятно. Не напирайте на сроки и наличие результата.
- Расскажите про рабочие инструменты: Asana, Slack и другие. Про внутреннюю Базу Знаний, если такая имеется.
- Спросите, понимает ли новичок роль наставника в команде? Удалось ли с ним познакомиться? Как все прошло?
- Расскажите про регулярные встречи и синки.
- Обсудите возникшие вопросы.
Третья встреча с менеджером проводится спустя неделю работы.
- Узнайте, как идет прогресс, впечатления от проекта и команды.
- Спросите, есть ли трудности с оборудованием, инструментами, поиском информации или чем-либо еще? Расскажите про проект Technical Support в Asana (где оформляются заявки на поддержку) на случай трудностей (и если ранее не рассказывали).
- Если по первым задачам уже можно дать фидбек — дайте.
- Проставьте регулярные статусы 1-1. Расскажите, для чего они нужны.
Дальше встречаемся с новичком 1-2 раза в неделю, пока он не войдет в рабочий поток. Повестки будут зависеть от результатов, фидбека и так далее.
Встречи с наставником. Задача наставника — поддерживать при выполнении первых задач и обеспечивать передачу знаний, которые затем помогут специалисту выполнять свою работу самостоятельно:
- Проводим встречу в первый день: знакомимся, рассказываем о задачах, о роли наставника и воркфлоу.
- Второй раз встречаемся, когда у нового сотрудника появляется первая задача. Обсуждаем постановку и способы решения.
- Затем наставник с менеджером выбирают оптимальный формат взаимодействия. Чаще всего делается ежедневный синк (на 10-15 минут) наставника и новичка по текущим задачам. Через две недели встречи можно реже (раз в 2-3 дня).
Техническое обеспечение
Процесс дефолтный — в первый же день у сотрудника должны быть все необходимые инструменты.
Для этого HR создает специальную задачу по новому сотруднику и назначает на нее ответственного из IT-отдела. В головной задаче «IT New employee Request — Ф.И.» менеджер/наставник утверждает список техники и софта, согласно внутреннему стандарту.
На IT-отделе распределение сабтасков на ответственных, закупка и передача софта в день выхода сотрудника.
Софт по умолчанию: Slack, Chrome, Unity, Sourcetree, OVPN для ноутбуков и работающих вне офиса. В остальном сильно зависит от роли сотрудника и отдела. Выдача доступов идет в основных сервисах сразу после обновления информации по выходу сотрудника в соответствующих директориях.
Коммуникации на удаленке и обмен опытом
Когда люди не сидят рядом в офисе и не сталкиваются на кухне за обедом — вопрос организации коммуникаций становится еще важнее. Инструменты тут общие для всей компании: Asana и Slack для текстовой коммуникации, а для видеовстреч используем Google Meet и Zoom (если много участников или нужно сделать запись доклада/круглого стола).
Коммуникации поделили на несколько основных типов: регулярные встречи, активности вне рабочего процесса и живые встречи. Теперь по порядку.
Регулярные встречи. Видеоконференции, созвоны, коллы — за их эффективностью на удаленке нужно постоянно следить. У нас расписано очень много митов, какие-то проводятся раз в три недели (синк лидов компании), какие-то раз в несколько месяцев (Q&A-сессии по компании в целом). Для удобства занесли все форматы регулярных встреч в Google Sheets. Что туда входит на примере мита 1 на 1 менеджера с сотрудником:
- Тема. 1 на 1 с сотрудником.
- Частота проведения. Раз в две недели.
- Формат. Произвольный (например, созвон по видеосвязи).
- Участники. Менеджер и сотрудник.
- Модератор. Менеджер.
- Повестка. Обмен фидбеком, обсуждение текущих статусов задач, прогресс по последнему фидбеку, обсуждение возникших вопросов и проблем.
- Хранение результатов. Произвольно, в виде текста: Google Docs или задача в Asana.
- Примечания.
Рекомендации для встреч по продукту
Основные принципы:
Встреча по продукту
Цель. Синкнуться по текущему вижену развития продукта, обсудить ключевые продуктовые решения (если есть необходимость).
Периодичность. Раз в две недели, после просмотра билда (когда получен фидбек от всех участников). Повестка крепится в описание, а встреча называется: «Встреча по продукту. <Имя проекта>».
Состав. Producer, Lead GD, Art Director (опционально), внешние продюсеры, Head of Product. На встречу дополнительно может быть приглашен эксперт (из команды или внешний), если есть необходимость.
Повестка. Примеры вопросов для обсуждения:
В шапке обязательно стоит давать ссылку на последний билд, чтобы каждый участник мог ознакомиться.
Подготовка к встрече. За 1-2 дня до встречи продюсер обновляет повестку, затем присылает ссылку остальным участниками встречи, чтобы каждый участник встречи заранее приготовил вопросы.
- Присутствие каждого участника должно быть обосновано.
- В повестке должны фиксироваться решения и договоренности. После встречи — создаются задачи в Asana и запускаются в работу по приоритету.
- На каждой встрече должен быть виден прогресс по ключевым вопросам. Договоренности и задачи не должны теряться.
- Фоллоу ап — после каждой встречи. Для этого можно создать постоянную задачу «Встреча по проекту/продукту», добавить участников и фиксировать информацию.
- Для небольших проектов (или на ранней стадии) проводить одну встречу, где обсуждать и продуктовые аспекты, и ход разработки. Когда количество вопросов для обсуждения увеличится, то можно разделить встречу на две: по продукту и по проекту.
Встреча по продукту
Цель. Синкнуться по текущему вижену развития продукта, обсудить ключевые продуктовые решения (если есть необходимость).
Периодичность. Раз в две недели, после просмотра билда (когда получен фидбек от всех участников). Повестка крепится в описание, а встреча называется: «Встреча по продукту. <Имя проекта>».
Состав. Producer, Lead GD, Art Director (опционально), внешние продюсеры, Head of Product. На встречу дополнительно может быть приглашен эксперт (из команды или внешний), если есть необходимость.
Повестка. Примеры вопросов для обсуждения:
- Видение по продукту: какой продукт мы делаем и для кого.
- Ключевые особенности и фичи с кратким описанием.
- Обсуждение последнего фидбека по билду, снятие противоречий.
- Мы ощущаем прогресс продукта? Он развивается правильно?
- Что можно улучшить? Какие есть идеи?
- На чем сейчас стоит сфокусироваться?
В шапке обязательно стоит давать ссылку на последний билд, чтобы каждый участник мог ознакомиться.
Подготовка к встрече. За 1-2 дня до встречи продюсер обновляет повестку, затем присылает ссылку остальным участниками встречи, чтобы каждый участник встречи заранее приготовил вопросы.
Ретроспективы внутри команд. Еще один пример регулярных встреч, опишу отдельно. Многие недооценивают его эффективность, но на деле с ним мало что сравнится.
Ретроспектива — это встреча, на которой команда находит и исправляет проблемы в процессах. Казалось бы, менеджер может это сделать и без отдельных созвонов. Но именно такой формат позволяет вовлечь всех участников и избежать феномена Not invented here (когда люди не чувствуют сопричастности к принятию решений и подсознательно противятся вещам, «спущенным сверху»).
В основе лежит концепция цикла Деминга (PDCA — Plan-Do-Check-Act или Планируй-Сделай-Проверь-Реши). Цель: получить план действий (задач), которые исправят проблемы и что-то улучшат. Сама ретроспектива — это стадия Plan в цикле.
Разницы между между обычной рабочей встречей и ретроспективой — в неформальности. Чем доверительнее атмосфера, тем больше профита все получат. Существуют специальные упражнения, чтобы разговорить участников, найти проблемы и способы их решения. Подсмотреть можно, например, в книге «Быстрый старт в ретроспективы» Алексея Кривицкого.
Строгого расписания ретроспектив нет, привязываемся к каким-то майлстоунам — выпуск нового проекта или окончание очередного спринта. Всё в онлайне, а в качестве доски со стикерами используем Miro.
Несколько рекомендаций по ретроспективе:
- Не стоит в этот момент заниматься задачами, отвлекаться на трекер или мессенджер. Это сложно сделать, когда все сидят дома за своими компьютерами, но возможно.
- Никаких посторонних. Только коллеги, которые работают вместе.
- Не превращайте ретроспективу в книгу жалоб. Профита не будет, если все будут искать виноватых. Ведущий должен следить за конструктивностью — жалобу превращать в сформулированную проблему, а выяснение личных отношений попросту пресекать.
- Обязательно фиксируйте итоги ретроспективы так, чтобы к ним в любой момент был доступ для участников.
И самое главное, чтобы это все работало: план и обещания, данные на ретроспективе, должны выполнятся. Если раз за разом вы будете собираться, общаться, записывать задачи, но ничего не будет меняться — доверие к ретро пропадет, а люди вообще перестанут говорить о проблемах. Поэтому убедитесь, что план понятен для всех, у него есть ответственные и он выполняется.
Активности вне рабочего процесса. Например, «техническая пятница» или «день обучения» раз в две недели. В эти дни мы не работаем над проектами, а проводим круглые столы, доклады, воркшопы и ретроспективу выпущенных продуктов (продакт-оунеры рассказывают, какие результаты показали продукты на рынке и не только).
Также оставляем свободное время для самостоятельной работы — у нас есть внутренняя система обучения, а наставники выкладывают прикладные уроки/задания, которые помогут прокачать скиллы. В рабочее время не всегда удается выделить время, но в тех. пятницу — пожалуйста. Всё это проходит онлайн, используем Zoom, потому что он умеет сохранять запись.
Например, недавно делали пошаговый урок по созданию эффекта выстрела из пушки.
Промежуточный скриншот урока
Встречи команд вживую. Тут всё просто. Стараемся раз в 6-7 месяцев собирать каждую команду в одном из офисов — поработать и пообщаться вживую.
Обучение и развитие
Мы пришли к достаточно простой внутренней системе развития сотрудников. Ее основные компоненты:
- Анализ результатов работы + карта компетенций.
- Развитие через фидбек.
- Наставничество и регулярные встречи с ментором.
Каждый месяц проходят встречи по командам. Менеджер готовит анализ результатов работы по каждому специалисту, собирает мнения коллег и делает выводы. На встрече говорим об успехах каждого сотрудника, смотрим на прогресс, результаты и даем фидбек.
Карта компетенций — это портрет идеального специалиста с учетом контекста и требований проекта. Например, мы стараемся качать художников-дженералистов (универсальных спецалистов, которые, кроме 2D, могут делать что-то еще — FX или анимацию). Карта делается в виде Google Таблицы, где отмечается уровень скилла специалиста в каждой области — базовые навыки (основы 3D, UI/UX, FX и так далее) и софт-скиллы (ответственность, коммуникабельность, инициативность, наставничество).
В фидбеке для сотрудника отмечаем области роста и даем для этого релевантные задачи.
Анализ работы. Как он проходит и из чего состоит:
- Ежемесячный анализ. Это промежуточный чек, чтобы увидеть прогресс, внести коррективы в работу, дать фидбек и так далее.
- Ежеквартальный анализ. Сбор расширенного фидбека.
Менеджер дает фидбек на статусе с сотрудником 1 на 1. Лид и/или наставник по развитию этим тоже занимаются, но обычно прямо в процессе работы и по той области, в которой работает сотрудник.
Важно: фидбек сотруднику выдается в том виде, в каком его заапрувила команда оценки (без срезания углов, смягчения каких-либо моментов). Дополнительно все фиксируется в текстовом виде, чтобы к нему можно было вернуться.
Сам процесс дачи обратной связи в офисе или удаленно — не отличается. Создайте благоприятную атмосферу, слушайте и анализируйте, что и как говорит человек. За ответом «все хорошо», может скрываться недовольство, или сотрудник просто стесняется. А в конце встречи спросите фидбек у сотрудника, полезны ли для него эти встречи.
Если проблемная зона есть у нескольких специалистов, мы делаем «обучалки» или курсы по нужной теме (доклады и воркшопы). На каждый такой мини-курс есть чат, в который наставники закидывают урок, а остальные проходят, делятся и получают отзывы.
В целом, все отделы работают по принципу мини-команд. Стараемся в некоторые команды подключать ребят из смежных отделов — это помогает делиться экспертизой, применять уже обкатанные решения и не изобретать велосипед.
Также хорошо работают круглые столы и доклады внутри отделов. Впоследствии любой желающий может посмотреть и перенять опыт.
Разработка на удаленке — есть ли отличия
Кардинальных различий нет. Все, что мы делаем — мы могли бы делать в офисе. Просто на расстоянии некоторым моментам надо уделять больше внимания. В первую очередь — коммуникациям, прозрачности принятия решений (в том числе — продуктовых) и качеству проектной документации.
При этом преимуществ у дистанционной работы гораздо больше. Мы не ограничены отдельными регионами при поиске специалистов, а процессы не привязываются к конкретным офисам и выстраиваются так, чтобы к ним в любой момент мог подключиться новый сотрудник. Например, результаты любых созвонов или личных встреч фиксируем в Asana или Google Docs — если вас подключили к задаче даже спустя полгода, вы все равно увидите всю историю сообщений с фоллоу апами встреч.
В работе распределенной команды очень много письменных коммуникаций, поэтому нужно научиться четко формулировать мысли, без спама и следить за тем, что и как ты пишешь.
Как показывает практика, люди по-разному истолковывают эмоциональный характер сообщений. Некоторые даже могут обидеться, потому что увидели претензию или недовольство, которых не было. В офисе это не так актуально.
Работа менеджеров на удаленке изначально зависит от того, как строилась работа до появления распределенной команды. Если бы у нас изначально не было бы регулярных активностей, планирование и мониторинг производства осуществлялись хаотично, а вместо документации был сборник легенд и былин — то, конечно, всё бы сильно поменялось. Просто потому что все процессы сломались бы работать на удаленке.
Если же процессы настроены заранее, то потребуется лишь переехать в онлайн и помочь команде адаптироваться для работы из дома.
uss
если бы люди были бы роботами статья была бы правдой :)
по факту:
завуалирован контроль, невозможность совместного решения задачи(любая дизайн проблема), руководитель имея дело с живими людьми пользуется речью, пользуется слабыми местами людей(делаем летучку и спрашиваем у человека, который не очень ладит с отстаиванием своего мнения перед толпой что либо, получаем 99% вероятности что он, между, тупо согласится и сказать своё мнение выберет промолчать и тупо согласится, а на удалёнке что? правильно индивидуальный подход, вытирание у всех соплей и понимание их родимых… в итоге вместо решения задач что делаем? играем в симулятор няни)
сколько людей умеют формулировать свою речь в тексте? кажется что все но на деле это далеко не так и это порождает проблемы: замалчивание проблем, трата времени на формулировку проблемы(в живую то не скажешь что мол вот подойди и глянь это всё не то… скрины-показывание экрана и прочее это не тот эффект совершенно особенно в творческой среде.
+ будем реалистами большая часть руководителей руководит как раз из за своих навыков общения а не из за технического превосходства перед другими работниками и удалёнка это огромное испытание для всех и вся но живой коллектив выиграет перед разрозненным на порядок потому возврат в офисы неизбежен
(сугубо моё мнение не стоит начинать холивар и посылать лучи ненависти :) )
mopsicus
Наверняка это задача отдела HR и первичных интервью, чтобы отсеять людей неспособных самостоятельно себя организовать и работать. Кроме того, уже давно контроль как таковой не на первом месте, главное результат. Если человек в поставленные сроки делает свою работу, то не важно, чем он в остальное время занимается.
uss
мы говорим о играх или о тетрисах?(игры это не копипаста это творчество)
мы говорим о реальной команде с джунами или о команде состоящей сугубо из про-разработчиков?
я вот себе не представляю как на удалёнке написать пубг-бдо-колофдьюти-прочие мобайл естественно если у кого(не обязательно автора) есть пример мол вот смотрите мы сделали игру(именно большую игру так как если можно сделать большую можно сделать и маленькую, а вот обратное утверждение не верно) на удалёнке командой из 20+людей и вот что у нас вышло я был бы не прав на 101%, а так выглядит просто как мечта полёта на марс в 2025 :) реально ли? ДА! это случится? НЕТ!
mopsicus
Если вы этого не представляете, ещё не значит, что этого не может быть.
У многих крупных компаний (в том числе и игровых) куча людей работает удаленно, десятки и сотни, это факт.
uss
атомные электростанции аутсорсят админов для бухгалтерии НЕ значит, что атомная электростанция может работать по удалёнке ведь правда?
удалённая работа существует уже более десятилетия точно покажите хоть один таковой продукт?
mopsicus
Если вам интересно – поищите, гугл работает.
uss
а я даже искал :)
мой ответ НОЛЬ
есть примеры ака удалёнка(линукс, куча апи, великое множесто библиотек НО критическим отличием от работы компании является то, что там люди уже мотивированы, приобретают навыки самостоятельно, не требуют оплаты, рабочего места… если мы говорим о коммерческом продукте то там всего этого нет в самой сути потому и примеров коммерческих продуктов созданных на удалёнке тоже нет)
глупо спорить с фактами реалий 2020… может в 2220 :) будет по другому но в мете 2020 есть как есть
fomonster
Плохо искали. Есть. Работаю уже 5 лет в такой компании.
uss
барабанная дробь
ПРИМЕР большой, хорошей, сложной в реализации игры(с полным циклом разработки удалённо как автор статьи пишет), которая составляет конкуренцию ааа лейблам(приме маленькой, простой, клоновой игры только подтвердит что удалёнка и качественный продукт живут в разных реальностях)? :)
Upproret
Например, Ori and the Will of the Wisps. Команда состоит из более чем 80 человек, живущих в 43 странах.
Информация взята из интервью: www.gamesindustry.biz/articles/2020-03-10-building-ori-and-the-will-of-the-wisps-with-80-people-working-from-home
Simipa
Gitlab полностью удаленный
uss
и там есть коммерческие продукты игростройные ну хоть один ну пожалуйста не будьте пустозвоном :)
Simipa
Я не понял суть вопроса. Если интересен удаленный игровой проект, то Ori and the Blind Forest была разработана полностью удаленной командой в 80 человек
uss
при всём уважении ПЛАТФОРМЕР?!
чуть выше по тексту просил примеры ака конкуренты переднего края игростроя, а вы занесли пример успешного но извольте с програмной точки зрения примитивного удалённого игростроя
так что майнкрафт ещё поболее денег собрал и он ещё более антиофисный.
не понижайте планку до уровня «деньги»
www.lookatme.ru/mag/live/industry-research/212581-ori-and-the-blind-forest
цитата:
С Ori and the Blind Forest получилось так: первый прототип я смастерил за две недели, и у него уже было хорошее управление, близкое к финальной версии.