看了“程序员写代码时多沟通”这个帖子，想问问大家还有什么建议嘛？
source link: https://www.v2ex.com/t/920115
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
感觉我也干过很多蠢事，先感谢不杀之恩；
想问问大家还有什么类似的建议嘛？免得哪天突然被开还不知道是自己的问题。
 |
estk 11 小时 22 分钟前 via iPhone 有一种不想沟通的原因是每次跟老板聊天，老板都脑洞大开，不过大公司有专业产品经理分工应该不至于
|
 |
yexiao117 11 小时 7 分钟前 干产品也干运营，说下我的看法，如果内部有交叉评价的话，我喜欢直接找我问业务场景和需求背景的技术，我不知道他技术咋样，但是起码他能从业务角度出发，和我一样想问题，再用自己的技术方案找到解决办法。
我：交代场景，提一个可行性的产品方案，拉会探讨技术解决方式（一般以上线快，少出错为首要目的），技术提供方案 ABC ，说下几个方案的优缺点，方案定稿，技术开干。 这个流程里面，技术提供我不知道知识，并且帮我评估出风险点，我作为需求方，我就很喜欢和这种技术同学合作。 |
6 |
jones2000 11 小时 3 分钟前 提供详细的需求文档， 千万不要是口头的，开发前做下流程图，小组内讨论清楚了，就按照这个流程图，动手开发。写代码只最后一步了，基于前面做的需求，设计的整理以后，给任何一个开发都是无脑完成的。
|
 |
Feedmo 10 小时 50 分钟前 能否提供下帖子的链接，谢谢
|
 |
tianyou666shen 10 小时 35 分钟前 出来公司打工不要因为一个人影响了整体的流程进度
因为延期不仅是你一个人的成本*天数 而是整个团队的成本*你延期的天数 算算这笔开销就知道了 所以老板肯定想干掉那个导致整体延期的人咯 |
 |
uni 10 小时 23 分钟前 要改变性格的话，最好的办法是进入一段全新的关系之中
推荐靠谱的心理咨询 |
 |
Dogtler 10 小时 20 分钟前 via iPhone 跟产品是沟通业务，跟技术同事沟通则是如何以架构角度审视需求或者砍需求。有效沟通都是双向的
闭门造车在哪里都是不对的，心里还是要有张脉络图并且在工作时间内有问题积极响应，即使是屎山和架构不合理也要提出来。 |
 |
wxlwsy 10 小时 3 分钟前 是我我也辞退. 这纯粹个人习惯不好怪不到别人. 工作做不好要你何用.
|
 |
zhangxh1023 10 小时 1 分钟前 第一份实习工作做测试，后来干不下去离职了，离职的时候 组长就和我说，让我以后多和别人沟通，说看我从来不和同事说话什么的。没办法，我是真不喜欢和别人说太多话 orz
|
 |
huajia2005 9 小时 43 分钟前 我的建议是多想,别闷头苦干,做之前先过一遍,看看有什么坑,流程合不合理,有问题要及时提出来解决.不明白或者不够清晰的一定要和产品沟通清楚
|
 |
buchikoma 9 小时 34 分钟前 多跟+1+2 的老板沟通，确定自己的工作大方向和老板的期望是否一致，也算是最基础的向上管理了
|
 |
KedaArray 9 小时 29 分钟前 @zhangxh1023
之前我也是很不爱和别人交流，有时候是因为把人和人之间的关系看的太重了， 怕说出来的话不合适或者说重复的话没有必要，或者是太关注自己在别人心里的印象； 前段时间，突然一下转变过来了，觉得家人朋友才是最重要的，把其他人在心里的“地位”放低了很多，沟通也更容易了，说实话我也觉得蛮神奇。 |
|
zhangxh1023 9 小时 21 分钟前 @KedaArray 是的，我现在也是，可能是工作了四五年以后，就会很平淡的和同事交流，有时候在外面也会和陌生人莫名其妙的搭个话，和刚工作的我差别巨大。
|
 |
stillsilly 9 小时 17 分钟前 多跟领导沟通，同事领导的负面反馈认真对待，确实是你做得不好就改，你没问题就当他们放屁
一般不会突然开人，沟通很多次不改才开 |
 |
