问题分析（1）救火式的研发模式

         经常有同事为了一些问题争论，争论的是我们要不要做这个功能，该做成什么样，参考机怎么样，我们要不要做……这种争论在研发的中后期都是非常可怕的事情，一旦一些重要的争论的结果带来的变更，付出的代价可能是一些本身比较稳定的模块，又需要一段时间的稳定。类似于这样的情况，不断地在我们项目的开发中上演，工程师疲于奔命地为此在拼命救火，我们真的对此束手无策，毫无作为吗？看看我们的现状，从产品定义到需求Spec真的少的可怜。

遇到问题，开发的找不到需求，只能凭自己的想象去设计，更加谈不上缜密的评审，测试的没有针对产品需求的测试Spec，需要做一大堆的对比工作，花费了很多时间来对比参考机的行为定义，再一堆人讨论需要做成什么样。整个过程中，可能带来一系列问题，工程师可能会有一些挫败感，之前设计的东西可能会推到重来，之前测试稳定的东西，又死灰复燃，工程师对团队管理者产生了不信任，在心里产生了抱怨－－项目的管理怎么在做?最坏的情况，做出来的项目得不到市场认可，一些有能力的工程师可能对项目，甚至公司的信心会越来越差，最后可能导致人才的流逝。

这样的情况，如果是专门有一个团队，哪怕是1,2个人，在项目初期思考，规划，做这些事情，对一些公共的问题，经常会出问题的争论，做一些系统的梳理，消化好，日积月累，转化为我们的一些设计的经验，对以后整个项目的研发，都会有莫大的帮助。

很多同事说我们是做平台的，一些设计上的细节，这个可以不考虑，那个以后可以让客户去做，其实这里已经埋下了救火的种子。客户最终的需求是满足客户需求的产品尽快的上市，我们不从设计的源头上下点功夫，带来的问题是一系列的：客户可能在过测试时，会报公共的问题，最终我们各个平台，各个项目都要修改一遍；客户迫于市场的压力，可能之前一些模棱两可的问题，我们后期还必须去做设计变更。

如果我们能早点去挖掘这些东西，多考虑一些产品需求的细节，多做一些人性化、易用性的思考，多站在客户的角度，来帮他们实现满足用户的要求来真正做我们的产品，救火式的工作是不是可能会少点？我们整个产品的质量，在客户送测时，也不会经常在相同的问题上被贬（怎么测来测去还是这几个问题，而原本这些问题应该是容易解决的）？最终用户对我们平台的方案的接受性也会越来越高呢？