4 основы культуры совместной работы

Безопасность, скорость, ясность и ответственность.

4 столпа культуры совместной работы

Делятся ли все в вашей команде идеями регулярно? Высказывают ли они обратную связь или задают вопросы? Могут ли они проявлять уязвимость? Безопасно оспаривать даже миссию?

Для культуры совместной работы существуют 4 ключевых столпа:

• Безопасность.
• Скорость.
• Прозрачность.
• Приверженность.

Первые два существенно влияют друг на друга: Безопасность и Скорость. Остальные два столпа обеспечат, чтобы ваш процесс приносил ценность как в краткосрочной, так и в долгосрочной перспективе.

4 столпа

• Безопасность: Безопасно ли ошибаться? Поощряется ли экспериментирование?
  • «Неудача» — это всегда возможность учиться и улучшать процессы.
  • Обсуждается ли и приветствуется смена обстоятельств и/или мнения?
  • Руководство должно акцентировать внимание на выводах из «отклонённых» предложений. Даже если ни одно предложение не «победило»
  • Показывать, где уместен анализ первопричин? (Не противоречило ли это OKR? Могло ли руководство уточнить или сузить цели?)
• Скорость: Сколько времени должно уходить на подготовку черновика?
  • Ориентир: в идеале 1–20 минут; допустимый максимум — 2 часа.
  • Скорость здесь означает эффективность. Это экономит время КАК ваше, так и время коллег.
• Прозрачность: Формулируете ли вы чёткие и исполнимые решения? Понятна ли ценность для всех вовлечённых сторон? Учитывайте выгоду для внешних команд от раннего информирования, чтобы избежать потраченных усилий на код, который может вызвать вопросы у юристов и специалистов по комплаенсу.
• Приверженность: Можете ли вы найти решения, принятые 2 недели назад? 3 спринта назад? Если нет, нет смысла тратить много времени

Командам следует определить свои нормы и ожидания

Совет: Обсудите и определите оптимальный формат работы команды. Корректируйте по мере необходимости.

Зафиксируйте результаты максимально лаконично, например:

• Для всего, что связано с UI, в начале предпочтительны скриншоты.
• Предпочтителен текстовый свод в одну строку. (Для BizDev или новых фич используйте один абзац.)
• В предлагаемых решениях до дедлайна финального решения включайте мокапы экранов.
• Формулируйте конкретные рекомендации по лейблам: (например, Urgent, [Team-Name], Needs C-Level Approval, Hackathon, Spike related.)

Учитывайте специфику вашей команды

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

• Задавайте четкие и минимальные ожидания. Обычно это регламентируется по ролям или подразделениям (например, финансы, безопасность, реагирование на инциденты, инженерия, топ-менеджмент.)
  • Ни один черновик не слишком «сырой» для обсуждения. (Используйте понятные лейблы, чтобы пометить такие версии.)
  • Требуется ли безупречное написание и грамматика? (Для предложений топ-менеджменту — да. Но при разборе инцидентов безопасности грамматике могут отдать приоритет ниже.)
  • Предпочитаете ли наброски или диаграммы? (Для изменений в сетевой инфраструктуре могут требоваться блок-схемы. В некоторых командах нормой могут быть прогнозы продаж.)
  • Ожидается ли, что автор предложит решение проблемы? (Или временный «соломенный» вариант для обсуждения?)
• Показывайте несколько примеров предложений
  • Создавайте краткие примеры для каждого формата.
  • Используйте ожидающие решения как повод вовлечь коллег.
• В зависимости от состава группы рассмотрите внедрение Кодекса поведения
  • Критично, если в процесс вовлечены сторонние лица, фрилансеры, сообщество Open Source и т.п.
• Эмпатия
  • Делиться идеями часто тревожно. Это нормально: даже опытные специалисты волнуются перед презентацией.
  • Учитывайте предпочтения и потребности в коммуникации членов вашей команды.
  • Регулярно обсуждайте это с группой (или индивидуально). Часто короткая парная сессия или мозговой штурм помогают снять блокировку и перезагрузить контекст.

Совет: Привыкайте публиковать предложение сразу после того, как сформулирован заголовок. Нормально, если статус останется draft на какое-то время. Как только предложение готово к следующему этапу, подключайте стейкхолдеров, обсуждайте детали и двигайте процесс дальше. По мере проработки предложений бэклог черновых идей превращается в источник возможностей. Отмечаете ли вы свежие идеи? Поддерживаете ли вы «неочевидные» предложения? Это напрямую влияет на ценность и объем поступающих идей.

Сознательно моделируйте поведение, которое хотите видеть.

Охват и ожидания

Насколько это возможно, процесс ответа на предложение должен сводиться к нескольким кликам.

Решите, нужна ли вам развёрнутая аналитика с подробными комментариями, быстрая однострочная заметка или даже голосование эмодзи.

Ожидания должны быть прозрачными. Попытки обозначить уровень качества через метки вроде «В РАЗРАБОТКЕ» или «ЗАПРОС МНЕНИЙ ПО РЕАЛИЗУЕМОСТИ» обычно не мотивируют комментаторов. Командам полезно чётко понимать, какой именно результат ожидается.

Отказ (или восприятие неудачи) никогда не должен становиться демотиватором. Здесь критически важна «культура ошибок»: Принимайте быстрые и частые неудачи! Цените дешёвый и ранний цикл обратной связи!

У каждой команды свои нормы и приоритеты. Старайтесь анализировать и улучшать подход своей команды в рамках ретроспектив.

Измерение успеха

Обратите внимание на то, как идеи рождаются и развиваются в вашей организации:

• Какой процент сотрудников/команды делится идеями?
• Сколько в среднем проходит времени до первого предложения сотрудника? Дней? Месяцев? Лет?!?!?
• Регулярно ли все члены вашей команды делятся идеями?
• Люди чувствуют себя в безопасности? Могут ли они быть уязвимыми? Даже ставить под сомнение миссию?