corcre 9 小时 8 分钟前 沟通是必须的, 不然领导想给谁升职的时候可能都没想起你来.
需求交流记得留下交流证据(文本 /邮件), 跨部门的邮件沟通最好记得 CC 各方的领导. 自己部门给出去的东西(数据 /资料 /功能 /报表)可以先给领导看. 这个是我以前一个领导教的, 给出去的东西, 如果你自己没给领导看过拿出去了, 出了问题那铁定是你的锅, 给领导看过了他点头的, 那就是他的锅, 他是领导, 他点的头, 那锅肯定是落他身上, 但是他是领导, 他坐这个位置就有这个责任, 所以不要怕麻烦他 |
 |
a4854857 8 小时 24 分钟前 从业务角度去理解需求.这样才不容易出错.然后不懂就问就行了
|
 |
itechnology 8 小时 21 分钟前 我就是发那个帖子的人，我觉得最重要的就是要理解清楚产品下发的需求，遇到没理解的地方一定要问清楚，不要自己瞎理解，这样很容易导致延期，因为最终跟产品预想的不一致的话，你还要返工。
|
 |
Cola98 8 小时 8 分钟前 多沟通不是让自己抱着交朋友这种心态去，比如说 leader 交代了一个活，自己理解完之后，和同事或者 leader 简单说下自己的思路，或者大概实现方法，不要造成不必要的浪费，比如说 ld 想做一个简单的登录注册，结果自己又想添加扫码和第三方登录等等，从而导致出力不讨好的情况（（
|
 |
dxckey 8 小时 3 分钟前 和 op 一样，也觉得自己以前做了不少蠢事，同谢不杀之恩
|
|
tianyou666shen 8 小时 1 分钟前 @Cola98 是的 我就发现了 以前人家说个功能我直接闭门造车 问题造出来的东西复杂度有时候太高了 或者有些地方做的不太清晰 现在都喜欢先有个方案的设计就拿出来给领导或者同事看看 有问题就改好再去实现 而且这样做出来不会在交付的时候突然被说"你做的不对 方向错了"
|
 |
litchinn 7 小时 52 分钟前 多沟通，遇到不清楚的一定多问，但是尽量要给出你的方案，比如你觉得哪里不好，你要给出你觉得好的方案，
其次有些功能你可能脑子里一下就想到了多种方案，有可能你觉得任意一种都行，但有时候更好的做法是提交给 leader 或产品做决定，具体情况还得自己判断，尽量让别人觉得你是有想法在认真为项目考虑，而不是无能 沟通技巧很多，但是这些技巧不具体带入某种情景真的很难说明诶 |
|
corcre 7 小时 43 分钟前 @litchinn 这里就需要再次提一下⟪提问的智慧⟫, 我希望所有问问题的人都先读一下这本书(好歹把那个思维导图版给看一遍), 提问之前自己先考虑一遍真的非常重要...
|
|
Cola98 7 小时 41 分钟前 @tianyou666shen 是滴，现在我也是，拿到需求之后，先写写画画，然后有一个大概的方案再去沟通，至少保证大方向上不要错
|
 |
Chinsung 7 小时 21 分钟前 也看领导和同事，你首先得辨别哪些人可以沟通，比如能给你行而有效的指导和建议，并且也比较好相处，心里拿不准的该问就去问，闷着头只能提升提升基础，眼界和思路一定是沟通中碰撞出来的
|
 |
BeforeTooLate 7 小时 20 分钟前 沟通不是瞎聊天，那个帖子看了，其中一点不确定的需求自己瞎搞，我觉得这样肯定不行，不确定可以多和需求提出者确认。
|
 |
tianmalj0613 6 小时 57 分钟前 之前我们部门对接的一个产品教的一个点：
人和人之间沟通都有自己的知识和认知领域，你和对方对话时也应该考虑用别人认知领域内的语言把观点或者问题描述清楚，以做到最少的信息偏差。 他给我们说这个问题的原因就是：老有研发给产品说一些技术层面的东西，说了半天，问题也没说清，产品也听不懂，浪费了时间。 |
 |
alen0206 6 小时 36 分钟前 遇到问题尽早提出来，多沟通，向上暴露风险
遵守团队内的规则 技术提升 |
 |
aceinnes 6 小时 32 分钟前 我也喜欢闷头搞，实在搞不定再求人问人
|
 |
chenyu0532 1 分钟前 来开发游戏吧。文案、 数值、场景、关卡、特效、ui 、原画 等，我基本每天都要跟他们交流一些，不交流怎么往下做。。
|
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK