让我看到了知乎上的对于技术研发人员的评价：
1、木讷，没礼貌；
2、合作做事情不喜欢 (del) 汇报 (/del) 沟通进度，比如正在做你的东西，忽然停下不知道干别的什么去了，不等你催他都不跟你讲；
3、不回信息，回的话就重现第 1 点；
提醒：不引战，这个也适用其他职能。因为上面的问题不在于人的问题，而是流程问题，因为这种互相不对付的情况，理论上会阉割在面试过程中。

只要不是太过分都不会骂的，很过分的比如说完全没自测过流程都跑不通就提交测试了·····

谁进公司的时候不是一腔热血呢。有些人沟通起来太费劲，有些部门又降本增效，有些客户仗着是甲方态度恶劣。
这种事情不能一概而论贴标签，一个人和所有人合不来那是这个人有问题，如果只和个别人合不来那就要考虑考虑到底是谁的问题。
现在又降本增效，不论哪个岗位都承担的越来越多，很多流程说上去都是有，执行起来又是另一码事情，人跟人就是有能力高下，有些人就是能让你火大。

牛马何必骂牛马，还爆粗口 我一直提倡的是测试工程师就是 “医生”，你既然说软件没有达到预期，有 “病”，你就拿出 “证据”（1、针对业务功能直接回溯需求文档，把需求截图贴上；2、针对需求含糊不清，当前可以找产品和项目其他人一起确认，确认后等项目结束开回顾会议，要求下次迭代要求产品经理需求文档出专业点；3、很多测试同学很喜欢研究用户体验的问题，关于用户体验这块比如 UI 和交互这些可以形成公司统一的风格规范，10 个人就有 10 种用户体验，这种 BUG 不影响使用，提上去改不改再说）
最后再说一点，小命是自己的，工作没有可以再找，干的不开心就趁早走~

我再多说点，当然这个和公司项目管理流程也有很大的关系，很多公司项目管理混乱，没有具体的 PMO 岗位来专门监督项目开发过程中管理的乱想
我们现在为了减少 BUG 和线上事故，每次版本开发计划排好之后，给开发 1 到 2 个工作日看需求，利用 1 个小时候的时间开需求反讲会议，会议有产品经理、项目经理、参与的研发和测试，每个开发都有去把需求讲一遍，讲自己对需求的理解和基本的设计思路，有问题产品经理当场指出，测试同学也要明白开发的设计，不明白的当场确认讨论

那就是我们所在的公司太 low 了，总能遇到无法沟通的人
希望所有打工人都能遇到和谐友善，步调一致的同事和战友