近两年一直有个疑问得不到满意的解答。最近，自己也慢慢的找到了至少让我认为正确的回答，在这里和大家探讨一下。首先说个现象，在博客园里，比较热门的文章基本都是很具体的那些技术的使用LINQ啊，WCF啊，ASP.net MVC啊这些，说明什么呢，大家都是技术的爱好者，很高兴，我也是这样。而像我之前写的两篇和开发过程相关的文章(软件开发流程概要-《Head
First OOA&D》读书笔记(1), 满足用户期望-《Head
First OOA&D》读书笔记(2)
)
就应者寥寥了，也许是我学艺不精。
但我固执的人为这是因为,这些管理相关的东西不像代码那样容易描述，不实在。因此也就很难让程序员引起兴趣了。
我的疑问来源于什么呢？以前做的一个项目，团队里的所有人除了程序员就是测试人员，没有做项目管理的人。做项目的方式也很简单，直接和客户打交道，客户让怎么做就怎么做。做了一年后，感觉挺痛苦，客户简直是不可理喻，说的话颠三倒四，明明是他要求这么做的，到头来还说不是他想要的。于是公司派了个全职的PM来，就是项目经理。PM是美国的MBA，又得到了PMP的认证，而且也很是勤奋，还是很有一套的。很快就把以前的一个很大的疙瘩解开了，和客户的关系缓和了,建立起来了很通畅的沟通渠道，做的各个项目也有计划了，规模估算也比较准确，里程碑也很清晰，交付日期也基本不会推迟，版本管理缺陷管理也像模像样了。按理应该说是，没有什么问题了。过了半年问题又出现了。项目倒是一直能够按期交付，但是开发人员和测试人员都是牢骚满腹。加班是常有的事情，自不必说。有的需求明明是客户考虑错了，但一切都听客户的，还要按照错的需求进行开发。质量出现问题时，测试人员开发人员都承受很大压力。光关注过程，结果，短期效果，不关心长期的目标。对管理的关注多余对人的关心，人员得不到激励，努力的付出得不到认可，成员不能在工作的过程中成长。最后的结果自然也都不理想。
要说这个现实的例子，是在就事论事。什么才是有效的管理，其实很多人都有结果了。公司老板开会的时候最爱说的话就是，我们把员工看做我们最宝贵的财富。实际呢，未必。就拿受很多公司追捧的CMMI来说就有非常多，非常细致的管理方法，和度量方法，涉及计划，风险，任务，缺陷，变更，场景，培训等等各个方面。把这些都掌握了就能做好项目了吗？就我的观点，是的！估计很快就有人给出反例，过了CMMI5级，依然项目做的一塌糊涂，那我就说了，是因为没有正确应用这些CMMI的方法。举一个例子，对于项目规模估算，CMMI里规定很多种方法，由下至上，由上至下，模块分解，公司的平均代码产量等等。我们都这样做的，为什么的得到的结果和实际数据有很大区别呢。那就是人的问题了，因为我们所计算的数据都是不准确的。我们的代码生产率是错误的，不是基于长期的统计结果的。这样大家看出来了，归根到底，所有的事情都是人来做的，不同的人做相同的事情，结果经常不同。也就是说，即使是CMMI这样细致的过程管理方法，你给的输入是错误的，那输出肯定也不会是正确的。
人的差别有多大呢，一些项目经理经常会认为，无外乎就是，效率的问题，一天的工作，技术好的，半天就做完，不好的两天才完成。那我就多找几个人不就行了吗？实际呢，不光是量的区别，很多时候是质的区别。因为一个不合格的程序员做的设计，很有可能就导致，最终系统的返工，无法按时交付，造成项目失败。绝不是危言耸听，有时需要一个领域专家整理，分析的需求，用一千个外行来代替都无法完成。这就是人的重要性。因此所有项目成员包括程序员才是关乎项目成败的关键。而不是这些花里胡哨的过程。反过来，一个优秀的程序员，不用这些风险啊，变更啊这些管理方法依然能够把项目做的很好，为什么？因为虽然没有明确的这些文档，但是所涉及的内容都是考虑到了的。比如采用的技术的合理性，外部接口的依赖等等，只是表现的形式不一样罢了。
当然，管理的方法也是很重要的，因为很少有人能够考虑到项目的所有方面。我们必须要借助一些方法来识别，规范，记录需要我们采取措施，需要我们去解决的问题。只是不要盲目迷信，这些管理方法能够自动的去帮我们把项目管理好就是了。
最后，要总结的就是，凡是说不管手下是些什么样的成员，我都能把项目做好的项目经理。要么是点石成金天才，要么是忽视个体价值的蠢货。
我的疑问来源于什么呢？以前做的一个项目，团队里的所有人除了程序员就是测试人员，没有做项目管理的人。做项目的方式也很简单，直接和客户打交道，客户让怎么做就怎么做。做了一年后，感觉挺痛苦，客户简直是不可理喻，说的话颠三倒四，明明是他要求这么做的，到头来还说不是他想要的。于是公司派了个全职的PM来，就是项目经理。PM是美国的MBA，又得到了PMP的认证，而且也很是勤奋，还是很有一套的。很快就把以前的一个很大的疙瘩解开了，和客户的关系缓和了,建立起来了很通畅的沟通渠道，做的各个项目也有计划了，规模估算也比较准确，里程碑也很清晰，交付日期也基本不会推迟，版本管理缺陷管理也像模像样了。按理应该说是，没有什么问题了。过了半年问题又出现了。项目倒是一直能够按期交付，但是开发人员和测试人员都是牢骚满腹。加班是常有的事情，自不必说。有的需求明明是客户考虑错了，但一切都听客户的，还要按照错的需求进行开发。质量出现问题时，测试人员开发人员都承受很大压力。光关注过程，结果，短期效果，不关心长期的目标。对管理的关注多余对人的关心，人员得不到激励，努力的付出得不到认可，成员不能在工作的过程中成长。最后的结果自然也都不理想。
要说这个现实的例子，是在就事论事。什么才是有效的管理，其实很多人都有结果了。公司老板开会的时候最爱说的话就是，我们把员工看做我们最宝贵的财富。实际呢，未必。就拿受很多公司追捧的CMMI来说就有非常多，非常细致的管理方法，和度量方法，涉及计划，风险，任务，缺陷，变更，场景，培训等等各个方面。把这些都掌握了就能做好项目了吗？就我的观点，是的！估计很快就有人给出反例，过了CMMI5级，依然项目做的一塌糊涂，那我就说了，是因为没有正确应用这些CMMI的方法。举一个例子，对于项目规模估算，CMMI里规定很多种方法，由下至上，由上至下，模块分解，公司的平均代码产量等等。我们都这样做的，为什么的得到的结果和实际数据有很大区别呢。那就是人的问题了，因为我们所计算的数据都是不准确的。我们的代码生产率是错误的，不是基于长期的统计结果的。这样大家看出来了，归根到底，所有的事情都是人来做的，不同的人做相同的事情，结果经常不同。也就是说，即使是CMMI这样细致的过程管理方法，你给的输入是错误的，那输出肯定也不会是正确的。
人的差别有多大呢，一些项目经理经常会认为，无外乎就是，效率的问题，一天的工作，技术好的，半天就做完，不好的两天才完成。那我就多找几个人不就行了吗？实际呢，不光是量的区别，很多时候是质的区别。因为一个不合格的程序员做的设计，很有可能就导致，最终系统的返工，无法按时交付，造成项目失败。绝不是危言耸听，有时需要一个领域专家整理，分析的需求，用一千个外行来代替都无法完成。这就是人的重要性。因此所有项目成员包括程序员才是关乎项目成败的关键。而不是这些花里胡哨的过程。反过来，一个优秀的程序员，不用这些风险啊，变更啊这些管理方法依然能够把项目做的很好，为什么？因为虽然没有明确的这些文档，但是所涉及的内容都是考虑到了的。比如采用的技术的合理性，外部接口的依赖等等，只是表现的形式不一样罢了。
当然，管理的方法也是很重要的，因为很少有人能够考虑到项目的所有方面。我们必须要借助一些方法来识别，规范，记录需要我们采取措施，需要我们去解决的问题。只是不要盲目迷信，这些管理方法能够自动的去帮我们把项目管理好就是了。
最后，要总结的就是，凡是说不管手下是些什么样的成员，我都能把项目做好的项目经理。要么是点石成金天才，要么是忽视个体价值的蠢货。