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

好友LZ一起午饭，讨论了一下各自遇到的问题和解决方案，LZ一直是我工作上的榜样，类似于Mentor一样的角色，所以其实大部分时候都是他在帮我答疑解难。

比较有建设性和普适性的一个讨论结果就是如何确定自己的技术解决方案，目前的难题在于，组里有两个资深技术（W和R）经常就解决方案提出不同意见，之所以要咨询他们两是因为确保设计方案没有大的纰漏，W经常要求Think Big但是不会在确定后反复确认，R经常参与决策讨论但是不参与决策确定，然后常常在技术实施的过程中挑刺，我相信大部分程序员会有类似的场景。

最简单的解决方案就是汇报老板，让老板解决问题，我也一直认为并且这样执行，遇到的问题是我老板是一个从不正面回答问题并且明确态度的人，所以调和是不可能的，他会给我很多如何调和获得结论的流程和方案建议，但是不会去做和决定。（LZ说这是对的，老板的信息不足，不应该做选择，也没有义务帮助我解决问题；帮助我的老板实际上是在助人为乐。）

插个题外话，前段时间深以为恼，因为过去的经验基本上都是有权威人士做出决定，大家服从并执行就好了，这条路走不通就大量耽搁时间和反复的工作量，甚至我有过换组和跳槽的想法。但是最近几天刚好做年终报告，自我察觉在这里做的很多工作对我而言都是新的挑战，并且切切实实感觉到自己的进步和成长，而所有这些棘手的状况肯定都有比我更好的处理方法，不行我应该学会处理这类问题再走。（昨天参加公司职业分享会，大佬们提出很多好的建议，其中一条就是，如果你是因为现有的问题换组，不是很好的时机，下次你还会遇到类似的问题，反正你想走，不如学会了如何处理好这个问题再走，在新组就有机会展示解决问题的能力了。）

LZ建议的流程是，弄明白谁是这个技术方案的负责人（Owner），客户（Stack holder）和评审人（Senior Engineer），那么负责人调研提方案最后和评审人过方案，对所有的选择项进行优劣比较和资源预算，和客户聊限制条件譬如交付时间和质量权重，确定方案。然后知会老板自己做了什么选择，为什么，这个方案的劣势和未来改进计划，相关人士的意见。评审人尽量只选一个，多出一个的的在技术确定会议上必须投票，不允许跑过来说几嘴就跑不参与最后决定过程的现象，根据票数确定方案，并把反对意见记录在后续任务里供后续优化参考。

这里面我以后要注意的改变是，既然我喜欢和W讨论也喜欢他的解决方式，以后就不要把R带进决策阶段，确定解决方案以后R的意见都可以放进后续优化里面记录就好；不要再找老板帮忙做决定，因为我需要独立负责完成任务；多和客户沟通，确定优先级和取舍；对所有选项要有优劣，对选定选项要有补救或者优化空间。

另外一个话题就是项目研究和进度估算，我一直认为研究是一个泛泛的事情，LZ认为研究起码要做到一个可运行的模型，这样才算是完成研究，这样才能够有一个好估算。研究一方面要能够化繁为简，把复杂问题转化成多个清晰的直接问题；一方面要确定每个直接问题是否可行，所有直接问题完成能够确保复杂问题完成。所以研究比实现花更多时间完全是可能的，估算可以随着研究的进度逐渐完善和确定。

我个人最近第一次真正承担类似项目规划的角色作为一个小组技术负责人，做得很不好，所以很慌，这也是我感觉收获比较大的一点。接下来要做到事情就是：确定当前状态和进度，更新客户获取一致观点和优先级，确定未来的进度更新和事件变动的机制；汇报老板自己的决定和未来的计划；继续深入研究学习项目逻辑和锻炼项目规划能力。

最近的工作上挑战和学习的经验都很多，算是比较现实的一些topic，自己今年的目标也包括程序人生（这个公众号也很推荐）上的一些提高和总结。
地里收益良多，也分享到这里，希望大家一起讨论看看有没有更多好的操作方法。
https://zhuanlan.zhihu.com/p/55827204




补充内容 (2019-2-8 00:41):
今年一大收获是Renew比New更重要，所以我会在这周内根据回复（感激！一亩三分地比知乎有效有价值！）重新Renew我的文档，归纳更多值得注意和学习的点。然后最近看书的一点收获，待办事项无效，日程表时间有效。

补充内容 (2019-2-8 03:15):
因为朋友过来聚会，喝了酒睡不着觉，就把自己的文章更新了，顺祝新春快乐！

补充内容 (2020-1-10 09:36):
现在回头看这些所谓争执，指导我的Principle变成了：1大家都在帮助这个设计变得更好 2任何观点背后的原因和考虑我是否清楚 3无论我选择冲突观点的哪一个 我有充分的理由做决定 我也必须先舒服不同意该观点的任何人

本文被提升为今日话题：凡是在置顶有效期内参与讨论，提供言之有物、切中主题的高质量回复，最低奖励20大米，欢迎讲述你工作中遇到的例子，干货越多奖励越多。
也请大家踊跃参与，看到好回答，请加分、请顶上去。对认真码字、热心分享的同学表示感谢，今后大家也会看到更多精彩分享。

说明：给别人加分不会扣除你的积分。

前面几楼说的都很好，做产品设计的，每天主要工作就是接受各种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的人开会的时候，我比较少加入争论，主要先听别人说，然后给他们总结他们有那些解决方案，同意的地方是什么，分歧在哪，能比较好的保证会议顺利进行。

