呵呵,“项目管理以文档为中心的管理模式”,简直不敢想像,这是一种什么管理方式。无论文档多么重要,我们都是以客户、产品为中心的。为客户提供核心价值的是代码,而不是文档。 呵呵,一般我空降到一个新公司的时候,要带起一个新公司的项目管理,我说的第一句说都是:项目管理!=文档。我只需要符合以下几个要求的文档: 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
|