闲聊中小公司小团队的项目管理（闲聊中小公司小团队的项目管理方案）

中国的中小型公司，一般因为创业者关注到某个市场特殊的需求，几个人拉着风投就干起来了。大都在盈利模式或市场上有过人之处。公司的老板将大部分注意力放在盈利模式和市场的维持与拓展上，关注内部的管理相对较少。道理也显而易见：盈利模式或市场是“开源”，而内部管理其实是“节流”。比如说，一个互联网公司，管理很糟糕，但是由于盈利模式新，还是可以赚大钱。而一个玩具工厂，管理非常好，但处于产业链低端。人民币一升值，关税一提高，全部完蛋。从某种程度上讲，关注盈利模式没有错，但管理为盈利模式提供一个强有力的支撑，可以实现良性循环。所以小公司变强大，管理是必须要走得路。

然而小公司团队的项目管理的确不好做,资源少且软环境较差。有种百废待兴的感觉。管理成份多了，体现不出船小好掉头的优势，浪费许多成本，老板看得心疼；管理成份少了，项目又不可控，风险频出，质量度量预测不可信。如果上CMMI，用不了多久就会发现：过程域多，每个过程域里的特殊实践多。对工程域裁剪不裁剪，对特殊实践裁剪不裁剪，的确是很难把握。大多数时候，我们身边没有CMMI的专家，很难把握项目的规模与CMMI裁剪的分寸；动不动就同行评审，会发现团队里有价值的专家时间全部被评审占完了，根本没时间去做别的事情。

那行，咱不用CMMI，用敏捷。XP编程，TDD开发……发现噩梦才开始。比如说XP编程，两个人相互结对编程。

“能保证100%的堵住问题吗？”——Boss

“呃……不能……”——我

“那你为什么浪费一个人干这个事情？”——Boss

“……”——我

结对编程的主要目的是加强同行评审，将同行评审引入过程。两个人编程也是相互学习加深理解的过程。同时结对编程基于对需求的正确理解上，而对需求的正确理解，又依赖一个人的知识和其他因素。如果一个强势的人和一个弱势的人在一起结对编程，恐怕是要一边倒吧。国外简单的问题，到国内来，就问题频出。曾仕强老先生的《中国式管理》实在是太有道理了。

再谈TDD编程，测试驱动开发的想法很好。但测试用例设计的有效性怎么保证？特别是单元测试，与最终的结果无法对应起来。并且需求变动后，内部的接口也要发生变化，那么自然测试用例也要发生变化，需要重新设计。然而设计依赖于编程人员本身的素质，如果设计的不好的话，带来的项目变更的成本还不如CMMI那种节约。

国内缺乏一些实施的土壤。PC编程的门槛很低，很便宜的工资可以招来一个人来干活，也能把事情做出来(质量低)。老板认为，PC编程本身就是廉价的，没必要高工资养着人，过两年，新员工变老员工，裁掉换一批新的便宜的。这个思路使得项目管理工作陷入一个万劫不复的无底深渊。恰逢中国这个市场，又是一个什么档次产品都有市场的地方……总有那么一部分人喜欢廉价产品，总是砍价砍得别人生存空间都没了，所以才有了染色馒头、工业醋酸勾兑的醋……实际上是一个劣弊驱良行的过程。敏捷对人员的初始素质要求是较高的，中小企业里实施100%的敏捷，我觉得是不太符合国情的。

中小公司的项目管理纯用CMMI、敏捷等方法都是不合适的。那么怎么办呢？过程是人、方法、技术、工具的四者有机结合。小公司的资源不足，软环境不好，说白了，人的问题可能更突出一些。没有完善的公司制度、没有健全的企业文化。不能为项目管理提供有效的支撑。小公司靠哥们义气，中型公司靠制度，大公司靠文化。 所以对项目管理者的个人能力要求就比较高了。和员工走得太近，容易背离组织和企业的价值目标；不和员工走得太近，又会使得团队没有凝聚力，人员流动率变高，需要项目管理者处处权衡。

