作为一个低调的程序员，平时除了要学学技术外，还要多多关心除开发以外其它职能的作用以及运作，方便站在一个比较高的层次看待问题。特别是当你的工作越长时间成为老鸟时，你要遇到的人的"品种"将越复杂，了解这些将能更好地利用资源。

 就开发而言，经常接触到的有项目经理、技术经理、一起开发的同事，偶尔技术遇到问题时找技术经理解决，如果是超出项目组能力范围的技术经理通常会调动项目组之外的其它资源，比如美工、SL、其它项目组等，也可能是你直接跟资源沟通，因为遇到的问题你最清楚。需求有问题时一般都会找项目经理，不会让你直接找需求人员。就我的经验，通常都是前期需求人员与项目经理一同做需求调研的，所以项目经理也是很熟悉需求，之后需求规格说明书出来后，基本上就见不到需求人员，中间的桥梁其实就是项目经理了。许多公司为了节省开支，通常在项目的前期会分配有一个项目经理和一个技术经理，或者只有项目经理或技术经理。技术经理根据需求设计详细设计之后经常会闪人，他们经常会同时有几个项目并发，分身乏术。

所以需求方面和开发人员没有啥关系吗？错！对于刚入职场的菜鸟而言，老大分配的往往只有开发任务，但是对于团队内部的精英、核心骨干，经常也会充当前期的需求调研角色，除非是需求人员开发出身，熟悉技术，能在技术可行性上引导客户，否则还是需要开发人员去提供技术支持的，所以开发人员也会和需求人员和客户打交道，包括前期需求范围的确定。开发人员不是机器人，接到什么任务就做什么，对于不能实现的技术或开销比较大的开发他们也要提出自己的意见。还有，有些公司没有专门的部署人员，通常部署的角色都是由开发人员承担，这个时候你需要和客户那边的运维打交道。部署后你又要做客户培训等等工作。然后你求神拜佛，希望部署后不要出现太多问题，然后催客户赶紧验收，然后有项目奖金可以拿。部署之后没有问题是不可能的，客户在使用之后会提出更多的需求，这是好事，说明你做的系统有人使用了。

 漏了一个环节：测试。其实规范的项目应该分配有测试人员的，而且在需求文档出现之后，开发项目之前就应该做需求测试了，然后做白盒测试，阿尔法测试、单元测试、回归测试、集成测试等。测试在正规公司其实占有很大比重，对于做企业应用的公司，这部分往往做得比较薄弱，一些游戏公司比较重视。在微软，测试人员其实就占了一半，可见测试的重要性。

刚才说了那么多，其实也还只是站在一个开发人员的角度去想问题而已，前后经历了需求、设计、开发、测试、部署、验收、维护等环节。现在以做ERP系统的公司为例，讲讲我对售前、售后、产品、市场、销售几个部门职能的理解，通过对这几个部门的理解我不再是站在开发人员的角度去想问题。（这里要多谢荣哥的指点）

市场：做市场调查，然后做宣传吸引客户（荣哥公司的市场是靠两种方式吸引客户的：一种是与行业内知名IT公司（如：Oracle）合作，然后搞产品宣传；第二种是请行业内的专家来做讲座或培训，培训完后顺水推舟做产品宣传）。总而言之，做市场的就是尽可能地挖掘好潜在客户，然后挖空心思给客户灌输公司的产品、宣传产品。

产品：做产品的对各方面要求都比较高，就荣哥说的，在他公司要进产品部起码要在这个行业内混上个四五年。产品要求对业务要达到精通的程度，并且能很熟悉产品的使用、产品的细节，业务上是这个领域的专家了，能在一定程度上引导客户。技术方面也要求比较高，因为要和开发人员交流。

销售：销售要做的就是“拿下单”，做销售的一定要懂业务和产品，可以不懂技术。，但最主要就是凭自己的三寸不烂之舌说服客户买你的产品，客户签下单之后销售就拍拍屁股闪人了。

售后：可以理解为实施吧。其实售后也是蛮考验人的，这一部分荣哥深有体会，说得也很具体生动。首先，公司虽然有产品了，但是毕竟人家原先就使用了一些系统，积累了很多数据，那么如何去将老数据整合到新产品中呢？而且产品最终能否比原先系统好用或更加规范，要经得起考验，经常会听到一些客户大骂：“怎么新系统比老系统还麻烦啊！要点好几个按钮才能出来？原先只要输入以下就行啊！”这个时候实施可能会成为出气包，导致这种问题有很多原因，有可能是为了数据更加规范统一，也有可能是为了某个报表的更好统计，能否说服或说安抚好用户，就要靠实施人员的经验和技巧了。而且客户提出的需求通常会反馈给实施，然后再由实施反馈回项目经理或开发人员，这当中有涉及到沟通问题，能否正确的传达客户要什么，也是一个考验。综上所述，实施中最难的就是需求变更以及新需求的把握、解决方案的沟通等。