新人刚入职第一个PSC收到Peer这样的feedback, 请问是什么信号？

我还以为有建议都私下提 review的时候只写好的是约定俗成的规矩?

从 feadback 本身看起来没啥问题，夸 LZ 的地方都是很重要的能力，最后给的两点建议也都是非常有用的。如果以后要独自带项目的话，这两点建议都是必须做到的：第一点有助于让项目少走弯路，第二点有助于说服别人（说服组员做某件事情、说服别人认同自己的项目）。

但从 LZ 后面附加的背景来看，LZ 和 A 确实存在交流上的问题。A 不回 LZ 信息或者是不主动和 LZ 交流会不会是因为 A 确实很忙，或者这就是 A 本身的风格？感觉 LZ 可以试一下单独和 A 聊聊，尝试直接解决问题。如果还是解决不了的话，可能减少和 A 的合作确实是必要的。

sshic 发表于 2020-07-22 02:03:18
新入职不是不用PSC么
我以为feedback就是吹彩虹屁再给些无关紧要的建议，lz这个感觉是很严重的不满了，看来以后再不喜欢同事也要笑脸相迎

新人第一个half 还赶在疫情 能干出啥花样？这psc我也服了

我觉得你可以直接和他1-1一下 让他给你提一些actionable的建议来解决这两个feedback

这些建议纯粹就是扯淡 私下不能说非要放在psc上。建议楼主换组

潜台词还是A需要LZ多和他沟通吧。

我感觉他话说的挺重的

我也在FB，正好看到这个帖子，和你聊聊我的看法吧…

纯粹从他给的feedback来看，我不觉得这个特别负面，或者话特别重。你可以对着看看公司对E3的要求，基本就是要给task就看完，对E4会要求给一个差不多规划好的project，能独立干完。给你的positive feedback基本就在说这两件事情。而constructive的部分，大致是希望你更好的做planning，多沟通，这个在FB这种大家都特别喜欢写post的公司，还是挺重要的。一个个人经验就是，有的事情真的很明显能做/不能做，但别人或者大老板不一定有context，你光靠自己的嘴说能不能干，别人不是特别的信任你的话，很难让人完全信服。但你只要写个看起来够牛逼的doc/post，加上一些例子，别人可能也不会仔细看，但就会觉得你说的是对的。这样就不容易出现他feedback里提到的问题。所以我觉得这个feedback还是很实在的，也给了实际的例子，你可以想想在他给的example里是不是真的有问题，如果是他想当然写的，你可以再找自己的EM聊聊。总之他的constructive feedback，基本没有说你在E3干得不好，所以不会对你的review有太多直接的影响，当然可能会影响EM对你的印象，影响他对你升职的规划等等。

对你后面的描述，FB也没有什么正经的mentor制度，都是新来的人，EM就随便找个人带一下，你也不必期望过高，以后他不回你block你了，你就可以问问其他人，或者直接找manager帮忙，对E3，manager本来就应该多花一点时间。再说他把这些实际问题写在feedback，上面大家都建议了，你可以直接和他当面聊一下。理想的情况下，他应该在发现这个问题的时候，就告诉你，给你feedback。而不是等到psc了，才写在review里，suprise你。你完全可以和他约个会，当面问问他，给他解释一下你当时的观察，让他以后再有类似的事情，直接当面告诉你（这里同样的，如果当时你把你和peer们讨论的结果，写下来，哪怕就写在design doc的最后，不额外发post，你就可以有凭据了，可能也能给他不一样的印象）。如果聊下来，发现他就是对你个人有意见，那就直接去找manager抱怨吧……

哎呦，一道经典的behavior question不就来了么：如何处理跟同事的conflict？

一般碰到这道题，我会说：首先我会assume同事的意愿是好的(well-intentioned)。大家都是想把一个东西做出来，在意愿是好的的前提之下，出现conflict都是沟通问题。楼主这个例子里，YYY这个项目有些design doc么？如果有的话，在design doc里应该有写alternative approaches。如果没有提到AAA，那么design review的时候，TL可以提出来。

可以看到，沟通出现了问题不一定是楼主单方面的问题。可能你们TL沟通能力也不好。但我们不能改变别人，只能改变自己。遇到沟通能力不好的人，要自己努力创造良好沟通的条件，比如问正确的问题。

如果单看TL给楼主的feedback，不考虑你们之间其他的交流之间的friction，我认为这个feedback挺好的。

当然，不可否认职场上有人会专门针对别人。但在下这种结论之前，我觉得还是应该给同事以the benefit of the doubt。

其实说白了就是让你在communication上多做一点了，做为一个刚入职的新员工也挺正常了，尤其如果这是你的第一个工作。而且这些feedback有一定道理，如果他/她说的是真的话，在做一个project前，确实需要大量的沟通，文档，以至做完之后还是需要各种分析看看你project带来的结果怎么样（将会是你的impact)。正式工作不光是写代码了，真正的coding估计能有一半就不错了。