看了“程序员写代码时多沟通”这个帖子,想问问大家还有什么建议嘛? - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制粘贴 AI 生成的内容
KedaArray
V2EX    程序员

看了“程序员写代码时多沟通”这个帖子,想问问大家还有什么建议嘛?

  •  1
     
  •   KedaArray 2023-03-01 11:48:17 +08:00 4384 次点击
    这是一个创建于 957 天前的主题,其中的信息可能已经有所发展或是发生改变。

    感觉我也干过很多蠢事,先感谢不杀之恩;

    想问问大家还有什么类似的建议嘛?免得哪天突然被开还不知道是自己的问题。

    42 条回复    2023-03-02 11:15:10 +08:00
    estk
        1
    estk  
       2023-03-01 12:30:20 +08:00 via iPhone   1
    有一种不想沟通的原因是每次跟老板聊天,老板都脑洞大开,不过大公司有专业产品经理分工应该不至于
    yexiao117
        2
    yexiao117  
       2023-03-01 12:45:10 +08:00   7
    干产品也干运营,说下我的看法,如果内部有交叉评价的话,我喜欢直接找我问业务场景和需求背景的技术,我不知道他技术咋样,但是起码他能从业务角度出发,和我一样想问题,再用自己的技术方案找到解决办法。

    我:交代场景,提一个可行性的产品方案,拉会探讨技术解决方式(一般以上线快,少出错为首要目的),技术提供方案 ABC ,说下几个方案的优缺点,方案定稿,技术开干。

    这个流程里面,技术提供我不知道知识,并且帮我评估出风险点,我作为需求方,我就很喜欢和这种技术同学合作。
    jones2000
        3
    jones2000  
       2023-03-01 12:49:41 +08:00   1
    提供详细的需求文档, 千万不要是口头的,开发前做下流程图,小组内讨论清楚了,就按照这个流程图,动手开发。写代码只最后一步了,基于前面做的需求,设计的整理以后,给任何一个开发都是无脑完成的。
    Feedmo
        4
    Feedmo  
       2023-03-01 13:01:54 +08:00
    能否提供下帖子的链接,谢谢
    KedaArray
        5
    KedaArray  
    OP
       2023-03-01 13:03:42 +08:00
    @yexiao117 有道理,我女朋友也是产品,不过不是 IT 的。她的说法也差不多,不能闷头死搞。
    KedaArray
        6
    KedaArray  
    OP
       2023-03-01 13:04:24 +08:00
    @Feedmo https://ww.v2ex.com/t/920072 应该还在热门里
    tool2d
        7
    tool2d  
       2023-03-01 13:04:57 +08:00
    @jones2000 我怎么觉得写代码也很难呢。

    程序员会复用代码,不会写以前写过一次的代码,所以每天都是写新代码和新问题。
    KedaArray
        8
    KedaArray  
    OP
       2023-03-01 13:05:00 +08:00
    @estk 有产品确实好很多,平时还是要搞好关系
    KedaArray
        9
    KedaArray  
    OP
       2023-03-01 13:07:13 +08:00
    @jones2000 看了挺多回复,确实是要基于业务去做事,把需求理清是第一步。
    tianyou666shen
        10
    tianyou666shen  
       2023-03-01 13:17:07 +08:00
    出来公司打工不要因为一个人影响了整体的流程进度
    因为延期不仅是你一个人的成本*天数 而是整个团队的成本*你延期的天数
    算算这笔开销就知道了 所以老板肯定想干掉那个导致整体延期的人咯
    estk
        11
    estk  
       2023-03-01 13:21:00 +08:00 via iPhone
    @KedaArray #8
    小公司很多老板觉得自己就是产品经理,直接面对程序员,觉得指点江山一下,产品就出来了
    uni
        12
    uni  
       2023-03-01 13:28:58 +08:00
    要改变性格的话,最好的办法是进入一段全新的关系之中
    推荐靠谱的心理咨询
    Dogtler
        13
    Dogtler  
       2023-03-01 13:32:33 +08:00 via iPhone
    跟产品是沟通业务,跟技术同事沟通则是如何以架构角度审视需求或者砍需求。有效沟通都是双向的
    闭门造车在哪里都是不对的,心里还是要有张脉络图并且在工作时间内有问题积极响应,即使是屎山和架构不合理也要提出来。
    wxlwsy
        14
    wxlwsy  
       2023-03-01 13:49:39 +08:00
    是我我也辞退. 这纯粹个人习惯不好怪不到别人. 工作做不好要你何用.
    zhangxh1023
        15
    zhangxh1023  
       2023-03-01 13:51:37 +08:00
    第一份实习工作做测试,后来干不下去离职了,离职的时候 组长就和我说,让我以后多和别人沟通,说看我从来不和同事说话什么的。没办法,我是真不喜欢和别人说太多话 orz
    huajia2005
        16
    huajia2005  
       2023-03-01 14:08:56 +08:00
    我的建议是多想,别闷头苦干,做之前先过一遍,看看有什么坑,流程合不合理,有问题要及时提出来解决.不明白或者不够清晰的一定要和产品沟通清楚
    buchikoma
        17
    buchikoma  
       2023-03-01 14:18:26 +08:00   1
    多跟+1+2 的老板沟通,确定自己的工作大方向和老板的期望是否一致,也算是最基础的向上管理了
    KedaArray
        18
    KedaArray  
    OP
       2023-03-01 14:22:54 +08:00
    @zhangxh1023
    之前我也是很不爱和别人交流,有时候是因为把人和人之间的关系看的太重了,
    怕说出来的话不合适或者说重复的话没有必要,或者是太关注自己在别人心里的印象;

    前段时间,突然一下转变过来了,觉得家人朋友才是最重要的,把其他人在心里的“地位”放低了很多,沟通也更容易了,说实话我也觉得蛮神奇。
    zhangxh1023
        19
    zhangxh1023  
       2023-03-01 14:31:12 +08:00
    @KedaArray 是的,我现在也是,可能是工作了四五年以后,就会很平淡的和同事交流,有时候在外面也会和陌生人莫名其妙的搭个话,和刚工作的我差别巨大。
    stillsilly
        20
    stillsilly  
       2023-03-01 14:34:47 +08:00
    多跟领导沟通,同事领导的负面反馈认真对待,确实是你做得不好就改,你没问题就当他们放屁
    一般不会突然开人,沟通很多次不改才开
    corcre
        21
    corcre  
       2023-03-01 14:44:30 +08:00   1
    沟通是必须的, 不然领导想给谁升职的时候可能都没想起你来.
    需求交流记得留下交流证据(文本 /邮件), 跨部门的邮件沟通最好记得 CC 各方的领导.
    自己部门给出去的东西(数据 /资料 /功能 /报表)可以先给领导看. 这个是我以前一个领导教的, 给出去的东西, 如果你自己没给领导看过拿出去了, 出了问题那铁定是你的锅, 给领导看过了他点头的, 那就是他的锅, 他是领导, 他点的头, 那锅肯定是落他身上, 但是他是领导, 他坐这个位置就有这个责任, 所以不要怕麻烦他
    jones2000
        22
    jones2000  
       2023-03-01 15:17:25 +08:00
    @tool2d 没有新的业务,新的需求, 哪来新代码,新问题。
    a4854857
        23
    a4854857  
       2023-03-01 15:27:48 +08:00
    从业务角度去理解需求.这样才不容易出错.然后不懂就问就行了
    itechnology
        24
    itechnology  
       2023-03-01 15:31:04 +08:00
    我就是发那个帖子的人,我觉得最重要的就是要理解清楚产品下发的需求,遇到没理解的地方一定要问清楚,不要自己瞎理解,这样很容易导致延期,因为最终跟产品预想的不一致的话,你还要返工。
    Cola98
        25
    Cola98  
       2023-03-01 15:43:55 +08:00   3
    多沟通不是让自己抱着交朋友这种心态去,比如说 leader 交代了一个活,自己理解完之后,和同事或者 leader 简单说下自己的思路,或者大概实现方法,不要造成不必要的浪费,比如说 ld 想做一个简单的登录注册,结果自己又想添加扫码和第三方登录等等,从而导致出力不讨好的情况((
    dxckey
        26
    dxckey  
       2023-03-01 15:48:59 +08:00
    和 op 一样,也觉得自己以前做了不少蠢事,同谢不杀之恩
    tianyou666shen
        27
    tianyou666shen  
       2023-03-01 15:50:49 +08:00   1
    @Cola98 是的 我就发现了 以前人家说个功能我直接闭门造车 问题造出来的东西复杂度有时候太高了 或者有些地方做的不太清晰 现在都喜欢先有个方案的设计就拿出来给领导或者同事看看 有问题就改好再去实现 而且这样做出来不会在交付的时候突然被说"你做的不对 方向错了"
    litchinn
        28
    litchinn  
       2023-03-01 16:00:20 +08:00   1
    多沟通,遇到不清楚的一定多问,但是尽量要给出你的方案,比如你觉得哪里不好,你要给出你觉得好的方案,
    其次有些功能你可能脑子里一下就想到了多种方案,有可能你觉得任意一种都行,但有时候更好的做法是提交给 leader 或产品做决定,具体情况还得自己判断,尽量让别人觉得你是有想法在认真为项目考虑,而不是无能
    沟通技巧很多,但是这些技巧不具体带入某种情景真的很难说明诶
    corcre
        29
    corcre  
       2023-03-01 16:09:33 +08:00
    @litchinn 这里就需要再次提一下提问的智慧, 我希望所有问问题的人都先读一下这本书(好歹把那个思维导图版给看一遍), 提问之前自己先考虑一遍真的非常重要...
    Cola98
        30
    Cola98  
       2023-03-01 16:11:28 +08:00
    @tianyou666shen 是滴,现在我也是,拿到需求之后,先写写画画,然后有一个大概的方案再去沟通,至少保证大方向上不要错
    Chinsung
        31
    Chinsung  
       2023-03-01 16:30:59 +08:00
    也看领导和同事,你首先得辨别哪些人可以沟通,比如能给你行而有效的指导和建议,并且也比较好相处,心里拿不准的该问就去问,闷着头只能提升提升基础,眼界和思路一定是沟通中碰撞出来的
    BeforeTooLate
        32
    BeforeTooLate  
       2023-03-01 16:31:53 +08:00
    沟通不是瞎聊天,那个帖子看了,其中一点不确定的需求自己瞎搞,我觉得这样肯定不行,不确定可以多和需求提出者确认。
    tianmalj0613
        33
    tianmalj0613  
       2023-03-01 16:55:42 +08:00
    之前我们部门对接的一个产品教的一个点:

    人和人之间沟通都有自己的知识和认知领域,你和对方对话时也应该考虑用别人认知领域内的语言把观点或者问题描述清楚,以做到最少的信息偏差。


    他给我们说这个问题的原因就是:老有研发给产品说一些技术层面的东西,说了半天,问题也没说清,产品也听不懂,浪费了时间。
    alen0206
        34
    alen0206  
       2023-03-01 17:16:09 +08:00
    遇到问题尽早提出来,多沟通,向上暴露风险
    遵守团队内的规则
    技术提升
    aceinnes
        35
    aceinnes  
       2023-03-01 17:19:55 +08:00
    我也喜欢闷头搞,实在搞不定再求人问人
    KedaArray
        36
    KedaArray  
    OP
       2023-03-01 22:35:31 +08:00
    @aceinnes 说实话,凭兴趣入这行的,大部分都喜欢闷头搞。我也是....
    chenyu0532
        37
    chenyu0532  
       2023-03-01 23:51:13 +08:00
    来开发游戏吧。文案、 数值、场景、关卡、特效、ui 、原画 等,我基本每天都要跟他们交流一些,不交流怎么往下做。。
    magiclz233
        38
    magiclz233  
       2023-03-02 00:41:10 +08:00   1
    需求来了要问清楚,不清楚的话要去看原型图,ui 设计,找产品经理问好,特别是细节地方,避免返工,另外一般会喊上产品,前后端开发,测试,ui 开一个需求说明会,产品经理给讲,下面提意见,最终确定好再开发。
    开发之前,比较复杂的模块,就是开发的这个人,出一个自己怎么开发这个功能的技术方案,然后喊上技术经理开会和确认技术方案,完事了再开发。
    另外出现那种跨部门的配合开发,这个是最烦的,经常对方改了啥不给说,导致其他部门的返工,后面就要求如果有啥改动影响其他部门的使用,特别是 iot 平台,基础服务之类的,必须在一个固定地方写出来,另外给相关人员发邮件确认。
    看起来特别麻烦,其实我觉得确认好之后,开发挺快的,之前经常返工,测试反复测,搞了半年吧,确实有效果
    KedaArray
        39
    KedaArray  
    OP
       2023-03-02 01:48:39 +08:00
    @chenyu0532 35 会被优化嘛( doge )
    MMMMMMMMMMMMMMMM
        40
    MMMMMMMMMMMMMMMM  
       2023-03-02 02:28:46 +08:00   1
    分人

    如果你的同事 / leader 也是混日子型的,有问题喜欢往别组推的这种,那么你找他沟通一般都是在讨论真正的、最小可解决的问题,提出的方案也都是落地的、合理的;会尽量把脏活、重活推出去,整完了大家一起划。

    如果你的同事 / leader 是那种"上进"型的,希望出业绩,"事业心"特强的。除非他就是老板,不然开会一般就是在放屁 / 造词,提出的方案一般也都是空话。

    前者你会感觉到和他沟通压力很小,是双向的。那么此人可以共事。
    后者你会闻到一股浓浓的"集体荣誉感"pua 味。精致利己就多学点甩锅话术,底层互害呗。

    当然,这是职场攻略,你要创业那另外一回事了。
    james122333
        41
    james122333  
       2023-03-02 02:58:35 +08:00 via Android
    没看过原帖 但沟通需要良性的 并不是沟通越多越好
    而是沟通需要有成效 无效沟通是无用的 耐心、同理心与和平
    cangcang
        42
    cangcang  
       2023-03-02 11:15:10 +08:00
    @estk +1 ,本来是要讨论应用场景,取舍一下功能。结果老板自己也说不清楚应用场景,只会 既要...又要...还要... 。那我还沟通个
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     965 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 30ms UTC 22:38 PVG 06:38 LAX 15:38 JFK 18:38
    Do have faith in what you're doing.
    ubao snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86