问题：在产品发展和项目推进过程中，如何追求项目管理的科学性和合理性，是恰当的？
下文中提到的所有项目管理观点，全部都以“利于产品发展”为最高优先级的大前提，其他利于团队团结、公司发展等细节都次之。（当然都是可以方向一致、相辅相成的，你懂的。）
在一个产品发展过程中，根据架构背景、项目背景、产品背景三个方面的因素，综合考虑当前项目管理的最后方案，才能保证“利于产品发展”的目标。三个背景缺一不可，少评估一个，就多一份风险，默默的埋藏在执行过程中，并且很难被再次发现。
将三个层面的背景梳理清楚，才有可能综合的判断问题根结，假设：
架构背景：
1、产品、运营、视觉三个方面的跨部门合作；
2、各个部门中的团队考核标准不同，晋升机制不同，团队氛围不同；
3、各个部门中团队，前期没有进行过磨合，并且供职于不同领域的产品；
项目背景：
1、产品上线初期的快速迭代优化状态；
2、竞争市场非常激烈；
产品背景：
1、社区产品，依据线上情况及需求变动，随时作出产品动作；
2、产品负责制，说白了，就是产品部门说了算，并对产品最终负责；
“架构背景”所导致的实际问题：
Q1：架构背景不同，导致：团队之间的思维模式及个人愿景不同（架构无法改变）
Q2：不同的思维模式及个人愿景，导致：合作过程中的细节及方向分歧
Q3：细节及方向分歧，导致：合作过程中的过度讨论及精力消耗，以及最终决策权的实施
Q4：在消耗精力的讨论过程中，反复由产品实施最终决策权，导致：产品负责制的外在表现更强，即产品强势
Q5：产品强势，导致：其他非产品团队成员的工作归属感减弱、工作挫折感增强
面对可怕的Q5，当其他非产品团队成员怨声载道的时候，如何很好的解决这个问题？这也是我们目前要做的选择。
PS：在架构背景不同的前提下，尝试统一思维模式，让不同团队的个人愿景与产品愿景一致。能做到吗？
答：当然可以用各种方式统一跨部门、跨地域团队的个人愿景与项目愿景，比如项目宣讲、团队洗脑。但要质疑的是，这种仅限于表层的苦口婆心，是否真正能够战胜不同的架构背景？在当前的产品背景和项目背景下，我认为不可能。此类产品及项目背景，决定了该项目属于创业项目（大公司也有无数个创业型项目），这种创业项目，不允许让项目核心成员把精力聚焦在团队默契培养和远景统一方面。
如很多同行所说，大公司里搞创业产品，困难比创业公司更大。就是这个原因吧。
产品初创期间，没有一个强有力的默契的大团队，就已经是危险的了。面对这种困难，选一条错路来与架构背景死磕，就更危险了。
下面看看各种解决方案的优劣：
针对Q5的解决方案1：
1、制定明确的需求确认过程，三方或N方共同确认，由产品方面组织，说服各方，正正规规的抹平分歧，降低产品强势的感觉；
2、制定明确的流程控制策略，明确各个环节的时间节点和责任人，并跟踪各节点，控制流程进度，拉平产品部门与其他部门的地位，克服产品部门的封闭感。
即，侧重法制。
方案1的风险：
风险1：对抗“产品强势”而做出的流程设计，导致：合作过程中的需求确认更加严谨、分歧讨论更加频繁、进度控制更加流程化，即“死板的需求、无谓的讨论、机械的流程”。
比如：需求管理无弹性，导致试错成本增大，让各方需求提出更加谨小慎微。为需求做减法，可不是以扼杀积极性为基础。
分歧讨论的频繁发生导致各参与成员逐渐形成逃避分歧的行为惯性，或者导致各个参与成员在无谓的细节中浪费大量时间。
进度控制流程化导致任务质量与时间节点之间的矛盾更加突出。
风险2：“死板的需求、无谓的讨论、机械的流程”，导致：各个团队之间的合作关系比较机械，即将合作过程中的社会规范变为市场规范。
比如：过去我可以跟其他团队成员，共同完成一个作品。现在，我是让其他团队成员为我的产品完成一个任务。
面对靠谱的合作人，我可以因为更高的质量，而放宽时间进度。现在，时间进度的死板与分歧讨论的挫折感，让我与他都开始不自觉的规避违背流程的事情发生。
最终，冰冷的市场规范与无谓的时间浪费，导致：迭代速度下降、产品决策效率降低，影响产品健康度。
1 2