项目中的需求

      本来以为给美国做项目，项目管理应该比较规范的。结果从开始到现在快结束，都没有接触过任何规范的文档。想想之前的形式CMMI公司，至少还有需求文档、概要设计、详细设计、单元测试用例（自测）、产品说明书、系统白皮书、方案设计说明书等文档。现在倒好，这些文档从来没写过，也基本没见过。好吧，没有关系。但是功能说明书，一旦确定，那么基本所有的研发设计活动就有据可依。

      我们这，需求应该是由产品线从客户拿到后进行分析后，转化成功能需求文档再发给研发相关人员的。但在这个项目中，基本都是客户给一份需求列表，然后产品线的产品工程师，直接由件转发给项目组的成员。基本没有什么细过滤。最多只有工业设计与软硬件开发两种区别的过滤。其结果是，软件研发人员需要自己从大量的需求列表中找出跟自己相关的东西，要剔除硬件基带、射频的部分。我都不奢望产品工程师能从软件部分中将驱动部分的功能从上层应用、UI界面、通信协议中区分出来。当一个客户需求来后，产品工程师，直接给项目所有开发人员发邮件，然后要求给出评估结论。有时，评估结论反馈后，产品线半天没有反应。直到研发觉得产品线应该是同意研发提出的解决方案了并且已经实现之后。结果产品线来个邮件，要求按这样那样做。事实上，这个要求根本就不符合实际情况，或者与已经实现的机制大相径庭。然后就是产品线和研发人员邮件之间争来争去。有时因为时间进度的条件，研发胜；有时是客户十分强硬而研发重新开发。不管最终是谁的胜利，都是项目运作的失败。

      在这种情况发生两次之上后，我意识到要采取必要的措施了。于是在研发项目组内部会议上，我提出我们研发人员要整理和自己相关的需求列表文档。之后在和产品线进行交涉的时候，依此为据。结果似乎大家都推托没有时间。好吧，你们没有时间那就算了。我把自己的整理好。大概花了半天的时间，整理了一份像模像样的需求文档，并且做好了版本规划。然后将该文档发给项目经理，项目经理再转发给产品线，并要求产品线进行评审确认。结果呢？三天之内没有任何反馈。OK！那么我就当作默认了。我的软件开发就以该文档为依据进行。

      第四天的时候，产品线回邮件了。把我文档中关于充电的方案作了一点修改。项目经理对我说：“我就知道，直接问他们问不出什么意见，一旦写出个文档，他们就会提意见了。”我知道，其实他对产品线这样的做法也不满意。不过没办法，我们这就是产品线比较强势。我说产品线强势没什么关系，但你要有强势的资本，啥都不懂，你强势什么呀？好在我们的设计还比较灵活，新需求还可以应付。OK，我不计较了。

      昨天产品线那边又提了一个需求，说是客户需求。我一看就有点崩了。这个需求没法做，要做的话，时间又需要延长了。那我们的项目进度在已经延误的情况下又要延后了。这样没法做了。项目经理直接就给产品线作了拒绝处理的回复。我真喜欢他的态度。呵呵。不过如果产品线在客户面前没有这么强硬的话，我们又要折腾了。不过，不管怎样我会要求客户先出详细的需求文档，详细地描述出功能的应用场景和需求细节。让客户和产品线被我们折腾一下，让他们知难而退。否则专门折腾我们，我们太冤了。