呵呵，“项目管理以文档为中心的管理模式”，简直不敢想像，这是一种什么管理方式。无论文档多么重要，我们都是以客户、产品为中心的。为客户提供核心价值的是代码，而不是文档。
呵呵，一般我空降到一个新公司的时候，要带起一个新公司的项目管理，我说的第一句说都是：项目管理！＝文档。我只需要符合以下几个要求的文档：
1 我们愿意维护和成本允许我们维护的文档；
2 我只要表现状态的文档，不要描述过程的文档（比如我一般不进行开发日志管理，那是项目组自己的事情，是开发者自己的事情，我不关心这种东西）
3 能够为下一个阶段提供输入的，或者是客户明确要求的文档；
其他文档，我都不要！
文档不是说不重要，但是文档的维护需要很大的成本的。文档的本质是为了交流和沟通，只有沟通障碍到了一定高度，我们才需要事无巨细的文档。
文档在制定过程中，首先要明确的是：维护成本，比如一份200页的spec，整理和撰写成本基本上是50个人天，维护成本基本上是100-150个人天。如果文档结构不好，成本会急剧上升。我们是否有更简单的方式来沟通？比如团队既然在一起，客户在你身边，你还有必要以文档为中心吗？
我对于文档的一个看法就是：把事情做细一些总不是坏事，但是做细事情是需要成本的，你是否真的能够做到？如果做不好，还不如不做。 我更希望看见的是以沟通为中心的项目管理模式，而不是什么以文档为中心的管理模式。 以上这些太虚了，对于一个普通的团队，我们重点监控的文档无非以下几种：Spec,high level design, rough design, test case, CR, schedule, release plan and user manual, system design doc,基本上就差不多了。事实上，我们即使在进行超大项目的时候（比如超过1000万的软件产品过程或者400万左右的项目），在每一个迭代过程中，我们也不会采用那么如此严密的文档管理。因为我们对于文档有个基本的认识。文档并不能拯救太多东西。 呵呵，以文档为中心的项目管理模式，OK，你可以列一个清单，说明你在项目中使用的文档，以及在至少2-3个项目中，告诉我你每个项目在文档上消耗的成本吗？ 呵呵，楼主举的例子是MOTO和你们合作研发的，我2年以前（应该是，具体时间记不得了）曾经了MOTO的SQA部经理聊过（当然，MOTO中国中心CMM5的牌子，让我很是敬仰），你知道他们内部的项目是如何做的吗？你知道MS内部的项目是如何展开研发的吗(我认识一批MS的朋友们，就这个问题，我们探讨过很长时间，包括MS本部的管理人员)？IBM软件的项目管理（别的不清楚，至少对他们软件中心的比较熟悉）如何？类似的Nokia的项目管理等等，多少知道一些。呵呵，不是你想像的那样过分的。 比如，去年我们和马来西亚和香港运营商合作的时候，我们也会如此来做（我们甚至有一份专门的文档来保存和对方MSN的聊天计录，和来往的Email等等，会全部计录在案的），这很大层面上是公司之间的合作，接口需要清晰，工作的边界需要明确，责任需要明确。我们为什么这么干？因为这是血的代价换来的，公司之间的合作要万事小心一些，也许一个疏忽，会使得一个项目从盈利变到亏损。但是在内部，恐怕并不是那样做研发的。仅此而已。当然了，如果你们也是面向外部的合作，还是不要管成本问题了，尽量细一些来做，别的行业我不清楚，电信行业，企业方面我领教了一些。这些虽然成本高昂，总好过长期的风险的存在。 当然，我如此说并不是文档不重要，相反，适当的文档会使得项目很流畅；但是，我从来不企图建立以文档为中心。只要能够通过面对面沟通解决的问题，我绝对不用文档解决。比如，如果客户就在我身边，我就不会做事无巨细的Spec文档。我绝对不做成本超过收益的文档，如果研发团队是内部团队，我只是要求Function接口清晰即可，对于内部的具体实现，我就不会要求一定要事先全部做好等等，因为他成本过于高昂了，而且使得项目组织缺乏弹性。 这是我个人的意见。FYI
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
