如何处理工作中的分歧讨论

一定要从客户角度，一切以客户交付为出发点

前面几楼说的都很好，做产品设计的，每天主要工作就是接受各种feedback，达成共识和决策，来贡献一点。
1. 根据不同的项目（大小，时间，人员）来确定出是driver，contributor，approver，informer。driver是决策者，开会讨论必须表达观点，投票。contributor是可以提建议，feedback 尽量address但不一定要有投票权，approver 可能不需要全程跟进，但是最后需要向其汇报，知会各种决策。informer 大概就是其他team相关team，keep in the loop 就行。 不同scale的项目， 可能不需要所有这些role，但是重点是项目开始前要确定好那些人在那些role里，所有人要on same page。
Atlasssian  有比较具体的操作 https://www.atlassian.com/team-playbook/plays/daci
2. 开会之前，明确这个会的结果是什么。尤其是要做决策的会，如果是driver会前列出goal,constraint，比如budget，时间，选方案的时候就看着这些东西，大家更容易达成一致。更进一步，某些特定的会议可以有一些protocols，比如有人如果提了scope 以外的话题，为了大家不跑偏，把这个东西放到”parking lot“ 我们以后考虑。
3. 不是很同意直接就不把R带进决策。可以私下跟他喝个咖啡吃个午饭的时候，开诚布公聊一聊，说觉得他很有想法，value他的意见，希望他能更早的把这些feedback提出来，希望他在决策的时候更明确的表达他的观点，结合上面的role，让他在决策阶段投票。后续挑刺的事感觉可能很难避免，可以就说很多东西鉴于现有的resource不好弄，以后优化的时候会考虑。


补充内容 (2019-2-1 07:17):
有个个人经验 在跟比自己更senior的人 而且都是strong option的人开会的时候，我比较少加入争论，主要先听别人说，然后给他们总结他们有那些解决方案，同意的地方是什么，分歧在哪，能比较好的保证会议顺利进行。

hxtang 发表于 2019/01/29 01:02:02
My 2 cents:
- 假如自己是owner：重点放在和stakeholder确认好deliverable，接口尽量简单清晰，可以避免很多back and forth。具体的实现谁是owner谁...

好方法，多谢分享

楼主其实总结得很不错，我想补充几点
1. Escalate其实是出现争议时候，特别是争议比较严重的情况下，最有效的方法之一，找到一个真正的owner或decision maker, 陈述利弊，请他作出决定并帮助说服有争议的其他人。但是楼主的经理不愿意出面，所以间接的就把这个球甩回给了楼主。
2.看公司文化，成熟一点的公司都会在公司文化里面规定了ownership, 争议处理的流程，有的是要有single owner, 有的要求大家disagree and commit服从大多数决定，有的是要经理或者项目责任人负责。如果有比较成文的公司文化及规定，按规定执行即可。
3.如果任务出现问题，要及时和各方沟通，不要自己一个人干着急；可以换技术方案，延长交付期，提高或者降低测试以及其他附加任务，增加人手和其他资源配给。
另外还有组与组之间，技术和PM之间都会出现类似问题，及时沟通，实时向上反馈，通过非技术手段间接缓解或者解决技术上遇到的困难

可能有一点偏题，并不能很好地解答题主的具体case。但对于一部分“如何处理工作中的分歧讨论”的情况，data driven是一个非常好的方法。尤其是对于产品上的分歧，有可能的话就做A/B Test，交给用户去判断。塑造出这样的公司文化的话，就有助于用客观依据去解决分歧，避免发展为意气之争。

KyleYLZR 发表于 2019/02/01 14:14:42
可能有一点偏题，并不能很好地解答题主的具体case。但对于一部分“如何处理工作中的分歧讨论”的情况，data driven是一个非常好的方法。尤其是对于产品上的分歧，有可能的话就做A/B Test，交...

谢谢。data driven的决策判断一般是针对性地，比如新旧feature和新旧逻辑。我现在做的大部分工作都是复杂系统的迁移，涉及到的决定往往是先什么再什么，dependencies和constrains，就不存在正确与否，在于过程如何。

hxtang 发表于 2019-1-29 01:02
My 2 cents:
- 假如自己是owner：重点放在和stakeholder确认好deliverable，接口尽量简单清晰，可以避免很 ...

        很有用的信息!

恭喜楼主有机会进到下一阶段的挑战，我提一点，做事和做人是两个方面，有时候很难平衡。 在你努力争取做好项目的同事，留下至少10%的空间想想如何做好一个manager，了解一下同事下属的感受，这会让以后的很多工作的执行变得简单顺畅很多。

hi_vicky 发表于 2019-2-1 06:05
在工作中学到的路径基本这样：

1. 团队内部讨论方法——就事论事，最后决策是投票。

投票本身就是形式，如果投票在起主导作用，这本身就有问题了

practicemake 发表于 2019-2-1 14:35
恭喜楼主有机会进到下一阶段的挑战，我提一点，做事和做人是两个方面，有时候很难平衡。 在你努力争取做好 ...

谢谢，最近W推荐我看一本书“高效15法则”，有效的帮助我减少相关的焦虑。其中一个点就是分包任务，把不是自己核心竞争力的任务拒绝或者外包或者重新规划，这个时候发现其实同事有愿意承担这些任务的，或者清楚任务的优先级和紧迫程度。确实是，事先多一些沟通，就能减少讨论和决策阶段的冲突。