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

Зміна remote стає такою ж простою, як зміна робочого простору Slack.

Чи звучить це для вас страшно при першому прочитанні? Якщо так, то, ймовірно, ви, як і я, є засновником або керівником remote . Але дозвольте мені сказати вам дещо — це найкраще, що може трапитися з вашою компанією:

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

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

Щодня мільйони учасників відкритих проектів (OS) присвячують значну частину свого часу проектам, навіть не зустрічаючись з колегами. Чи це божевілля? Ні, зовсім ні. Вони можуть сидіти поруч з вами в офісі, раді спілкуватися та йти на обід.

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

1. Висока відповідність найму місії має вирішальне значення для remote .

Я не можу уявити організаційної структури, в якій би краще узгоджувалися інтереси окремих учасників та довгострокова місія проекту, ніж в OSS. Учасники відкритого програмного забезпечення приєднуються (наймають себе) до спільноти шляхом активної участі, не маючи жодних початкових стимулів, окрім своєї пристрасті до великої мети проекту та перспективи стати частиною спільноти однодумців, які об'єднуються навколо нього. Найближче до такого рівня узгодження між наймом і місією традиційна компанія може наблизитися, якщо наймати виключно своїх найвідданіших клієнтів. Це дуже важко досягти в масштабі. Проте, особливо в remote , чітке узгодження з місією є обов'язковою умовою. Щоб залучити таланти, які мають високу відповідність вашій місії, ми, remote , повинні думати більше як проекти OSS: публікувати та поширювати контент про вашу місію, ваших клієнтів, вашу культуру та вашу команду, щоб дати заявникам прозоре уявлення про вашу компанію. Рух «будівництво на публіці» надихає, і ми в tl;dv прагнемо робити це все більше і більше, оскільки віримо, що це найкращий спосіб залучити однодумців. 

2. Прозора документація та процеси сприяють автономії та незалежності

Написання коду, перегляд коду, створення контенту... можливості внеску в OSS є різноманітними. Проекти з відкритим кодом повинні бути розроблені таким чином, щоб кожен новий член спільноти міг самостійно робити свій внесок. Тому кожен проект має чітко визначені принципи спільноти, детальну документацію, а також дуже прозору систему співпраці, яка дозволяє окремим учасникам відстежувати еволюцію проектів, а також індивідуальний внесок колег. Подібно до OSS, успішні remote прагнуть розробляти свою документацію та робочі процеси таким чином, щоб максимально сприяти незалежності своїх співробітників та прозорості. Спочатку це досить складне завдання, але його вплив на швидкість роботи вашої команди з часом посилюється, і з кожним новим співробітником, якого ви наймаєте. Ми також продовжуємо вчитися, як покращувати та підтримувати нашу документацію та процеси. Ми рекомендуємо амбітним remote розпочати цей процес з першого дня, це того варте! Деякі корисні джерела натхнення для початку — це Aula Brain і, звичайно, GitLab Handbook.

3. Асинхронні комунікації

Я вже згадував про добре продуману документацію та процеси в проектах з відкритим кодом, але також і канали комунікації в проектах з відкритим кодом здебільшого є асинхронними. GitHub, Discord, спеціальні форуми... більшість проблем вирішуються повністю асинхронно. Для деяких читачів це може бути шоком, але зараз процвітають багатомільйонні компанії, які ніколи не потребували жодної наради. Бум. Це ставить все на свої місця, чи не так? Це чудовий орієнтир для будь-якої remote , і асинхронність, безсумнівно, має бути стандартним режимом комунікації. Чудовим практичним правилом може бути те, що зустріч потрібна, коли 3 повідомлення вперед-назад не можуть вирішити проблему асинхронно. Більшість (99,9%) remote не повинні покладатися виключно на асинхронну комунікацію, оскільки вони зазвичай є більш гетерогенною групою людей і, як правило, дещо менш інженерно-орієнтованими, ніж спільнота OSS. Більш «традиційні» remote складаються з різноманітних професійних фахівців, справжнього плавильного котла з продажів, HR, маркетингу, успіху клієнтів, фінансів та програмної інженерії, де зустрічі важливі для забезпечення емоційної згуртованості всередині компанії. Зрештою, більшість нашого спілкування є невербальним. Деякі дослідження, такі як звіт Міннесотського державного університету, навіть стверджують, що 93% нашого спілкування є невербальним. Зустрічі мають вирішальне значення для започаткування та розвитку співпраці, досліджень, генерування ідей та інсайтів, надання зворотного зв'язку та прийняття бізнес-рішень. За допомогою tl;dv ви можете впровадити зустрічі, орієнтовані на асинхронну комунікацію, у свій стек remote та досягти правильного балансу.

Отже… майбутнє remote схожим на ОС?

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

Давайте відкинемо всі технічні описи: хто не хоче отримувати зарплату за роботу над проблемами , які вам дійсно важливо вирішити, разом з людьми, яким це теж важливо? 😉

Майбутнє є світлим!