Документ описывает шесть основных ловушек и рисков, возникающих при изменении структуры команд, таких как недостаток прозрачности и демотивация участников. Для каждой ловушки предложены индикаторы, потенциальные риски и превентивные меры, направленные на поддержание эффективности работы. Основное внимание уделяется необходимости вовлечения команды в принятие решений и поддержанию документации, чтобы избежать ошибок и улучшить рабочие процессы.

1. From distributed to
collocated team:
traps & pitfalls.

2. Expectations

3. Reality
6 ловушек,
поджидающих нас
при изменениях и
перестройке
команды.

4. 1. «А что мы
решаем?»
• Case:
1. Решение не той
проблемы.
2. Решение принято
менеджментом, не
спрашивая
команду.

5. Индикаторы.
• «Что происходит?»
• «Зачем это всё надо?»
• «Они там что-то решили, мне всё равно.»
• «Нас вечно никто не спрашивает.»
• «А чего я добиваюсь?»

6. Риски.
1. К старым проблемам добавляются новые и
непредсказуемые.
2. Команда демотивирована и пассивна.

7. Превентивные меры.
• Сначала ищем проблему, потом находим под неё
решение. Не путаем эксперименты с решениями.
• Обсудить с командой подход и возможные риски. Не
пренебрегать мнением, даже если считаете
высказавшихся пессимистами и «нытиками».

8. 2. «Мы изменились, а мир нет.»
• Case:
Процессы и среда
оказались не адаптированы
к новой организационной
структуре.

9. Индикаторы.
• Вы и ваши команды не находят себе места в текущем
сетапе.
• «Я не знаю, как сделать и у кого спросить.»
• «Что делать, если случилось..?»
• «А кто теперь вместо %userrole%?»
• Текущие процессы оказываются сложными
и неприменимыми.

10. Риски.
• Хаос и вакханалия.
Потеря контроля и
предсказуемости
работы.

11. Превентивные меры.
• Придётся думать заранее. =)
• Продумать аналоги всем событиям и церемониям,
которые кажутся неудобными.
• Провести риск-анализ и разработать структуру, в
которой вам хотите работать.

12. 3. «А что это
вы там
делаете?»
Case:
Синхронизация
решений
(бизнес и
технических) со
стейкхолдерами
и/или другими
командами.
Прозрачность
работы.

13. Индикаторы.
• Постоянные переделывания.
• Микроменеджмент со стороны стейкхоледров.
• Нечастая синхронизация.
• «Я думаю, что должно быть так.»
• «Undevelop!»

14. Риски.
1. Создание не того продукта.
2. Многократное переделывание из-за несогласованных
технических решений или изменившихся
требований.
3. Потеря доверия и репутационные риски.

15. Превентивные меры.
• Регулярная синхронизация, инициируемая со
стороны команды.
• Митинги по дизайну, архитектуре и требованиям.
• Регулярные ревью работы и рефайнменты.
• Синхронизация с другими тех.специалистами и
командами, чтобы иметь всю информацию.

16. 4. «Да мы же
все рядом.»
• Case:
Иллюзия, что работа
в одной команде
избавляет от
бюрократии и
ведения
документации.

17. Индикаторы.
• «Ой, да мы же все рядом.»
• «Что, разве сложно спросить?»
• «Зачем двигать таски, мы и так знаем, кто что делает.»
• Зачем эта бюрократия?»
• «Давай сейчас быстро поменяем, а потом запишем.»
• «У нас agile, а в манифесте написано,
что communication over documentation!»

18. Риски.
1. Потеря vision продукта или фичи. Рассинхронизация
реального продукта с требованиями и проблема с
тестированием.
2. Усложнение любого onboarding-процесса.
3. Потеря любого члена команды – это потеря
множества «сакральных» знаний.

19. Превентивные меры.
• Вводить простые правила поддержания документации
и требований.
• Сделать 1 источник основным, чтобы облегчить
поддержку.
• Backlog maintenance best practices.
• Не бояться форсировать правила.
• Эксперименты с вводом нового человека
в команду.

20. 5. «Колхоз и
групповая порука »
• Case:
Размытие зон
ответственности внутри
команды.
Перекладывание
ответственности за
ошибки на членов вне
команды.
Нестрогое применение
стандартов качества.

21. Индикаторы.
• Спагетти-код.
• Слишком быстрые код-ревью без замечаний.
• Невозможность проследить, откуда взялся тех.дизайн.
• Всегда виноват кто-то вне команды.

22. Риски.
1. Падение качества продукта (технического дизайна,
кода и тестирования).
2. Невозможность root-cause анализа последствий.
3. Peer-pressure.

23. Превентивные меры.
• Политика придерживания стандартов.
• Внешние код-ревью.
• Условное разделение по компонентам.
• Дизайн-митинги для обсуждения технической
реализации.

24. 6. «Д’Артаньяны»
Case:
Самоизоляция и
зацикливание на
привычных решениях.
Устаревание знаний и
потеря компетенции в
специфических задачах.

25. Индикаторы.
• «Да там одни д*билы сидят!»
• «Мы и сами знаем, как лучше.»
• «Да что там работы.»
• «Что он нам может рассказать, всё есть в интернете.»
• «Там они джуниоры, поэтому только мы должны
поехать на %дорогая конференция%».

26. Риски.
1. Потеря качества.
2. Применение привычных, но неподходящих подходов.
3. Отсутствие знаний о других рынках и новых
подходах, неизвестных в наших реалиях.
4. Утрата актуальности знаний.
5. Игнорирование других команд и отказ
делиться знаниями.

27. Превентивные меры.
• Поощрение коммуникации с другими командами и
саморазвития на местах.
• Командировки для обмена знаний.
• Сторонние эксперты с подтверждённой экспертизой.
• Конференции с представителями других рынков.

29. Contacts:
Facebook:
Julia Svistun
Email:
svistun.yulia@gmail.com
https://www.facebook.com/gealai
LinkedIn:
Julia Svistun
https://www.linkedin.com/in/
julia-svistun-6933a4a4/