某SE从国内某著名电信IT企业空降过来，并且在C++领域有着10几年的开发经验。估计是做电信软件的，经验丰富，电信软件那一套高可靠性，高性能玩的很熟。来了之后做JAVA项目，但JAVA毕竟不是C++，我们的领域也不是电信，这一套武功因此失去了大半功力。
在C++领域，毫不客气的说，很多人的视野偏窄的，这根C++项目长久以来的稳定性有关系，在电信业需求更为固定，尤其是平台层，需求多基于协议；但在行业软件开发中，需求很多情况下不明确，而且需求分析师这一神圣职位很多时候被SE兼任，于是SE就用他专业的眼光梳理需求，创造需求，和曲解需求。
开发人员欣赏的SE的技术眼光一定是要广博，尤其是要有相当的技术储备，紧跟行业趋势，了解最新的框架，开发思想等，不能临时抱佛教，查百度，这样才能给开发人员指导，输出的规格也能更加贴合实际。
除了技术眼光，SE在本领域内的业务也需要是专精的，在某种程度上，要更加重要于技术水平，技术的问题开发人员可以解决，但在需求，场景上，由于着眼点的不同，开发人员很难窥得系统全貌，这时需要SE理清需求，理清思路，我们询问SE，当然不希望听到“这样吧”，“我认为”，“先这样了”这些模凌两可的答案，开发人员更希望得到确定的，自信的答案，这也是我们信任SE的关键。
在沟通上，某些SE往往走向两个极端，在面对项目经理及其他SE评审多接受；面对开发人员的质疑，多采用压制态度。根据我的观察，采取压制态度的SE会导致更加频繁的设计变更，因为开发人员提出的问题往往是细节的，甚至是绕不过的。
某些SE喜欢把规格写的无比详细，具体到类，方法，甚至参数，其实在规则中的东西，真正能进入开发人员意识的并不多，尤其是长篇大论的场景式描述，关键信息淹没文字中，大家都是成年人，阅读能力没有问题，开发人员应当熟悉场景，但不应该分析场景，场景的分析和具体化，应该由SE给出的。我们希望见到的规格是：场景描述+AR点。
规格评审完毕，SE BOSS同意了，或者是厌倦了；开发人员明白了，或者是干脆不想明白了，总之，项目进入了开发阶段。这时候，SE还债的时候到了，以前没有想到的，或是规格中没有描述清楚的，或是前后矛盾的，会有开发人员频繁的过来澄清。为什么叫澄清，这个词太好了，因为原本是浑的。
另外，好的SE是一定要带有光环的，类似于升级游戏，或者叫做信任叠加。
后记，该文转自园子里面一位哥们的，作为一个SE，觉得其中部分的看法有些许道理，转过来，自勉一下。