Робота з distributed-командами на високому рівні складності

Десь у світі починається тенденція повернення до офісів. Десь працівники змогли це забойкотувати, десь – ні. Але, незважаючи на тенденції, distributed-команди давно вже стали таким собі золотим стандартом. Коли ви чуєте про розподілені команди, що ви відчуваєте? Страх перед нескінченними мітингами? Нерозуміння, куди писати з якихось питань? Неможливість планування дедлайнів через те, що «ота команда не здатна запланувати те, що нам треба»? А якщо я скажу, що можна інакше? Усе, що написано нижче, неодноразово впроваджувалось особисто мною та кількома знайомими менеджерами.

1. Визначте правила взаємодії та очікувані SLA

- Якщо цього не було зроблено до вас, чітко регламентуйте, коли і як ви спілкуєтеся (email, месенджери, таск-трекери), а також, які канали призначені для термінових питань (наприклад, Slack чи Microsoft Teams із позначкою «urgent»).
- Домовтеся, за який час треба дати відповідь на запити (наприклад, 24 години на лист, 2-3 години на терміновий запит) – SLA, що узгоджені на рівні компанії, дадуть вам розуміння дедлайнів, коли ви ТОЧНО отримаєте відповідь.

2. Тільки асинхронна робота

- Хоча кількість мітингів треба мінімізувати, ви не зможете зовсім відмовитись від онлайн-зустрічей. І кожен мітинг повинен бути нести цінність. Після кожного мітинга у вас повинні бути нотатки, що містять ключові теми, що обговорювалися. Та action points (хто, що, як і коли зробить). Якщо цього ще не зробити до вас – затвердіть шаблон рекапу мітинга на рівні компанії. Ці нотатки повинні бути у доступі у конкретному місті, де зберігається ваша документація.
- Вам не потрібні мітинги, щоб дати апдейти. Актуалізуйте таск у таск-трекінговій системі, надішліть лист усім зацікавленим сторонам – у будь-який спосіб повідомте про апдейт асинхронно.

3. Відстежуйте продуктивність та якість

- Те, що не вимірюється, не може бути покращено. Тому обов’язково почніть рахувати ключові показники для типових дій – як скоротився час відгуку, як швидко виконуються типові завдання тощо.
- Використовуйте усі можливості вже наявних інструментів. Наприклад, Jira здатна сформувати безліч репортів «за замовчуванням», навіть без додаткових плагінів.

4. Враховуйте культурні та часові особливості

- Колись я прочитав фразу «Ви повинні бути кращим другом для ваших клієнтів». Якщо трошки її розширити, то треба бути кращим другом для усіх стейкхолдерів. Так, ви повинні знати, які свята у індусів, з якими ви співпрацюєте. Ви повинні знати, коли ДН у CEO компанії, що він любить. Та як вести перемовини з ним, враховуючи його походження.
- Small talk. Обов’язково розповідайте щось про себе, давайте більше контексту. Просто покажіть, що ви – жива людина. І ставтесь до інших також як до живих людей, яким притаманні особливості.

5. Підтримуйте прозорість і спільне бачення

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

Ну і на останок. Прозорість – це ключ до зменшення несподіванок. А неподіванки ну дуже рідко бувають приємними.

Що почитати на цю тему:

- Гайд «GitLab’s Guide to All-Remote»
- Стаття «How to Collaborate Effectively If Your Team Is Remote»
- Книга «Remote: Office Not Required» (автори: Jason Fried та David Heinemeier Hansson)