Как сотрудничать в межотдельских проектах: устраняем информационные барьеры и перекладывание ответственности
Межотдельское взаимодействие становится конкретным в тот момент, когда результат работы одной команды становится исходным материалом для другой. Прежде чем назначать новые встречи, договоритесь о том, что именно передается, кто это готовит, кто проверяет и по каким критериям оценивается готовность к использованию. Заявление отдела о завершении своей задачи еще не означает, что следующий отдел может приступить к работе.\n\nНачните с одного ключевого этапа передачи в рамках проекта. Вам не нужно перестраивать методы работы каждого отдела. Достаточно проработать детали настолько, чтобы обе стороны одинаково понимали формат поставки и видели обязанности, которые ни одна из сторон на себя не взяла.
Двигайтесь от принимающей команды в обратном направлении
Представьте вымышленный проект по созданию печатного путеводителя. Редакция готовит текст, дизайнеры верстают страницы, а специалист по операционным процессам организует печать. Договоренность «отправить материалы во вторник» — это еще не готовый к работе процесс передачи. Дизайнерам может потребоваться утвержденный текст, подписи к изображениям и четкий порядок страниц, в то время как авторы могут посчитать достаточным черновик с нерешенными комментариями.
Спросите принимающего сотрудника, что именно ему необходимо иметь перед началом следующей задачи. Затем уточните у передающего сотрудника, возможно ли подготовить эти исходные данные в согласованные сроки. Зафиксируйте ответ рядом с текущей задачей, указав расположение файла и нужную версию. Это двустороннее соглашение, а не список требований, навязанный принимающей стороной.
Сделайте взаимосвязи наглядными
В случае с путеводителем зафиксируйте, что верстка зависит от утвержденного текста, а печать — от проверенного файла для печати. Определите контактных лиц с обеих сторон. Учтите последствия возможных изменений: если абзац сдан с опозданием, может потребоваться повторная проверка верстки, а не просто еще одно письмо. Не нужно картографировать все связи в организации; сосредоточьтесь на зависимостях, влияющих на эту конкретную поставку.
Руководство Atlassian по картированию зависимостей (Dependency Mapping) рекомендует командам выявлять входящие и исходящие зависимости, ответственных лиц, риски и порядок проверок. Это помогает сделать взаимосвязи наглядными, вместо того чтобы предполагать, что дедлайн в одном отделе автоматически учитывает работу другого. Обсудите эту карту с задействованными командами, поскольку координатор может не знать обо всех входящих материалах, от которых они зависят.
Распределите работу между конкретными ролями
При работе над путеводителем может выявиться задача без четкого владельца: кто проверяет, соответствует ли каждая подпись финальному изображению? Указание «редакция и дизайн» рядом с ней может лишь замаскировать этот пробел. Определите, какой конкретно человек выполнит проверку, кто предоставит недостающую информацию и кто подтвердит, что результат можно брать в работу. Имена должны отражать принятую на себя ответственность и реальную нагрузку сотрудника.
Упражнение Atlassian «Роли и обязанности» (Roles and Responsibilities) рекомендует назначать основного ответственного в ситуациях, когда обязанности пересекаются. Для задач без владельца необходимо найти ответственного и установить дату контрольной проверки. Это не означает, что нужно создавать постоянную новую роль под каждую мелкую задачу. Сначала оцените, можно ли разумно включить ее в существующую зону ответственности; если взять ее некому, открыто поднимите вопрос о нехватке ресурсов или полномочий.
Договоритесь о том, что считается приемкой работы
Выберите небольшое количество проверяемых условий приемки. Для передачи в дизайн это могут быть: полностью готовый текстовый файл, согласованные подписи и отдельно выделенные нерешенные вопросы. В этом случае принимающая сторона сможет сразу сказать, что готово, а чего не хватает. Открытие общей папки или ответное «спасибо» не должны автоматически означать приемку незавершенной работы.
В Scrum Guide используется понятие «Критерии готовности» (Definition of Done) для формирования единого понимания завершенной работы внутри Scrum. Обычному межотдельскому проекту не обязательно перенимать всю методологию. Полезный принцип здесь заключается в том, чтобы сделать завершенность задачи понятной каждому, кто рассчитывает на этот результат. Не называйте черновик финальной версией лишь потому, что у автора вышло время, и не выдвигайте новых требований к приемке после передачи работы без фиксации этих изменений.
Отрабатывайте изменения входных данных, не перекладывая проблему целиком
Если утвержденный текст меняется после завершения верстки, зафиксируйте, какие страницы затронуты и что необходимо перепроверить. Автор по-прежнему отвечает за исправленный текст; дизайнер подтверждает объем необходимых правок в макете; координатор проверяет, не влияют ли изменения на печать. Это раздельные обязательства. Если один человек уведомил всех, это не означает, что он автоматически берет на себя все три задачи.
После первой передачи сопоставьте договоренности с тем, как все прошло на самом деле. Получила ли принимающая сторона пригодные для работы материалы? Не остались ли задачи ничейными между ролями? Не привели ли правки к непредвиденным задержкам в других звеньях? Скорректируйте это конкретное соглашение, прежде чем масштабировать подход. Сохраняйте привычные инструменты каждого отдела там, где они работают, и выстраивайте между ними понятные связи, чтобы проект мог двигаться вперед.