​Пока авторитетные люди пытаются разобраться, кто короновал вирус, огромное количество продуктовых команд внезапно для себя стали удалёнными (внушительный список по миру). Это непростой формат работы и без подготовки запустить его сложновато (примерно как провернуть agile-трансформацию за две недели).

Но вариантов нет, так что надо учиться на ходу. Вот пачка годных советов для распределённых дизайн-команд, которые выходили за последнее время:

ОПЫТ КОМПАНИЙ
1. GitLab давно работает полностью удалённо и собрали целую мини-википедию.

2. Trello. К некоторым из них доступны шаблоны.

3. Shopify (и ещё статейка). Сложность зависит от степени распределённости и, как ни странно, проще всего с полностью рассредоточенными людьми — тогда не возникает локальной группы, которая неизбежно становится ядром всех активностей.

4. Microsoft: как объединялись разрозненные дизайн-команды, работающие над Outlook.

5. Cisco.

6. Nielsen/Norman Group. Компания все годы своего существования работала без офиса.

7. Google.

8. Facebook.

9. Salesforce.

10. Zendesk. Практики и методы с учётом нескольких стран и временных зон.

11. Jeff Gothelf.

12. Mark Boulton.

МЕТОДЫ И ИНСТРУМЕНТЫ
1. Встречи 1 на 1 в Miro. Шаблон для фиксации тем обсуждений и результатов.

2. Бренд-спринт при ребрендинге Miro.

3. Nielsen/Norman Group: Инструменты для проведения удалённых рабочих сессий. Генерация и оценка идей, картирование. Их прошлая статья про создание CJM в таком формате.

4. То же от Cisco.

5. Синхронный и асинхронный подход к генерации идей.

Большинство знаковых конфренций и массовых мероприятий в мире отменены или перенесены. А пользовательские исследования переходят на удалённый формат. Зато растут акции Zoom. А тот же InVision изначально работает полностью удалённо.

Кстати, Елена Малышева советует не забыть помыть руки 20 секунд после прочтения этого сообщения — наверняка ваш телефон давно не мыт :)

#remote #designmanagement

Курс лекций аспирантуры MIT по распределённым системам от Роберта Морриса

https://www.youtube.com/watch?v=cQP8WApzIQQ&list=PLrw6a1wE39_tb2fErI4-WkMbsvGQk9_UB

Сага в четырёх частях от СЕО Percona Петра Зайцева о мониторинге производительности в Linux и типичных ошибках:

- Часть первая: CPU
- Часть вторая: Disk
- Часть третья: Memory
- Часть четвёртая: Network

Очень хороший разбор, рекомендую к прочтению 👍

#observability

Как в Slack подходят к росту тимлидов внутри команды.
https://slackhq.com/develop-engineering-team-leaders

Очень (очень!) хорошая статья от Nuclino о том, почему никто не читает документацию, почему это нормально и варианты разрешения этой ситуации. Nuclino сами занимаются разботкой софта для Обмена Знаниями, такой себе аналог Notion, поэтому они знают о чем говорят.

Статья написана просто прекрасно, еще и без запихивания рекламы своего продукта глубоко всем нам в горло.

Ключевые моментики из статьи:

- Никто не читает документацию и это ОК
- Документация нужна не чтобы её читать, а чтобы с ней консультироваться
- Не пишите документацию, только ради написания. Никому не нужен огромный, толстый, пускай и всеобъемлющий кусок текста
- Пишите документацию держа в голове то, что скорее всего, её будут искать в поиске, а не просматривать все оглавления
- Пишите небольшие кусочки документации и пользуйтесь кросс-ссылками, ссылаясь на другие, такие же небольшие кусочки док.

Бонусный трек: их же статья про ценность документации и сколько может стоить отказ от обмена знаниями.

Онбординг-книга новых сотрудников Valve. Хоть и с 2012 года очень много воды утекло, но все равно очень кайфово читать.
https://dtf.ru/life/191528-rukovodstvo-dlya-novyh-sotrudnikov-valve-na-russkom-yazyke

https://www.perforce.com/blog/qac/8-tips-working-legacy-code в целом нормальные советы по работе с легаси.

Я тут решил начать пересказывать в разных местах тимлидконф своими словами - https://g-mate.timepad.ru/event/1472018/ Только ленивый про это ещё не говорил, пришла моя очередь. Точнее я про это тоже говорил в Воронеже года два назад, но записи с GDG нет в открытом доступе, поэтому не считается.