问题和方案

        大家都知道提出问题重要，解决方案更重要，可是又有多少人真正的去重视和了解提出的问题。

        刚刚加入新的公司，新的团队，对产品和项目了解的都不多。但是随着这段时间的接触，我越来越多的了解了现在的项目。作为这个项目中主要的研发人员，当项目中其他人员给我提出项目修改时，我会问很多相关的问题。甚至会因为一些小小的问题而争论，当同事没有了解这方面的需求时，会给我抛来一句“就按我说的做就可以了”要不就是“这个我不知道，你自己去问吧”。我的确可以去问，的确可以去做，他能做的我都能做，但是如果都是我去做了，也许……也许我就应该拿两份工资了。以上是自己的一点小牢骚，今天主要就是说说问题和解决方案的关系。

        我认为一个成熟的解决方案必须可以解决客户大部分的问题，经不起质疑的解决方案是一个失败的解决方案。一个优秀的解决方案是从问题中提炼出来的。当客户提出需求时，我们可以问以下几个问题：

1）为什么需要？

    只有真正的了解了用户的需求才能制定出真正的解决方案。用户表述的需求也许并不是用户的真正需求。我们需要通过问题了解用户需要解决的现实问题。这部分是需求的一个最最关键的部分。很多你现在做的工作，就是之前这部分工作没有做好的结果。

2）是否已存在功能？

    客户并不真正的了解我们的系统，这需要我们去阐述、讲解。很多需求是可以通过系统的现有的功能来实现的。这就需要我们真正的了解系统、把握系统。

3）是否可实现？

很多客户的需求并不是我们能实现的，对于不能实现的需求，我们要善于说NO。程序员不是万能的，其实他们很脆弱的，伤不起的……作为需求人员在真正的了解需求之前，请量力

4）如何实现？

    不加思索的确定解决方案不是一个聪明的决定。这些年的经验告诉我，在真正敲键盘写代码之前，一定要先动笔写下你的思路，保证思路的清晰，可以让你的编码过程事半功倍。这就像是对于一个项目的概要设计或详细设计，是一个指导性的方针。

5）实现周期？

     这是我们作为研发人员需要确认的事情，只有确定的实现时间才能客户真正的满意。作为研发人员将自己估计的时间*1.5告诉项目经理，项目经理*1.5告诉客户。在项目时间达到1的时候，需要评估是否能够完成，如无法完成，需要提报相关人员。毕竟我们还有0.5的时间进行弥补。

    最后一个原则就是需求不能违背原则，我想这不光是一个需求的问题，这也是一个做人的问题。违背了原则的需求总有一天是会需求修改的，除非用户书面确认不会再需要修改此需求。做人和做事一样，违背原则只会让你走更多弯路。