Вы задаете вечный вопрос об управлении проектами (программным обеспечением). На написании книг на эту тему делают карьеру.
Я в целом согласен с rockinthesixstring в этом вопросе.
Если у вас нет эффективного менеджера проекта, который может фильтровать запросы заказчиков, управлять их ожиданиями и говорить "нет", то это должно стать частью вашей работы.
Иногда есть искусство не говорить "нет". Иногда можно сказать что-то вроде: "Как вы видите в расписании, версия 1.1 выходит в альфа-версию на следующей неделе. Список функций для версии 1.2 уже составлен. Я добавлю вашу новую функцию в начало списка для версии 1.3. Но если хотите, я могу созвать встречу с другими командами, чтобы узнать, можем ли мы изменить приоритеты функций версии 1.2."
Что касается конфликтующих идей, если нет другого "решателя", это тоже становится частью вашей работы.
Поймите, что не все получат свое.
Без подхода, который решает подобные проблемы, вы просто не добьетесь успеха ни по каким показателям.
Я бы начал с фиксации согласованных функций и поместил все запросы функций в какое-нибудь программное обеспечение для планирования проекта ( OnTime Возможно). Затем разверните альфа-версию с согласованными спецификациями, прежде чем переходить к «мы хотели бы» и «навороты».
Похоже, что принадлежность продукта не ясна (что можно ожидать от внутренних проектов с несколькими командами). Возможно, вам следует провести какую-то форму игры по планированию. Если у вас несколько заинтересованных сторон, вы можете дать им по 50 очков, чтобы они проголосовали за все функции в итерации. Вы, как разработчик, решаете, насколько велика каждая функция. Функции с наибольшим количеством очков/размером попадают в итерацию. Если некоторые команды более важны, дайте им больше баллов. Вы также должны потратить несколько очков сами.
Вам необходимо расставить приоритеты и упорядочить запросы функций, возможно, даже некоторые из тех, которые вы уже согласовали.