My 2 cents:
- 假如自己是owner：重点放在和stakeholder确认好deliverable，接口尽量简单清晰，可以避免很多back and forth。具体的实现谁是owner谁定，组里其他人的feedback尽量address，如果分歧是因为有一个tradeoff space，那么owner需要在design里明确这个space是什么，并且做出选择。
- 假如自己是reviewer：重点放在提出问题，解决问题的空间留给owner。如果是owner碰到困难，提出多个解决方案，给owner选择的空间。这点在带junior的时候尤其重要。
- planning/costing：我觉得最大的坑是或者一点不计划就直接上，或者反复optimize plan却不执行。个人觉得有个比较合理的方案和中等程度的细节就可以开始干了。小的细节留给owner在实现的过程中决定。需求和design都是流动的，所以重要的是时时track变化，把握大方向，而不是一下子就把project做完美了。

具体到你说的例子，我觉得你老板挺好的。两个senior的讨论其实都应该听，但是有争执的时候不要想自己该听谁的，而是应该分析他们争执的点在哪，然后自己做最后决定，并且跟两边一起沟通清楚是为什么。

一定要把讨论的agenda书面记录下来，有哪些proposal，讨论各自的优缺点，然后做了什么样的decision以及原因。
如果自己有足够的ownership/responsbility，就自己做决定或者组内投票决定采取哪个方案。比如可以写因为时间原因所以多数人同意go with比较容易实现的作为short term solution，以后再慢慢改善来实现long term solution。
如果你没有足够的ownership/responsibility，那就找老板讨论，注意不是让老板协调w和r，而是把两个proposal提供给老板，陈列各自的优缺点，提出自己建议采纳的方案，找老板背书。
就像楼上说的，重点是确定好deliverable以及可能的接口。具体的实现细节重要但没有重要到花大量时间back and forth讨论。

太好了 bq问题有救了 把楼主的疑惑稍加改动编个具体事例完美过bq

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

感谢！这个项目我做为owner半途接手，stakeholder也半途换人，然后眼睁睁看着这个项目放作为今年的goal还有比较紧的时间线，所以进度无法推进就很慌乱。现在有一些具体的指导方针了就看接下来的实践效果。
我也意识到其实feedback越早address越好，就是想到deadline的约束觉得不好把握优先级。

t__c___ 发表于 2019-1-29 11:07
感谢！这个项目我做为owner半途接手，stakeholder也半途换人，然后眼睁睁看着这个项目放作为今年的goal还 ...

deadline压力大的情况下我会加强planning和progress tracking，确保时时on track。
另外就是如果有变化或者deadline不合理还是要跟相关的人聊，要人手或者要求push deadline都行。
最需要避免的是自己panic，或者指望自己累死累活赶上不合理的deadline。

汇报老板我认为是最后的手段。已经属于内部不可能达成共识的时候。
既然组里大家都是好朋友好同事不存在敌我矛盾，我觉得最好的方案是挑明了。

同时我不同意楼主的“就不要把R带进决策阶段”。如果我是R我可能会觉得非常被冒犯。不好。

把问题都放到桌面上，
. 1point 3acres 1. 我更喜欢你W的这点。
2. 我喜欢你R的这点，但你后来挑刺我不知道如何执行。
3. 我们各自有各自的分歧，但是还是要达成共识。所以我们三人都要进行妥协。

W和R作为资深人士，也不可能不知道必须要达成共识这点。

楼主所提“研究起码要做到一个可运行的模型，这样才算是完成研究，这样才能够有一个好估算”。我觉得灰常正确。学习了。

在工作中学到的路径基本这样：

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

有想法、有意见，积极建言献策，是好事，说明大家都在思考，为项目出力，但要维持平等和平的气氛，先摆出列出 idea，不要很快陷入对技术细节、如何有效实施等层面的讨论，甚至互相攻击…… 最后无记名投票——成为团队的决定，大家既然事先同意了这个制度设计，后来就应尊重结果，不管是否自己喜欢的，然后move on, 与团队一同成长，自己也在其中提升， 而非被卷入无休止争论与翻旧账，没结果也伤感情。任何方案都不会是普适的，都只在一定时期、情境下有效。

因为自己参与创意类项目较多，在打磨产品时，经常要平衡 idea 与 效率，感觉维持一个好的投票机制，是比较长久的措施。

当然也参与过基本纯实施的项目如下。

2. 给客户做纯实施的项目——负责人综合考虑后决定。

实施项目，效率优先，每一天的人力成本，都要跟客户算钱。一般项目启动前，大方案是双方确认并签好的，即使用敏捷，中间也基本是增改需求层面之类的讨论，很少遇到大方向的调整——那种就要层层上报，客户方的领导也会进来做决定。既然技术方案的讨论，多与效率并客户满意度挂钩，则我遇到的一般是技术负责人（Senior Engineer）综合各开发团队意见、同项目负责人（owner）集中决定，再与客户方代表（Stakeholder）碰，以保证项目进度，节省成本为优先考虑。

综上，两种有侧重的情况，个人体会。





补充内容 (2019-2-1 06:16):
根据楼主后来提到情况——自己是owner、形势严峻、各方都逼紧，私以为应该走 效率优先 与 集中决策 的大方向了， 所谓项目质量是平衡考虑的，得看落脚哪里——一般是技术验收与客户满意度，保证根本，其他都是过程。