《构建之法》 第八章需求分析

        作为程序员，拥抱敏捷是一种心态。灵活的接受来自各个方面的需求是我们这种产品多变化，团队小的公司的利器。但是我们也要去注意需求的质量。这里要谈到《构建之法》的第八章，需求分析。

        需求的获取渠道有多种：（请记住上一篇博文的一句话，每一个流程必须要结果）

        1.经验

        2.焦点小组

        3.人类学调查（同吃同住同玩）

        4.快速原型调研

        以上前三个我们都有去尝试，也是做成我司产品的重要需求来源。这里代入一个场景；

        我司星星是一个PM，最近做一个后台管理系统，后端前端。火急火燎的设计开发。老板驱动，写了再改的工作模式。在完成预期目标大部分的情况下，上周交付运营冰冰试用。冰冰反馈问题太多，不合理，想要的东西不出现在想要的地方。星星说：没事产品马上改版。what，我还没写完成，要不你把新的设计给我，我做了？

        上述事件我想说：

        请学会快速原型调研，在产品设计初期，你们可以将设计呈现给用户（如果可以），就像上文的产品设计之初将原型交付运营评审。而不只是给技术评审。这样减少成本与人力的浪费。

        为什么要做这个需求，其实是产品出需求前要扪心自问的。

        技术接到需求的时候，要去计划与估算时间。技术们，请了解目标，估算，决心的不同点。需求的不完善，技术的盲目乐观都会有排期不可控的风险。但是我想说，排期不可控没关系，请如实的报告进度。这才是最重要的，对于我们这样的团队。

        最后，我提议，产品要担风险，整个过程哪一个步骤出问题，你们都要负责，责任人负责，产品也要负责。产品不仅仅是出需求。PM要负责，要有推动力。驱动流程，组织会议，实践敏捷，保证进度。