不同的公司，有着不同的组织形式，各种名字相同的职位在不同的公司也有着不同的职能与权限。在软件公司，一般存在以下职务：项目经理，产品经理，高层管理者，部门经理，测试经理，SCM经理，SQA经理，客户服务经理和客户经理。而中小公司，这些职务是交叉，兼职的。
项目经理这是一个最为被滥用的字眼。再多数公司，项目经理即负责技术，也负责管理工作，同时，项目经理也是这些公司中非常尴尬的角色。一方面，项目经理没有资源控制的权利，他（她）不能主宰谁会参与该项目，项目所需要的硬件设备；另一方面，他（她）还要对整个项目负责，出了问题，领导/客户/市场人员一定会找他（她）。他们（她们）还要负责与客户，甚至其它部门，项目组的协调工作，还要受到SQA的百般刁难。听起来真的不是一件好差事！
我曾知道有个项目，项目经理是公司的一般员工（当然经验丰富，资历甚老），他手下的设计、开发人员却有公司的部门经理，甚至有公司的技术副总。天哪，要知道这些人即不好管，也非常忙，一会儿在公司，另一会儿就可能远在几千里之外了。可以想象的出来，项目做得并不成功。我看到那个项目经理面无表情的样子，出现在我心中唯一的一个词就是“哀莫大于心死”。果然，项目完成后，项目经理辞职，而公司老总对他的最终评价是“这个人不适合做项目经理”。当然，这牵扯到另一个敏感话题－“人力资源评价标准”，这个问题，我要留到以后专门谈起。
产品经理产品经理的职权相当大，他应该是最了解某项产品的人。一般该职务由某产品的项目经理后继担任。做的久了，该人员对系统的把握和业务的了解，达到了一个新的档次。不少公司主打产品（大产品）的产品经理一般由公司的分管部门经理担任。
产品经理应该对负责产品的发展趋势有着敏锐的洞察力，在一些非常大的企业，产品经理可能由售前人员担任，因为他们眼界比较开阔，而且，也拥有大量跟踪产品发展趋势的职能和必要的资源保证。
当然不排除有限公司将一些不太成功的产品交由其他人员管理的情况，但这种情况多为原先的产品经理看到形式不妙，或有其他更“重要”，更有“价值”的事情去做，而将该产品推给别人，将风险或问题转移到他人身上。若有这种现象，公司应予谨慎关注。理想情况下，公司可能会得到两名优秀的产品经理－原先的产品经理吸取了教训，新的产品经理在维护中学到了许多东西，真正称为行业专家；不理想情况－原先的产品经理故技重施，而新的产品经理只会发牢骚，最终辞职。
SCM经理开发人员是不喜欢专职做SCM的，那等于宣告技术生涯的结束。所以，SCM经理的职务并不高，起码得不到公司里大多数人的尊敬。不过SCM有一个尚方宝剑－公司严格的规章制度，但这也得罪了不少技术人员，其中包括测试人员。
由于工作的特殊性，SCM一般由技术不强，但办事认真的员工担任（我可没有贬低SCM工作的意思，事实上是我的两个很好的朋友都做过SCM，而且我自己也有幸在一个项目的后期充当了SCM）。但由于技术不强，SCM往往无法深入理解软件构造过程和需注意的技术问题，还有就是对设备、环境的不熟悉也会导致一些偶尔棘手的问题。
出于对系统的不了解的先天缺陷，SCM也不能对将来的工作做太多的符合实际的改进活动，对到底需要哪些配置项，甚至配置项的安全级别的控制依赖于项目经理的一面之词和开发人员的自觉性。
SQA经理其实这是一个最痛苦的角色。对某个项目或产品评头论足，有唱红脸的，有唱白脸的，那么SQA一般是唱白脸的。原则上SQA应该权限十分巨大，该人应该是公司重量级人物，但又有几个公司会将如此重量级的任务放在SQA的位置上呢？而且又有几个重量级的人物会自愿做SQA呢？
我曾见过一个SQA，在指出了项目的一些问题但得不到解决后，向高层领导反映，但许多高层领导也是做技术出身，他们（她们）反而帮着项目经理说话，活活要把SQA气死。概念上，SQA只保证过程，过程是完善的，那么产品一定也不会出大错，但关键是怎样的过程是合理的，这个问题要具体问题具体分析。中国有句成语，叫“金玉其外，败絮其中”，SQA又如何揭开金玉，看到其中的败絮呢？如果没有对项目足够的关注和经验，SQA是无法有效开展工作的。事情往往是，SQA只审查文档编写是否符合规范，有无错别字，评审开了没有，代码书写是否规范等，而这些问题并不能给项目的质量构成实质性的威胁。而且，若SQA感觉到项目有重大问题，如需求迟迟不能确定，没有确定好大的架构就开始详细设计甚至编码这些问题时，高层领导也往往会因为项目进度等种种理由原谅了项目小组。
SQA在我心目中就像一只独自上蹿下跳的猴子，自己急得要命，旁观的人却无动于衷，偶尔还会有人侧过头去耳语：“皇上不急，太监急！”。
高层经理高层经理应该是有着足够大的资源调配权利，以及对产品的未来和客户非常关注的人。许多高层经理虽然没有直接的人事任免权，但他（她）对某个人的评价是至关重要的。缺憾是，高层经理都很忙。他们（她们）往往只关系所谓的大事，如与同级或上级之间的沟通，与客户之间的应酬等等，却往往疏于内部管理。
好多年了，“授权”的管理理念已经深入人心，深入到扭曲的程度。许多高层经理使用“授权”的思想，将事情分派下去后，就较少关注了。
记得《兄弟连》里有这样的一个片断：一段时间，美军被德军压制住，天天遭受疯狂的炮火轰炸，战士们的情绪非常沮丧，“恐惧像瘟疫，是可以传播的”。这时，有一位兵士长跟每个士兵聊天，鼓舞他们的士气，对他们说笑，倾听他们的想法。本集的最后，新任命的连长告诉个兵士长说：“你才是这个连的灵魂”（我记不清了，或者是“杰出的领袖”？）。而前任连长却是个只会瞎指挥，根本没有作战经验的领导，士兵们在需要的时候找不到他们的连长。
当然，战争时期是非常时期，与现在和平年代里的公司环境是相差极大的，但我希望每一个高层经理都能称为公司某一领域的灵魂，而不是只会发号施令的“活死人”。古时就有“失察”之罪，无论如何，上级应该对下级应有足够的关注。
测试经理其实在许多中小型软件企业，特别是中型软件企业，测试经理是一个较容易出成绩的职位。关于测试，一方面理论、技术已经比较成熟；另一方面，许多公司也开始意识到测试的重要性，但测试的许多规范、制度还没有完善，这个时候做测试经理的确是容易引人瞩目的。
测试经理需要心细，但不能心软，而且需要一定的业务领域知识和技术技能，若技术技能不具备则可以找领导派技术人员配合。尽管许多开发人员是不愿意做转职的测试人员的，但请相信我，做测试对个人的发展是有许多好处的。开发，做的多，错的多；甚至有时维护时期，碰到一些傻瓜客户，不断的向客服提问题，领导很有可能会认为开发人员做的产品不好（有时领导不说，TMD，这下你可吃哑巴亏了）。我的意思是，测试人员的功劳很可能比开发人员的明显，或者说“立竿见影”。
部门经理部门经理是一个部门的接口，他（她）对对部门的人员、处理的业务都非常熟悉；如果你有事情需要某一个部门协助，那么，找该部门的部门经理。可惜的是，一般部门经理不能做高层经理，因为，如果项目需要跨部门协调的时候，单独的一个部门经理的能量是不够的。而且，有些公司分工比较细，找某一部门的部门经理担任高层经理，可能会使决策有些偏颇，因为可能他（她）是如此关注于某一领域，而忽视了其它部分，造成整体的不和谐，但无论如何，这点不足不会影响他（她）称为行业专家。
部门和项目不同；许多项目是由许多部门的人员组成，项目一结束，人员也都回相应的部门；所以，部门经理对人员的关注应该是很高的，他（她）对部门人员的评价也是至关重要的。
客户服务客户服务部的主要职责是解答客户的问题和咨询，如有必要，需协调开发部门或市场部门。客户服务部是公司的窗口部门，责任重大。该部门对人员的要求是耐心，同时对技术知识和业务知识也要有比较深刻的认识。不过，同SCM一样，一般的技术人员是不愿意去客服的，去了客服也意味着技术生涯的终结。而且，客服天天与客户打交道，更是出力不讨好的活，对客户不能发脾气，哪怕对方的问题有多么幼稚。客服有时还会督促技术部门尽快答复（或修正BUG），这也意味着客服与一般技术部门之间的关系不会很融洽。
更可怕的是，技术部门的人员可以很快接手客户服务部门人员的工作，他们也拥有相关的背景，所以，客户服务部门的人很可能会生活在对未来，对自己前程的忧虑中，而且忧虑的程度要远大于其它技术技术人员。
客户经理客户经理一般由市场人员充当。在许多将软件行业管理的书中，经常忽视这个角色；但实际上，该角色的重要程度远远大于它在许多人心目中的分量。
客户经理是项目或技术部门与客户之间关系的纽带。尽管我们都要求项目经理有很好的与客户的沟通能力，但由于后天的培养环境终究有异，市场人员与客户打交道的能力与权限（如请客报销等）是项目经理等人员所远远不能比拟的。你会发现，如果拥有一个与客户关系融洽的客户经理会是一件多么幸福的事情。就算你犯了一些错误，遭到了客户的职责，一个优秀的客户经理会想办法将这事情大事化小，小事化了，弄不好，你甚至可以通过客户经理的穿针引线而拉进了与客户的关系，更深层次的了解到了客户的需求，乃至品性，还可能因祸得福。
好好的利用你的客户经理吧，并且虚心向他们（她们）学习，当你叫天天不应，叫地地不灵的时候，你会发现，哪些你平时认为只会拍马屁，不懂技术的傻瓜是你唯一的救命稻草。
其它服务部门其它服务部门更是被许多书籍遗忘的角落，尽管它们对于技术人员的作用要远远小于市场部门，但，真的，它们会影响到技术人员，甚至是开发团队的工作。这些影响在有时甚至是致命的。
其它服务部门包括办公室，财务部。有些人可能要问了：你忘记了人力资源部。噢，我暂时还不想讨论人力资源的问题，还是留到后面的章节深入讨论吧。
我曾见过一个水平非常高的技术人员，他谈起，财务部的报销制度不合理是他第一次辞职的直接导火索。那个时代软件工程师还是一个非常牛的职业，一些技术牛人真的可能因为一句话而辞职。我们抛开对与错不谈（事实上，我的这位朋友后来非常后悔当时他做成的决定），服务部门的确会给员工以不好的/好的影响。
你敢保证大多数人不会因为节日没有发礼品而抱怨，从而对公司的前景，公司对员工的态度而四处网上发简历？你敢保证大多数人在外出差或封闭，天天加班，为公司卖命，回到公司后报销正常的发票，查了一大堆财务说明后，还是被告知“你的发票贴得不规范，回去重贴”，当问及如何才是规范时，唯一的答复是“回去看notes”的时候，不会心里酸酸的，而出现消极怠工的情况？你敢保证办公室的人员乱扔传真，而严重影响项目进度，造成上帝（客户）怒骂你的时候你会向大家微笑：“我就是贱”？而且事后，办公室可能还会贴出通报：“我们对此类事情不予负责，请大家注意…。该规定的最终解释权在办公室。”你敢保证当你的计算机坏了，添了一堆表格后，等待了几十天后问题还不能解决时不会影响工作？
事实上，许多公司的技术员工与服务部门的关系不是很和谐。财务是二当家，办公室是对老总们负责的。我承认，办公室的人员和财务的人员工作压力很大，主要责任不在他们（她们）身上，技术人员应该理解他们（她们）的苦处，其实他们（她们）是很容易相处的。问题最本质的原因在于部门职责定义不清，或定义太空泛。
本文地址：http://com.8s8s.com/it/it36869.htm