Как договориться со смежной командой, когда планы уже зафиксированы

Давайте разберем стандартную ситуацию отделов и команд в больших организациях. Нашей команде нужен результат от другой команды или отдела: разработка функционала, настройка оборудования, предоставление доступов, согласование документа или макета, что-то другое. Но планы на месяц, квартал или другой период у всех уже утверждены, а заранее мы не подумали (планировать ведь и немодно, и на самом деле нелегко). Что будем делать?

Номера пунктов ниже ≠ порядок или приоритет.

Сначала ещё раз сами

1. Безжалостно декомпозируем — выделяем MVP-шечку из эмвипишечки. Находим ещё меньший результат, который по-прежнему будет ценен с точки зрения пользователя, получения каких-то выводов, снижения технических, менеджерских и других рисков.

Договариваемся всей бригадой

2. Просто ещё раз просим котиками: "Пожа-а-алуйста! Выполните эту задачу для нас на следующей неделе." А дальше спасибо и шоколадка, "но только в рамках закона."

3. Слегка сгущая краски, обосновываем, почему эта задача архиважная, и если её не выполнить, то беда-беда. Однако есть риск нарваться на логичный вопрос: "Если она такая важная, то почему вы не подумали о ней раньше?"

4. Просим договориться нашего руководителя +1 или даже +2. Это может сработать, потому что цели на уровне команд и отделов могут отличаться сильно, а над-над-цели департаментов и дивизионов в дереве целей организации гораздо ближе друг другу и могут пересекаться.

Как договориться со смежной командой, когда планы уже зафиксированы

Как можно больше сами, максимально упрощаем

5. Максимально делаем вместо смежной команды всё, что только сможем, чтобы на их стороне задача оказалась ничтожно простой как физически, так и эмоционально.

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

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

Бартер

6. Узнать, задачи каких других команд находятся в списке задач команды №2. Начать с тех, с которыми больше дружим, или с менее критичных по времени, и попросить такую команду №3 уступить нам место в бэклоге команды №2.

7. Командировать сотрудников. Если в команде 2 используются компетенции, которые есть и у вас, даже если они нужны им не для вашей задачи, то отправьте своего сотрудника "в командировку" в эту команду, с намеренно выгодным для них бартером, например, на 2 недели за 1-недельную задачу.

8. Развивая предыдущий вариант, найти для команды 2 сотрудника с компетенцией, необходимой им для нашей задачи или любых других их задач, из другой команды №3. А со своей стороны как-то помочь команде 3.

Варианты 6, 7, 8
Варианты 6, 7, 8

9. Сотрудника вашей команды "отправить в командировку" на спринт в другую команду, чтобы он обучился. Если сотрудник Junior/Regular, то, возможно, он будет больше отвлекать команду 2, чем помогать ей. В таком случае для взаимной выгоды можно отправить его на дополнительный спринт. А вот Senior специалист может довольно быстро погрузиться в специфику смежной команды и даже помочь свежим взглядом. Опасения, что "он всё испортит," преувеличены, потому что ваша команда заинтересована в долгосрочном сотрудничестве, а не в разовом набеге. К тому же, все изменения будут проверяться и одобряться командой-владельцем.

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

Помогаем материально

11. Если процесс бюджетирования позволяет, то предоставить бюджет для оплаты сверхурочной работы, необходимой для выполнения нашей задачи.

Готовимся заранее

А вообще, к таким ситуациям нужно готовиться превентивно.

12. Создать Матрицу заинтересованных лиц (Stakeholder map), в которую входят:

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

Заранее познакомьтесь со смежниками, согласователями и руководителями, которые оказались в верхней 1/3 списка участвующих лиц. Даже если пока что у вас нет общих задач. Подружитесь и поддерживайте приятельские отношения с ними.

А что ещё можем сделать?

Упор на выгоды

Опытный руководитель ИТ-проектов Роман Гольцев предлагает всю аргументацию основывать на выгодах для бизнеса.

