Это чаще всего встречающиеся, реже всего ожидаемые и наиболее деструктивные по отношению к проекту ограничения. Составленная на предыдущем этапе таблица конфликтов анализируется следующим образом: если конфликтующие аффилянты находятся в разных клеточках организационно-ресурсной схемы, возникает ограничение типа «запрет контактов», а если в одной и той же клеточке – ограничение типа «запрет повода».
Запрет контактов – наиболее простой и понятный метод, использующийся во многих методологиях (см. хотя бы «Жизнь внутри пузыря» Игоря Ашманова или SCRUM, где все контакты с разработчиками идут только через продактоунера). Однако запретить контакты внутри одной клеточки невозможно: стейкхолдеры, разработчики или поставщики обязательно познакомятся, а познакомившись, обнаружат повод для конфликта. Поэтому каждый такой потенциальный повод нужно заранее вписать в схему проекта.
Начинать анализ следует с возможных политических конфликтов (между стейкхолдерами): если в интересах какого-либо аффилянта – «подсидеть» другого аффилянта, он может сознательно вести проект к краху, чтобы свалить вину на конкурента. Другие варианты конфликта между стейкхолдерами – из-за требований к продукту («мои требования важнее!») или к процессу («пусть мой племянник будет главным дизайнером»; «я должен контролировать расходы»).
В случае если в проекте обнаруживается худший сценарий – политический конфликт между стейкхолдерами, – применяется метод «Проект смерти».
Политический конфликт между стейкхолдерами – это ситуация, когда группировка, объективно (по KPI) заинтересованная в провале проекта, имеет сопоставимый аппаратный вес по сравнению с группировкой, заинтересованной в его успехе. Поскольку оценка аппаратного веса всегда неточна, существует реальный риск неудачи проекта по политическим мотивам с возложением ответственности на ПМ и команду разработчиков. В этом случае ПМ должен четко разграничить сферы ответственности путем официальной фиксации своей позиции.
1. Пишется служебная записка (или другой официальный документ) о том, что наступление «крайне маловероятного события Х» (которое ПМ ожидает в случае реального возникновения политического конфликта) является угрозой успешности проекта.
2. Команде открыто сообщается, что в проекте возможен форс-мажор, который очевиден ПМ и наступление которого можно будет предсказать заранее.
3. Всем аффилянтам, заинтересованным в успехе проекта (прежде всего – потенциальным потребителям), сообщается, что существует риск «события Х», которое может воспрепятствовать созданию замечательного, всеми ожидаемого продукта.
Исключение. Если ПМ определяет по знакомым из личного опыта признакам или получает информацию от аффилянтов, что проект носит заведомо подставной характер, то он должен уйти из проекта с публичным заявлением о наличии риска уголовного преследования.
Результат. ПМ «играет на стороне проекта» и пытается изменить настроения стейкхолдеров в пользу проекта («сведем счеты в другой раз, тут, кажется, намечается успех, который всем пригодится»).
Во всех остальных случаях потенциальный повод для конфликта может быть устранен, и поэтому он вписывается в качестве ограничения (например, «в проекте не должно быть дизайнера») в общую таблицу ограничений.
В случае если повод не может быть устранен (личный конфликт, вызванный прошлыми событиями), необходимо избегать его путем использования других, не столь токсичных ресурсов. Например, если заранее известно, что один из разработчиков точно не сработается с другим, от кого-то из них следует отказаться. Или когда становится ясно, что поставщик бесплатного ресурса может перекрыть кислород, если его пожелания к продукту не будут выполнены, от такого бесплатного ресурса также следует отказаться.