稳定团队可以使得技术解决方案、业务递进有一致的延续性, 有延续性才能谈提高、创新。团队的稳定一是要靠项目管理者的个人魅力（或关系）；二是要靠公司所处行业好；三，技术人员一般寻求以下2个目标：1.技术/能力的成长；2.待遇的增长。通过项目的锻炼，挑选出有能力的人做相关模块的专家。这些专家轮流培训组内成员。同时，给予一定的物质奖励，形成良性循环。

项目的生命周期中的需求、计划、实施、收尾四个四个阶段有四个阶段的交付物，如需求、概要/详细设计、产品、测试用例、测试报告等。项目的过程也会产生组织资产，也会产生项目的最终交付物。只要在20%的事情上，投入80%的精力，可以达到一个80%的效果。所以，应把主要的精力放在需求的收集定义以及测试用例的设计上。

需求是条河流的源头，如果污染了，下游就肯定会遭殃。然而需求的管理是非常复杂的。 这个没什么捷径可走，我觉得只能是苦练内功，并且将这些内功练好的人作为企业的专家养起来。 CMMI在需求管理PA的几个SP是非常有意义的。但实践中做到是比较困难，特别是需求跟踪矩阵(RTM)，对项目的风险控制及其最终的交付都有着非常大的意义， 项目越大，意义越大 。DOORS 就是这样的一个跟踪工具，这个工具比较早了，有点不太好用。一些UML工具扩展了UML2.0的语法，可以支持需求建模，也支持RTM，如EA等。如果团队有比较高的素质，使用这个工具可以大幅度的提高风险应对控制能力。

测试是对我们结果的复核，检查我们的工作是否满足我们的要求(需求说明书)。测试时应控制好版本对测试的影响，把每个测试用例分级，严重级别的Bug一定要出问题分析报告，普通级的Bug和轻微级别的Bug按一定的比例随机抽取一些，也要分析问题，给出报告。所有测试和错误报告必须有书面文档，最好使用集成化的研发管理环境，便于查找翻阅。这个会作为组织过程资产，可能被下个项目所利用。用来培训员工，提高整个团队的业务素质是非常有帮助的。

相对需求和测试，中间的过程相对来讲可以稍微“放纵”些。至于详细/概要设计，主要看项目的实施者，

如果他是个经验丰富的工程师，只要求他将一些接口，一些重要的业务模型用UML建模，其他不强求。如果是个新人，要求全部建模，然后一点点评审，直到全部通过。需求如果发生更改，对于老鸟，只要求需求、测试用例以及用户说明书更改，简单的更改，设计只是口头定义；复杂的更改，需要给出更改的模型。对于菜鸟，不管简单复杂，都要求对UML模型更改。设计的时候要做白板讲解，不妨让所有人都来听听，让大家提提都有什么问题(识别风险，同行评审)。形成一个意见书或会议记录，在实施的过程中形成指导。我的感觉是，一个人在感觉他能影响组织和结果的时候才愿意担负责任。对于提出有建设性意见的人给予一些物质奖励，大家都愿意为项目最终的成功交付而努力。每周或两周举行一次这样的会议，对项目进行良性刺激。

在团队空闲时，可召集团队的老人、新人一起研究公司的各个业务模型，抽象出一些公共的部分形成标准代码库。像我的团队对产品的一些通信协议抽象，形成标准协议库。对业务模型抽象，形成一个业务模型代码库。并进行严格的单元测试和集成测试。经过多年的努力，一些重要的项目，公共代码库已经占到了项目代码量的70%以上。在开发项目时，尽量复用这些公共代码库，减少风险，提高最终的交付质量并大幅度减少交付周期。我们响应客户的需求有原来的2~3个月缩短到了1~2周。

在整个项目实施的过程中，可以适当的引入一些CMMI、敏捷的工程实践。如代码评审，每天抽一个小时，大家都来看代码。分析哪里写得好，哪里写得不好。坚持一段时间，代码的撰写质量会大幅度的提高，也会积累相当的文档，用于培训新人(满足技术人的第一个目标)。同时结合一些自动化的代码评审工具，如IAR中的MISRA的标准审查，cpptest等代码静态测试工具等。会达到一个更好的效果。

———————

作者：coolbacon 原文：https://blog.csdn.net/coolbacon/article/details/6326017