С одной стороны, принцип "кто раньше занял место в бэклоге команды, того и тапки" помогает делать работу связанных подразделений гладкой и предсказуемой. С другой стороны, нужно приносить максимальную пользу организации. В работу должны идти самые ценные задачи! И бывает так, что о критичных задачах узнаём позднее, чем хотелось бы. Поэтому приходится ворошить согласованные планы своей срочной задачей.

3б. Подготовьте расклад по бенефитам конфликтующих задач.

Обоснуйте на базе спущенных сверху целей и текущих приоритетов. Желательно выразить всё в деньгах — это универсальный критерий.

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

Технологическую задачу тоже приведите к деньгам: поддержка старой платформы, влияние дефектов на предоставление услуги. Реально были случаи, когда мы приводили к деньгам реализацию какой-то удобной фишки для клиентов на сайте. Просто для этого надо хорошо понимать свой бизнес и правильно обосновывать предположения для расчета. Например, отсутствие чего-то, что есть уже у всех конкурентов, повлияет на отток клиентов, а это столько-то денег. И наоборот, реализация чего-то, чего еще ни у кого нет, повышает лояльность, может быть использовано для продвижения и привлечения новых клиентов, что опять же — удержание уровня доходов или его повышение на x%.

Такое обоснование можно использовать как на уровне "договориться по-братски на своём уровне", так и на уровнях выше. К топ-боссам идти без такой подготовки очень плохо. Большая удача, когда у вас и смежной команды общий босс+1, у него несколько задач, и приоритет вашей очевиден. Тогда отпадает риск дуэли вашего и соседнего босса перед супер-боссом.

Все поползновения "где вы раньше были" выносите за рамки диалога, пока проблема не решена — не давайте дискуссии уходить в это русло, иначе там и завязнете.

Максим Зотов, Enterprise Agile Coach в Сбере делится наблюдениями:

Сейчас всё чаще обоснование срочности и важности основано на эффекте от выполнения задач — это позитивный тренд.

"Хотя по-прежнему иногда вижу, как сотрудники используют свой вес, громкий голос, административные полномочия или влияние на руководителя," — добавляет Максим.

Менеджерские резервы

Senior Architect в Data Cloud Solutions Александра Стоянова по-дружески делится в утрированном формате и с юмором:

2б. "Я бы взяла двух лидов и инициировала бы дискуссию: "Вот, так и так, sh*t happened. Ты как оценивал эффективность своего племени? Количество съеденных вами лосей поделить на количество вас, съеденных лосями, плюс корень квадратный из белки. А у тебя от корня что-то ещё осталось? Может туда и впихнем? А с меня напиток вкусный."

4б. А если команда не дружественная, донести до seniors, что sh*t happened. Они, наверное, [потреплют вам нервы]. Но у них стопудово в contingency заложено — там на каждом уровне вверх до заказчика соломка подстелена. Вот из этой соломки и наскрести."

Заключение

Из всех предложенных вариантов лично мне больше других нравятся пункты 1 и 5+2, когда команда максимально берёт работу на себя и вежливо договаривается с соседями о помощи, а также превентивная подготовка к неожиданностям — 9 и 12.

Резюмируя, все пункты кратко:

1. Декомпозируем выделяем независимое, делаем самостоятельно.

2. Ещё раз вежливо просим. 2б. Договариваемся по-братски.

3. Обосновываем приоритет. 3б. Обосновываем риски и выгоды, поднимаемся по иерархии выше.

4. Просим руководителя договориться на уровне выше.

5. Оставляя зависимость, делаем по-максимуму сами, оставляя смежникам минимум.

6. Просим третью команду уступить нам свое место.

7. Командируем своих сотрудников у смежникам на помощь по любым задачам.

8. Командируем сотрудников 3-й команды.

9. Командируем своих сотрудников обучаться ради нашей задачи.

10. Приглашаем сотрудника смежников в свою команду на время.

11. Помогаем деньгами.

12. Готовимся к таким ЧП – определяем всех участников процесса. Знакомимся наперёд и дружим со всеми причастными.

Какие из перечисленных вариантов показались вам годными?

Какие вы не использовали раньше, но хотите попробовать?

Что ещё вы сделали бы, чтобы договориться о выполнении вашей задачи и при этом сохранить дружеские рабочие отношения?

Начать дискуссию